I try to avoid as much as possible any Runtime error in my programs.
And it takes a lot of time!
Most of my methods start checking all the parameters in any possible way to find Nill, out of bounds, etc.
However, recently, I came across with another type of error that worries me a lot because it generates no message.
It is about multiplying integers to get another integer. If the result overflows, you get an integer that is whatever, but not the real result nor an NotANumber nor any error message…
I’ve looked into the forum and I’ve seen that this has been tackled other times, but I found no help in those texts.
How can I avoid errors when multiplying integers?
Which is the best practice?
If your integers are going to be that big, use Int64 or UInt64. If they are going to be bigger than that, use Bob Delaney’s plugins to handle any size integer.
If you want to confirm that an integer has “rolled over”, you can always do bitwise math to check the first bit, I suppose. I haven’t tried so I don’t know if that will work in all cases, and it certainly won’t work if you are using unsigned integers.
Thanks Kem and Tim.
That gives a little more light to the subject.
But in my opinion these silent errors are not good calling cards for Xojo.
I don’t like them at all.
[quote=131005:@Ramon SASTRE]Thanks Kem and Tim.
That gives a little more light to the subject.
But in my opinion these silent errors are not good calling cards for Xojo.
I don’t like them at all.[/quote]
Today I played with an integer set to 2,147,483,647 which is supposed to be the maximum such a variable can hold.
Adding 1 produced 2,147,483,648
Adding 2 produced 2,147,483,647
Adding 3 produced 2,147,483,646
So it seems instead of an error, an overflow becomes a subtraction.
The most amazing is that afterward if you subtract 3 to 2,147,483,646, you get back to 2,147,483,647
[quote=131016:@Michel Bujardet]Today I played with an integer set to 2,147,483,647 which is supposed to be the maximum such a variable can hold.
Adding 1 produced 2,147,483,648
Adding 2 produced 2,147,483,647
Adding 3 produced 2,147,483,646
So it seems instead of an error, an overflow becomes a subtraction.
The most amazing is that afterward if you subtract 3 to 2,147,483,646, you get back to 2,147,483,647[/quote]
Make sure when you display it you display it with leading negative signs
That seems to be what you’ve overlooked as
dim i as integer = &h7FFFFFFF
[quote=131026:@Norman Palardy]Make sure when you display it you display it with leading negative signs
That seems to be what you’ve overlooked as
dim i as integer = &h7FFFFFFF
[quote=130985:@Ramon SASTRE]However, recently, I came across with another type of error that worries me a lot because it generates no message.
It is about multiplying integers to get another integer. If the result overflows, you get an integer that is whatever, but not the real result nor an NotANumber nor any error message…
I’ve looked into the forum and I’ve seen that this has been tackled other times, but I found no help in those texts.
How can I avoid errors when multiplying integers?
Which is the best practice?[/quote]
As far as I know, this is normal behavior: integer addition/subtraction is more a bitwise operation than a math operation. The overflow is expected with a limited number of bits and with 2’s complement (I assume xojo/intel cpus use this) used to represent negative numbers, oveflowing bits will wrap to a negative integer. Adding more bits as suggested is the way to go.
One issue esp with integers is there is NO bit pattern that can indicate NaN, Inf etc.
With floating point values there are well defined bit patterns that can be used to indicate results like NaN, INF etc.
With an integer EVERY possible bit pattern is a legal value in the range that integers can represent.
Way back in the annals of history it was decided that there would NOT be overflow checking in RB / Xojo.
I don’t know why - but there never has been. Not since version 1.0 went out in 1997.
Theoretically it would be possible to add it in but lord knows how much code it might break.
Then I’m sure there’d be a need to be able to turn it on & off conditionally.