Approximate comparisons of core::time::Duration

[jpleyer]

Hi everyone,

I am the maintainer of approx. We are currently having a conversation about which default epsilon value to use when performing approximate comparisons. Similarly to f64 and f32, the core::time::Duration type has MAX and Zero consts but no EPSILON const. Most modern HPET devices have a ~100ns uncertainty. And then there are all kinds of operating system interrupts, etc. that can occur.

My question is this: What would be a sensible default that you as an end-user of the approx crate would expect? Let me know.

feat: Duration Support (#105)

[jwodder]

@jpleyer

What would be a sensible default that you as an end-user of the approx crate would expect?

I think the sensible default is no default; require the epsilon to always be explicitly given.

[scottmcm]

@jpleyer

Similarly to f64 and f32, the core::time::Duration type has MAX and Zero consts but no EPSILON const.

Obligatory reminder that the ESPILON const is wrong to use as an "approximate comparison" distance. This statement is thus completely meaningless.

[jpleyer]

The current design of approx does not permit this. It would require a breaking change.

[curoli]

What is the purpose if the comparisons? Is it for debugging, to compare actual and expected result? In that case, what are the allowed operations that produce the actual result? Depending on how the actual result is achieved, the deviation from expectation can be anything.