3 ms·
Oh, just found this: > The Duration type could be simplified with this: instead of using a u64 for seconds with a seperate u32 for nanoseconds, it could just b
by kevhito 10y ago
Oh, just found this:
> The Duration type could be simplified with this: instead of using a u64 for seconds with a seperate u32 for nanoseconds, it could just be a single u128/i128 count of nanoseconds.
Of course, just a single u64 at ns precision would get you 500+ years of range. But ok.
- eropple 10y agoFive hundred years and eighty-four years? Recorded human history is almost ten times that range and history to which we can get precise dates is nearly five times that range. There are financial debts being paid, today, that exist from nearly the limit of that range (Dutch debts dating from 1624) even if you left a mere quarter of it for the future. So why are you middlebrowing at this?
- Veedrac 10y agoTo be fair, you basically never need scale and precision at the same time. Debts from 400 years ago aren't known down to the nanosecond.
- eropple 10y agoI can think of astronomical measures from a couple hundred years ago that are at least second-accurate. Do you want to have DurationSecondsOnly and Duration as types? =)
- Veedrac 10y agoIt's more an argument for floating point.
- TillE 10y agoFloating point is awful if you care about precision.
- Veedrac 10y agoWhat scenario would you need more than 53 bits of precision in a time variable for? Even eropple's somewhat excessive subsecond-accurate timing for an event several hundred years ago has plenty of room to spare with 53 bits.
- MaulingMonkey 10y ago"Absolute" timestamps. If you're using a double to represent, say, epoch time (technically relative to the relatively recent 1/1/1900), your precision has dropped off to about half a microsecond or so. I read GPU profiling results in nanoseconds. You can work around the problem - time since program start, time since capture start, etc. - of course, this can lead to fun edge cases, where e.g. Windows 95/98 crashed due to a 32-bit milliseconds timer rollover after around 50 days. For comparison, pow(2,53) nanoseconds is only a little over 100 days. Of course, a floating point value won't roll over in quite the same way, but... The problem is surmountable if you throw enough edge case handling at the problem. Force the devs to be vigilant about choosing the necessary precision, the proper time to measure relative to, for each possible application of anything time related, etc... ... or you could just throw more bits at the problem, and suddenly my accounting software can accurately calculate compound interest on both a 400 year old debt, and a 49 nanosecond debt clearing HFT trades, if that's your kind of thing - without as many edge cases to worry about. EDIT: Use pow(x,y) formatting since HN collapses x double-star y to simply xy ...
- Veedrac 10y agoYeah, sorry, that was a bit of a knee-jerk response from me. I took TillE's comment to be more a statement of the general (IMO unfounded) mistrust of floating point, and my comment was intended to take it in that light. Once you have values in the domain you're interested in, floating point more than suffices for precision, and generally handles rounding better than the equivalently-sized fixed point variable. I do agree that a general timestamp needs to be domain-agnostic, and I'm certainly not saying Rust should use it, not least because Rust aims to preserve the semantics of underlying APIs.
- 10y ago
- halomru 10y agoYou usually don't need scale and precision at the same time, but a lot of algorithms get a lot simpler if you don't have to worry about rounding errors that get worse with every operation. Floating point errors are hard to reason about and often makes equality a very fuzzy concept. If your not starved for bandwidth or memory, large fixed precision numbers are incredibly useful.
- Veedrac 10y agoAlthough a large, fixed precision type is probably an easier default, in practice a floating point variable will work at least as well as a 53 bit fixed integer scaled to the range you're interested in. Inexactness through rounding isn't a big deal, because you rarely care about exact equality for inexact measures like time.
- lifthrasiir 10y agoIt is closely related to "native" time representation, where you can frequently have u64 seconds in the API. Being able to represent them without a trap would be beneficial.
- dom0 10y ago64 bit ns timestamps are ok if you are only recording current events, but are completely insufficient as a general purpose timestamp.