# App Inventor Stores Numbers as “Floating Point” Format

When you type a number, such as “123”, computers convert the text values of “123” into an internal representation used by the computer. There are many possible ways that numbers can be represented inside a computer. For example, the computer could:

• keep numbers in their original text format “123” (decimal format)
• convert them into a binary representation (binary integers)
• a “floating point” representation (floating point or “float” format)
• or even a “binary coded decimal” (BCD) representation.

Each internal format has benefits and drawbacks, depending on the application. Most computers (and programming systems) convert entered numbers from their original text format into either integer format or floating-point number format.

App Inventor converts values to floating point format. Which is fine, except that you will encounter some odd and subtle issues. As the link below notes, in App Inventor arithmetic, 0.3 + 0.6 does not equal 0.9!

To fully understand these internal formats would require far more detail than you are likely interested in learning right now. Read the following as a high level summary – do not worry if you do not follow the details. The general message is that text numbers are stored in different internal formats which affects memory required, speed of calculations and round off errors.

1. Integer values are often converted into “Two’s complement binary” or into unsigned binary. Basically, Two’s complement format converts a base 10 number (“123”) into a binary number containing only 0s and 1s, and a sign bit (positive or negative).  In a binary number, each digit (a 0 or 1) is called a bit. The value 123 becomes

1111011

Since computers typically store binary values in groups of 8-bits, this becomes

01111011

16 bits are used to represent values in the range -32768 to +32767. In some programming languages, there are small integers (range of -128  to +127) up to long integers having a range of about + or – 2 billion.

2. When numbers contain decimal points and fractional values – such as 123.456 – these are converted into a somewhat complex “IEEE Floating Point” format. This involves a conversion of the numbers into a “normalized” binary format, and use of an “exponent” value such that a number like 123 is represented (in binary, not decimal) as something like 1.23 x 10^2 power which is 1.23 x 100 or 123 (again, this is internally in binary). As with integer’s short and long formats, there are different floating point sizes with different ranges of acceptable values.

Integer values can be processed more quickly than floating point values and can use less memory than floating point storage formats. Originally, computers performed only integer arithmetic – special software code was stored in libraries (sort of like App Inventor call blocks) and used to add, subtract, multiple and divide floating point numbers. Obviously, a software adder is not as fast as a hardware-based integer adder. However, much of today’s computing hardware now includes floating point arithmetic capabilities implemented in hardware, which are also quite fast.

What does this have to do with App Inventor?

Last fall, Rick Regan published results of a simple experiment to determine how App Inventor stores numbers. What he confirmed is that App Inventor numbers are stored in floating point format.

How did he do that? Without going through the details, basically, when a decimal number “123.456” is converted to binary, there are situations where the binary representation cannot accurately represent the base 10 decimal value. This results in round off values – such as finding a value of 1.00000000000000001 instead of 1.0; the round off values are a clue that a binary floating point conversion took place.

Rick notes that in App Inventor code, 0.3 + 0.6 does not equal 0.9 and if you were to compare the values 0.3 + 0.6 = 0.9, this would test as false! Why? Because 0.3 and 0.6 cannot be stored precisely in binary, which results in a rounding error – thus 0.3 + 0.6 is very close to 0.9 but not exactly 0.9 as you would expect!

This type of calculation problem can be the source of some very confusing and hard to find programming problems!