Python wrong outcome because it rounds my float value


My Excel is dutch =AFRONDEN() means =ROUND()

The Python values:
value 1 = 13 decimals
value 2 = 100 + value 1 (it should still have 13 decimals, but it seems to round)

if i do the same in Excel it seems to make the same mistake …

maybe someone can help me or explain why this happens?

Need help with precision in python

If you look at the amount of digits that are displayed this should help to identify the issue.

What seems to be happening is that it is limiting the displayed total numbers to 15(16 characters if you include the dot). This means the one with “10” at the start has 2 digits prior to the dot and 13 digits afterwards. Once you add 100 to it this means there is now 3 digits prior to the dot so therefore can only display 12 digits afterwards.


Yeah, for some reason 15 digits is the default. but this way it makes an calculation error :frowning:

here i see its possible to exceed the limit to 17 digits:

but i dont know if this is adaptable in python and if so, how?


I haven’t seen your python code so i cannot comment about it, but have you tried just adding .ToString() to the end of where the number is set to see what the outcome is?


I am unsure if the additional areas of what you have indicated can be added within the () for the tostring method, but you could try and see?


I’m trying to calculate how much times a dimension is dividable by (value 1 + value 2). if it automaticly rounds the outcome of (value 1 + value 2) for me, i get wrong outcomes.


It looks like, even though Dynamo is only displaying 15 digits, it is storing the float with full accuracy. See below:

dyn str vs float.dyn (18.3 KB)


you are running into the limits of double precision floating pt numbers:

The 53-bit significand precision gives from 15 to 17 significant decimal digits precision (2−53 ≈ 1.11 × 10−16). If a decimal string with at most 15 significant digits is converted to IEEE 754 double-precision representation, and then converted back to a decimal string with the same number of digits, the final result should match the original string. If an IEEE 754 double-precision number is converted to a decimal string with at least 17 significant digits, and then converted back to double-precision representation, the final result must match the original number.[1]

if you need more precision you will have to look into arbitrary precision numbers and math libraries.


Hi @Schasfoortyoeri

How about displaying decimal places like this?


@Kulkul that looks good! would it be possible to also calculate with it?

@kennyb6 made me this working code:

little explaination:

userinput: seam value = 700/65 in this case the 10.(alot decimals)
userinput: brick value = 100

in python brick = seam + brick 110. (alot decimals, in this case)

and because of the rounding somewhere in python it always gives me the else case instead of elif.

@Mostafa_El_Ayoubi we currently use the Data Shapes package to input number value’s (which always works if they are readable numbers)
would it be possible to let the user give the division? 700/65 is alot easyer than 10.7692307692308


Yes! Could you describe more what you want to calculate.


@kulkul i think the link in my last post was the best description. Also the script works, it Just seems not precise enough in case the user inputs alot decimals. In the example in the picture below it works (its calculating the dimension.below value based on dimension value)



if it automaticly rounds the outcome of (value 1 + value 2) for me, i get wrong outcomes.

Excuse me if i’m being stupid, but your number is going off to infinity…

So there has to be rounding?

I’m probably misunderstanding… But I tried to suggest (badly) in the previous thread, that it’s surprisingly hard to establish from the calculating values whether a calculated number will be correct to a specific decimal place.

My experience with your method is that it works for 99% of cases. I showed a graph which instead works off the calculated values, finds the surrounding correct numbers and compares them.

Apologies if I’ve gone off on a tangent.



@Schasfoortyoeri You mean like this?


@Kulkul no exactly, i ll give an example of what i m trying to achieve:

With the current code it gives me 65 X + R (which is not right.)


please read the link I posted above. double precision math is not arbitrarily precise.
The key quote is:

The 53-bit significand precision gives from 15 to 17 [significant decimal digits]( precision (2−53 ≈ 1.11 × 10−16).


Yes, i was allready affraid but hoped for a work around… thanks all