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:59:29

2011/3/15 Joachim Faulhaber <afojgo_at_[hidden]>:
> 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      =       f
> |              |
> 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 them.
>
> 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.

Ooops, corrections above.

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