We have run into an issue where we require a Big Integer / Big Number “class”. We are currently implementing our own, as no known typed Luau versions exist. I would really like to see Roblox implement a native version that exists in the same space as types like Vector3, CFrame, etc. We are limited by the speed of the Luau VM in our case and it is going to cause a massive CPU bottleneck long term.
I would like to work with Roblox to provide this features to the benefit of everyone on the platform.
The core issue as to why implementing this in native Luau is not being able to use full 32-bit integers, we can only use 24-bit words for the mathematics because otherwise it would overflow the integer precision available. To do this efficiently, we need access to 64-bit unsigned values - which is not possible in native Luau. I am hoping that Roblox engineering sees the use case of a class/module such as this, and that it prioritized with the sheer amount of simulators that exist on the platform.
Another requirement we have is the ability to quickly encode them into forms that would be acceptable for a DataStore, the solution we have chosen is to use an integer array. The integer array also stores meta information such as signum and scale.
There exists a lot of good implementations of Big Number / Big Integers out there, but none are Luau compatible with --!strict, and it would be nearly as much work to make them so. Not to mention that they are not exactly “fast” or lightweight.
Anyway, thank you!
UPDATE:
We have adjusted game design to basically “not care” about the imprecision on higher levels of currency values, allowing players to effectively purchase cheap items for free once they reach 2^53 and above. We decided that the effort required to adjust all of our inventory/saving systems was not worth it. This currency is also not a premium currency so it does not cause any issues on our end.
Yes, but you need 64 bits to compute x*y if both x and y are 32 bits, therefore you have to implement using 24 bit words. 24-bit words multiplied equals 48 bits, which is less than the mantissa of a double precision floating point.
So your premise that you need 64 bits to compute x * y if both x and y are 32 bits is incorrect.
Are you also (implicitly) suggesting adding math.imul in Luau with the semantics of returning the low 32 bit of a 64-bit resulted from a 32-bit integer multiplication?
You are emulating 64-bit math, that is painfully slow. Worse than using 24-bit words. The ideal/performant implementation of a BigInteger / BigDecimal system uses 32-bit words on a 64-bit platform. So, no, I am not implicitly suggesting the addition of that ‘imul’. I would like a natively implemented BigInteger/BigDecimal, along with potential future ability to declare and use C structs which contain C types, rather than being forever stuck with double’s.
UPDATE:
We have adjusted game design to basically “not care” about the imprecision on higher levels of currency values, allowing players to effectively purchase cheap items for free once they reach 2^53 and above. We decided that the effort required to adjust all of our inventory/saving systems was not worth it. This currency is also not a premium currency so it does not cause any issues on our end.
We’re open to extending bit32 library with additional integer methods like imul/idiv helpers when emulating those is too expensive, but big numbers and 64 bit integers should be a custom library implemented in Luau.
Luau buffers do not support reading or writing 64 bit integers. This wouldn’t even make sense considering that numbers only have integer precision up-to 53 bits.