just came across this in a setup where I evaluate many 3d points on several surfaces and extract only the points with 0.0 distance, but I could boil it down to this
really strange, feeding the data trough the panel fixes it, tried “reformatting” the sorted keys with a float container but no luck either.
I am a bit clueless here
edit*:
it is not the sort-keys node
thanks
how (visually) irritating!
I know, but it’s either this or all numbers become giant unreadable sequences of digits.
Hi David,
would this display be possible/make sense to you?
My impression, because the additional digits were removed, was that these values should be really 0.0
I’d say leaving the whole 0.000000 (without rounding) would also suggest that there has been some floating point calculation happening.
displaying something rounded to the smallest float 0.000001 instead of a “fake” 0.0 seems to make sense to me, maybe that could be a “display” option?
You can change the way Grasshopper formats numbers in the Preferences, but it won’t really ever solve the issues you’re trying to solve.
There are a lot of values close to zero, that are probably ‘meant’ to be zero if it wasn’t for floating point inaccuracy. The smallest non-zero value equals “4.94065645841247e-324”, which is not a particularly readable number. It takes me a good ten times longer to grok the magnitude of such a notation compared to “0.0”
One of the things I’d like to try for Grasshopper2 is to display additional information alongside numbers in the UI, for example by drawing a very small accurate representation underneath the larger, friendly notation, like so:
Solutions like this often require quite a mature text rendering api and I haven’t experimented enough to get a feel for what’s possible yet.
But it’s always important to remember that you simply cannot trust floating point numbers, ever. If your algorithm requires that some number has a specific value, your algorithm is wrong. That sort of specificity is only possible when using integer number types.
