You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of the crypto projects are now using u128 for token balances and u32 for scales, would be great to have a u128 method, right now i am just using the i128 one but its off course unsafe as it might overflow.
The text was updated successfully, but these errors were encountered:
It's certainly possible to introduce a try_from_u128_with_scale however it should be noted that if the i128 is at risk of overflow then it is more than likely not going to be representable in Decimal either. (i.e. the max i128 is 2^127 - 1 whereas the max Decimal is currently 2^96 - if an u128 will overflow an i128 then it'll certainly overflow the Decimal).
That being said, I am looking at increasing the capacity of Decimal via configuration in V2. Issues such as #480 are intended to start tracking how this can be performed whilst still maintaining the high performance of operations. The idea is to make the mantissa component configurable - I'm currently looking at extremely high precision options and experimenting with that. This is just an experiment at the moment however, and not yet ready for use.
All that being said, an existing library which does allow greater precision at the expense of speed is bigdecimal-rs. Internally it uses a BigInt which can easily grow to a u128 and larger. Could this be a better fit?
Many thanks for your reply! I do not have any performance requirements in my use case so yeah maybe bigdecimal is a better fit, haven't tried that and thanks for the hint :) will close this for now.
Most of the crypto projects are now using u128 for token balances and u32 for scales, would be great to have a u128 method, right now i am just using the i128 one but its off course unsafe as it might overflow.
The text was updated successfully, but these errors were encountered: