Unexpected "noise" in hard values typed in a constant CHOP

I am a bit confused by the these values printed out in the Textport:

I am manually typing in values in the constant CHOP.
if I type 0 or 1, I get the correct print out, 0.0 or 1.0
if I type a number with one decimal (i.e. 0.1, 0.2 etc…) I get a “noisy” value print out.

I was working on a match case scenario in python and the code would never execute the case for the hard value 0.1.
I guess I can find a workaround like limiting the number of decimals to two digits, or rounding, or something… look at 1.3!! so much personality standing out returning 1.29 ! :slight_smile:

Running the same numbers returns always the same “noisy” values.

I don’t understand what’s going on?
Shouldn’t a hard value of 0.1 just print out 0.1, like 0.5 does? :sunny:

match case.toe (3.9 KB)
TD 2023.11600

https://0.30000000000000004.com/

In short, there is n such thng as 0.1 just a super awkward nearing to that. Why TD/Python prints it sometimes out one way or the other, who knows.

If you want to use switch cases/selection etc. always try to work in integers. So instead of matching 0.1 maybe try matching against 1 and 0.1*10

Thank you @alphamoonbase for that link, that was an interesting reading for sure, I wasn’t aware of that!

Thanks also for suggesting a solution, I appreciate that! In my particular case I need to keep the decimals, and the solution that worked best for me was print (round(val,2))

The link you suggested has a python example, that led me to the python decimal module, which I think it’s the real answer to my question.

  • Decimal “is based on a floating-point model which was designed with people in mind, and necessarily has a paramount guiding principle – computers must provide an arithmetic that works in the same way as the arithmetic that people learn at school.” – excerpt from the decimal arithmetic specification.
  • Decimal numbers can be represented exactly. In contrast, numbers like 1.1 and 2.2 do not have exact representations in binary floating point. End users typically would not expect 1.1 + 2.2 to display as 3.3000000000000003 as it does with binary floating point.