falsehood-prices.md

Falsehoods programmers believe about prices

1. You can store a price in a floating point variable.
2. All currencies are subdivided in 1/100th units (like US dollar/cents, euro/eurocents etc.).
3. All currencies are subdivided in decimal units (like dinar/fils)
4. All currencies currently in circulation are subdivided in decimal units. (to exclude shillings, pennies) (counter-example: MGA)
5. All currencies are subdivided. (counter-examples: KRW, COP, JPY... Or subdivisions can be deprecated.)
6. Prices can't have more precision than the smaller sub-unit of the currency. (e.g. gas prices)
7. For any currency you can have a price of 1. (ZWL)
8. Every country has its own currency. (EUR is the best example, but also Franc CFA, etc.)
9. No country uses another's country official currency as its official currency. (many countries use USD: Ecuador, Micronesia...)
10. Countries have only one currency.
11. Countries have only one currency currently in circulation. (Panama officially uses both PAB and USD)
12. I'll only deal with currencies currently in circulation anyway.
13. All currencies have an ISO 4217 3-letter code. (The Transnistrian ruble has none, for example)
14. All currencies have a different name. (French franc, "nouveau franc")
15. You always put the currency symbol after the price.
16. You always put the currency symbol before the price.
17. You always put the currency symbol either after, or before the price, never in the middle.
18. There's only one currency symbol for any currency. (元, 角, 分 are increasing units of the Chinese renminbi.)
19. For a given currency, you always, but always, put the symbol in the same place.
20. OK. But if you only use the ISO 4217 currency codes, you always put it before the price. (Hint: it depends on the language.)
21. Before the price means on the left. (ILS)
22. You can always use a dot (or a comma, etc.) as a decimal separator.
23. You can always use a space (or a dot, or a comma, etc.) as a thousands separator.
24. You separate big prices by grouping numbers in triplets (thousands). (One writes ¥1 0000)
25. Prices at a single company will never range from five digits before the decimal to five digits after.
26. Prices contains only digits and punctuation. (Germans can write 12,- €)
27. A price can be at most 10^N for some value of N.
28. Given two currencies, there is only one exchange rate between them at any given point in time.
29. Given two currencies, there is at least one exchange rate between them at any given point in time. (restriction on export of MAD, ARS, CNY, for example)
30. And the final one: a standalone $ character is always pronounced dollar. (It's also the peso sign.)

How about IDR, which has a subunit, but it's not generally used or displayed. (due to it's very low value)
This recently bit me when I was working on an integration. All of the third-party APIs I was interacting with required passing integer amounts of subunits.
This would be fine, except that some third-parties considered IDR to have a subunit, and some considered it to not have a subunit.
(the ISO standard is to treat it as a currency with a subunut, but some software doesn't care about standard)

In the end, I ended up juggling a different representation of IDR in my api integreation for a particular third-party and had to handle conversions to and from.

So maybe the bullet points would be:

• If a currency has a subunit, the subunits should be displayed.
• A currency either has subunits or it does not. (e.g. IDR)

How about: "Any valid money in a currency can be withdrawn from the bank in cash". Counterexample: CHF is subdivided into 100, but the smallest coin is 5.

After reading this list I was wondering what the best way would be to model currencies in general while respecting all these specifics.

It seems to me that prices in any given currency should always form a vector space: Obviously we can add and subtract prices. But we should also be able to multiply them by e.g. tax rates, discounts etc. So I think requiring those two operations to be always implemented for any given currency (and you may be able to reuse some code for currencies that share similar features), you should be able to write generic price calculation code for any past, present or future currency.

But maybe I'm missing something.

After reading this list I was wondering what the best way would be to model currencies in general while respecting all these specifics.

You can't. In the real world, you try your best, but you often have to pick the assumptions you can live with. And not just in currencies. Languages, names, dates, addresses, ages... Trying to account for every single scenario is a recipe for madness.

After reading this list I was wondering what the best way would be to model currencies in general while respecting all these specifics.

The Common Locale Data Repository (CLDR) does a pretty thorough job of describing currencies and their decimal digits, output formatting, parsing, rounding (cash and accounting) and symbols in a localised fashion.

See number and currency formats, currency symbols and currency format localisation.

About yen and triplets: large sums are actually are written in triplets, not in fours as it can be expected from the actual number system. It is sure confusing, but that is the life.

Large numbers (and therefore also prices) are written in pairs followed by a single triplet on the Indian subcontinent like this: 10,00,00,000 (https://en.wikipedia.org/wiki/Indian_numbering_system)

@MartinThoma The example used in #4 also works for #3, since #4 is a more specific version of #3. The Wikipedia page for MGA lists denominations like 1/5 and 2/5, so presumably you'd talk about 1 1/5 ariary rather than 1.2 ariary. But the website of Madagascar's central bank does list these coins in a decimal format, as ARIARY 0,4 and ARIARY 0,2, so maybe Madagascar has switched to a decimal format since this Gist was written? I don't know how the currency is actually used in practice.

Hi @MartinThoma @newtrat,

To give more context about this, it's not that MGA is not subdivided to decimals by definition, but "de facto", we have always avoided them.
First, our smallest used coin is 10 Ariary so it's almost impossible to use decimals in real life. Also a large number of the remote population have not been to school and using decimals makes life really hard for them.
On the other hand, with the raise of mobile banking and "electronic" money, we tend to use more and more decimals for online purchases and rate conversions with other currencies.

A falsehood parallel to #10 and #11 might be “all transactions are conducted in a single currency.” In Cambodia USD is widely circulated, but only in bills — change of less than $1 is returned in KHR. So e.g. if one purchases something costing 5.75USD with a 10USD note, the change given might well be 4USD + 1,000KHR.

I'm curious if anyone knows the counter-example for #17 (never in the middle)? That's the only one I haven't run into.

@stephenwilcoxon Found on Wikipedia: the Cape Verdean escudo and the defunct Portuguese escudo. Also, the defunct French franc, as reported in this Stack Exchange answer.

Item 15+16: Wikipedia has a nice list of which countries that put the Euro symbol (€) before or after the amount: https://en.wikipedia.org/wiki/Language_and_the_euro#Summary