On Wednesday, 22 November 2017 at 05:50:53 UTC, Walter Bright
wrote:
There is another, perhaps obsolete, consideration.
Some CPUs do not have floating point units. C, for example, is
carefully set up so that when you don't need floating point, it
isn't required to have an FPU. This made C usable on cheap
processors.
It's sorta like "why is the GC linked in even though I never
used it?"
Hi Walter - I wonder if there is a miscommunication. My
understanding is that the question is whether there should be a
built-in conversion from Duration to float/double in a specific
unit of measure, like milliseconds. It sounds as if your concern
is more to ensure that the time package not be required to
support something other than integral values in its internal
operations.
Perhaps there is an alternative perspective, but being able to
convert a Duration to a double in a specific unit of measure
would not seem to place any burden on the time package to support
the result of conversion as a first class time object. In this
view, what happens with the converted value is entirely in the
hands of the end user, not the time package. If the user decides
to use the double in a mathematical operation, floating point
round off error is the responsibility of the user, not the time
package.
To give a concrete example of why this is conversion is useful -
I often do performance analysis involving service calls that take
from single digit milliseconds to hundreds of milliseconds, with
standard deviations in that ballpark. I might use tens of
thousands of timing samples and analyze those samples using stats
and graphing packages. Those packages all use doubles, and it is
generally convenient to work in units appropriate for the
measurements being done, milliseconds in the case I described. In
this case, the last step in generating a timing value is to
convert to milliseconds as a double and store it somewhere, often
a log file. These will be read back in by the stats/graphing
package, where follow-up processing will be done.
In the older version of StopWatch, this last step conversion
could be done with a call like:
double ms = sw.peek.to!("msecs", double));
In the new version, a call needs to be something like:
double ms = sw.peek.total!("hnsecs").to!double / 1e+04);
The latter form is more error prone and less clear about intent,
etc. It sounds as the rationale for depreciating the previous
form of conversion is because the end user may incur floating
point round-off error by performing mathematical operations on
the double value. The user can still perform the conversion, but
must go to greater effort. It sounds as if the other part of the
rationale is that conversion is likely to be rare. In my
experience, this is not the case.
