> Rational numbers always give precise results, they don't introduce rounding errors and they don't require us to acknowledge a “smallest representable unit”<p>This is assertion may be invalid when the problem domain includes either (a) compound interest calculations that require calculating a rational number raised to a rational power, (b) expected value calculations with random variables drawn from a probability distribution such as the normal or exponential that is defined using transcendental functions, (c) any formula involving e, pi or the mathematician's favorite, those three little dots ...<p>For example, the asserted feature of rational arithmetic does nothing for one facing the 6th grade arithmetic problem that introduced us all to the shortcomings of decimal numbers when I went to school: One quart of paint covers 5 square feet; paint costs $2.75 per gallon; how much will it cost to paint a circle 4 yards in diameter?
> Interestingly, the value of most currencies is measured in terms of the value of other currencies, most of which have no value other than the trust recursively vested in them by civilization.<p>This doesn't make any sense. The value of any currency is measured constantly by its users conducting trades: when you buy a coffee, you're measuring the value of the currency used; when you pay for a haircut, you're measuring the value of the currency used. That is far more frequent and larger than FX trading.
Rational arithmetic is not a good choice for money, since applications that deal with money probably involve user input and so can be trivially DOS-ed. Money should use decimal arithmetic, like COBOL. If it's good enough for banks, it's good enough for you.
The value of a currency is the effort required to obtain it.<p>And transitively that boils down to time - expenditure of the finite lifespan of humans.<p>It's a proof of burn system.
Here's a (partial) porting to TypeScript <a href="https://github.com/gcanti/money-ts" rel="nofollow">https://github.com/gcanti/money-ts</a>
This is one of those articles interesting to new programmers. The actual answer is that currency is complicated; any small library you will write it likely to forget some complication; and, absent new open source you should go commercial. For example, glance over the list of classes in the "money.h++" which was sold decades ago (<a href="http://docs.roguewave.com/legacy-hpp/mnyug/2-9.html" rel="nofollow">http://docs.roguewave.com/legacy-hpp/mnyug/2-9.html</a>)<p>TL;DR: The article is Too Long; Don't Read.
> Money, in other words, mostly measures trust. This is less obvious for precious metals or cryptocurrencies because they have an intrinsic value of their own as well<p>Cryptocurrencies have intrinsic value? Did the author intent to write that or was it an accident? S/he has grouped precious metals, which have purposes from engineering to jewellery - with solutions to arbitrary cryptographic problems, which are useless for everything except swindling.
I'm a bit confused as to why they don't just keep the currency values in the smallest unit for each currency. They gave an example about un-used coins which seemed to be their justification, but I can't figure out why adding a "scale" is a better approach. Most of the other examples were backed up by the type system, so I feel like I'm missing something.