4 ms·

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 Eucl

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.