For a forthcoming article in xDev I had to use the Mod function and came across an interesting problem:
From the Xojo documentation:
result = number1 Mod number2
The Mod operator divides number1 by number2 and returns the remainder as result. If either number1 or number2 is a floating-point type, it is first coerced to Int32. If either number1 or number2 is an Int64, then both values are promoted to Int64.
Result is an Integer, and should be a 64 bit integer on a 64 bit system. Testing revealed that the coercing to 32bit Integer rule takes precedence over promoting to 64bit Integer.
But why would the double be coerced into a 32bit integer on 64 bit systems? That just screams overflow error!
Basically you are running into a 32 bit limitation on a 64 bit system.
Have Xojo forgotten to update this when they moved to 64 bit?
And now don’t have a compiler guy anymore to fix it?
They do most stuff themselves. e.g. William does a few things. And I bet they have the staff to find the conversion from double to Int32 in the code generating the Intermediate Representation for LLVM for a MOD operation and change it to Int64.
by the way, I don’t use mod often. And even less often with double as input. This is not an issue affecting a lot of people.
The basic problem is that under a 32 bit system a Double can represent a MUCH larger range of integers accurately than an Integer can. So a LOT of code used Double instead of Integer to avoid integer overflows:
The maximum value of “whole numbers” that can be accurately represented:
On 32 bit systems it made some sense to cast to a 32 bit integer even though I would argue it would have been better (and more future proof) to cast to a 64 bit integer (and yes, you CAN use 64 bit integers on 32 bit systems though it will probably slow down the calculation).
However on 64 bit systems it is simply not acceptable to cast a Double to 32 bit Integers.
Btw the two Boeings that fell out of the air because their engines stalled? That was due to a 32bit Integer overflow error.