.Simplify() seems confusing or inconvenient

[AlekseyCherepanov]

I find .Simplify() method quite inconvenient: it is not a part
MathObject, it is a part of Sum and Product classes (and maybe some
others). It'd be more convenient to call it through general interface.

On the other hand, .Simplify() is not needed usually because Symbolism
simplifies automatically. It is needed if one changes .elts list
directly (there may be an Exception on following manipulations without
the simplification). Moving it to the interface may cause assumptions
that it is intended for regular use.

This bug report shares my concerns and documents observations. I don't
insist that it is a defect.

[gregsdennis]

I think that for full support of printing, perhaps .Simplify() should not be called internally at all. For instance, I think it may be useful to print 4+5 without it being simplified to 9.

I agree, however, that it should be a base MathObject method.

[gregsdennis]

Exploring it a bit more, there may be certain scenarios where .Simplify() should be called internally. For example, when evaluating comparisons, it would be a computation saver to simplify the expressions and compare the results.

But, I think the library would be faster if it weren't simplifying all of the time. I may be able to set up some benchmarks.

[cdrnet]

Just for the record, automatic simplification to a well-defined standard form is common practice and massively simplifies code almost everywhere if you can safely assume it always has standard structure. We do this as well in Math.NET Symbolics, and to my understanding most full CAS do this.

[gregsdennis]

I'm reminded of my TI-89 calculator in college that would output both the entered expression and a simplified version (see below). I believe that outputing an unsimplified version should be supported.

[gregsdennis]

It would also facilitate testing a bit better if we could be certain that the desired functionality was actually taking place. For instance, we can't properly test the .AlgebraicExpand() extension method if everything is simplified before equality is tested.

Consider this test:

AssertIsTrue(
    ((x + 2) * (x + 3) * (x + 4)).AlgebraicExpand()
    ==
    24 + 26 * x + 9 * (x ^ 2) + (x ^ 3));

If the == operator simplifies each side at evaluation, we don't know that the expand actually worked; we only know that the two sides simplify to the same expression. It may be argued that the equivalence is what matters, and from a math point of view, that's correct, but from a computer science point of view, we need to ensure the method does what we intend.

It seems we need a concept of structural equivalence as well.

[gruckion]

I agree. Simplification is needed to compare expressions. Specifically computational of the canonical form is needed.

However automatically simplification cases issues with the expected MathObject you get back, which is a problem for testing.

The solution here I believe is to remove the automatic simplification. But rather call into a function to do the simplification step.