I wonder if it is posible to adjust dynamo’s accuracy to less decimals
Actually i’m programming some foundation slabs made by the lines created, in turn, by the unión of some points and i have some problems due to the imprecisión of their rounding method
The fact is that i have to group points which has the same “x” or “y” component” in order to make an ortogonal grid of this foundation slabs, but i cannot group this “x” or “y” list factor by their keys cause their values are infinitesimaly different! Okay, really they are the same, i mean those points are aligned in “x” or “y”, but i don’t know why dynamo adds this error
Look what happen with this marked “Y” value in blue and red that should be grouped BOTH in list number 4 at the “List.Groupbykey” results:
I understand that this is frustrating, but the truth of the matter is, the alternative (setting a defined precision) would cause way more problems than it would solve. Most of those rounding “errors” are due to Dynamo tracking high levels of precision (often beyond what the initial geometry or computation used) in order to not lose precision over time. Rounding to make comparisons is standard practice and worth while in most cases.
There’s also the matter of natural error. Even within a digital environment where most values can be input directly, it’s possible to end up with objects (points for example) that look the same, act the same, and should be the same, but aren’t. In those cases you’re going to have to use some level of tolerance anyway. This even happens with the natural conversion of units or any non-terminating decimal.
Using a default rounding setting across the board would only help these cases until it didn’t. Then it would be a mess.
(Also it’s worth remembering, especially in this context, that precision is not the same as accuracy. Just because the value doesn’t seem accurate doesn’t mean that the precision isn’t necessary.)
So you likely don’t really want Dynamo to round these values. You think you do, but that will cause other issues with the graph. But method for this is to set the geometry scaling. Another method and what I would do is leverage the Point.PruneDuplicates node to remove duplicated points in a particular scope.
The method which will give you the most control will be to leverage the Math.Round node to shift the X and Y values to a given precision.
Uhmm, so I understand this is caused by software limitations? I was wondering if you know any way to set the round type to another that could be more accurate with the pretended result
I mean, I’ve tryed with “ToZero”, “ToEven”, etc… but still I can’t make -0,35499999999 and -0.35500000000000000000422 became both a -0.35 But maybe this is what you’re telling me is not possible, isn’t it?
Sticking to mathematics here, but if I’m not mistaken, when rounding to “0.00” precision, any software will take the third decimal and use a conventional rounding rule to make the exchange.
This means -0,354xx will round to -0,35 and -0,355xx wil round to -0,36. The same apply for positive values.
This is what I was thinking about. Two different rounding rules should be applied on the same list based on the desired value.
I was thinking on scaling and using ceil, floor, scale back, or truncate to 2 decimals, but all would result in the same (undesired) results one way or another as some should be rounded up, and others rounded down.
I would rather check why there is that deviation in the Y values if they should be on the same orthogonal line.
That’s because you’re rounding to the wrong precision.
Your values aren’t -3.54 and -3.55. They’re -3.549999 and -3.550000. If you round to 1 or 2 decimals they won’t match. It’s a high precision value so you can use a high precision rounding. I usually use 7 or 8 (I think Revit only tracks to 8 decimal places?).
No, it has to do with two things neither of which are related to Dynamo, the first is your data the second is how computers work.
To address the first, we don’t know the origin of your data. It could be user generated points (i.e. someone clicked in Autocad). It could be from interop (i.e. bringing data from AutoCAD to Revit to Civil 3D to GIS to Forma to Infraworks to Revit and back to AutoCAD). It could be from a external data input (i.e. someone going on site and taking some pictures). It could be from pretty much anything. Without that information no one can even start to ‘guess’ as to the cause.
The other thing at play is how computers work. They only work with 1’s and 0’s. But when we provide a number (let’s say 8), that is neither a 1 nor a 0 and so the computer has to do some magic to convert from our base 10 system to a base 2 system. As such just about every language out there will return values like this: .1 + .2 = 0.3000000000000004. This happens in Python (any engine), Javascript, C#, and even excel (try putting this formula into any cell with the precision turned up to 15 digits: =(43.1-43.2)+1).
And so Dynamo is being as accurate as any other part of your system. The reason you don’t usually see these issues is because the software developers take into account how to display the values they present to you, often rounding to 2 digits, or 6 digits, or no digits as the use case may be (prices round to 2 digits, while the location of a point on site would likely round to 1 mm, while the GIS coordinates would likely round to 6 digits as that is a grain of sand levels of precision).
So to go back to the original question: “how do we adjust accuracy?” the answer is you don’t. You modify the data to be at the precision you want, or let the cull points for you (i.e. via the Point.PruneDuplicates node).
