resolving issue

I agree, I almost want to redo the whole thing by this point and refactor extensively.

Seems to work.

ETA: I just saw how you fixed it. Man, that's ugly. :S

updated with assertApproxEquals, i think it must not have saved the last time. Cheers for the help

ok ive changed it so if the input is a string which is only a number and no operators, it just returns the string

I don't know what error you fixed, but that was not this issue. This issue was strictly to do with very small errors and is fixed with assertApproxEquals.

The other error (see above) is not fixed (or was actually introduced), but I had not even found that yet.

input: "1222"

Expected actual value 1222 to approximately equal expected value 0

The reference solution has a bug.

Cheers, updated once I found the error. shouldnt fail random tests now. Also updated the random tests to assertApproxEquals as suggested

Or in this case it may be better to forbid reordering? Compilers and interpreters usually don't reorder even mathematically commutative and associative operations with default options.

When comparing floating point Number values, use assertApproxEquals instead of assertEquals.

I got inconsistent fails in the random tests, because my answer was off by very small amounts, probably because I did not replicate the exact order of calculation of the reference solution.

Expecting inconsistent data types as a return value is not a best practice.

There is a perfectly good Number to return for invalid input: NaN.

Also, the description doesn't mention input validation at all, it's a task separate from doing maths, and it's not necessarily simple (or at least as simple as doing the math).

updated for Function, will look at the others

Thanks I'll see what I can do

One problem down. Thank you