Does DAML support U256 (or another big numbers)?
Here are the built-in types, although note that BigNumeric was deprecated with 2.9.1.
Will daml bring back the BigNumeric at some point?
Hi @zhe_bd , It’s all a question of demand and justification of the cost. Just out of interest, if you had the choice between BigNumeric (arbitrary precision fixed point type) or low level binary types like U256 (the topic of this thread), which would you rather have and why?
Hi @bernhard ! Sorry for the late response! For some reason I thought I have already replied here.
We need U256 or BigNumeric for our CLMM implementation. Without them we will have to emulate but it is not ideal. Will it increase the node operators’ cost if we bring it back?
I think U256 gives you a lot more control over tx cost and size than BigNumeric and has more general applicability. BigNumeric is really there to do math with arbitrary precision - e.g. on-chain pricing. And how large it is once serialized is fairly opaque.
U256 can be used also for binary operations, cryptographic operations etc. and you know how much it adds to your transaction: 32 bytes.
Therefore I’d favour introducing U256 over bringing back BigNumeric.
Make sense! What does it take to introduce U256?
@bernhard do you think it is a good candidate for a dev grant project?
Hey @Lukasz2891 What did your team end up solving this issue?
Hi. This thread has kicked off an internal discussion about opening up the Daml language development and we are open to a dev grant. However, keeping Daml secure in such a model needs some considerations and we are discussing that. Please give us a couple of weeks and we’ll get back to you.
Make sense! I also created a grant proposal using a daml library approach instead of modifying the daml itself: Proposal: daml-u256 by zheli · Pull Request #177 · canton-foundation/canton-dev-fund · GitHub
Would love to hear your feedback on it.