4 ms·

True, but the extra code around those solutions cost gas, of which your looking at around 500 lines worth. How long is BigDecimal.class?

SanFranManDan 9y ago
Likely you don't need a generic implementation of Decimal. What money do you want to represent, they all have a "atomic value". For instance, when working with dollars store cents. When working with Eth, store wei. etc. I can't think of a use case of money that needs decimals except maybe computing ownerships percentage. but that should never be stored, but rather computed. Anything that needs to be converted is a "front end" view. all computations should use atomic store of value, thus no conversion is needed in contracts.
- aquadrop 9y ago
  You might need to work with fractions of "atomic values" to get the desired level of accuracy. So you have to store not logical cents, but 1/100th of cents or something like that. Much easier and straightforward just use decimal-like type.
  - jackpeterfletch 9y ago
    Yep, when doing financial stuff, those half cents can count.
  - mbrock 9y ago
    That's what happens in e.g. the Maker stablecoin project. Decimal fixed point to give sub-wei precision when prorating per-second compounding fees. Other than the normal simple arithmetic operations, we use "exponentiation by squaring" to take a decimal fixed point raised to an integer power.
- dragonwriter 9y ago
  > What money do you want to represent, they all have a "atomic value". This is mostly not true. > For instance, when working with dollars store cents. While external transactions often must occur in cents, internal accounts and unit prices often have smaller amounts. If you don't believe me, visit any US gas station and the prices will be in mils, not cents (and will usually be one mil less than some full-cent value per gallon.) Atomic units for financial applications are application-specific if there is an appropriate value at all, they aren't trivially determinable by looking at the base currency. In some cases you really want an arbitrary precision decimal (or even rational) representation.
- alasdair_ 9y ago
  >For instance, when working with dollars store cents. How does this work of you are, say, coding for a gas station where the price is in 1/10ths of a cent? Alternatively, how does your banking application handle adding 10% interest to a bank account with 1c in it?
Slartie 9y ago
Providing a decimal type would of course not be the job of the developer of a smart contract - I would expect that the smart contract platform would anticipate the necessity of convenient decimal number handling and thus provide a suitable abstraction. In the case of Ethereum, it could either be provided in the language or on the virtual machine level. I'm not that much into the EVM's inner workings to judge whether a machine-level implementation would be a good idea from an architectural viewpoint, but it would definitely deliver the best possible performance and lead to the smallest amount of contract code, thereby saving on gas to deploy the contract. As a second-best solution, the language could provide such an abstraction - it would at least be able to apply optimizations when compiling the code down to EVM opcodes, which an implementation purely on the contract level would not be able to do.
- monocasa 9y ago
  EVM is a 256-bit architecture, so it probably doesn't a BigDecimal equivalent for financial transactions.

SanFranManDan 9y ago

Likely you don't need a generic implementation of Decimal. What money do you want to represent, they all have a "atomic value". For instance, when working with dollars store cents. When working with Eth, store wei. etc. I can't think of a use case of money that needs decimals except maybe computing ownerships percentage. but that should never be stored, but rather computed. Anything that needs to be converted is a "front end" view. all computations should use atomic store of value, thus no conversion is needed in contracts.

aquadrop 9y ago
You might need to work with fractions of "atomic values" to get the desired level of accuracy. So you have to store not logical cents, but 1/100th of cents or something like that. Much easier and straightforward just use decimal-like type.
- jackpeterfletch 9y ago
  Yep, when doing financial stuff, those half cents can count.
- mbrock 9y ago
  That's what happens in e.g. the Maker stablecoin project. Decimal fixed point to give sub-wei precision when prorating per-second compounding fees. Other than the normal simple arithmetic operations, we use "exponentiation by squaring" to take a decimal fixed point raised to an integer power.
dragonwriter 9y ago
> What money do you want to represent, they all have a "atomic value". This is mostly not true. > For instance, when working with dollars store cents. While external transactions often must occur in cents, internal accounts and unit prices often have smaller amounts. If you don't believe me, visit any US gas station and the prices will be in mils, not cents (and will usually be one mil less than some full-cent value per gallon.) Atomic units for financial applications are application-specific if there is an appropriate value at all, they aren't trivially determinable by looking at the base currency. In some cases you really want an arbitrary precision decimal (or even rational) representation.
alasdair_ 9y ago
>For instance, when working with dollars store cents. How does this work of you are, say, coding for a gas station where the price is in 1/10ths of a cent? Alternatively, how does your banking application handle adding 10% interest to a bank account with 1c in it?

Slartie 9y ago

Providing a decimal type would of course not be the job of the developer of a smart contract - I would expect that the smart contract platform would anticipate the necessity of convenient decimal number handling and thus provide a suitable abstraction. In the case of Ethereum, it could either be provided in the language or on the virtual machine level. I'm not that much into the EVM's inner workings to judge whether a machine-level implementation would be a good idea from an architectural viewpoint, but it would definitely deliver the best possible performance and lead to the smallest amount of contract code, thereby saving on gas to deploy the contract. As a second-best solution, the language could provide such an abstraction - it would at least be able to apply optimizations when compiling the code down to EVM opcodes, which an implementation purely on the contract level would not be able to do.

monocasa 9y ago
EVM is a 256-bit architecture, so it probably doesn't a BigDecimal equivalent for financial transactions.