Counter shows gibberish when it should show number "0"

[SteveJG]

The gibberish you see is actually a number in scientific notation. What you see represents a very small value. You might use a Math format block ahead of the Number Block to set the number of decimal places. That will take the display out of scientific notation mode.

Why does it happen? A guess is you are touching the buttons very rapidly and that is confusing the Math algorithm by not giving the app time to respond.

Did you notice you have an empty puzzle piece in your Reset.Click event handler? Perhaps that relates to your issue by setting Number to a value that is not a number.

[Arman]

@SteveJG

Did you notice you have an empty puzzle piece in your Reset.Click event handler?

I filled it, it doesn't changed anything, its weird!

[ABG]

It is a side effect of inexact arithmetic.

0.1 is an infinite length quantity in binary, like 1/3 is an infinite length decimal number.

You got math sawdust.

P.S.
AI2 might still support rational number data type arithmetic, if you substitute 1/10 for 0.1 everywhere. But some math operations result in floating point results , so avoid those.

FAQ section: Maths

AI2 mathematical precision - ewpatton AI2 exact to inexact conversion - @ewpatton ASCII Conversion - Italo ASCII Table Binary Conversions Video - Pixii Bomb Can't find a Math Block - dora_paz Commas as decimal separators? Convert Integer to Roman Numerals Displaying Math Formulas in Latex - easrng Displaying Math Formulas with jqMath - Juan Antonio Displaying math formulas with MathJax (Thunkable, Taifun) Generate different random number in blocks Generate different random numbers in …

[ABG]

@SteveJG

a number in scientific notation

1.1102E-16 = 1.1102 * 10^-16

An exercise for further study:

How many binary digits are needed to store 1.1102 * 10^-16 ?

How does that compare to the floating point spec mentioned in the first (ewpatton) article in the Math FAQ?

[Mark_c]

Hi ABG,

"0.1 is an infinite length quantity in binary, like 1/3 is an infinite length decimal number."

Ok, but then, why does this only seem to happen at zero?

As for a solution, I will try to replace 0.1 with 1/10.

Thanks for your explanation, much appreciated!

Mark

[ABG]

@Mark_c

Ok, but then, why does this only seem to happen at zero?

Near zero, a floating point number starts to expose incremental losses of accuracy.

There's also the salami effect, which banking software guards against.

(Not to encourage a life in cyber-crime)

I hope you got to read the comprehensive post by ewpatton at

Strings, numbers, what size can they have?

I’ll address the question in three parts as the actual answer is somewhat complicated. In particular, it’s important to know that at the core of App Inventor is an implementation of the Scheme language called Kawa. Theoretical String Length There are two different internal string types in App Inventor. Kawa provides a mutable string type called FString and then there’s Java’s standard String type. Conversions are done from FString to String on an as needed basis to interact with the parts of th…

You may need to study up on floating point formats first.

[Mark_c]

using fractions here does not change anything

I may just need to work around it with if-then blocks to correct the value back to "0.0000" at zero.

[Mark_c]

This will do as a work around

[Mark_c]

This has the advantage (in my case) of also formatting 0.0 to 0

[ABG]

@Mark_c

why does this only seem to happen at zero?

Where do you find sawdust?

On the floor.

[Mark_c]

and in the air all around, before it settles

[ewpatton]

Technically, the rounding errors occur at pretty much every number once you get small enough fractional differences that cannot be expressed neatly in the 53 bits of mantissa of a double floating point number. For example, 0.1 + 0.1 + 0.1 will give you 0.30000000000000004. Typically when App Inventor renders a number it does so only to 5 decimal places by default so you don't see the error. However, in the case of numbers near zero, scientific notation is a more compact and accurate representation, so you end up being able to see the accumulated error in a more up-front way since that's all that remains. The use of the floor or round functions may be useful in this case.

[Mark_c]

Do you see any better solution to mine (using that "correct_zero" procedure)? Round doesn't work, right, because I do use decimals

[ewpatton]

The format as decimal block is likely a good candidate:

yielded "0.0" and using "Do It" on the math block feeding into it yielded a scientific notation number on the order of 10^-17.

[ABG]

Work in tenths of points, so you keep only whole numbers until display time?

For 0.1 keep 1, for 0.2 keep 2,...

Save the divide by 10 until the end.

[ABG]

Does that rational number data type still exist in the AI2 math stack, or am I on a wild goose chase?

[ewpatton]

I think these days all of the exact numbers are converted back to inexact numbers when they get passed up to the user. It might take me a little while to verify that.

[ewpatton]

Ok, so it looks like there are only two places where we are converting exact numbers to inexact numbers. The first is in conversion from numbers to strings, and the second is in the division operator. Therefore, you can still get some access to the rational numbers but unfortunately you can't really visualize them because the number to string coercion will convert them from their rational representation to the decimal representation. But, you can still do something like this:

And the latter will return 0 rather than the floating point error of adding and then subtracting something near 0.1 but not actually 0.1.

[ABG]

Thank you!

[Mark_c]

Thanks, good to learn about this option

I'll leave the high-level conversation to you and ABG!

Have a good day