On 11/21/2017 1:40 PM, Timon Gehr wrote:
Computer clocks have discrete ticks, they are not continuous.
That may be true, but the plotting library may still just expect a list of
doubles. What's the point of removing the simple conversion function that was
already available for such use cases? This is a breaking change with zero benefits.
I'm in general opposed to "kitchen sink" abstractions, preferring pluggable
component abstractions. Floating point has no business being in a type that is
represented as an integral type. There are no 0.3 clock ticks, the notion does
not exist.
The behavior maps cleanly onto integral math,
I'm not doing computations on times. I could just use Duration for that.
Time durations are always discrete quanta by the nature of the clock used.
not fuzzy fp math.
There is nothing fuzzy about floating point operations,
Fuzzy as in inexact. Integral time computations are always an exact multiple of
clock ticks.
but still, yes, for some
use cases, the tiny rounding error will just not matter.
Whether the rounding error matters or not should not be decided by the time
package, it should be decided by what the user decides to do with the time values.
I.e. it is not properly part of the time abstraction.
