Numbers In App Inventor Are Stored As Floating-Point

I am exploring App Inventor, an Android application development environment for novice programmers. I am teaching it to my kids, as an introductory step towards “real” app development. While playing with it I wondered: are its numbers implemented in decimal? No, they aren’t. They are implemented in double-precision binary floating-point. I put together a few simple block programs to demonstrate this, and to expose the usual floating-point “gotchas”.

(Also check out this recent discovery about integers: entered in blocks they are represented in floating-point; generated through calculations they are represented as arbitrary-precision integers.)

App Template

Each testcase I wrote is embedded in a simple app “template”, consisting of a button and a label (I used the default names, Button1 and Label1). The button is used to run the testcase, and the label is used to display its output. I ran each test on both the emulator and a real device (a Samsung Galaxy Tab 3), although I only show screenshots of the emulator in the examples below.

The main tool I used is a math block called “format as decimal”:

The ‘places’ parameter specifies how many digits to print after the decimal point. I discovered it can print a number to any number of decimal places; this was a surprise, given that many industrial strength programming language implementations can’t do that! This allowed me to show the floating-point implementation in all its glory.

Printing Enough Digits To Expose Floating-Point Implementation

The following program (the same one shown in the introduction) prints the number 0.1 to 17 digits:

Here is its output:

You can see the “extra 1 on the end”, the tell-tale sign of a binary floating-point representation; let’s verify by printing all its digits:

Those blocks in fact display the exact representation of 0.1 in double-precision floating-point:

Numbers Are Converted Before They’re Displayed

There’s a simpler way to show that App Inventor uses floating-point, or at least get a clue that that’s what it’s using. If you enter a number of 16 to 17 digits or more, it will be changed as soon as you hit enter. It is converted instantly, like in a spreadsheet cell.

In this example, I entered 0.12345678901234567, even though App Inventor displays it as 0.12345678901234566 in the number block:

I wrapped the number in a “format as decimal” so that I could show all its floating-point digits:

That number, 0.1234567890123456634920984242853592149913311004638671875, is in fact the double-precision floating-point number closest to 0.12345678901234567. App Inventor displays it as 0.12345678901234566 because that is the full floating-point number rounded to 17 digits. So even though App Inventor changed the external representation from 0.12345678901234567 to 0.12345678901234566, it doesn’t matter; both convert to the same floating-point number internally.

Floating-Point Gotchas

The three examples that follow show mathematical results that surprise the uninitiated; I’ve written about them in other contexts.

Equality is Broken

Simple decimal addition fails to work in floating-point; for example, 0.3 + 0.6 ≠ 0.9. Here are blocks to demonstrate that:

(Notice the ‘\n’ formatting — a shout out to C!)

This exposes two issues:

• 0.3 and 0.6 converted to floating-point, and then added, does not give 0.9.
• 0.9 converted to floating-point does not even give 0.9!

The Floor Function Is Broken

4.35 * 100 is 435, so floor(4.35 * 100) is 435, right? Not in floating-point. 4.35 * 100 is slightly less than 435, so the floor is 434.

Let’s look at all the digits to verify:

Algebra Is Broken

I wrote this C function to show that floating-point does not honor algebraic manipulations:

double f(double a)
{
 double b, c;

 b = 10*a - 10;
 c = a - 0.1*b;

 return (c);
}

Algebraically, it should always return 1: c = a – 0.1*(10*a – 10) = a – (a-1) = 1.

I rewrote that function in blocks, and I tested it on input 719525522284533115.3 (which App Inventor converted instantly to 719525522284533100, a clue that this is not going to go as expected):

The answer is not 1, but -128!

Should App Inventor Hide Binary?

App Inventor hides much of the complexity of Android app development, allowing non-programmers to easily write simple apps. Yet it doesn’t hide binary floating-point, something that trips up countless people, beginners and non-beginners alike. Should it? Arbitrary-precision decimal floating-point would fix the most glaring gotchas, while rational arithmetic would handle expressions involving fractions like 1/3. (Rational arithmetic might be overkill though, since anyone that has used a calculator would expect inexact results using decimal fractions.)

Maybe it’s best to hide binary until new programmers get more experience — and start programming real apps in Java.