algorithmic modeling for Rhino
Tags:
Hi Giulio:
I am following your formatting exactly, but get an error. Does the Evaluate component still work the same way in the latest version of Grasshopper?
Thanks! Justin
Yes, formatting has never changed as it works in the same way as standard .NET formatting.
Formatting rules are somewhat obscure but they are consistent and quite flexible. Basically your formatting string may contain any number of curly bracket pairs with non-negative integers in them:
"When {0} brings back {1} days and {2}"
The number inside the brackets refers to the data to insert in that location. In effect, {x} is a placeholder for actual data. The data inserted into a specific bracket pair is the data supplied in the latter part of the function. {0} refers to the first item, {1} to the second, {2} to the third and so on ad infinitum.
If I supply some data the entire expression may look like this:
Format("When {0} brings back {1} days and {2}", "Spring", "blue", "fair")
which will result in the string "When Spring brings back blue days and fair".
If the data you're inserting is a number (or a date) then you have additional formatting flags that you can use. These additional flags appear behind the placeholder index integer separated by a colon.
Format("Pi = {0:0.00} ({0:0.000000})", Pi)
The :0.00 means the number will be formatted using two digits. The other flag will enforce six digits, resulting in: "Pi = 3.14 (3.141593)"
--
David Rutten
david@mcneel.com
Poprad, Slovakia
Thanks David. I think I've got it. Unfortunately, this does not solve my real problem since the Orient (Change Basis Transformation) component seems to subtly change the length of objects. No matter how accurately I view the floating point numbers, the lengths of reoriented objects don't match their parent objects. Practically speaking, thi means that when I compare the lengths of oriented and unoriented objects in order to make corresponding labels, the wrong objects get referenced. (it isn't the best system anyway but it's the one I could think of...)
Any floating point operation is limited to the precision of double floating numbers (a bit more than 15 significant figures). So any math operation will produce inaccuracies.
In order to compare two floating point values, you should calculate the difference and check against a given (document-)tolerance.
@David: since this seems to pop up quite often, what about a "compare with tolerence" component?
Similarity sort of does this, but with a relative tolerance rather than an absolute one.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
Ok, but what about the math components?
I mean, most cases people actually need the equality component for numbers they don't want to compare numbers to the last significant digit. It just happens to work sometimes and if not, people end up asking about tolerance issues.
What would be the possible harm in implementing float equality "the right way"? Maybe with an option to deactivate document tolerance settings. Speed doesn't seem to be a valid argument when a single-cycle operation is encapsulated in a GH-component. ;)
The problem isn't speed, it's predictability. I can set an arbitrary tolerance for floating point comparisons but there will always be people with even less accurate numbers or people who have more accurate numbers and require that significance to be part of a comparison.
Floating point numbers will always have tolerance issues and it's not possible to write a smart comparison algorithm that will always tell you whether two numbers are identical within the implied tolerance.
I could replace the inequality output of the [Equality] component to be a Similarity output that performs fuzzy equality, but there will always be border cases and it will be much harder to explain the behaviour of the components when they are so 'smart' to begin with.
One question about fuzzy comparisons, should it be up to 6 or 8 or 10 decimal places in decimal notation or scientific notation? I.e. is 0.999998 the same as 1.000001? If yes, is 0.000001 the same as 0.000002? The difference between the first two numbers is 0.0003% but the second pair differs by 100%.
What about 1000000 and 1000010? They only differ by 0.001%
--
David Rutten
david@mcneel.com
Poprad, Slovakia
I see you point but let me play devil's advocate here.
GH isn't MATLAB, it's a tool to manipulate Rhino geometry. All Rhino geometry is bound to the document tolerance. No numeric value should be expected to have more precision than quaranteed by the tolerance setting. So one way or the other errors due to Rhino operations will creep in.
Most users will have a Rhino background, some may know their way around math but only very few will know about the problems and limitations of digital floats. They expect their curves to be the same length before and after the are rotated. They expect the equality component to just work.
In Rhino, if an operation on very small geometry fails, it's common sense to just allow for a few more digits of tolerance. Already there are some GH operations that work or fail depending on document tolerance.
Very large numbers are bad in Rhino because they mean the geometry is far from origin or a bad choice of units. Both to be avoided according to Rhino doctrine.
So very large numbers and numbers far below tolerance are bad In Rhino. I don't see any reason they shouldn't be bad in GH. At least for comparison.
Comparing the relative difference of 0.999998 and 1.000001 to 0.000001 and 0.000002 is a moot point, since both deviate below any reasonable Rhino tolerance. Both cases should be equal. As for 1000000 and 1000010, since both numbers deviate above reasonable tolerance the are not equal.
Numbers are not always related to distances, whereas the Rhino tolerance settings are. You could have two points that are further apart than a tolerance of 0.01 units, however when you project them onto a curve the difference between their projection parameters may well be less than 0.01.
I think it makes sense to add another output to Equality that compares maybe 12 decimal places instead of all 16 and call it "Implied equality" or something, but sooner or later people will run into floating point problems and I'd hate to be in a position where I have to explain the Grasshopper 'smart equality' algorithm before I can explain why two numbers really aren't equal.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
David:
Please take a look at the attached file if you have the chance. The edge lengths of the Reoriented Mesh have been rounded or are distorted from the original. I know that it is very slight, but I am trying to match shared edges in a larger, exploded mesh by length (to label them for fabrication). I think greater precision would allow me to this correctly. Can I get values that match between the original mesh and re-oriented mesh?! Many thanks!
Justin
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by