Hey there!
I was working on a GeoNodes rig where I needed to input a very large number.
8419326.85, specifically.
But for some reason the value node won't accept that number for me. It will round up, while keeping .000 for decimals.
I figured I'd ask here if the same happens to anyone else?
Here's a quick video demonstrating what's going on for me: https://youtu.be/cGqlmrN_9EY
If it's not just me I'll just add a Report in for Blender. I'm using Blender 5.2 LTS.
Hi Nathi,
That number might need a 64 Bit representation and I don't think Blender would reserve that much place for each Float.
To clarify: at least in C (and probably also in C++) you need to 'tell the computer' how much data storage needs to be reserved on declaration of a variable (at least that's how I remember that it used to be in the 80's and as far as I know, C hasn't changed).
Let me be clear: I don't really know what I'm talking about and you can report it as a bug, even if it's just to get a clear answer, but it sounds to me like the number just won't fit in the memory that's reserved for a float.
That's wild! But makes sense! I reported it just to a least learn what the limit is.
Also to double check on the when it doesn't round the number, but randomly changes the decimals.
It started behaving somewhat odd in the 10s of thousands. But the interesting part is that millions are fine, as long as we don't throw decimal points at it.
Here's the report, in case anyone tested other numbers that were odd:
https://projects.blender.org/blender/blender/issues/162530
It's quite complicated how floating point numbers are stored (look up IEEE 754 and then close the page again, before you fall into the rabbit hole). If I'm not mistaken, not just the absolute size of the number matters, but also the amount of (significant) digits. And your number with 9 decimals and starting with an 8 might very well be too large.
The behaviour has been there forever. Remember seeing it a long time ago and just checked in 3.6 and it's the same. Think I stumbled upon it because I usually work in mm and at some scale that just isn't feasible anymore and produces errors like this too. Not that I know anything about what would cause this. 😁
I'm just gonna trust Martin on that.
Actually using different value nodes in smaller increments, or round numbers, and adding them up does indeed work Martin.
For my purposes on this project the .85 in 8.5 million was negligible, but I can imagine that could be a proper workaround for you Sascha. For precision down to the mm it can indeed make a difference. Let's see what they say from the report.
Maybe. But then again once I get into the millions of mm it's easier to just switch to a different unit and go decimal.
I think it's just a limitation of the variable. {Float in this case) Basically it breaks down to something like this: First bit is the sign. (Negative or positive) Bits 2 through 12 determine the exponent. Bits 13 through 64 determine the number. Then there is a precision level of the floating point processor built in the CPU.
