Okay so I was working on making a calculator (project), and I tested the problem “96215 × 35.2”. It for some reason came out to be 3386768.0000000005. I tested it on a real calculator and it was 3386768, no decimal. I did it with the Scratch block like this:

((96215) * (35.2))

, clicked it, and it also said 3386768.0000000005. This is obviously not correct - where does the super small decimal come from? It does similar things with similar problems, e.g. 26215 × 35.2 and 56220 × 35.2 show up as 922768.0000000001 and 1978944.0000000002 respectively.

I haven't done excessive tests on the reason it does it or the only times it does it, but it is weird…
My browser / operating system: Windows NT 10.0, Chrome 75.0.3770.100, No Flash version detected

This is actually normal - it's because of the number format Scratch uses, which is a double precision floating point number. Double floats, as they are called, are able to represent a very wide range of numbers from very small to absolutely massive, but only with about 15 digits of accuracy.

The classic example is adding 0.1 + 0.2, which equates to 0.30000000000000004, instead of 0.3 as expected. To paraphrase a Scratcher named TheLogFather, the issue is that the number 0.3 doesn't exist as the computer sees it. If you end up going from Scratch to more serious languages, you'll have to learn to code around these limitations.

Here's a quote from 0.30000000000000004.com, which I think gives a really good explanation of this:

0.30000000000000004.com wrote:

It's actually pretty simple. When you have a base 10 system (like ours), it can only express fractions that use a prime factor of the base. The prime factors of 10 are 2 and 5. So 1/2, 1/4, 1/5, 1/8, and 1/10 can all be expressed cleanly because the denominators all use prime factors of 10. In contrast, 1/3, 1/6, and 1/7 are all repeating decimals because their denominators use a prime factor of 3 or 7. In binary (or base 2), the only prime factor is 2. So you can only express fractions cleanly which only contain 2 as a prime factor. In binary, 1/2, 1/4, 1/8 would all be expressed cleanly as decimals. While, 1/5 or 1/10 would be repeating decimals. So 0.1 and 0.2 (1/10 and 1/5) while clean decimals in a base 10 system, are repeating decimals in the base 2 system the computer is operating in. When you do math on these repeating decimals, you end up with leftovers which carry over when you convert the computer's base 2 (binary) number into a more human readable base 10 number.

CR, that's just stupid. My browser / operating system: Windows NT 10.0, Chrome 75.0.3770.100, No Flash version detected

Banana

(round ())
([floor v] of ())
([ceiling v] of ())

These blocks will help.

banana439monkey wrote:

CR, that's just stupid. My browser / operating system: Windows NT 10.0, Chrome 75.0.3770.100, No Flash version detected

Banana

…? What does CR mean?

Flowermanvista wrote:

This is actually normal - it's because of the number format Scratch uses, which is a double precision floating point number. Double floats, as they are called, are able to represent a very wide range of numbers from very small to absolutely massive, but only with about 15 digits of accuracy.

The classic example is adding 0.1 + 0.2, which equates to 0.30000000000000004, instead of 0.3 as expected. To paraphrase a Scratcher named TheLogFather, the issue is that the number 0.3 doesn't exist as the computer sees it. If you end up going from Scratch to more serious languages, you'll have to learn to code around these limitations.

Here's a quote from 0.30000000000000004.com, which I think gives a really good explanation of this:

0.30000000000000004.com wrote:

It's actually pretty simple. When you have a base 10 system (like ours), it can only express fractions that use a prime factor of the base. The prime factors of 10 are 2 and 5. So 1/2, 1/4, 1/5, 1/8, and 1/10 can all be expressed cleanly because the denominators all use prime factors of 10. In contrast, 1/3, 1/6, and 1/7 are all repeating decimals because their denominators use a prime factor of 3 or 7. In binary (or base 2), the only prime factor is 2. So you can only express fractions cleanly which only contain 2 as a prime factor. In binary, 1/2, 1/4, 1/8 would all be expressed cleanly as decimals. While, 1/5 or 1/10 would be repeating decimals. So 0.1 and 0.2 (1/10 and 1/5) while clean decimals in a base 10 system, are repeating decimals in the base 2 system the computer is operating in. When you do math on these repeating decimals, you end up with leftovers which carry over when you convert the computer's base 2 (binary) number into a more human readable base 10 number.

Woah, that's going a little over my head haha. Does that mean it isn't a “bug”? Because I still am going to have to code around it now, since the calculator is incorrect in these cases. And that I guess means I'll have to figure out a way to use the rounding block to my advantage…

EIephant_Lover wrote:

Flowermanvista wrote:

This is actually normal - it's because of the number format Scratch uses, which is a double precision floating point number. Double floats, as they are called, are able to represent a very wide range of numbers from very small to absolutely massive, but only with about 15 digits of accuracy.

The classic example is adding 0.1 + 0.2, which equates to 0.30000000000000004, instead of 0.3 as expected. To paraphrase a Scratcher named TheLogFather, the issue is that the number 0.3 doesn't exist as the computer sees it. If you end up going from Scratch to more serious languages, you'll have to learn to code around these limitations.

Here's a quote from 0.30000000000000004.com, which I think gives a really good explanation of this:

0.30000000000000004.com wrote:

It's actually pretty simple. When you have a base 10 system (like ours), it can only express fractions that use a prime factor of the base. The prime factors of 10 are 2 and 5. So 1/2, 1/4, 1/5, 1/8, and 1/10 can all be expressed cleanly because the denominators all use prime factors of 10. In contrast, 1/3, 1/6, and 1/7 are all repeating decimals because their denominators use a prime factor of 3 or 7. In binary (or base 2), the only prime factor is 2. So you can only express fractions cleanly which only contain 2 as a prime factor. In binary, 1/2, 1/4, 1/8 would all be expressed cleanly as decimals. While, 1/5 or 1/10 would be repeating decimals. So 0.1 and 0.2 (1/10 and 1/5) while clean decimals in a base 10 system, are repeating decimals in the base 2 system the computer is operating in. When you do math on these repeating decimals, you end up with leftovers which carry over when you convert the computer's base 2 (binary) number into a more human readable base 10 number.

Woah, that's going a little over my head haha. Does that mean it isn't a “bug”? Because I still am going to have to code around it now, since the calculator is incorrect in these cases. And that I guess means I'll have to figure out a way to use the rounding block to my advantage…

Yes, that technically means it isn't a “bug”, but a limitation that many programmers work around because double floats are easy for computers to do math on, and they can store wide ranges of numbers.

Flowermanvista wrote:

banana439monkey wrote:

CR, that's just stupid. My browser / operating system: Windows NT 10.0, Chrome 75.0.3770.100, No Flash version detected

Banana

…? What does CR mean?

Can't replicate?

I did manage to replicate it when I clicked on the multiply block in the scripting area, but that floating point error cleared when I put it inside a [ say [ ] ] block and when I put that block in a variable.

Flowermanvista wrote:

banana439monkey wrote:

CR, that's just stupid. My browser / operating system: Windows NT 10.0, Chrome 75.0.3770.100, No Flash version detected

Banana

…? What does CR mean?

Can reproduce.

Banana

CatsUnited wrote:

Flowermanvista wrote:

banana439monkey wrote:

CR, that's just stupid. My browser / operating system: Windows NT 10.0, Chrome 75.0.3770.100, No Flash version detected

Banana

…? What does CR mean?

Can't replicate?

I did manage to replicate it when I clicked on the multiply block in the scripting area, but that floating point error cleared when I put it inside a [ say [ ] ] block and when I put that block in a variable.

It was replicated in my calculator when added to a list.

Flowermanvista wrote:

EIephant_Lover wrote:

Flowermanvista wrote:

This is actually normal - it's because of the number format Scratch uses, which is a double precision floating point number. Double floats, as they are called, are able to represent a very wide range of numbers from very small to absolutely massive, but only with about 15 digits of accuracy.

The classic example is adding 0.1 + 0.2, which equates to 0.30000000000000004, instead of 0.3 as expected. To paraphrase a Scratcher named TheLogFather, the issue is that the number 0.3 doesn't exist as the computer sees it. If you end up going from Scratch to more serious languages, you'll have to learn to code around these limitations.

Here's a quote from 0.30000000000000004.com, which I think gives a really good explanation of this:

0.30000000000000004.com wrote:

It's actually pretty simple. When you have a base 10 system (like ours), it can only express fractions that use a prime factor of the base. The prime factors of 10 are 2 and 5. So 1/2, 1/4, 1/5, 1/8, and 1/10 can all be expressed cleanly because the denominators all use prime factors of 10. In contrast, 1/3, 1/6, and 1/7 are all repeating decimals because their denominators use a prime factor of 3 or 7. In binary (or base 2), the only prime factor is 2. So you can only express fractions cleanly which only contain 2 as a prime factor. In binary, 1/2, 1/4, 1/8 would all be expressed cleanly as decimals. While, 1/5 or 1/10 would be repeating decimals. So 0.1 and 0.2 (1/10 and 1/5) while clean decimals in a base 10 system, are repeating decimals in the base 2 system the computer is operating in. When you do math on these repeating decimals, you end up with leftovers which carry over when you convert the computer's base 2 (binary) number into a more human readable base 10 number.

Woah, that's going a little over my head haha. Does that mean it isn't a “bug”? Because I still am going to have to code around it now, since the calculator is incorrect in these cases. And that I guess means I'll have to figure out a way to use the rounding block to my advantage…

Yes, that technically means it isn't a “bug”, but a limitation that many programmers work around because double floats are easy for computers to do math on, and they can store wide ranges of numbers.

https://scratch-mit-edu.ezproxyberklee.flo.org/projects/319236044/ This projects tests these limitations by adding over 8000 numbers together. 8 possible values can come from this project.

-snip-

kysk219dhsaek102 wrote:

https://scratch-mit-edu.ezproxyberklee.flo.org/projects/319236044/ This projects tests these limitations by adding over 8000 numbers together. 8 possible values can come from this project.

Wow, over 3000 mistakes. How do you find them?

*Edit - maybe like a simple explanation for how it can tell whether it is wrong since, of course, Scratch does it wrong, and, if possible, a way to fix these errors :)

banana439monkey wrote:

CR, that's just stupid. My browser / operating system: Windows NT 10.0, Chrome 75.0.3770.100, No Flash version detected

Banana

What are you calling stupid - the error or me pointing it out?

This is normal for scratch, because it can hold numbers that have many digits. Using a calculator, your answer would be rounded in order to contain less digits. Calculators usually can't hold that many digits, so the system they use is a simple fix.