Changes between Version 1 and Version 3 of Ticket #20461


Ignore:
Timestamp:
04/22/16 23:24:50 (6 years ago)
Author:
mkoeppe
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #20461 – Description

    v1 v3  
    1 Even after merging #20414, both `copy` and (the identical) `deepcopy` have weird semantics in relation to the `MIPVariable`s in a problems -- because a MIP does not have an API to gain access to its variables; and trying to use the old `MIPVariable`s with the copy is questionable and definitely broken if one creates new components of this variable, see #15159, #19523. Same when there's no explicit `MIPVariable` and only the `_default_mipvariable` is used via the problem's `__getitem__` method.
     1Even after merging #20414, both `copy` and (the identical) `deepcopy` have weird semantics in relation to the `MIPVariable`s in a problems -- because a MIP does not have an API to gain access to its variables; and trying to use the old `MIPVariable`s with the copy is questionable and definitely broken if one creates new components of this variable, see #15159, #19523. Same when there's no explicit `MIPVariable` and only the `_default_mipvariable` is used via the problem's `__getitem__` method:
     2
     3{{{
     4sage: sage: p = MixedIntegerLinearProgram()
     5sage: p[0]
     6x_0
     7sage: q = copy(p)
     8sage: q[0]
     9x_0
     10sage: q[1]
     11x_1
     12sage: sage: p.number_of_variables()
     132
     14sage: sage: q.number_of_variables()
     151
     16}}}
    217
    318Here's a possible fix without having to change the whole design: