"You are a great wizard, you know."

me two man , i solve it in the old fashion to find someone did it

I was trying to do the same thing, but for some reason regex just refused entirely to double up the \ character.

"* you really like to challenge yourself, huh...?" - Sans

Well, there is a very good use case for doing this: it is whenever you need to use both the character and its index.

This is some chaotic evil energy

wow

Sometimes passes and sometimes does not pass my submission. Do one or the other. If something should be tested then ensure it gets included. Or if it's your code, whatever it is, something isn't right with that.

Example:

Should throw an error for "13J1HIJJ5[27] * S11SDNPKF3[31] + DEI40275D[20] + 000001010[2] * 3577D[28] / CE5JGGCIH[22] / 00000[2] / 402330[5]" and maybe it's the 00000[2] cause I saw that on a different one and if that's it then it's probably your code. I haven't bothered checking the rest though, could be mine. But then it should as mentioned always fail.

I don't think "run this through eval" is great. It's not.. solving anything. It's just applying eval. Alternatively, without eval it's a duplicate kata with whatever kata it is that does arithmetic expressions and the base thing becomes a trivial addon.

Being shown things like Should return 1.2580056316652936e+28 is not great. It's unclear to me whether that's showing all digits. Maybe it does, but it's still unclear.

The part about float is not very good. Internally it's still floating point operations which then get truncated. There's room for error here with undefined rounding direction in tie situations. Additionally for js specifically it's obviously a float result either way, so that wording is a bit.. weird. It would be better to define / as integer division - obviously that immediately makes it much more difficult than simply passing the whole thing off to eval because that involves figuring out operator precedence in order to replace / with something else, unless of course sending it off to gcc or something. Alternatively never do any rounding and instead tolerate a small difference. Rounding/truncating doesn't make the problem go away, it only moves it.

As for the error part, I added a clarification in the description and adjusted the tests.

"an error should be thrown." should be explained. If an error is a part of a contract, it has to be specified w.r.t. expected type, properties, etc.

In fixed tests, mixing cases with correct solution and with errors in one it is a bad design of tests. These are two separate test cases, and should have separate it-s (or describe-s).

Because the real requirements are specified by the provided tests.

PHP: It should be specified in the description that, if the array has a NaN element, the function should return NaN.

hm... didn't think that such a simple pattern would work. but okay i guess.