MicroPython
float into variables #14364
Replies: 9 comments 15 replies
-
Like everybody else around the world. It's NOT a Micropython problem, it's the way floats are stored in memory. PS. Try to increment by 1/16 or 1/32 or … and be prepared to be surprised. PPS. And here's some code to visualize what's going on internally: #!micropython
from struct import pack,unpack
def show_value(value):
bits = unpack('I', pack('f', value))[0]
sign = bits >> 31
exponent = (bits>>23) & (2**8-1)
mantisse = bits & (2**23-1)
print(f'{value:33.30f} S:{sign:1b} M:{mantisse:023b} E:{exponent:08b}')
def test(divider=10):
incr = 1
last_value, this_value = None, 1
print(' --------decimal number--------- -----IEEE754 bitwise representation-----')
while last_value != this_value:
show_value(this_value)
last_value = this_value
incr /= divider
this_value += incr
test(10)
print()
test(2)And the result: |
Beta Was this translation helpful? Give feedback.
-
|
Increment an integer by one and to get the result, divide it by 10. count=0
for i in range(60):
count += 1
print(count / 10) |
Beta Was this translation helpful? Give feedback.
-
|
You are just hiding the underlying problem: count=0
for i in range(60):
count += 1
print(f'{count/10:33.30f}')Result: |
Beta Was this translation helpful? Give feedback.
-
|
There are really multiple problems in the OP's code, at least if you wanted it to be exact, or are interested in the numerical methods used. The most obvious is that negative powers of ten can not be expressed in terms of negative powers of two, which is to say not all decimal values have an exact binary floating point representation. And you're quite right, dividing an integer by ten to produce a float still has this same problem. But there are other problems. The value 0.1 is also inexact, and repeatedly adding an inexact value accumulates error. By repeatedly adding an integer, this accumulation of error is avoided. This is a general pitfall of floating-point math. One should avoid repeatedly adding/subtracting values when it can accumulate error. A way to avoid this is to repeatedly add/subtract integers instead. Convert to floating point, but don't accumulate in floating-point. Another flaw, which would become apparent as the |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, I understand. Isn't it possible to make a data type that would store the integer part and the fractional part separately in two int variables? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's called fixed-point arithmetic. But you have to remember, the number of available bits somehow determines how precise it's going to be. Another way of thinking about it, is: Take a piece of checkered paper The same problem happens with binary values. |
Beta Was this translation helpful? Give feedback.
-
|
See: For alternative number model approaches ... |
Beta Was this translation helpful? Give feedback.
-
|
You certainly could do that. It's part of the CPython standard library, https://docs.python.org/3/library/fractions.html But mpy doesn't have that module. |
Beta Was this translation helpful? Give feedback.
-
|
That would work as long as one stays within ℚ. |
Beta Was this translation helpful? Give feedback.
-
On platforms where there is hardware support (e.g. Pyboard D SF6W, Unix) it uses 64 bit. On other platforms software 64 bit support can be enabled with a build option. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting. Why doesn't count += 0.5 break anything? |
Beta Was this translation helpful? Give feedback.
-
|
Because 0.5 can be exactly represented as binary number. Like 0.25, 0.125, .... But not 0.1 |
Beta Was this translation helpful? Give feedback.
-
|
Any fraction which can be built with a combination of 1/2**n values are OK. #!micropython
# -*- coding: utf-8 -*-
result = 1 + 1 / 2**22
print(f'{result:35.30f}')
result = 1 + 1 / 2**23
print(f'{result:35.30f}')
result = 1 + 1 / 2**24
print(f'{result:35.30f}')Result: |
Beta Was this translation helpful? Give feedback.
-
There is no inaccuracy as a result of addition because they are
Correction of code: count=0
for i in range(60):
count += 1
value = count / 10
print(f"{value:.1f}") |
Beta Was this translation helpful? Give feedback.
-
That's so fundamentally untrue that even the opposite wouldn't be true. ;-) Let's say that floats are a problem for those who do not understand them and their limitations. |
Beta Was this translation helpful? Give feedback.
-
|
The process of mapping floats onto a fixed size integer variable is by definition inaccurate. I rather think this even applies if the integer has infinite size - floats being aleph 1 and integers aleph 0. I may be wrong, my memory of this stuff is hazy. |
Beta Was this translation helpful? Give feedback.
-
|
Peter, please map a float value of – hmmm, let's say – 3.0 to an integer and let us know about the expected and realized precision. Oh, one more thing, those set of roughly 33 million number which are an absolute precise representation, those sets repeat 255 times. With intervals between two consecutive numbers of two,four,eight,… or moving the other direction 1/2,1/4,1/8,… |
Beta Was this translation helpful? Give feedback.
-
|
With a sufficiently large number of bits you can create a mapping whereby many floats have precise representations. You might even create a mapping where transcendentals such as |
Beta Was this translation helpful? Give feedback.
-
Again, you are not displaying the true contents of ›value‹ |
Beta Was this translation helpful? Give feedback.
-
|
There is a whole field of mathematics to deal with this problem. See https://en.m.wikipedia.org/wiki/Numerical_analysis, generation and propagation of errors. Fortunately there are packages such as ulab (numpy for big python) that help to minimize the effects of the floating point error. |
Beta Was this translation helpful? Give feedback.
-
We don't care! I hate these dogmatic discussions. |
Beta Was this translation helpful? Give feedback.
-
Wow. Clueless and loud at the same time. What a combination. |
Beta Was this translation helpful? Give feedback.
-
|
@GitHubsSilverBullet Please stay polite. |
Beta Was this translation helpful? Give feedback.
-
|
@robert-hh Take a look at the previous post. Reconsider. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
count = 0
for i in range(60):
count += 0.1
print(count)
displays:
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8000001
0.9000001
1.0
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
2.0
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.799999
2.899999
2.999999
3.099999
3.199999
3.299999
3.399999
3.499999
3.599999
3.699999
3.799999
3.899998
3.999998
4.099998
4.199998
4.299998
4.399998
4.499998
4.599998
4.699998
4.799998
4.899998
4.999998
5.099998
5.199997
5.299997
5.399997
5.499997
5.599997
5.699997
5.799997
5.899997
5.999997
It seems that the error is accumulated in the variable. I tried it on pyboard and esp32c3, on micropython 1.22.2 and 1.23.0. How can I live with this now?
Beta Was this translation helpful? Give feedback.
All reactions