3 ms·

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 n

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.
    - mythhabit 3y ago
      If you model your particular computations and storage after FP, obvious that is closer. My guess is, that is with all likelihood a choice made for performance reasons when computers was far less powerful than they are today. The rest might as well just be inertia and a different choice could be made today if it was to start over. Or maybe not, but it's no longer as a clear cut choice as it once was. Your original claim was that Int64 would not work for financial calculations. For most normal calculations it would be fine, and for tax purposes it would be too, as the tax authority defines exactly when to round and how (at least in Denmark). If you retain the fractional precision the "true" calculations have, your tax calculation would be wrong. No matter what you use, it is always a tradeoff between precision, range, and speed. Floating point have been use a lot because they provide relative precision and have much bigger range and vastly faster speed compared to the same range in integers. But that comes with a lot of gotchas. To get the same range as a 64bit float, you need around 1024bit integer, which will inevitably be slower and require more memory.

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.
  - mythhabit 3y ago
    If you model your particular computations and storage after FP, obvious that is closer. My guess is, that is with all likelihood a choice made for performance reasons when computers was far less powerful than they are today. The rest might as well just be inertia and a different choice could be made today if it was to start over. Or maybe not, but it's no longer as a clear cut choice as it once was. Your original claim was that Int64 would not work for financial calculations. For most normal calculations it would be fine, and for tax purposes it would be too, as the tax authority defines exactly when to round and how (at least in Denmark). If you retain the fractional precision the "true" calculations have, your tax calculation would be wrong. No matter what you use, it is always a tradeoff between precision, range, and speed. Floating point have been use a lot because they provide relative precision and have much bigger range and vastly faster speed compared to the same range in integers. But that comes with a lot of gotchas. To get the same range as a 64bit float, you need around 1024bit integer, which will inevitably be slower and require more memory.