Opened 6 years ago

Last modified 6 years ago

#20461 closed defect

Fixes for copying a MIP and its variables — at Version 1

Reported by: mkoeppe Owned by:
Priority: major Milestone: sage-7.3
Component: numerical Keywords: lp
Cc: dimpase, vdelecroix, jdemeyer, nbruin, chapoton Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by mkoeppe)

Even after merging #20414, both copy and (the identical) deepcopy have weird semantics in relation to the MIPVariables in a problems -- because a MIP does not have an API to gain access to its variables; and trying to use the old MIPVariables 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.

Here's a possible fix without having to change the whole design:

  • a new MixedIntegerLinearProgram.copy method that takes a names keyword argument, enabling this operation:
    sage: p.<x,y> = MixedIntegerLinearProgram()
    sage: q.<newx,newy> = p.copy()
    

and the less magical syntax

sage: q, newx, newy = p.copy([x, y])
  • copy and __copy__ (and __deepcopy__) should make a copy of _default_variable (this requires writing a __copy__ method for MIPVariable)
  • if MixedIntegerLinearProgram.new_variable has been called, it should set a flag and then if __copy__ (or __deepcopy__) are called, it should display a warning (deprecation??) and refer the user to the new copy method.

Change History (1)

comment:1 Changed 6 years ago by mkoeppe

  • Description modified (diff)
Note: See TracTickets for help on using tickets.