Timeline for Geometry Nodes: How to Read Last Digit of a Big Integer?
Current License: CC BY-SA 4.0
8 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Feb 4 at 11:50 | comment | added | Markus von Broady | I deleted the comment that you can't use string input, clearly you can, what I meant is, you can't animate a string input, and you can't store it in as an attribute... It's a 2nd class citizen. Also the interface doesn't allow you to neatly adjust a string as you do with an integer... | |
Feb 3 at 16:53 | comment | added | StefLAncien | This is related to "how/why do we get such a large integer ?". If it is from user input, use a string (as for the locker you show here: blender.stackexchange.com/a/311086/177431) ; if it is from algebra using "regular" integers, this is only GN internal storage so strings should do. Remaining without answer: could a GN node (such as "Domain Size") return such a large value ? | |
Feb 3 at 16:38 | comment | added | Markus von Broady | But how would you convert the input integer to a hex representation? I don't see any option to do that. | |
Feb 3 at 16:09 | comment | added | StefLAncien | A "brute force" approach might be to use hexadecimal representation (for example) of integers as string, and to develop new "Math " GN manipulating strings. Inside such nodes, an int32 might be decomposed as two float32. The internal algebra could be coded using standard Math GN. Then the result could be encoded back as a string. A challenge ? (side note: instead of HEX, chucks of 7 digits, as 1234567_8901234_5... ?) | |
Feb 3 at 16:07 | comment | added | Markus von Broady |
Exactly. But it gets worse. See even if you stay green, the internal implementation often uses floats or otherwise just fails. Try generating a random integer in range of MAX-2...MAX. You will get a negative integer. Try setting an integer attribute on curve, on both points set it to MAX. Resample to 3 points: the attribute becomes negative. BTW MAX = 2147483647 i.imgur.com/VvrDdTJ.gif
|
|
Feb 3 at 16:03 | comment | added | StefLAncien | I am sharing the same hope for a hack. After failure of the classical x-floor(x/10)*10 to get the last digit, I tracked down the round-off error and found that as soon as an integer socket is connected to a value/float socket, the last digits were lost. So the idea to use strings. But the "Value to String" node suffers the same limitation ! My conclusion is that we can rely only on nodes manipulating integers without conversion to float (green noodles should remain green...). I have to check yet, but I think there are not so many... | |
Feb 3 at 14:52 | comment | added | Markus von Broady | This is all correct, but question is, can a hack be used to obtain that digit anyway. For example my answer does just that, it just requires ridiculous processing power to do such a simple task. Imagine if "Value to String" had an integer input, it would then be possible to succeed by analyzing the string. Maybe I'm missing something that is possible... | |
Feb 3 at 14:17 | history | answered | StefLAncien | CC BY-SA 4.0 |