Initially it seemed straight forward. Pi for instance was only worth recoding six/seven digits (see below).
const float pi = 3.14159
The last post by JimEli however cast doubt on this simplified approach. Since then I've read about how Arduino stores floats (IEEE-754 Format). I've read about Two's Compliment. I've even read about Significant Digits. Unfortunately I'm not having a light bulb moment.
It appears that it's a rather convoluted process converting a decimal number into a single precision binary number. In addition the conversion from decimal to binary presents a number of problems such as rounding errors.
In a nutshell when using floats where do I draw the line?
const float pi = 3.141592653589...
Should I be running the decimal number I wish to use through something like the following? If so is there something specific I should be looking for?
If I type 3.14 in the 'You entered' field then press Tab the other fields get populated. If I then click on the +1 button the fields appear to change but I can't work out what's happening? The article below doesn't seem to explain this either. Can you explain?
If I type 3.14 in the 'You entered' field then press Tab the other fields get populated. If I then click on the +1 button the fields appear to change but I can't work out what's happening?
I didn't say to click on the +1. If you enter 3.14 and press the tab or enter key, the other fields get populated. If you modify the entered value to 3.141 and press the tab or enter key, the other fields get updated. At some point, the other fields stop changing values.
You entered: 3.1
Value actually stored in float: 3.099999904632568359375
You entered: 3.14
Value actually stored in float: 3.1400001049041748046875
You entered: 3.141
Value actually stored in float: 3.1410000324249267578125
Skip ahead
You entered: 3.14159265
Value actually stored in float: 3.1415927410125732421875
You entered: 3.141592653
Value actually stored in float: 3.1415927410125732421875
In the last two attempts there is no change to the 'Value actually stored in float'. I'm guessing that this means there is no point in entering further numbers because they simply can't be stored?
Secondly, 'You entered' and 'Value actually stored in float' are a match up until here 3.141592. Is this where I stop?
In the last two attempts there is no change to the 'Value actually stored in float'. I'm guessing that this means there is no point in entering further numbers because they simply can't be stored?
You entered: 3.14159265
Value actually stored in float: 3.1415927410125732421875
I have two queries:
1. According to binary32 format, there are 23 fractional digits after the decimal point. Why are there only 22 digits after the decimal point?
2. The entered value is 3.14159265 which is accurate up to 8 digit. In the print out (3.1415927410125732421875), the value has come out with 6/7 digit accuracy. Where and how have we lost the accuracy?
I call it decimal point looking at the decimal point of the Real value definition as shown above. To me Real value is a decimal number along with a decimal point.
The Real Value can be represented in decimal, binary, or any other base. For example, a Real Value could be 1.011*2^5 or 101100 (binary) or 44 (decimal).
Regardless of what base you represent the Real Value in, float32 has only 23 significant binary digits. The "decimal point" in a binary number (such as 1.011) is more accurately called a "binary point". You can also call it a "radix point" to use it with any base.
I call it decimal point looking at the decimal point of the Real value definition as shown above. To me Real value is a decimal number along with a decimal point.
This is my faded memory from studying this in college (30+ years ago). But, I’m sure it’s a binary point and all 23 bit of the mantissa are to the right of it. There is an assumed “1” to the left of it.
So, for the example shown, the full mantissa (in binary) is:
1.01000000000000000000000
The 8-bit exponent is 0b01111100 = 124. So, e = 124 - 127 = -3
So, take the mantissa and move the binary point thee places to the left and you get:
Thanks for all the replies. So the root of the problem is the 'mismatch' between binary and decimal fractions? So at some point your number will depart from what's being stored? This is why we only have 6-7 decimal digits for 32 bit single precision?
