Sum and Product evaluates zeros and ones

[legendre6891]

Right now, the Sum and Product primitives do a little bit of calculation on their own. For example, Sum(<anything>, 0) === <anything>. Unfortunately, this process is already carried out in parse so the user can't intervene:

parse(A + 0) = Variable(A) and parse(A * 1) = Variable(A)

This makes the implicit assumption that 0 is always the identity corresponding to the operator denoted by +, and that 1 is always the identity corresponding to the operator denoted by *.

This assumption doesn't always hold (example).

Can you add an option to parse so that parse(A + 0) come out to be Sum(Variable('A'), 0)?

[inducer]

Hmm. So my whole reason for starting pymbolic (and not using sympy) was because sympy made 'too many assumptions' and 'did too much stuff' to my expressions behind my back. So it's kind of ironic (and a little embarrassing!) to me that it now appears to have gotten caught in the same thing. Fortunately, it doesn't do anything of that nature in the constructor, it's just the operator overloads that pretend they know what they're doing--and that's what the parser uses.

Based on this, my vote would be get the operators used to the idea that they can't assume that x + 0 == x and x * 1 = x. I'd be happy to take a pull request that does that.

[dokempf]

I just stumbled over the mismatch between the operators and the constructor as well. To be honest, I would prefer the constructor to do the same thing the operators do as I would need to implement the same thing wrapped around otherwise. Then again, I am very far away from tropical geometry...

[inducer]

Could you use flattened_sum and flattened_product instead of the constructor? Those do simplify, and I'd prefer to keep the constructors non-simplifying.

[dokempf]

I didnt know about these, they perfectly fit my use case. Thanks!

[inducer]

I think this was closed by accident via a Gitlab issue close.

cc @kaushikcfd