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.

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

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.

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.

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.

Yep, when doing financial stuff, those half cents can count.

> 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.

>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?