This is a really nice one 😎 , thanks Glen!

I see some unit tests are breaking, probably because I just merged #2394. Can you have a look at that?

Yes, the changes from #2394 made it necessary to move simplifyConstant later to be sure to be able to collect up al the constants being shed by moving terms around. So this should now be safe to merge. My only concern about it is that it now greatly increases the simplifications that might be done that are not actually valid for all real numbers (basically, canceling things in the denominator can increase the domain of an expression). Would it be good to settle on a plan and resolve #2391 before merging this?

Would it be good to settle on a plan and resolve #2391 before merging this?

That sounds good 👍

Added WIP tag, as this will be rebased and modified to take advantage of the new features when #2399 is finalized and merged, so this should not yet be merged.

Updated to use assumption marking from #2399. Should now be good to merge. Removing "WIP" from title.

Because it's listed as resolving #1423, I expected the following to pass on this branch, but all fail:

  it('factor out common terms', function () {
    simplifyAndCompare('6x / 3x', '2')
    simplifyAndCompare('-28k / -4k', '7')
    simplifyAndCompare('-28 * (k / -4k)', '7')
  })

I keep wondering if, rather than a long list of heuristics, simplification could be implemented in terms of fundamental properties of the various operations. E.g. we know that 1/1 -> 1 because the identity property for division means x/1 -> x, and we know that b + a -> a + b because of the commutative property of addition. And then by performing a search that seeks lower complexity expressions (rather than just iterating the rules until they stop changing anything) perhaps a wider range of expressions could be simplified with simpler code.

It also strikes me that in many ways a binary tree is not an ideal representation for mathematical operations, as it obscures groups which could be commutatively rearranged or regarded as equivalent---so the code must twist itself around the tree structure rather than benefiting maximally from it.

I'll take a look right away at your examples. As far as your suggestion of searching for lower complexity based on properties like commutativity/distributivity/etc., that proposal is there in the issues and we do intend to follow it up. The difficulty is that there is a combinatorial explosion of possible simplification paths, so such a search must be controlled tightly. The unfortunate fact is that simplification to the least complex form is known under fairly mild assumptions to be intractable (I forget whether NP-hard or even uncomputable, at the moment) so I am afraid there is a significant art to it (just look at the simplify facilities in other CASes) so I suspect we will be eternally stuck with a fair amount of heuristic. That doesn't mean that we can't do a pretty good job -- certainly your examples should simplify -- but I do think there will always be edge cases.

OK, I have added all three tests as you specified (without any other changes, see the latest commit) and they all pass. Perhaps there was some issue with how you were performing your tests or checking out this branch? Thanks for your investigations!

Thanks again Glen, looks good. Merging the PR now.

These fixes are published now in v10.2.0 🥳