6 ms·

“The best way to store money or time is using int64/bigint” is a hill I’m willing to die on.

by encoderer 3y ago

jandrewrogers 3y ago
Zimbabwe has entered the chat.
- deleted 3y ago
  [deleted]
- nequo 3y ago
  First I thought you were joking. But as of February 2, 2009, 1 ZWL (third re-denomination) was equal to 10^12 ZWR (second re-denomination), 10^22 ZWN (first re-denomination), and 10^25 ZWD (original currency).[1] 1 ZWL does not fit in a 64-bit integer if converted to ZWN or ZWD: log2(10^22) = 73.08 log2(10^25) = 83.05 Bigint would work though. [1] https://en.wikipedia.org/wiki/Zimbabwean_dollar#History https://en.wikipedia.org/wiki/Zimbabwean_dollar#History
John23832 3y ago
Int64 wouldn't work because it's not floating point. You'd need to store the base and the mantissa separately for calculation. However there are languages that are looking at F128 (https://rust-lang.github.io/rfcs/3453-f16-and-f128.html https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). The problem is that there isn't really hardware support for them yet so you'd do it through software.
- hortense 3y ago
  To store dollars with a precision of 1 cent, you store into your integers cents instead of dollars. No need to mess with anything more complicated.
  - pests 3y ago
    Gas is sold in 9/10th of a cent fraction. What now?
    - hortense 3y ago
      To store dollars with a precision of 1/10 cent, you store into your integers 1/10 cents instead of dollars.
  - John23832 3y ago
    >To store dollars with a precision of 1 cent, you store into your integers cents instead of dollars. No need to mess with anything more complicated. As someone who does it, financial math is often done at a precision of more than 1 cent. This is the reason that most (high-latency) financial libraries use strings underneath. This al doesn't address the high order floating point arithmetic of geo-spacial, which was the Patriot issue.
    - hortense 3y ago
      To store dollars with a precision of 1 billionth of a cent, you store into your integers 1 billionth of cents instead of dollars.
- mythhabit 3y ago
  Why would it have to be floating point to work? For ("physical") money there always is a finite smallest part, so integer math works fine. For time, if you go nuts and store Planck time a 256 bit integer is enough to store almost 1 billion billion billion years and you cannot go smaller for more precisions. So I'm curious why you claim it must be floating point for calculation.
  - John23832 3y ago
    Because floating point math doesn't work the same as basic integer arithmetic? Divide two floating point numbers.
    - glial 3y ago
      I'm curious what situation you have in mind. I suppose if you wanted to calculate a rate, you would need to divide (integer) money by an (integer) time interval.
    - mythhabit 3y ago
      Of course they are not the same. But why does it matter? With floating point you must always be conscious of precision errors and they can lead to catastrophic compounding errors vs with integer you have to decide how to handle rounding and overflows. One is not better than the other, it's just different, and both work fine with time and money if you are careful enough. That said, I personally find integer math to be the less surprising of the two. It's simply easier to reason about, and handle, edge cases.
      - John23832 3y ago
        Because that is not how we model computation and that matters for how the computation is done? Obviously I could do any math in unary, or construct it from Euclid's elements. However that is not typically how floating point numbers are stored in computers or represented to users. And it is typically no how the computations on them are done? I personally find FP math perfectly find when you are dealing with numbers "small enough" to fit the datatype you're working with. The issues with overflow exist in both integer and fp's alike.
- semi-extrinsic 3y ago
  IBM z/Architecture has had hardware support for F128 since the 90s. It has been in ISO 754 since 2008, with support in both C/C++ and Fortran.

“The best way to store money or time is using int64/bigint” is a hill I’m willing to die on.

jandrewrogers 3y ago

Zimbabwe has entered the chat.

deleted 3y ago
[deleted]
nequo 3y ago
First I thought you were joking. But as of February 2, 2009, 1 ZWL (third re-denomination) was equal to 10^12 ZWR (second re-denomination), 10^22 ZWN (first re-denomination), and 10^25 ZWD (original currency).[1] 1 ZWL does not fit in a 64-bit integer if converted to ZWN or ZWD: log2(10^22) = 73.08 log2(10^25) = 83.05 Bigint would work though. [1] https://en.wikipedia.org/wiki/Zimbabwean_dollar#History https://en.wikipedia.org/wiki/Zimbabwean_dollar#History

John23832 3y ago

Int64 wouldn't work because it's not floating point. You'd need to store the base and the mantissa separately for calculation. However there are languages that are looking at F128 (https://rust-lang.github.io/rfcs/3453-f16-and-f128.html https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). The problem is that there isn't really hardware support for them yet so you'd do it through software.

hortense 3y ago
To store dollars with a precision of 1 cent, you store into your integers cents instead of dollars. No need to mess with anything more complicated.
- pests 3y ago
  Gas is sold in 9/10th of a cent fraction. What now?
  - hortense 3y ago
    To store dollars with a precision of 1/10 cent, you store into your integers 1/10 cents instead of dollars.
- John23832 3y ago
  >To store dollars with a precision of 1 cent, you store into your integers cents instead of dollars. No need to mess with anything more complicated. As someone who does it, financial math is often done at a precision of more than 1 cent. This is the reason that most (high-latency) financial libraries use strings underneath. This al doesn't address the high order floating point arithmetic of geo-spacial, which was the Patriot issue.
  - hortense 3y ago
    To store dollars with a precision of 1 billionth of a cent, you store into your integers 1 billionth of cents instead of dollars.
mythhabit 3y ago
Why would it have to be floating point to work? For ("physical") money there always is a finite smallest part, so integer math works fine. For time, if you go nuts and store Planck time a 256 bit integer is enough to store almost 1 billion billion billion years and you cannot go smaller for more precisions. So I'm curious why you claim it must be floating point for calculation.
- John23832 3y ago
  Because floating point math doesn't work the same as basic integer arithmetic? Divide two floating point numbers.
  - glial 3y ago
    I'm curious what situation you have in mind. I suppose if you wanted to calculate a rate, you would need to divide (integer) money by an (integer) time interval.
  - mythhabit 3y ago
    Of course they are not the same. But why does it matter? With floating point you must always be conscious of precision errors and they can lead to catastrophic compounding errors vs with integer you have to decide how to handle rounding and overflows. One is not better than the other, it's just different, and both work fine with time and money if you are careful enough. That said, I personally find integer math to be the less surprising of the two. It's simply easier to reason about, and handle, edge cases.
    - John23832 3y ago
      Because that is not how we model computation and that matters for how the computation is done? Obviously I could do any math in unary, or construct it from Euclid's elements. However that is not typically how floating point numbers are stored in computers or represented to users. And it is typically no how the computations on them are done? I personally find FP math perfectly find when you are dealing with numbers "small enough" to fit the datatype you're working with. The issues with overflow exist in both integer and fp's alike.
semi-extrinsic 3y ago
IBM z/Architecture has had hardware support for F128 since the 90s. It has been in ISO 754 since 2008, with support in both C/C++ and Fortran.