why is this a minus?

[Jay]

hi all cam anyone tell me why this int multiplication shows as a minus? im confused

and should it not come out as 2157840000

eh lol..png (8.7 KiB) Viewed 18230 times

[billv]

At first, I thought it was a practical joke, or some guru math trick.....but
Confirmed.
+1.
And we can't get inside to fix it..... just send it to DSPR, with a note attached:WTF?

[nix]

IMO FS is confused!

[VPDannyMan]

What is the largest number an integer in FS can hold?

[billv]

just send it to DSPR,

on second thought

What is the largest number an integer in FS can hold?

A standard 32-bit integer can handle -2,147,483,648 through 2,147,483,647.
I knew it was guru math trick thanks for the reminder
thanks VPDannyMan
can you tell me why this happens....?? still

[nix]

Looks like it has added the irresolvable 10000... to the minimum negative.
Like it has pushed it into a loop,
and restarted it's range from minimum.
Not the ie005 768 or whatever it does with floats.

[Jay]

ah so it is a little bug! lol i was thinking either my pc had gone wonky or my install had gone south!

tried the same in the ruby box and got these results which are even weirder! but it shows that it is the int system

eh lol 2.png (19.14 KiB) Viewed 18214 times

[tester]

Here is the trick to solve it

In other words - don't use integers if you don't have to.

[trogluddite]

ah so it is a little bug! lol i was thinking either my pc had gone wonky or my install had gone south!

Well, the PC's CPU is doing exactly what it has been told to do.
It attempts the multiplication, and then finds that the result won't fit to 32 bits - so the bits that would represent the bigger number are just lost, leading to the strange results (one of the bits is used to indicate +/- too). It's what's known as an overflow error - trying to "fit a quart into a pint pot."

But there is something being hidden from us.
When this happens inside the CPU, a flag gets set called the "Overflow flag" - and in many PC languages, the programmer would be able to check that flag, and use it to show an error message, or call a special maths routine that could handle a bigger number by splitting the number up into chunks.

Tester's solution works up to a point - but there is still a problem that must be accounted for...
Although the float numbers are alllowed to be much bigger (or smaller), there will be a loss of precision - i.e. the result of the multiplication will be approximately the right size, but not always the exact answer.
It works a little like this...
Lets say you have a very rubbish calculator that could only show you four digits. How would you write 123,000,000?
Ah - there is a way - we can make a rule that says "the last digit is the number of zeros". So the calculator could write it as "1236" - which is the principle of 'scientific notation" or "E notation" (e.g. 1.543e12).
But what about 123,000,001? Well, the best we could do here is to say "the one is so small, let's just ignore it" - and our crappy four digit calculator still writes "1236"
So when using float numbers, above a certain value, you can't represent every single integer value - there's a point where only even numbers can be represented, later, only every fourth one, and so on as the numbers get bigger - which means there can still be maths errors. e.g.
123,000,000 + 1 = 123,000,000

So , FS is not really doing much wrong - the way the CPU represents numbers is the biggest part of the limitation. BUT, I do think it would be good if the integer maths primitives showed us the overflow error rather than outputting a confusing value - the same way that floats show us "NF" or "NAN" when there is a float maths problem.

Note that within Ruby, the number ranges are much larger - floats are 64bit rather than 32bit, and integers are also 64bit, but also with a special "BigNum" class than can handle integers of any size (at much greater CPU cost). But once you send those numbers out of Ruby and into the 'green' world, they will again be truncated to the 32bit values.

[Jay]

yeh i know about that tester cheers! but it is no good for what i was doing! that gives a result of 2.15784e+009! it is fine as i was outputting it to a label anyway m8!

also it is not a bug, i understand now! it is the largest number an int32 is capable of!