On Saturday, 18 November 2017 at 16:17:00 UTC, Jonathan M Davis wrote:
> Folks have asked for the ability to create Durations from floating point values too, and I rejected that for the same reason - using floating point values with time is just begging for bugs, and Walter backed me up on that one.

Makes me think about my money library. It does accept floating point values and it has lead to at least one confused user [0]. Hm.

[0] https://github.com/qznc/d-money/issues/3

On Sunday, 19 November 2017 at 16:02:34 UTC, Jonathan M Davis wrote:
> On Sunday, November 19, 2017 15:01:50 Rumbu via Digitalmars-d wrote:
>> On Saturday, 18 November 2017 at 22:46:20 UTC, Jon Degenhardt

> Was the documentation on Duration not informative enough, or did you have trouble finding it from the documentation for the benchmarking functions, or something else? Simply converting a Duration to a string gives you what I would have thought would have been plenty human readable (though obviously not necessarily what you want in all cases), and it's split and total functions should make it straightforward to put the result in some other format if that's what you want. Was the documentation on those not enough?

1) Finding the documentation for Duration from the documentation of std.datetime.stopwatch is not quick enough. There is only one link from the page, and it's near the bottom, with the benchmark function (which is rarely what I need). Also, aside from the link at the bottom of the page, no mention of what module it is in.

2) The stopwatch page doesn't describe a Duration, and it also refers to core.time.MonoTime, plus a discussion that the "precision of StopWatch differs from system to system. And references to the depreciated TickDuration

Before one can do anything, one has to parse through all this material. It's all necessary material for tasks requiring very high accuracy. However, if what is being timed is inherently precise only to hundreds or tens of milliseconds, then this is way more investigation than needs to be done for the task at hand.

3) hecto-nanoseconds is not an especially common unit of measure.

4) Even from the Duration documentation, there aren't many examples of conversion to other standard units of measure. The only one I see is converting 12 days to hecto-nanoseconds, which isn't helpful as an example.

5) The built in conversion to string is one I've never found useful. Generally, I'm putting a set a values in a table, perhaps a large table. The output shown is not amenable to this. And yes, it often needs to be both human and machine readable. For example, I may read the table into R and plot the values.

Some recommendations:

a) Put a link to the Duration documentation in StopWatch page.

b) Put examples in the StopWatch and Duration sections that explicitly show how to convert to usecs, milliseconds, and perhaps seconds in floating point formats. Show this in the context of printing them.

c) Try to clean up some of the language describing the backward compatibility vs the newer stuff. It's a bit intertwined. The language doesn't have to explain the depreciation or justify it, at least not mixed with the description of the new facilities.

d) Be more explicit in the documentation about tradeoffs of integer precision used in Duration and floating point accuracy. That Duration supports this high accuracy without loss of precision in the face of mathematical operations is a real value, one worth calling out. However, it's also the case that this high mathematical precision is not required for many timing use cases, especially in the printing, but even calculations.

Making this distinction puts the stopwatch facilities more in the position of being an enabler of good end-user choices and less trying to prevent end-user mistakes. The reality is, that the accuracy needs are only known in the context of the timing measurements being done. The library code does not have enough information to know. However, providing the user with the information to make good choices about accuracy representation is a real benefit.

On 19.11.2017 20:29, Jon Degenhardt wrote:
> ...
> 
> Some recommendations:
> 
> a) Put a link to the Duration documentation in StopWatch page.
> 
> b) Put examples in the StopWatch and Duration sections that explicitly show how to convert to usecs, milliseconds, and perhaps seconds in floating point formats. Show this in the context of printing them.
> 
> c) Try to clean up some of the language describing the backward compatibility vs the newer stuff. It's a bit intertwined. The language doesn't have to explain the depreciation or justify it, at least not mixed with the description of the new facilities.
> 
> d) Be more explicit in the documentation about tradeoffs of integer precision used in Duration and floating point accuracy. That Duration supports this high accuracy without loss of precision in the face of mathematical operations is a real value, one worth calling out. However, it's also the case that this high mathematical precision is not required for many timing use cases, especially in the printing, but even calculations.
> 
> Making this distinction puts the stopwatch facilities more in the position of being an enabler of good end-user choices and less trying to prevent end-user mistakes. The reality is, that the accuracy needs are only known in the context of the timing measurements being done. The library code does not have enough information to know. However, providing the user with the information to make good choices about accuracy representation is a real benefit.

This is exactly how I think about this. I'd additionally recommend to keep supporting something like "to". It's nicer to read than something like total!"hnsecs"/1e7.

On Sunday, 19 November 2017 at 19:29:06 UTC, Jon Degenhardt wrote:
> On Sunday, 19 November 2017 at 16:02:34 UTC, Jonathan M Davis wrote:
>>> [...]
>
>> [...]
>
> 1) Finding the documentation for Duration from the documentation of std.datetime.stopwatch is not quick enough. There is only one link from the page, and it's near the bottom, with the benchmark function (which is rarely what I need). Also, aside from the link at the bottom of the page, no mention of what module it is in.
>
> [...]

Considering you know what would improve the documentations, why not create a pull-request yourself?

On Saturday, 18 November 2017 at 22:46:20 UTC, Jon Degenhardt wrote:
> I admittedly don't understand the argument that it should be hard to user programs to convert time durations to alternate standard units of measure.

If you want to communicate with a system that uses a floating point time format, you would need exactly same conversion algorithm not just something similar, so that round trip doesn't introduce computational errors.

On Sunday, 19 November 2017 at 19:29:06 UTC, Jon Degenhardt wrote:
> 1) Finding the documentation for Duration from the documentation of std.datetime.stopwatch is not quick enough. There is only one link from the page, and it's near the bottom, with the benchmark function (which is rarely what I need).

dpldocs sort of allow you to do it: http://dpldocs.info/experimental-docs/std.datetime.stopwatch.StopWatch.peek.html it links types used in function signature.

On 11/18/2017 8:17 AM, Jonathan M Davis wrote:
> Folks have asked for the ability to create Durations from floating point
> values too, and I rejected that for the same reason - using floating point
> values with time is just begging for bugs, and Walter backed me up on that
> one.

Yup. It's the same reason one does not do accounting with floating point.

Computer clocks have discrete ticks, they are not continuous. The behavior maps cleanly onto integral math, not fuzzy fp math.

On 21.11.2017 21:52, Walter Bright wrote:
> On 11/18/2017 8:17 AM, Jonathan M Davis wrote:
>> Folks have asked for the ability to create Durations from floating point
>> values too, and I rejected that for the same reason - using floating point
>> values with time is just begging for bugs, and Walter backed me up on that
>> one.
> 
> Yup. It's the same reason one does not do accounting with floating point.
> ...

The use case here is plotting the time taken by an algorithm depending on instance size.

> 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.

> The behavior maps cleanly onto integral math,

I'm not doing computations on times. I could just use Duration for that.

> not fuzzy fp math.
> 

There is nothing fuzzy about floating point operations, but still, yes, for some use cases, the tiny rounding error will just not matter.

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.

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?"