5 ms·
This is why I always just use an int64 on embedded systems for timestamps. I'll be dead of old age before my software kills anyone by accident.
by greesil 3y ago
This is why I always just use an int64 on embedded systems for timestamps. I'll be dead of old age before my software kills anyone by accident.
- encoderer 3y ago“The best way to store money or time is using int64/bigint” is a hill I’m willing to die on.
- jandrewrogers 3y agoZimbabwe has entered the chat.
- deleted 3y ago[deleted]
- nequo 3y agoFirst 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 agoInt64 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.
- kstenerud 3y agoThe problem wasn't in the way the time was stored (integer representing tenths of seconds); it was in the conversion to float for the calculations being done. A 1/1000000 error margin is fine for small numbers (up to 30,000 seconds), but not for big ones (100,000 seconds) where being even a tenth of a second off causes the calculation to become unreliable.
- greesil 3y agoRule #2 is when calculating duration is to keep the timestamps as long long. If for some reason you need to convert the duration to float, check the duration first and/or just use double precision.