Number_input Step Precision Issue With Floats

[Kuppingtons]

Summary

When incrementing a number input with floats Streamlit seems to add extra digits at the end after a few clicks. It seems to get worse the more the value is incremented. Not a huge issue since it can still be edited, but a bug nonetheless.

Steps to reproduce

Code snippet:

result = st.number_input("Testing Step", value=1.0, step=.05, format="%f")
result

Expected behavior:

I expect the number input to step exactly by the specified step.

Actual behavior:

The step is adding on .0000000000000001 Every three steps or so.

Debug info

• Streamlit version: 1.15.2
• Python version: 3.9.5
• Using PipEnv
• OS version: Windows 10
• Browser version: Chrome 108.0.5359.95

Requirements file

Pipfile

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
streamlit = "*"

[dev-packages]

[requires]
python_version = "3.9"

Additional information

Video:

[mathcatsand]

This is the general reality with programming (and not just Python).

Floats are stored as binary, so there is inherently a rounding error converting back and forth between base 2 and 10. You need to format the number so it disregards those tiny rounding errors. If the tiny rounding errors are significant to your computations in your use case, you can do a bit more lifting with code to remove the issue (like multiplying times 100 so 0.05 becomes and integer for the sake of the increment and dividing by 100 for the sake of display).

import streamlit as st
import time

counter = st.empty()

total = 0

for i in range(20):
    total += 0.05
    counter.write(total)
    time.sleep(0.2)

st.button('Do Over')

[Kuppingtons]

Thank you for your reply @mathcatsand! I was assuming this issue was due to Streamlit and not programming.

I will format the number input and result with %.2f for now since I can get away with lower precision.

If I did need that precision is there a way to change the displayed number within the number_input so I could store it as an integer? I’m not seeing anything in the docs like selectbox’s format_func. I’m thinking I would have to create my own or component find another one that does that.

[Goyo]

Formatting cannot help you here. If you want the number displayed as a float then the widget needs to have a float value. But you can store the corresponding integer value separately.

The following code can fail if the errors accumulate too much, but it won’t happen unless you keep pressing the arrows a million times (conservative estimate).

float_value = st.number_input(
    label="Number",
    step=0.01,
)
int_value = round(float_value * 100)
st.write(int_value, float_value)

[mathcatsand]

I really wanted to have a cheeky solution to this. I tried defining a custom format string (but the interwebs say it’s impossible to wedge it in to being understood by the string interpolation operator). I extended the int and float class to perform math as expected but display divided 100, and was so hopeful. Sadly, as far as I can tell, the component forcibly re-classes everything as either int or float even if you feed it an extended class (and this appears to occur in the widget Streamlit imports as opposed to within Streamlit’s own code).

I was so hopeful this would work…

class mint(int):
    def __add__(self,other):
        return mint(int(self)+int(other))
    def __sub__(self,other):
        return mint(int(self)-int(other))
    def __str__(self):
        return str(self/100) # self/100 becomes a float, hence not a circular definition
    def __format__(self, spec):
        return format(self/100,spec) # self/100 becomes a float, hence not a circular definition

mint(1)+1 # will return mint type (e.g. divided by 100 for display only)
1+mint(1) # will return int type (e.g. displays the value as used for computation)

f'{mint(2):.2f}' # __format__ is defined to divide by 100 then format as usual
'%s' % mint(2) # __str__ is defined so mint with be divided by 100 for display as a string

That last line could have been the path to victory if only the widget didn’t overwrite the object class. So close! Oh well.

Just sharing for posterity…