the TYPE of the result is IRRELEVANT until the computation is completed and needs to be put into the destination
The compiler looks at each operand and sees that each fits an integer
Not sure it opts for 32 vs 64 bit integers internally based on what target you’re compiling for
However that the first gets the wrong result I suspect it opts for a 32 bit one
And so uses that to do the work
The result overflows 32 bits & is then assigned to the double
In the second
resultd = 24 * 60 * 60 * 180 * 1000.0
it sees that at least one operand is a floating point value and so uses doubles for everything
And then eventually assigns the floating point value to the result
Quite possible as I’m not sure about these sorts of details about the internals of the compiler and what types it assumes things are
It may well opt for using an int64 - and if compiling for 64 bit does give the right answer for the first test then that makes sense as no overflow is experienced
FWIW : NOTE I’m not saying Xojo has this uniquely wrong
Java does the same
When no type is stated or hinted then the compiler has to assume something about the literals
In both java and Xojo it appears to assume numerics are implicitly int32
And then when you multiply enough int32’s together you eventually overflow the type
Possibly the compiler(s) could be altered to do something like
// resultd = 24 * 60 * 60 * 180 * 1000 ;
dim temp1 as int32 = 24
dim temp2 as int32 = 60
dim temp3 as INT64 = temp1 * temp2 // because int32 * int32 can overflow an int32
dim temp4 as int32 = 60
dim temp5 as int64 = temp3 * temp4 // int64 * int32 will give an int64
dim temp6 as int32 = 180
dim temp7 as int64 = temp5 * temp6 // int64 * int32 will give an int64
dim temp8 as int32 = 1000
dim temp9 as int64 = temp7 * temp8
dim resultd as double = temp9
there is still a way to overflow int64
and an fr to add int128
I use MPLABX for my embedded stuff and if you try to use literal with 32 bit calculations it completely fecks up and seemingly has no idea what to do.
fine on other types.
to use a literal it has to be declared as the same 32 bit type and given the value you wish to represent by that literal:-
cant say I have evener used MPLABX
I have run into compilers that are very touchy about assumptions
BUT being that way also means they are VERY explicit
ie/ no literals in expressions means EVERYTHING has to be explicitly typed before used and that can help with several things like optimizations and even overflow checking
it seems a pain but depending on what kind of code you’re writing can also be much safer
that is the goal of lots of new langs like swift go rust etc
to reduce the things that constantly & perpetually get done that create bugs
Maybe we should go back to using hand calculators since every one I tried, from the one in my iPhone to an ancient Casio EL-386L, came up with the correct answer.
