Float/Integer overload?

Question

Attached is a Geometry nodes timer in days, hours, mins, seconds. The clock is... nothing special. It takes the days, hours, minutes seconds input, evaluates everything into seconds, adds the frame time, then re-composes the time into a dynamic string.

If you enter 192 days in the Group input and run the animation, the clock turns over as you'd expect.

If you enter 193 days or over, things get weird.

The maximum value of seconds is 31 million - easily handled by floats or integers. But the value doesn't increment regularly if days exceed 193 or so.

Any help?

Answer 1

Geometry Nodes floats are implemented as IEEE 754 float32(). This means the mantissa part has 23 bits. Mantissa encodes a value between 1 and 2. This means that $\text{mantissa}^{exponent}$ can use an exponent of 23 (it's not a coincidence it's the same number as the number of bits of mantissa¹) to encode the smallest value $8388608.0$: 01001011000000000000000000000000

and the biggest value $16777215.0$: 01001011011111111111111111111111

Then for the next number you need to increase the exponent and start at mantissa = 0 (implied +1):

01001011100000000000000000000000

Problem is, at this point you can't increase the number by 1 again, because you ran out of the float precision: the smallest possible change to mantissa is ${1\over2^{23}} = 0.00000011920928955078125$:

$$1 × 2^{24} = 1 × 16 777 216$$ $$1.00000011920928955078125 × 2^{24} = 16777218$$

For the above screenshots I used a great tool to play with floats32:

h-schmidt.net: IEEE-754 Floating Point Converter

Here's a Q&A about C#, but it implements the same IEEE 754 standard as C/C++ used by Blender:

Why does a float variable stop incrementing at 16777216 in C#?

Geometry Nodes context

The problem in regards to geonodes comes down to the fact there are no nodes for mathematical operations on integers. So whenever you do stuff like modulo, you need to connect an integer to a float socket, which converts the variable and loses precision in the process. I ran into this problem here:

How can I re-sort the points/indexes of an object in geometry nodes?

If you read into the comments you will see how Quellenform, upon testing, discovered the setup starts failing at large geometries, and I later discovered it starts failing after exactly $4096$ vertices: that's because I square my geometry there, and $4096^2 = 16777216$, Once you exceed that number, doing divmod to get the row/column of a squared geometry starts failing. In my case the solution was easy, nowadays when I square geometries I do it like so:

In your case it's not immediately obvious what the algorithm should be, except that you shouldn't add all the days, hours, minutes, seconds together to then modulo them; you want to avoid big numbers, so if you e.g. want to be able to input a number of days with a fraction part (I imagine that's why the socket types are floats), then take the fraction part, multiply by the 24 and add to hours, then take the fraction part of that, multiply by 60 and add to minutes etc.

¹ - the logic is, the right-most bit of mantissa means either $0$ or $1\over 2^{23}$ to be added to fractions described by other bits (the exponent in each fraction is the number of the bit). So ${1\over 2^{23}} × 2^{23} = {2^{23}\over 2^{23}} = 1$. So for any float, once the exponent is equal to the number of (explicit) bits in mantissa, the minimum step becomes exactly $1$:

>>> import numpy as np
>>> np.nextafter(np.float16(2**10), np.float16(inf))
1025.0

>>> np.nextafter(np.float32(2**23), np.float32(inf))
8388609.0

>>> nextafter(2**52, inf)
4503599627370497.0

(the mantissa in float16 has 10 explicit bits, and in float64 used by Python has 52 explicit bits)

For some interesting bugs in integer domain, related to the fact underlying implementation uses floats32, see this:

Geometry Nodes: How to Read Last Digit of a Big Integer?