4 ms·
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 bit
by 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 agoAnd 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 agoExactly. 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 agoWhy 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?