Re: [boost] [chrono] Interoperability with ICL and common concepts

Subject: Re: [boost] [chrono] Interoperability with ICL and common concepts
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-03-15 17:41:07

2011/3/15 Howard Hinnant <howard.hinnant_at_[hidden]>:
> On Mar 15, 2011, at 2:00 PM, Vicente Botet wrote:
>
>>
>> Joachim Faulhaber wrote:
>>> To summarize, for a domain type Dom, Icl expects
>>> Dom(), <, ++, --
>>> and if dom is a equidistant scalar type we expect an associated type
>>> Dom::difference_type
>>> to be defined.
>>>
>>>
>>> This choice has not been taken for chrono::durations, which is a
>>> little inconsistent also, because interestingly for its
>>> chrono::time_point type the semantic is just the desired one.
>>>
>>
>> Yes, you are surely right. time_point could have a default constructor, and
>> have a epoch function. Howard, what do you think?
>
> The current std::chrono::duration default constructor has this definition:
>
> constexpr duration() = default;
>
> The rationale for this is to give the client and the Rep author as many options as possible:
>
> typedef std::chrono::duration<long long> D;
>
> D d1;  // d1.count() uninitialized - speed
> D d2 = D();  // d2.count() zero-initialized - safety if you believe 0 is safe
>
> typedef std::chrono::duration<BigInt> CustomD;
>
> CustomD d3;  // d3.count() default constructed
>

Hi Howard,

thanks for your comments. I understand the value and foresight of this
flexible design. Yet from my point of view I would have chosen zero()
as default and uninitialized as configurable option.

But anyway, maybe its the more flexible and long lasting design to
separate identity_element<T> and default ctor T(). Sine c++ is about
speed, uninitialized could be the standard default for T() then. I'm
kind a standard agnostic :( Maybe there is already something like a
std::identity_element<T> ?

> The author of BigInt may decide that 0 is the best default value.
> *Or* he might decide that nan is the best default value
> (personally I'd be tempted to go with nan).

Hmm, personally I'm a NaN hater. Although I basically think it's
healthier to start loving the world one lives in (difficult at times,
if one thinks of Japan). Maybe you can bring the enlightenment and
beauty of NaN to me.

> We did not want to dictate that a default-constructed duration
> always represented zero, as this decision would have dubious
> qualities from a safety point of view.

Not always, ok. But why not as a default?

> For time_point a default constructed object is specifically documented
> to have the value "epoch", and duration's static zero() function
> is used to initialize it.  It was felt this was more useful for time_point.
> Though time_point will most often be constructed from the value returned
> by now().

>From an algebraic point of view, chrono::time_points (and durations)
seem to be "pretty" isomorphic with the representing type Rep, which
is a number. Roughly I'd expect that the following diagram will
commute:

Let
P : time_point
R : Rep (representing type)
f : P -> R  forget Period information
r : R -> P  recall Period information
g : functions on P and R

P ---- g ----> P
|              |
f      =       r
|              |
V              V
R ---- g ----> R

If functions g (additions, multiplications, .... and also compositions
of them) are performed on time_points, and we take the Rep value this
is the same, as if we take the Rep value and perform the same
functions g on then and then go back to the time_points via recall
function r.

So all functions on P should be the isomorphic to the same function on R.
If R() yields the identity_element on Rep, then also P() should yield
an identity on time_point.

Those are my thought about Chrono, correct me if I'm wrong.

Thanks again,
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de