One (from memory, not exact) calculation I've had to implement for a customer: Multiply prices by whole numbers. Prices are given in cents subdivided to 5 digit precision, result should have 10cent precision, rounded down. Then, for the tax calculation, get taxes from some tables, 3 different taxes for each line item. Apply the first two taxes, Euros with 10 digit subdivisions, then round "according to trade custom" (which is the usual "up from .5 cents, down from below .5"). Then add the third tax, Cents with 5 digit subdivisions, round down. Then add all the line items and their taxes, separately as well as together.
And if there is a Skonto, take care to properly unravel the tax stuff again.
I've had to do it in plain Typescript, it is possible, but it really sucks. Those days when you yearn for COBOL... ;)
Javascript has one number type; float.
2) Wow, those downsides are insane. It's not constant time, thus can't be used in cryptography...? Has huge performance impacts and can't be casted to a "number"- how is this implemented? it can't be native INTs on the CPU?
Is this to optimise memory operations over a large plaintext/cipher text or is there some other advantage to it that is less obvious (e.g. more resistant to timing attacks?)
I use this approach to minimize the amount of time I have to waste on trivial money operations such as storage and api's, but this approach (number of cents) falls apart quickly the moment you need to do something as simple as calculate tax or a commission. So, still likely no getting around proper float math even if you may not really be all that interested in sub-cent units.
You don’t need to work in decimal cents. Many work in thousandths of a cent or smaller. But you want an infinite upper and lower bound. Even 64 bit integers only has so much upper range depending on how far you subdivide a penny. You also want the precision guarantees when you take those numbers and do more than just add or subtract them.
With all numerical calculations, you need to be careful about losing precision on mathematical operations, so it's a good idea to think about things like this even if you use a decimal number system with a very wide dynamic range - it won't be very precise all the time.