4 ms·
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
by 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 agoTo 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 agoGas is sold in 9/10th of a cent fraction. What now?
- hortense 3y agoTo 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 agoTo 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 agoWhy 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 agoBecause floating point math doesn't work the same as basic integer arithmetic? Divide two floating point numbers.
- glial 3y agoI'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 agoOf 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 agoBecause 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 agoIBM 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.