5 ms·

I don't know if the popularity of this on HN is a case of the emperors new clothes, or if I am really missing something, but to me this is sophomoric. There is

I don't know if the popularity of this on HN is a case of the emperors new clothes, or if I am really missing something, but to me this is sophomoric. There is nothing inherently base-10 to finance or any other field. Finance deals in exact quantities but that is because it deals in exact units. E.g. if a single stock tick is 0.1 cents, then a 0.11 cent increase is as meaningless as a 1/30 cent increase. There is no more need to represent arbitrary exact decimals as there is to represent arbitrary exact binary decimals. All that finance needs is integer multiples of the relevant unit. And presumably this is already hardcoded into their COBOL or FORTRAN code. Nothing presented on that page made me thing that DEC64 would be useful for anything that integer arithmetic in the right units would not be better suited to.

ArchD 11y ago
You may not know beforehand that the smallest unit is $0.01. What if it becomes $0.001 or $0.0001 later? You'll have to migrate your data to use the new smallest unit. If you use decimal floating point, you don't need to deal with that.
tomsmeding 11y ago
Totally agree! If you want to calculate with cents, or tenths of cents for that matter, just use an integer based on that unit. You have not just 56, but 64 bits of precision, and no loss of generality in the money field.
- detaro 11y ago
  And then you get a conversion rate with 1/1000 of a cent, and you have to manually make sure your fixed point gets converted correctly. Or worse, you get a conversion rate input with a variable number of digits after the decimal point, and you have to use all of them. For simpler cases this is fine, but for more complex ones I suspect the mental overhead for developers would get problematic.
  - pgaddict 11y ago
    Exactly. Then you realize you need to deal with values with different scales, because "amount of money" may need 2 decimal places while "exchange rate" may need 3, so you start tracking scales. At which point you've just reinvented basically the same data type as described here.
  - robert_ 11y ago
    Why not just represent different currencies as different "types" and a quantity of their basic unit (cents for $, pennies for £, tambala for Kwacha) and have standard conversions between them: kwacha_t my_kwacha = 100000; // 1000 Kwacha euro_t my_euro = EU_from_kwacha(my_kwacha); printf("My Kwacha in Euros: %d", my_euro / 100); Most of the problems discussed seem to resolve around trying to have some universal monetary unit, which isn't possible in practice anyway. Just settle on a universal currency for international trade (as the $ effectively is) and convert from/to as necessary for local representation. Of course you're going to have to select an appropriate "minimum value" of your selected currency to suit your expected conversions but how is that different from selecting an appropriate epsilon?
pgaddict 11y ago
Really? So what about exchange rates or interest rates, for example? Surely those are not multiples of "revelant units".
batbomb 11y ago
Chavez - Little Twelvetoes (from Schoolhouse Rocks! Rocks) https://www.youtube.com/watch?v=p2H6RLKGNDc https://www.youtube.com/watch?v=p2H6RLKGNDc

ArchD 11y ago

You may not know beforehand that the smallest unit is $0.01. What if it becomes $0.001 or $0.0001 later? You'll have to migrate your data to use the new smallest unit. If you use decimal floating point, you don't need to deal with that.

tomsmeding 11y ago

Totally agree! If you want to calculate with cents, or tenths of cents for that matter, just use an integer based on that unit. You have not just 56, but 64 bits of precision, and no loss of generality in the money field.

detaro 11y ago
And then you get a conversion rate with 1/1000 of a cent, and you have to manually make sure your fixed point gets converted correctly. Or worse, you get a conversion rate input with a variable number of digits after the decimal point, and you have to use all of them. For simpler cases this is fine, but for more complex ones I suspect the mental overhead for developers would get problematic.
- pgaddict 11y ago
  Exactly. Then you realize you need to deal with values with different scales, because "amount of money" may need 2 decimal places while "exchange rate" may need 3, so you start tracking scales. At which point you've just reinvented basically the same data type as described here.
- robert_ 11y ago
  Why not just represent different currencies as different "types" and a quantity of their basic unit (cents for $, pennies for £, tambala for Kwacha) and have standard conversions between them: kwacha_t my_kwacha = 100000; // 1000 Kwacha euro_t my_euro = EU_from_kwacha(my_kwacha); printf("My Kwacha in Euros: %d", my_euro / 100); Most of the problems discussed seem to resolve around trying to have some universal monetary unit, which isn't possible in practice anyway. Just settle on a universal currency for international trade (as the $ effectively is) and convert from/to as necessary for local representation. Of course you're going to have to select an appropriate "minimum value" of your selected currency to suit your expected conversions but how is that different from selecting an appropriate epsilon?

pgaddict 11y ago

Really? So what about exchange rates or interest rates, for example? Surely those are not multiples of "revelant units".

batbomb 11y ago

Chavez - Little Twelvetoes (from Schoolhouse Rocks! Rocks) https://www.youtube.com/watch?v=p2H6RLKGNDc https://www.youtube.com/watch?v=p2H6RLKGNDc