feat: Duration Support

[JamesWiresmith]

Added support for the core duration type for abs_diff_eq as mentioned in #103

Default is to treat it similar to an unsigned value with 0 epsilon but included tests allowing greater epsilon values.

[jonaspleyer]

Hi and thanks for the PR. I have a few suggestions/questions:

1. Add RelativeEq and Ulps implementations
2. What is the justification to use a zero-value epsilon here? My intuition tells me that this should be non-zero but I am not entirely sure why. It would probably be implementation-specific for how the duration is calculated depending on the underlying OS and hardware. However, maybe there is a sensible upper limit for this.

[jonaspleyer]

A quick look at https://en.wikipedia.org/wiki/High_Precision_Event_Timer notes that HPET devices run at at least 10 MHz giving a time resolution of roughly 100ns.
See:
https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf

Most modern devices run between 14MHz and 25MHz which gives roughly 70ns to 40ns resolution. The wikipedia article also states that reading requires about 1-2µs of time as well. However I would suspect that this reading delay will only affect absolute times, not time deltas, as long as it is concistent across measurement operations.

Source:
https://web.archive.org/web/20160626142735/http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

[JamesWiresmith]

Thanks for the feedback. I copied the epsilon as I was comparing it to integers which is the internal representation. i.e. we don't expect any error from purely mathematical operations as with floating point.

However I'm happy to set it higher if it makes more sense but I confess I'm not entirely following the logic of the timer. I believe you are saying that if we say the underlying resolution is 100ns then that should be the epsilon as anything lower is essentially the same point in time from a computers perspective?

[jonaspleyer]

However I'm happy to set it higher if it makes more sense but I confess I'm not entirely following the logic of the timer. I believe you are saying that if we say the underlying resolution is 100ns then that should be the epsilon as anything lower is essentially the same point in time from a computers perspective?

Yes. As far as I have understood the hardware and software interplay, there is a ~100ns resolution for HPET timers. It could still be debated if it might make sense to use this as an epsilon in an approximate comparison. Maybe it is best if we ask in the rust forum for help. What do you think?

[jonaspleyer]

I asked in the forum:
https://users.rust-lang.org/t/approximate-comparisons-of-core-duration/140688

Let's see what people say about that.

[JamesWiresmith]

Great thanks - apologies for the slow response!

[jonaspleyer]

I think I am going to merge this with the default 0. I will however write a few additional comments which summarize the information here. Furthermore I am thinking about redesigning some of the components of approx such that there are no default values for core::time::Duration.