On 22.11.2017 03:22, Walter Bright wrote:
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.
But this is orthogonal to my complaint. I don't care which Phobos module
contains the conversion functionality. It can be part of std.conv.to,
for example.
Floating point has no business being
in a type that is represented as an integral type.
Why would it need to be part of the type? I just want the obvious
conversion functionality, to enable further processing where this is
appropriate.
There are no 0.3 clock ticks, the notion does not exist.
...
(Great then. There also is no 0.3 float value. :P)
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.
...
The plotter or whatever other component consumes the timing data might
not care about this.
not fuzzy fp math.
There is nothing fuzzy about floating point operations,
Fuzzy as in inexact.
The result is well-defined, it's just rounded. Whether that is exact or
not depends on what you expected the result to be, it's not properly
part of the floating point abstraction.
Integral time computations are always an exact
multiple of clock ticks.
...
The reason why floating point values are popular is that it is often
enough infeasible or unnecessary to do the computation without rounding.
The output of a computation might be inexact even if the inputs are not.
There needs to be some way to move from one regime to the other.
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.
My claim is not that conversion from time to floating point values
associated with a few natural units is "properly part of the time
abstraction", just that it should exist. Do you agree with that?
