Mod funktion wrong output

[Nike]

mod("175367809538821201","1767842701") returns 421042353 but its wrong in real its 421042338
why autoit says its 421042353 ?? funny mathematic bug oO

[jchd]

Could it be a sign that Mod() in doing a floating-point computation instead of integral? Sounds like a 56-bit mantissa representation limitation.

Mod(175367809538821167, 1767842701) = 421042289
Mod(175367809538821168, 1767842701) = 421042321
Mod(175367809538821169, 1767842701) = 421042321
...
Mod(175367809538821200, 1767842701) = 421042321
Mod(175367809538821201, 1767842701) = 421042353
Mod(175367809538821202, 1767842701) = 421042353

[Valik]

Yes, the problem is because the operation is being performed as floating point.

[anonymous]

Replying to Valik:

Yes, the problem is because the operation is being performed as floating point.

Do you think it can get changed anytime soon or will it be part of a deeper rework to be expected significantly later?

A workaround can be to code a small dll for 64-bit bitwise ops, Mod() and possibly other functions. Is it worth doing it, since it's very easy?

[Valik]

I have changes made to do it as an int first and fall back onto floating point but I'm not sure at this time if that will be changed in the next release, at a later time or ever.

[anonymous]

Replying to Valik:
OK.
Last thing: are there other _basic_ core function besides bitwise ops and Mod() having a 32-bit int or floating-point limitation right now, that could benefit of a 64-bit int add-on?

[Valik]

I don't know that an add-on would really help the situation. Its kind of something that needs fixed internally and its something that we need to do as soon as possible.

[Valik]

Fixed by revision [5432] in version: 3.3.1.7

[Valik]

This ticket is referenced in revision: [5433]