||Adding myself as a developer.
||Added documentation for SOSConstraint objects.
||Fixes bug in error-catching routine. Previously, errors were raised
via `raise some_string', rather than `raise some_exception,
||Changes to allow Block objects to contain other Block objects.
Added `self.domain = None` in Block.__init__ as a temporary workaround
to ticket #4108.
Changed logic in _setattr_exec to avoid infinite recursion when
assigning Block objects to Block objects.
Clarified logic in __setattr__.
||The `cpxlp` writer did not allow constant objectives to be printed
out, which precluded solving feasibility problems. Changed the
behavior to output "obj: +0.0 ONE_VAR_CONSTANT" since that dummy
variable was already acting in a similar fashion as a placeholder for
empty constraint blocks.
Note that this does introduce "ONE_VAR_CONSTANT" as a 'variable' in
the result object of problems involving constant objectives. If this
should cause issues with users parsing the result objects, we can
teach them to ignore "ONE_VAR_CONSTANT" entries.
||Fixes bug in Pyomo reading unbounded/infeasible solution files from
Bug fixed as a side effect while formatting code to fix the bug,
indicating that it was likely caused by a poorly-indented `raise`
statement, or some other source of an Exception that was resolved via
It is worthwhile here to note that our solution may still read as
'infeasible' when the problem is in fact known to be unbounded; this
is due to GLPK's presolver, and short of turning off GLPK's presolver
this is beyond Pyomo's abilities to fix.
||Reverting previous change to give a better commit message...
||Fixes parsing error on infeasible/unbounded problems.
Not actually sure exactly what fixed the problem; I started by making
the indentation uniform so my editor could play nicely with the code,
and the error went away, suggesting that a 'raise' statement was
poorly aligned in the original code.
||Bug fix in error message.
||Fixes an apparent bug.
Before, arithmetic operations on expressions were defined to operate
in-place, which causes issues when manipulating expressions. For example,
> foo = model.X + model.Y
> for x in xrange(0,10):
> print foo + model.X
would in fact manipulate the expression foo. As this is believed to be
undesirable (and was motivated by a specific use case, namely model
transformations) it has been changed to return a clone of the
expression in question.
One test case failed as a side effect of this change, and a correction
was made to resolve this. This correction was also inside expr.py. The
problem was that the ._nargs attribute of _SumExpression objects was
not copied on .clone() calls. This has been changed. NOTE: it is not
known whether a similar fix must be made to product expressions. No
test cases are failing now, but this must be resolved.