Okay, I'm approaching completion of my date/time code, and it looked like a good idea to use SHOO's stopwatch code that has now become the nascent std.datetime in order to get the current time (there's no need to duplicate code after all), and given that my code would have to be merged with his if it it's accepted, it seemed prudent to just merge them now (which I've now done). However, a bit of a naming issue has arisen.

SHOO has a struct called Ticks which holds a time in so-called system ticks, which is effectively the precision of the system clock - x ticks per second. So, the internal value's resolution varies from system to system. That's fine. The problem is that my code has a separate tick concept - that is 100ns is a tick. That is the precision that my SysTime struct holds when it holds the time. My date/time code considers tick a unit just as much as it considers days or seconds to be units. However, that makes it so that there are two types of ticks, and I'm afraid that that is going to cause some confusion. For the moment, I've renamed my ticks to std ticks and tried to make the documentation clear on the matter, but it still risks being confusing.

So, I'm looking for suggestions as what to name my ticks (which are held as a long and aren't a struct at all) and what to name SHOO's Ticks struct. The best that I can think of at the moment is to rename mine std ticks (with StdTick being an alias for long) and rename SHOO's to SysTicks, PrecisionTicks, or ResTicks, or something similar, but it would be even better if we could come up with a term for one of them which wasn't ticks at all.

So, does anyone have any ideas on how to name these two concepts/types?

1. My ticks (which represent 100 ns and are units of time).

2. SHOO's Ticks, which is a struct which holds the time from the system clock in ticks with the number of ticks per second varying with the system clock.

- Jonathan M Davis

I recognize that there is some confusion for a name of Ticks.
I have been troubled about it once before, the time when my 'std.time'
was discussed. I adopted Ticks because there was not name confused at
that time. There were only types that named Ticks, Duration, Time and
Date. Perhaps I suppose that your Ticks of this time is equivalent to my
Duration.
This time, I agree about changing name to merge your code.
I want to see your merged code once. And then I want to evaluate it.

I'm looking forward to seeing your code.


(2010/09/27 16:20), Jonathan M Davis wrote:
> Okay, I'm approaching completion of my date/time code, and it looked like a good idea to use SHOO's stopwatch code that has now become the nascent std.datetime in order to get the current time (there's no need to duplicate code after all), and given that my code would have to be merged with his if it it's accepted, it seemed prudent to just merge them now (which I've now done). However, a bit of a naming issue has arisen.
>
> SHOO has a struct called Ticks which holds a time in so-called system ticks, which is effectively the precision of the system clock - x ticks per second. So, the internal value's resolution varies from system to system. That's fine. The problem is that my code has a separate tick concept - that is 100ns is a tick. That is the precision that my SysTime struct holds when it holds the time. My date/time code considers tick a unit just as much as it considers days or seconds to be units. However, that makes it so that there are two types of ticks, and I'm afraid that that is going to cause some confusion. For the moment, I've renamed my ticks to std ticks and tried to make the documentation clear on the matter, but it still risks being confusing.
>
> So, I'm looking for suggestions as what to name my ticks (which are held as a long and aren't a struct at all) and what to name SHOO's Ticks struct. The best that I can think of at the moment is to rename mine std ticks (with StdTick being an alias for long) and rename SHOO's to SysTicks, PrecisionTicks, or ResTicks, or something similar, but it would be even better if we could come up with a term for one of them which wasn't ticks at all.
>
> So, does anyone have any ideas on how to name these two concepts/types?
>
> 1. My ticks (which represent 100 ns and are units of time).
>
> 2. SHOO's Ticks, which is a struct which holds the time from the system clock in ticks with the number of ticks per second varying with the system clock.
>
> - Jonathan M Davis

On Monday 27 September 2010 02:25:55 SHOO wrote:
> I recognize that there is some confusion for a name of Ticks.
> I have been troubled about it once before, the time when my 'std.time'
> was discussed. I adopted Ticks because there was not name confused at
> that time. There were only types that named Ticks, Duration, Time and
> Date. Perhaps I suppose that your Ticks of this time is equivalent to my
> Duration.
> This time, I agree about changing name to merge your code.
> I want to see your merged code once. And then I want to evaluate it.
> 
> I'm looking forward to seeing your code.

Well, it should be less then a week before I'm done (hopefully sooner rather than later), but I keep ending up having to refactor things, and I haven't always had as much free time as I expected, so it's been taking me longer than I expected. I'll post it here as soon as it's ready, and then everyone can review it.

I don't know about your Duration, but normally a duration would be a value and units, while my ticks are just units. For instance, I declare this enum

/++
    Represents possible units of time.
  +/
enum TUnit { year, month, week, day, hour, minute, second, millisecond,
microsecond, stdTick }


to represent all the possible units of time (it was tick until I changed it to stdTick). Your Ticks, on the other hand, is a value with variable units, so it's kind of like a duration, except that it's specifically a duration since midnight January 1st, 1970. So, like time_t, it could be viewed as a duration (or as an interval for that matter since it has a fixed point for its start), but it's used more like a point in time. In fact, now that I think about it, in boost terminology, it really is a time point; it just lacks all of the trappings that let it work with durations, and intervals, and iterators/ranges, and the like. In any case, what my code means by tick (or stdTick) is totally different from what Ticks does.

I'm tempted to rename Ticks to PrecisionTime or something similar, since that's more or less what it is. It's a time point with the maximum precision that the system clock has to offer. Unfortunately, even doing that doesn't quite fix the ticks problem, since it would still have ticksPerSecond. I'd be tempted to change it to the number of ticks in its precision (e.g. a clock with microsecond precision - 1 million ticks per second - would be 10 std ticks, whereas a clock with millisecond precision would be 1000 std ticks) - it would make it so that there was only one type of tick. Unfortunately, that falls apart once your precision goes beyond 10 million ticks per second (1 std tick), since then you'd get fractional std ticks, and any computer with nanosecond precision would obviously fall in that category. ticksPerSecond, at least, scales to no matter what resolution the system clock has.

What I'd really like is to find a better name than tick or std tick for my ticks. What would that be anyway? A deci-microsecond? A centa-nanosecond? Either name would be horrible.

As for merging your code, it's mostly been just copy and paste. The only things that I've changed thus far are adding the ability to get std ticks out of Ticks and fixing it so that Ticks works with precision less than a microsecond. For instance, toMicroseconds() is now

const
T toMicroseconds(T)() if (isIntegral!T && T.sizeof >= 4)
{
    if(ticksPerSec >= 1_000_000)
        return value / (ticksPerSec / 1_000_000);
    else
        return value * (1_000_000 / ticksPerSec);
}

The problem was that dividing by 1_000_000 when the precision is less than that resulting in a floating point exception (I ran into it because I added std ticks and my system clock has microsecond precision). Other than that, your code is exactly as it is in std.datetime right now. Oh, and I had to add an alias for TemporaryValue, otherwise compilation failed when attempting to produce ddoc files.

The one thing that I think that I'm going to change at this point is the name of the Ticks struct. The best that I can think of at the moment is PrecisionTime, but I'm open to suggestions (that is why I started this thread, after all).

In any case, hopefully it won't be much longer before I'm able to post the finished result here for review.

- Jonathan M Davis

(2010/09/27 20:22), Jonathan M Davis wrote:
> Well, it should be less then a week before I'm done (hopefully sooner rather than later), but I keep ending up having to refactor things, and I haven't always had as much free time as I expected, so it's been taking me longer than I expected. I'll post it here as soon as it's ready, and then everyone can review it.
>
> I don't know about your Duration, but normally a duration would be a value and units, while my ticks are just units. For instance, I declare this enum
>


Correct! You shouldn't see my 'std.time'. There is the doubt why poison is mixed with in the code.


> /++
>      Represents possible units of time.
>    +/
> enum TUnit { year, month, week, day, hour, minute, second, millisecond,
> microsecond, stdTick }
>
>
> to represent all the possible units of time (it was tick until I changed it to stdTick). Your Ticks, on the other hand, is a value with variable units, so it's kind of like a duration, except that it's specifically a duration since midnight January 1st, 1970. So, like time_t, it could be viewed as a duration (or as an interval for that matter since it has a fixed point for its start), but it's used more like a point in time. In fact, now that I think about it, in boost terminology, it really is a time point; it just lacks all of the trappings that let it work with durations, and intervals, and iterators/ranges, and the like. In any case, what my code means by tick (or stdTick) is totally different from what Ticks does.


Ticks is not a time point. It is rather near to a time span. It is a time span since indeterminate time point that may not be midnight January 1st, 1970 and may be when you started a StopWatch.


> I'm tempted to rename Ticks to PrecisionTime or something similar, since that's more or less what it is. It's a time point with the maximum precision that the system clock has to offer. Unfortunately, even doing that doesn't quite fix the ticks problem, since it would still have ticksPerSecond. I'd be tempted to change it to the number of ticks in its precision (e.g. a clock with microsecond precision - 1 million ticks per second - would be 10 std ticks, whereas a clock with millisecond precision would be 1000 std ticks) - it would make it so that there was only one type of tick. Unfortunately, that falls apart once your precision goes beyond 10 million ticks per second (1 std tick), since then you'd get fractional std ticks, and any computer with nanosecond precision would obviously fall in that category. ticksPerSecond, at least, scales to no matter what resolution the system clock has.
>


Therefore I am against PrecisionTime.


> What I'd really like is to find a better name than tick or std tick for my ticks. What would that be anyway? A deci-microsecond? A centa-nanosecond? Either name would be horrible.
>
> As for merging your code, it's mostly been just copy and paste. The only things that I've changed thus far are adding the ability to get std ticks out of Ticks and fixing it so that Ticks works with precision less than a microsecond. For instance, toMicroseconds() is now
>
> const
> T toMicroseconds(T)() if (isIntegral!T&&  T.sizeof>= 4)
> {
>      if(ticksPerSec>= 1_000_000)
>          return value / (ticksPerSec / 1_000_000);
>      else
>          return value * (1_000_000 / ticksPerSec);
> }
>
> The problem was that dividing by 1_000_000 when the precision is less than that resulting in a floating point exception (I ran into it because I added std ticks and my system clock has microsecond precision). Other than that, your code is exactly as it is in std.datetime right now. Oh, and I had to add an alias for TemporaryValue, otherwise compilation failed when attempting to produce ddoc files.
>
> The one thing that I think that I'm going to change at this point is the name of the Ticks struct. The best that I can think of at the moment is PrecisionTime, but I'm open to suggestions (that is why I started this thread, after all).
>
> In any case, hopefully it won't be much longer before I'm able to post the finished result here for review.
>
> - Jonathan M Davis


Because your Ticks is completely different from mine, there must not be
misunderstanding for each name.
SysSpan/SysDuration/SysPeriod/PerfSpan/PerfDuration/PerfPeriod/SysClockSpan/SysTicks/PerfTicks/PrecisionSpan/PrecisionDuration/PrecisionPeriod/...etc.
Please pick your favorite name.
I don't know English little nuances well... If the name does not provoke
misunderstanding, I am not particular about the name.

On Mon, 27 Sep 2010 09:52:17 -0400, SHOO <zan77137 at nifty.com> wrote:
> (2010/09/27 20:22), Jonathan M Davis wrote:
>> /++
>>      Represents possible units of time.
>>    +/
>> enum TUnit { year, month, week, day, hour, minute, second, millisecond,
>> microsecond, stdTick }

[snip]

>> What I'd really like is to find a better name than tick or std tick for
>> my ticks.
>> What would that be anyway? A deci-microsecond? A centa-nanosecond?
>> Either name
>> would be horrible.

A hundred nanoseconds would be a deci-microsecond or a hecto-nanosecond. Both are used, though hectonanosecond seems to be more popular, both generally and with programmers. For example, Apple's Network Time Protocol codebase uses the unit. I don't find either name horrible and would prefer an actual unit of time in TUnit as opposed to a made up name which I'd have to remember is actually a hectonanosecond. Perhaps this is my scientific background coming through.

On Monday 27 September 2010 06:52:17 SHOO wrote:
> Ticks is not a time point. It is rather near to a time span. It is a time span since indeterminate time point that may not be midnight January 1st, 1970 and may be when you started a StopWatch.

Ah, okay. I obviously didn't look at it close enough. For the most part, all I did was copy it, so I didn't look at all that closely, and I obviously misunderstood. So, no, it isn't a time point. It's more like a duration.

- Jonathan M Davis

On Monday 27 September 2010 07:52:48 Robert Jacques wrote:
> On Mon, 27 Sep 2010 09:52:17 -0400, SHOO <zan77137 at nifty.com> wrote:
> > (2010/09/27 20:22), Jonathan M Davis wrote:
> >> /++
> >> 
> >>      Represents possible units of time.
> >> 
> >>    +/
> >> 
> >> enum TUnit { year, month, week, day, hour, minute, second, millisecond, microsecond, stdTick }
> 
> [snip]
> 
> >> What I'd really like is to find a better name than tick or std tick for
> >> my ticks.
> >> What would that be anyway? A deci-microsecond? A centa-nanosecond?
> >> Either name
> >> would be horrible.
> 
> A hundred nanoseconds would be a deci-microsecond or a hecto-nanosecond. Both are used, though hectonanosecond seems to be more popular, both generally and with programmers. For example, Apple's Network Time Protocol codebase uses the unit. I don't find either name horrible and would prefer an actual unit of time in TUnit as opposed to a made up name which I'd have to remember is actually a hectonanosecond. Perhaps this is my scientific background coming through.

Well, aside from the fact that I think that most people have never heard of a hectonanosecond, it's awfully long to type. millisecond and microsecond are bad enough. And do you really want to have to use functions like totalHectonanoseconds()? Perhaps with a good abbrevation... hnsec? I'll have to think about it. As words go, ticks is far more pleasant, but it isn't as precise.

- Jonathan M Davis

On Mon, 27 Sep 2010 11:51:00 -0400, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Monday 27 September 2010 07:52:48 Robert Jacques wrote:
>> On Mon, 27 Sep 2010 09:52:17 -0400, SHOO <zan77137 at nifty.com> wrote:
>> > (2010/09/27 20:22), Jonathan M Davis wrote:
>> >> /++
>> >>
>> >>      Represents possible units of time.
>> >>
>> >>    +/
>> >>
>> >> enum TUnit { year, month, week, day, hour, minute, second,
>> millisecond,
>> >> microsecond, stdTick }
>>
>> [snip]
>>
>> >> What I'd really like is to find a better name than tick or std tick
>> for
>> >> my ticks.
>> >> What would that be anyway? A deci-microsecond? A centa-nanosecond?
>> >> Either name
>> >> would be horrible.
>>
>> A hundred nanoseconds would be a deci-microsecond or a hecto-nanosecond.
>> Both are used, though hectonanosecond seems to be more popular, both
>> generally and with programmers. For example, Apple's Network Time
>> Protocol
>> codebase uses the unit. I don't find either name horrible and would
>> prefer
>> an actual unit of time in TUnit as opposed to a made up name which I'd
>> have to remember is actually a hectonanosecond. Perhaps this is my
>> scientific background coming through.
>
> Well, aside from the fact that I think that most people have never heard
> of a
> hectonanosecond, it's awfully long to type. millisecond and microsecond
> are bad
> enough. And do you really want to have to use functions like
> totalHectonanoseconds()? Perhaps with a good abbrevation... hnsec? I'll
> have to
> think about it. As words go, ticks is far more pleasant, but it isn't as
> precise.
>
> - Jonathan M Davis

Well, if you make up a unit, then you can guarantee no one will have heard of it before. And really, learning the hecto SI prefix means someone will always understand what hectonanosecond means, as opposed to StdTick or Duration, etc, which would have a tendency to be quickly forgotten or confused with another library type from another language. As for typing, I would expect the 100ns unit to be mainly an internal thing. Most of the time I deal in microseconds/1000.0 (i.e. floating point milliseconds), when dealing with std.perf today.

On Monday 27 September 2010 22:08:12 Robert Jacques wrote:
> On Mon, 27 Sep 2010 11:51:00 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> Well, if you make up a unit, then you can guarantee no one will have heard
> of it before. And really, learning the hecto SI prefix means someone will
> always understand what hectonanosecond means, as opposed to StdTick or
> Duration, etc, which would have a tendency to be quickly forgotten or
> confused with another library type from another language. As for typing, I
> would expect the 100ns unit to be mainly an internal thing. Most of the
> time I deal in microseconds/1000.0 (i.e. floating point milliseconds),
> when dealing with std.perf today.

Well, it's not entirely made up. 100ns is the tick that Windows uses. So, I believe that it's used in C# and other Windows-centric code. So, there is a precedent. And while ticks/hectonanoseconds are mostly internal, there are certain operations where you're going to want to use them, albeit hopefully fairly rarely. The documentation does use the term quite a bit though, particularly since std ticks pretty much replace time_t - though that can be a bit confusing because time_t is a type which holds the number of milliseconds since midnight January 1st, 1970 while std ticks are unit of time which are 100 ns and are used to hold the time from midnight January 1st, 1 AD.

Maybe, I should replace some of the mentios of ticks with something like StdTime (would be an alias for long and hold units of 100 ns with midnight January 1st, 1 AD as its epoch) and use hectonanosecond where its an issues of units rather than type.

Bleh. I don't entirely like any of the options. Having StdTime does seem like a good idea, since it does help properly separate the idea of the unit and a type with those units from the epoch, but I really don't like hectonanoseconds. It's just way too long. milliseconds and microseconds are already seriously pushing it. Hectonanoseconds do have the virtue of being explicit however. Some people will know what they mean (though I wouldn't expect very many people to), and those who don't probably wouldn't have known what ticks indicated anyway, though the few people that I've talked to about it haven't liked the idea of having hectonanoseconds, since it's really ugly.

- Jonathan M Davis

Guys, let's settle for HNSeconds and call it a day. There's no real good name for it. hectAny name we use, people will have to look it up at least once when using it and that's that.

Andrei

On 9/28/10 0:39 PDT, Jonathan M Davis wrote:
> On Monday 27 September 2010 22:08:12 Robert Jacques wrote:
>> On Mon, 27 Sep 2010 11:51:00 -0400, Jonathan M Davis<jmdavisProg at gmx.com>
>> Well, if you make up a unit, then you can guarantee no one will have heard
>> of it before. And really, learning the hecto SI prefix means someone will
>> always understand what hectonanosecond means, as opposed to StdTick or
>> Duration, etc, which would have a tendency to be quickly forgotten or
>> confused with another library type from another language. As for typing, I
>> would expect the 100ns unit to be mainly an internal thing. Most of the
>> time I deal in microseconds/1000.0 (i.e. floating point milliseconds),
>> when dealing with std.perf today.
>
> Well, it's not entirely made up. 100ns is the tick that Windows uses. So, I believe that it's used in C# and other Windows-centric code. So, there is a precedent. And while ticks/hectonanoseconds are mostly internal, there are certain operations where you're going to want to use them, albeit hopefully fairly rarely. The documentation does use the term quite a bit though, particularly since std ticks pretty much replace time_t - though that can be a bit confusing because time_t is a type which holds the number of milliseconds since midnight January 1st, 1970 while std ticks are unit of time which are 100 ns and are used to hold the time from midnight January 1st, 1 AD.
>
> Maybe, I should replace some of the mentios of ticks with something like StdTime (would be an alias for long and hold units of 100 ns with midnight January 1st, 1 AD as its epoch) and use hectonanosecond where its an issues of units rather than type.
>
> Bleh. I don't entirely like any of the options. Having StdTime does seem like a good idea, since it does help properly separate the idea of the unit and a type with those units from the epoch, but I really don't like hectonanoseconds. It's just way too long. milliseconds and microseconds are already seriously pushing it. Hectonanoseconds do have the virtue of being explicit however. Some people will know what they mean (though I wouldn't expect very many people to), and those who don't probably wouldn't have known what ticks indicated anyway, though the few people that I've talked to about it haven't liked the idea of having hectonanoseconds, since it's really ugly.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos