Skip to content

[PEP] Remove ConstraintData.equality #2105

Open
@jsiirola

Description

@jsiirola

Summary

Deprecate the ConstraintData.equality property.

Rationale

#2093 and #2097 highlighted confusion as to the meaning of ConstraintData.equality. There are (at least) 3 interpreatations of "equality":

  1. Was the Constraint initialized with an EqualityExpression object (as opposed to an InequalityExpression or RangedExpression)?
  2. Does the ConstraintData represent a "structural equality"; that is (1) plus RangedExpression where the upper and lower bounds are symbolically equal?
  3. Does the ConstraintData represent a "numerical equality"; that is (1) plus RangedExpression where the upper and lower bounds are have equal value()?

Looking through the code base, there is not real consistency ... some places assume equality means case (1) (primarily transformations), and others (primarily writers) assume something closer to (3). As this is confusing (and not something easily rectified), this PEP proposes:

  • restore the current definition of equality to interpretation (1) (i.e., restore it to very close to the Pyomo 5.7 meaning)
  • deprecate the equality property altogether.

Removal of equality is no longer a significant burden to the end-user, as ConstraintData objects now preserve the original expression returned from the rule. As a result, interpretation (1) can be implemented as:

equality = isinstance(con.expr, EqualityExpression)

and interpretation (3) is:

equality = con.lb is not None and con.lb == con.ub

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions