Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge Expression Branch #272

Merged
merged 759 commits into from
Apr 27, 2018
Merged

Merge Expression Branch #272

merged 759 commits into from
Apr 27, 2018

Conversation

whart222
Copy link
Member

@whart222 whart222 commented Dec 5, 2017

This PR can be referenced to discuss issues that need to be resolved to merge the expressions branch: expr_dev.

Dependencies:

1. Created a RangedExpression, and simplified the logic
in InequalityExpression.  Now, inequality expressions always
have two arguments, and ranged expressions always have 3.  This
cleans up a lot of code, and it simplifies the semantics of
constraint management with expressions.

2. Migrated logic for detecting chained expressions into a
separate class (_chainedInequalities) rather than annotate
the InequalityExpression class.
Following the update to expressions to use
RangedExpression, this commit uses the
_chainedInequality global data and explicitly recognizes
RangedExpression objects.
Removing expressions of the form:

  lower <= body <= upper

Using the tuple notation, which is
more robust.
In the kernel, we explicitly construct a ranged
expression rather than use chained inequalities.
Added tests that this generates ranged expressions.
Using the inequality() function, and updating
baselines.
The bounds_to_vars transformation was modified slighty,
since the standard repn doesn't include coefficients that are zero.
Hence, such constraints are ignored.
If a nonmutable param is uninitialized, accessing its value returns
an exception.  Hence, the logic for parameter access was modified in
several places.
Resolving changes due to the merge:

1. The param semantics changed with uninitialized parameters

2. A change in semantics for a transformation, based on the new
representation logic.
The isclose() function is not available in Python 3.4
@codecov-io
Copy link

codecov-io commented Apr 26, 2018

Codecov Report

Merging #272 into master will decrease coverage by 2.03%.
The diff coverage is 88.41%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #272      +/-   ##
==========================================
- Coverage   65.97%   63.94%   -2.04%     
==========================================
  Files         488      354     -134     
  Lines       63228    59572    -3656     
==========================================
- Hits        41715    38093    -3622     
+ Misses      21513    21479      -34
Impacted Files Coverage Δ
pyomo/core/kernel/component_interface.py 100% <ø> (ø) ⬆️
...o/core/kernel/component_piecewise/transforms_nd.py 100% <ø> (ø) ⬆️
pyomo/core/kernel/component_map.py 100% <ø> (ø) ⬆️
pyomo/core/base/util.py 100% <ø> (+3.84%) ⬆️
pyomo/core/kernel/component_dict.py 100% <ø> (ø) ⬆️
pyomo/core/expr/expr_pyomo5.py 97.99% <ø> (ø)
pyomo/core/kernel/component_tuple.py 100% <ø> (ø) ⬆️
pyomo/core/kernel/component_list.py 100% <ø> (ø) ⬆️
pyomo/core/kernel/component_set.py 100% <ø> (ø) ⬆️
pyomo/core/kernel/component_piecewise/util.py 95.69% <ø> (ø) ⬆️
... and 256 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bc89b21...e92309d. Read the comment docs.

blnicho
blnicho previously approved these changes Apr 26, 2018
Reordering a multiplication in the standard repn
Added another check for a simple product with a constant.  This
was needed after removing the tacit assumption of ordering
within product expressions.

This "bug" led to a significant degredation in runtime in the uc1
test problem.
1. Clarified the semantics of is_potentially_variable()

    If this method returns False, then there are no variables
    in the expression.  But if it returns True, the expression
    may still not have any variables.  This allows for performance
    optimizations in cases where expressions are likely to be
    variable.

2. SumExpression.is_potentially_variable() returns True

    This is the typical case, so this provides a modest
    improvement in runtime (e.g. 3% improvement writing the
    uc1 nl file).
Pyomo5 expressions print integer values when possible
Gabe has a nice example illustrating why the new semantics
didn't make sense.

I updated the documentation to account for John's description
of this method.
_ampl_repn was renamed to _repn
@whart222
Copy link
Member Author

Can someone re-review this PR so I can merge? I'm awaiting test results, but they're looking good so far.

@ghackebeil
Copy link
Member

@whart222: Either before or after you merge, can you remove the 'pyomo5_expected_failures test categorization stuff from PySP. I've verified that all of those tests pass locally, and I imagine they haven't been running on Travis because of this categorization.

@whart222
Copy link
Member Author

Thanks. I'm going to leave these in. I'm about at the point where I have clean tests, and I want to be able to merge soon.

@whart222 whart222 merged commit 996e0a8 into master Apr 27, 2018
@whart222
Copy link
Member Author

I created the branch master_at_exprdev_merge immediately before merging this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Design of Pyomo expressions with kernel subclasses
7 participants