I have made the following setup:
As you can see, the assertion fails. The Custom Group is what you would expect:
(╯°□°)╯︵ ┻━┻
Some approaches I tried and failed
I figured you can calculate the biggest possible error you got upon conversion to float, by using an expression:
$$\operatorname{floor}\left(2^{\log_{2}n-24}\right)$$
floor(2**(log(number, 2) - 24))
or just much simpler 😜
$$\operatorname{floor}\left({n \over 2^{24}}\right)$$
n // 2**24
And at the end of the integer range $2147483647$ that error is no bigger than $128$. For simplicity I just assumed this maximum regardless of the input, because a loop of 128 iterations is no challenge for a computer (sure, should be optimized when dealing with many numbers).
So the idea is: just after converting the integer to float (add zero to the int) I can convert it back to an integer and see if it's smaller or bigger than the original integer (or equal if I'm lucky, but this case is simple). Then I can add/subtract the calculated error (or assumed $128$) and end up with two float values, one lower than the original integer, one bigger.
First approach was to spawn a curve with two points, and capture on them an integer attribute: the lower bound one the first point (start of curve), and the upper bound on the second point (end of curve). I captured it in the integer domain. Now upon resampling the curve to 129 points, I would expect the integer attribute to lerp with $1$ increments. This is where the idea fails, because apparently lerping is done using float32, even if the datatype is integer. Moreover, even assigning a single integer value to both endpoints before resampling, for a big integer, upon resampling produces a corrupted result (different integer, a negative one). If it actually worked properly, I could use my answer of a repeat zone, simply starting with a modulo $10$ on the lower bound, and iterating through the points, incrementing (mod 10) my digit only if the captured attribute on currently evaluated point is lower than the original integer.
An even more desperate attempt was to increment an integer using a "Random Value" node. I could take the lower and upper bounds, use integer comparisons and hopefully, using a ridiculous (but not 4 billion!) number of iterations emerge at the integer that is just 1 higher. This way I could iterate over 128 integers one by one, like I planned in the first solution. Moreover, I discovered a random integer just randomizes an integer in range from zero to the difference of max and min, and then adds min. So I can actually find a seed that for a random integer in range $[0, 128]$ gives me $1$ and then I can use the same seed for a bigger range to the same effect. Except, again, at big integers the node breaks:
- I tried to simplify the StefLAncien's answer (the first one that actually worked!), by simply spawning the input number of points (at first I disregarded this option thinking it would take too much memory, and went for a repeat zone that shouldn't take any memory and just take long time - turn out I was wrong), detect if the integer converts to a float by going down or up, in the second case just add 128 more points (or less, as I argued earlier; hardly matters for performance) separate the points with indices larger than than the float, take modulo of the separated domain size (subtract 128 if you added it earlier), take modulo of the float, add together, take modulo again. But I discovered yet another integer related bug!
The above turned out to be a tooltip bug - thanks scurest!
At this point I'm thinking... Maybe we should consider big integers just not supported? Maybe we shouldn't limit integer inputs to the big range of $[-2147483648, 2147483647]$? It clearly just doesn't work, we should limit the range to $[-2^{24}, +2^{24}] = [-16777216, +16777216]$