An open discussion on improvements to 'simplifyConstant'

[samueltlg]

As discussed in various repo past discussions (#2817) and PR's (such as #2827), function simplifyConstant has some remaining limitations in both default and non-commutative contexts.

In default contexts, a current known issue is regarding the simplification of multi-arg. associative exprs. involving string constants, such that constant op. evaluation remains incomplete for these. For example:

simplifyConstant('2 + 7 + "foo" + 3 + 8')  === '9 + "foo" + 11'  // rather than '20 + "foo"'

More remarkably, within non-commutative contexts, there are currently an extra quantity of similar incomplete expr. simplification examples, such as:

simplifyConstant('a + 2 - 2') === unchanged
simplifyConstant('b + 4 - 2 - 1 + b') === unchanged
simplifyConstant('c * 6 / 3') === unchanged
simplifyConstant('c * 1 / 1 * 3 * d') === unchanged

In all of the above non-commutative scenarios, these expressions are constituted by constant sub-expressions which include commutative operations (addition, multiplication) and their inverse operations.
These exprs. simplify as expected when passed directly to simplify, due to the benefit of standard simplify rule application.
Simplification occurs as expected here because the expr. benefits from 'flattening' of non-commutative ops. (e.g. via rules including n / n1 -> n * n1 ^ (-1) and n - n1 -> n + -n1).Technically, for these cases then, it appears that the limitation of simplifyConstant is its inability to flatten these commutative-op. inverse operations, and therefore simplify these entire expressions as a single, flattened (associative) expression able to benefit from the evaluation of constant sub-expressions within (such as 2-2 within a + 2 - 2).

This open discussion acts as a place to discuss ideas on how to approach these scenarios; notably in no particular hurry!

[josdejong]

Thanks for collecting and sharing these examples,

simplifyConstant('2 + 7 + "foo" + 3 + 8')

This example is probably caused by mathjs trying to evaluate addition with a string by converting the string into a numeric value, and not by concatenating them as strings. If you do simplifyConstant('2 + 7 + "123" + 3 + 8'), the output is a ConstantNode with value 143 .

It indeed feels like simplifyConstant should be able to simplify 'a + 2 - 2' into a since it is "just" two constants. It is indeed related to flattening and normalization, which is done in simplify by the rules you mention. I'm not sure what we would win exactly by improving simplifyConstant to handle that logic too. Do you see added value of that?

[samueltlg]

Hi Jos - no issue.
I also feel regarding the second point that there is not much to be gained per se; mostly because the desired/full constant simplification behaviour here can be achieved by calling simplify with simplifyConstant and any required 'flattening' rules as part of the ruleset.
I guess though that having simplifyConstant being able to fully simplify constant expressions as the aforementioned would be staying more true to its name. So maybe something to backlog; unless there is an easy implementation which does not involve op. flattening via rules which comes to mind?

The first point I imagine of evaluating non number-equivalent strings is likely an edge case too. I suppose something of not the highest priority but nonetheless possibly something reasonable that it should be able to do 👍

[josdejong]

Yes that makes sense, having simplifyConstant being "full featured" on it's own.

It is good though to keep in mind that simplifyConstant was not a goal in itself so far. We developed simplify with the rule-system, and then there grew two dynamic rules out of it: simplifyCore and simplifyConstant. These two rules are now standalone functions and useful on their own. I think though that we should not implement another rule-system inside simplifyConstant, but if we can add a bit of logic to make simplifyConstant more powerful on it's own that would be nice of course.

[samueltlg]

Yes! I did imagine that what you have described there has been the progression in terms of 'simplify' branching out.
None of these points are personal requests of mine, and so I am not imposing any kind of demand that these two main opening points be addressed (any time soon).
Regarding your thoughts written there too - yep it makes sense not to re-implement a rule-application procedure (again) within here.
Maybe over time a simpler solution will come to mind? (I'm sure that there is one!)