3 ms·

Decimal floating point is a standard that some people use and which even has hardware support in some IBM cores. https://en.wikipedia.org/wiki/Decimal_floating

Decimal floating point is a standard that some people use and which even has hardware support in some IBM cores. https://en.wikipedia.org/wiki/Decimal_floating_point https://en.wikipedia.org/wiki/Decimal_floating_point

eru 3y ago
You can do that, but I think for most applications where you want decimal, you can get away with fixed point computation? Eg if you want to calculate with money, just specify everything in terms of cents (or 0.001 of a cent or whatever), and then use an integer data type. Perhaps even an unlimited size integer data type.
- afiori 3y ago
  I feel like at some point the performance hit of using actual rationals (pairs of bignums) makes sense
  - adgjlsfhk1 3y ago
    The downside of rationals is that they degrade extremely quickly as soon as you take a sqrt or do trig. Decimal floating point has the advantage of losing accuracy in the places people are used to.
    - afiori 3y ago
      I believe that for almost all rationals trig functions never return a rational so you must have some kind of rounding tecnique. An advantage of rationals is that you have much more freedom in handling how the rounding works, for example you can limit your rounding to produce fractions n/2^m and then they behave sort of like floats or n/10^m and then they behave like decimals while still being able to know that basic arithmetic operations (+, *, -, /, <, <=, <>, mod, exponentiation by integer) work as precisely as you want them to. GPUs, ML, an massive numericall processing will want to always use floats, ints, posits[0] with operations that can be efficiently implemented in hardware but most apps could easily afford to use bigint/bigint rationals for most things. [0] https://spectrum.ieee.org/floating-point-numbers-posits-processor https://spectrum.ieee.org/floating-point-numbers-posits-proc...
- wruza 3y ago
  And don't forget to adjust after multiplication, e.g. ($ * kg) = (price * qty) / (10 ^ qty_scale). But not before you finished with a "sequence-point" in calculations, cause otherwise rounding will accumulate, e.g. ((price * qty) * (100 * (10 ^ pct_scale) - discount)) / (10 ^ (qty_scale + pct_scale)). Thus no operator[+-*/%^] magic for you either. Also, all these temporary ...0000000s will bite into your "mantissa" part along the way. Fixed point sounds reasonable until you have to actually implement a sales/debt/tax/trade-related routine that takes a couple of pages with proper decimals alone.

eru 3y ago

You can do that, but I think for most applications where you want decimal, you can get away with fixed point computation? Eg if you want to calculate with money, just specify everything in terms of cents (or 0.001 of a cent or whatever), and then use an integer data type. Perhaps even an unlimited size integer data type.

afiori 3y ago
I feel like at some point the performance hit of using actual rationals (pairs of bignums) makes sense
- adgjlsfhk1 3y ago
  The downside of rationals is that they degrade extremely quickly as soon as you take a sqrt or do trig. Decimal floating point has the advantage of losing accuracy in the places people are used to.
  - afiori 3y ago
    I believe that for almost all rationals trig functions never return a rational so you must have some kind of rounding tecnique. An advantage of rationals is that you have much more freedom in handling how the rounding works, for example you can limit your rounding to produce fractions n/2^m and then they behave sort of like floats or n/10^m and then they behave like decimals while still being able to know that basic arithmetic operations (+, *, -, /, <, <=, <>, mod, exponentiation by integer) work as precisely as you want them to. GPUs, ML, an massive numericall processing will want to always use floats, ints, posits[0] with operations that can be efficiently implemented in hardware but most apps could easily afford to use bigint/bigint rationals for most things. [0] https://spectrum.ieee.org/floating-point-numbers-posits-processor https://spectrum.ieee.org/floating-point-numbers-posits-proc...
wruza 3y ago
And don't forget to adjust after multiplication, e.g. ($ * kg) = (price * qty) / (10 ^ qty_scale). But not before you finished with a "sequence-point" in calculations, cause otherwise rounding will accumulate, e.g. ((price * qty) * (100 * (10 ^ pct_scale) - discount)) / (10 ^ (qty_scale + pct_scale)). Thus no operator[+-*/%^] magic for you either. Also, all these temporary ...0000000s will bite into your "mantissa" part along the way. Fixed point sounds reasonable until you have to actually implement a sales/debt/tax/trade-related routine that takes a couple of pages with proper decimals alone.