Objects that know how to combine themselves

[asmeurer]

This is related to issue #5007 . When I met with Ondrej last summer, we worked on a core where
objects knew how to combine themselves with respect to Mul and Add. See the handler branch at http://github.com/certik/sympyx/ . The idea originally stemmed from issue #4435 , but we soon
discovered that it also simplifies the logic for things like O() (the order function), and oo, which
combine abnormally with respect to Mul and Add. This could also be useful for issue #5039 , so that
the units could tell Mul that they need to stay together without Mul explicitly having to know about
units. Right now, Mul.flatten is cluttered with code for handling all these things, and the only way
to handle additional classes is to either completely separate them from Basic (as with Poly), or to
add more special case code in Mul.flatten.

Anyway, if we ever rework the core as suggested in issue #5007 or elsewhere, we should also look
into doing this too.

Original issue for #5040: http://code.google.com/p/sympy/issues/detail?id=1941
Original author: https://code.google.com/u/asmeurer@gmail.com/
Referenced issues: #4435, #5039, #5007

[asmeurer]

**Blockedon:** 4983  

Referenced issues: #4983
Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c1
Original author: https://code.google.com/u/asmeurer@gmail.com/

[asmeurer]

**Blocking:** 4959  

Referenced issues: #4959
Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c2
Original author: https://code.google.com/u/asmeurer@gmail.com/

[mattpap]

**Blocking:** -1860  

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c3
Original author: https://code.google.com/u/101069955704897915480/

[asmeurer]

**Labels:** CodeInCategory-Research CodeInDifficulty-Hard  

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c4
Original author: https://code.google.com/u/asmeurer@gmail.com/

[mattpap]

**Owner:** ---  

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c5
Original author: https://code.google.com/u/101069955704897915480/

[asmeurer]

**Labels:** CodeInImportedIntoSpreadsheet  

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c6
Original author: https://code.google.com/u/asmeurer@gmail.com/

[rlamy]

Issue 576 has been merged into this issue.

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c7
Original author: https://code.google.com/u/101272611947379421629/

[asmeurer]

**Labels:** -codeinimportedintospreadsheet CodeInImportedIntoMelange  

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c8
Original author: https://code.google.com/u/asmeurer@gmail.com/

[asmeurer]

**Blocking:** 6220  

Referenced issues: #6220
Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c9
Original author: https://code.google.com/u/asmeurer@gmail.com/

[asmeurer]

**Status:** Valid  

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c10
Original author: https://code.google.com/u/asmeurer@gmail.com/

[asmeurer]

**Labels:** DeprecationRemoval  

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c11
Original author: https://code.google.com/u/asmeurer@gmail.com/

[asmeurer]

Oops.  That should be issue 4590 .

**Labels:** -DeprecationRemoval  
**Blockedon:** -sympy:1884 -sympy:1908 sympy:1884 sympy:1908  

Referenced issues: #4590
Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c12
Original author: https://code.google.com/u/asmeurer@gmail.com/

[asmeurer]

See https://github.com/sympy/sympy/wiki/Canonicalization for some more discussion on this.

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c13
Original author: https://code.google.com/u/asmeurer@gmail.com/

[asmeurer]

**Labels:** -CodeInImportedIntoMelange  
**Blocking:** -sympy:1336 -sympy:3121 sympy:1336 sympy:3121  

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c14
Original author: https://code.google.com/u/asmeurer@gmail.com/

[Krastanov]

It does not make sense for GCI anymore.

**Labels:** -CodeInCategory-Research -CodeInDifficulty-Hard  

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c15
Original author: https://code.google.com/u/100157245271348669141/

[asmeurer]

It just occured to me that this same kind of idea could be applied to the printer. For example, at #1788 , we special case Function, Atom, and Operator in print_Pow, making everything else use parentheses. But what if some object wanted to define it's own power printing representation. What is needed is a way for it to consistently say, "object A should print like this when it contains me".

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c16
Original author: https://code.google.com/u/asmeurer@gmail.com/

[mrocklin]

Sets know how to combine themselves with pairwise intersections and unions. It really does simplify the canonicalization process and greatly improves extension.

See any ._intersect and ._union methods in sets as well as Union.reduce and Intersection.reduce

Original comment: http://code.google.com/p/sympy/issues/detail?id=1941#c17
Original author: https://code.google.com/u/109882876523836932473/

[eric-wieser]

Is the Basic._constructor_postprocessor_mapping machinery related here?

[asmeurer]

Yes, that is currently the best method for doing this, although that API is still considered experimental, and I'm not yet convinced there isn't a more elegant way.

[asmeurer]

There's a question if we can use multiple dispatch #14490. It's not straightforward because Add and Mul take an arbitrary number of arguments.

[eric-wieser]

I've found _constructor_postprocessor_mapping is a little unreliable, because a lot of sympy seems to use Mul._from_args which bypasses the postprocessors. My use case in a branch of https://github.com/pygae/galgebra is much like the MatExpr one that's used internally, where I need to define extra attributes / operator overloads, and want them to stick around after addition.

[asmeurer]

Yeah, we should remove _from_args from places outside of the core. See for instance #19083. The use of _from_args predates the processors, and it wasn't until recently that the processors were even used for anything useful (the matrix expressions), so we are still ironing out issues.

I should also note there is a suggested extension of the API here #18769.

[mcpl-sympy]

@eric-wieser
I am glad to see that someone else is intersted in this matter. Seeing that this issue has been open for (exactly) ten years, I think it's about time to roll up the sleeves and get it done.
I opened a discussion page in google groups. Please take a visit and leave your opinion.

Also ping @asmeurer