This is a big deal: without negative numbers (or unary minus), one can use a much, much simpler parser.

I modified the test cases so they accept the alternative forms of differentiating tan (C#, Java and JavaScript language versions).

In my case, saying which of the two ways of differentiating tan was expected would have helped.

TBH I'm surprised I didn't run into issues with the ordering of chain/product/quotient rules... or maybe it just didn't come up.

If you look at the sample tests those are the expected forms.

I would "simplify" (- 0 (sin x)) to (* -1 (sin x)) because usually you dont put unecessary 0 in the result expression.
And (^ (cos x) -2) is the same as (+ 1 (^ (tan x) 2)) which is what the tests expect.

I will see if I can make it more clear what to simplify and to look at the tests for guidance.

language?

The tests reject correct derivative forms such as (- 0 (sin x)) for the derivative of (cos x), or (^ (cos x) -2) for the derivative of (tan x). Similar problems arise from a choice of ordering of terms in the product when taking the derivatives of exp, sin, cos etc.

The expected forms should be stated explicitly, or there should be a set of canonical simplifications that the solutions and tests can both apply in order to validate the results. Generally, this is going to be 'hard', especially for
trigonometric identities.

Made a new solution based on this one which fixed up the untidy std::string reference/initialization on solve_state - which of course I only noticed after submitting.

Doesn't this have a problem with e.g. v = {3, 4}; s = {5, 0}?