Remove expression _args_ tuple

[jsiirola]

Fixes # .

Summary/Motivation:

@bknueven reached out a couple months ago pointing out that the recent work to standardize the internals of the expression system (and in particular, that LinearExpression should more directly inherit from SumExpression) had the indirect effect of tripling the memory used by a LinearExpression object:

I traced the issue we are having with constraints and memory, and I think it goes back to changes made to LinearExpression a few years back. When I calculate the memory needed to store a single (coefficient, variable) entry in a LinearExpression object, I come up with 120 bytes per-entry for our use case:

MonomialTermExpression : 40 bytes
    MonomialTermExpression._args_ : 40 bytes
          pointer-to-Pyomo-var: 8 bytes
          pointer-to-Python-double: 8 bytes
                    Python-double: 24 bytes

Blow this up to 40000 entries per row and a few hundred rows, and we’re in GBs of memory.

In the old implementation, LinearExpression would store two lists, which for the marginal entry in this use case would cost only 40 bytes instead of 120 bytes.

@bknueven's request was to revert the LinerExpression storage model back to using a pair of lists. The challenge there is that the "pair of lists" model doesn't gracefully handle incrementally building LinearExpression objects through the normal operator overloading process (in large part because of challenges with handling constants that appear within the summation) -- and the fact that Pyomo's expression system now "automatically" recognizes and creates LinearExpression objects is a big part of the benefit from that previous rewrite.

As a result, this PR does not re-implement the "pair of lists" data structure (nor does it resolve all the memory degradation). Instead, it proposes a compromise that removes the _args_ tuple from MonomialTermExpression (and all other Expression objects). Storage now depends on the Expression object:

• unary operators store the single argument in the _arg attribute
• binary operators store the arguments in the _l_arg and _r_arg attributes
• some specialized ternary operators (e.g., Expr_IF) store the operands in named attributes
• n-ary operators continue to store the arguments in either a tuple or list as the _args attribute.

This reduces the marginal memory overhead from 120 bytes/entry to 80 bytes per entry.

It also significantly improves model creation time (and marginally improves the lp and nl writers). In my opinion, the slight performance degradation in the GAMS writer is OK, as that writer needs to be completely redesigned (to bring it in line with the current LP/NL writers).

Changes proposed in this PR:

• remove standard _args_ attribute from all expression classes
• implement custom (tuple-free) storage solutions for 1, 2, and some 3-operand expression nodes.
• standardize the CP expression system to leverage / reuse more of the infrastructure developed for the numeric expression system
• remove most (but not all) instances of accessing private argument attributes outside of the class that defines them (and the core expression generation callbacks)
• clean up some inconsistencies between numeric and boolean expression systems (e.g., value should be a property)

AI-Use Disclosure

• AI tools were NOT used during the preparation of this PR

or

• AI tools contributed to the development of this PR

  • AI tools generated documentation (including the PR description/comments, code comments, and/or Sphinx documentation)
  • AI tools generated tests (baselines, examples, and/or code)
  • AI tools generated code (apart from tests)

  Review process (select ONE):

  • Rewritten: All AI-generated content was rewritten by me before being committed.
  • Reviewed/verified: I retained AI-generated content and verified it before committing. Verification included (as applicable):
    • Ran the code and fixed issues
    • Added and ran tests
    • Checked correctness/logic of code and tests
    • Checked for alignment with the contribution guide
    • Considered security implications
  • As-is: AI-generated content was commited directly to the repository

Notes for reviewers (optional):

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[jsiirola]

I do think there there is still a need / use for a more memory-efficient expression object for @bknueven's use case, but I think that should be done separately (probably through a re-thought MatrixConstraint expression object).

[codecov]

Codecov Report

❌ Patch coverage is 95.59585% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.14%. Comparing base (e099f64) to head (2788171).

Files with missing lines	Patch %	Lines
pyomo/core/expr/numeric_expr.py	94.79%	5 Missing ⚠️
pyomo/core/expr/boolean_value.py	70.00%	3 Missing ⚠️
pyomo/core/expr/logical_expr.py	95.12%	2 Missing ⚠️
pyomo/core/expr/template_expr.py	89.47%	2 Missing ⚠️
pyomo/contrib/appsi/solvers/maingo_solvermodel.py	50.00%	1 Missing ⚠️
...ib/cp/scheduling_expr/step_function_expressions.py	97.05%	1 Missing ⚠️
pyomo/core/base/expression.py	92.30%	1 Missing ⚠️
pyomo/core/expr/expr_common.py	83.33%	1 Missing ⚠️
pyomo/core/expr/relational_expr.py	95.65%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4022   +/-   ##
=======================================
  Coverage   90.14%   90.14%           
=======================================
  Files         917      917           
  Lines      109261   109233   -28     
=======================================
- Hits        98494    98472   -22     
+ Misses      10767    10761    -6     

Flag	Coverage Δ
builders	29.14% <50.25%> (+0.02%)	⬆️
default	86.14% <95.59%> (?)
expensive	35.11% <60.62%> (?)
linux	87.67% <95.59%> (-1.98%)	⬇️
linux_other	87.67% <95.59%> (-0.01%)	⬇️
oldsolvers	28.07% <57.51%> (+0.02%)	⬆️
osx	83.12% <95.33%> (-0.01%)	⬇️
win	85.44% <95.33%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mrmundt]

Feels a bit redundant to the main description 😛

[jsiirola]

Yup - it is. But I was just copying the docstring from ExpressionBase. Fixed in both places.

[mrmundt]

Isn't it 6.10.2.dev0?

[jsiirola]

This branch predates the 6.10.1 release. <sigh>

[mrmundt]

I found two other typos, so sorry, nag nag nag.

[mrmundt]

I am officially good with this and will probably not nitpick anymore.