8888888888888888 + 1111111111111111 bug

Denis_Kinces122

My browser and operating system: Windows NT 10.0, Chrome 110.0.0.0

Using the + reporter from the Operators section, and put these numbers in the reporter

((8888888888888888) + (1111111111111111))

you will get the result of 10000000000000000, and not 9999999999999999.

There is also no workarounds for this.

If you also put

(((8888888888888888) + (1111111111111111)) - (1111111111111111))

It will result 8888888888888888. Not 9999999999999999.

-ElectronicArts-

Denis_Kinces122 wrote:
If you also put
(((8888888888888888) + (1111111111111111)) - (1111111111111111))
It will result 8888888888888888. Not 9999999999999999.

Got this on calculator

medians

The first one might just be a small issue with big numbers.
The second seems to be right to me since numbers cancel out but I might be..

CST1229

Integers above 9007199254740991 aren't safe to work with (becoming less and less precise), due to how floating-point numbers work. This isn't really a bug.

Last edited by CST1229 (Feb. 19, 2023 15:17:53)

10data10

Denis_Kinces122 wrote:
There is also no workarounds for this.

Actually there are workarounds using lists or strings. Here's one in this project: https://scratch.mit.edu/projects/97834341/

I think these workarounds are interesting to study but if you actually had a project that needed high precision numbers you probably would do better to use a different language.

mybearworld

This is not a bug.

10data10

mybearworld wrote:
This is not a bug.

In fairness to the OP, their integer calculation is not producing the expected result. Perhaps Scratch should not be abusing a computer hardware floating point register by making it store an unsafe whole number.

I think this type of error gets reported about twice a month. Maybe it is better to say that this is one of the perils of floating point, the Scratch Team isn’t going to accept this as a bug, and if it causes a problem then it’s up to us to find away around it in our projects.

Chirover

10data10 wrote:
mybearworld wrote:
This is not a bug.
I think this type of error gets reported about twice a month. Maybe it is better to say that this is one of the perils of floating point, the Scratch Team isn’t going to accept this as a bug, and if it causes a problem then it’s up to us to find away around it in our projects.

The thing is, Scratch is meant for kids and they expect them to work with small numbers (hundreds, thousands, millions, etc) and most of the educators don't seem to encourage using Scratch for performing operations with numbers that can't be handled properly by JavaScript, so to be fair, the Scratch Team is better off not fixing bugs that affect the “2 people a month” compared other bugs millions of active users face.

10data10

My reply is going a little off topic but, oh well.

Finding and reporting this ‘numeric glitch’ is actually a good thing. It’s almost like a rite of passage and people should be congratulated for getting to this point. Floating point numbers are not always accurate but they are good enough for what people do in Scratch and all numbers in Scratch are actually floating point numbers.

So I’d rather we not gaslight people and tell them that they didn’t find a glitch. They did. It’s just not an issue that the Scratch team is going to accept as a bug. But it is an issue that all sorts of people using many different computer languages sometimes have to mitigate themselves.

GIitchInTheMatrix

10data10 wrote:
It’s just not an issue that the Scratch team is going to accept as a bug. But it is an issue that all sorts of people using many different computer languages sometimes have to mitigate themselves.

The reason they aren’t is the only way to fix would be setting up a number system just for Scratch, which wouldn’t work well. Floating point integers, numbers after 9007199254740991, are above the 64-bit integer limit, which is Scratch’s max.

someone_random58

when green flag clicked
if <[88888888888888888888+11111111111111111111111] = [1000000000000000000000000]> then
throw my squishmallow at the window
end

CST1229

GIitchInTheMatrix wrote:
The reason they aren’t is the only way to fix would be setting up a number system just for Scratch, which wouldn’t work well. Floating point integers, numbers after 9007199254740991, are above the 64-bit integer limit, which is Scratch’s max.

By the way, the maximum safe integer is not the 64-bit integer limit (which is around 18446744073709552000 when represented as a float; well above the safe integer limit) - it's actually the 53-bit integer limit. [relevant information]
Also, implementing arbitrary-precision numbers (numbers that don't lose precision) would lower performance a lot, which is probably why Scratch doesn't use them (alongside the fact that older Scratch versions also used floats).

Last edited by CST1229 (Feb. 25, 2023 14:31:06)

cosmo250

Denis_Kinces122 wrote:
My browser and operating system: Windows NT 10.0, Chrome 110.0.0.0
If you also put
(((8888888888888888) + (1111111111111111)) - (1111111111111111))
It will result 8888888888888888. Not 9999999999999999.

Of course it is 8888888888888888 for this one. there is a minus 1111111111111111 in there. It minuses 1111111111111111 from 9999999999999999 Making no change in the equation.

Discuss Scratch