TickDuration deprecation

[Walter Bright]

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.