Forums Bug Reports "==" if operator bug with long numbers

Noticed a little bug with the "==" if operator and long numbers:

Even though the numbers aren't the same, it still claims it's a match. Tried it on mIRC 7.43 and 7.44, both gave the wrong answer.

225559219690881181
225559219690881185

Changing the last numbers to letters makes it work like it should, adding more numbers doesn't. It seems to check the first 16-17 numbers and stop, unless there's letters after those numbers.

Same thing happens with "isnum" operator.

This is not a bug per se, because as far as mIRC is concerned, those numbers are in fact the same. Internally, mIRC stores numbers as IEEE745 64-bit floating point numbers ("doubles"), which are supported natively by your CPU, but allow accurate representation of integers "only" up to 2**53, which your examples exceed. This limitation can be found throughout all parts of mIRC that involves parsing strings as numbers. A simple example is $calc: $calc(225559219690881181) and $calc(225559219690881185) both return 225559219690881180.

mIRC could implement support for arbitrary-precision numbers, but this would come at the cost of performance for pretty much everything involving numbers. Alternatively, you as a scripter can work around some of these issues. In your use case, you can force mIRC to not interpret such strings as numbers, e.g. by prefixing them with some text:

Technically it's not a bug when it comes to "isnum" operator, but why does the "==" operator interpret the strings as numbers? Shouldn't it by default treat them as whatever random text you throw at it, why does it "randomly" start interpreting the strings as numbers?

If I wanted it to treat the strings specifically as numbers, I'd use the "isnum" operator. I kind of expected "==" operator treat the strings "normally."

Presumably to allow, say, "1" and "1.00" to be regarded as equal. It's a design choice that at this point can no longer be changed without breaking existing scripts..