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

Subject: Re: [boost] [chrono] Interoperability with ICL and common concepts
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-03-15 14:00:11

Joachim Faulhaber wrote:
> 
> Hi Vicente and Boost Chronoists,
> 
> thank you for implementing Boost.Chrono! It's a very fine piece of
> software :)
> 

Thanks :)

> Currently I'm checking out the usage of chrono types with
> icl::intervals and interval containers. Obviously, using intervals of
> chrono::time_points or chrono::durations can be an important use case.
> Also ICL already works well with other date and time data types from
> boost data_time, so chrono's interoperability should be at least as
> easy.
> 
> A problem here is, that Icl, while working instantly with built in
> data types (e.g. int, short, double or even int*), for other numeric
> types (e.g. boost::rational) or types "based on integral types" (e.g.
> data_time::ptime) I needed to provide adapter code.
> 
> I think it'd be ideal, if boost libraries interoperated with each
> other just out of the box, of course. To achive this, we have to find
> a common understanding of those concepts, that make a seamless
> interoperability work. I think, this is important work to be done,
> because it widens the view from one's own library perspective to a
> broader horizon of generic interplay.
> 

Recall that adding an indirection use to solve a lot of problems.

> The problem:
> There is a minimal set of requirements that Icl expects for the domain
> types of intervals and interval containers
> (1) A zero element, more precisely an identity element w.r.t. the
> type's composition operation, which usually is +. An assumption that
> works well for all built in types and many STL-types is, that we get
> this element by the default constructor T().
> 

What about creating a customization point identity or zero

template 
struct zero {
  T value() { return T(); }
};

The user or Boost.Chrono could specialize it. 

template <...>
struct zero&lt;duration&lt;...&gt; > {
  T value() { return duration<...>::zero(); }
};

> (2) A strict weak ordering <
> (3) For all discrete types and for continuous numeric types: Operators
> ++, -- (Only pre-variants needed e.g. ++x)
>   (3.1) For discrete types ++/-- increments/decrements by a *least step*
>   (3.2) For continuous numeric types ++/-- increments/decrements by a
> *unit step*.
> 

The same can be done for customizations points increase_unit, and
decrease_unit.

> 
> (4) For such equidistant scalar types D the ICL assumes, that the type
> of the difference values of D is D::difference_type.
> 

You can add another customization point

template
struct difference_type{
  typedef typename T::difference_type;
};

and specialize for the types not conforming to this trait.

> 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 possibility of default ctor customization is no remedy, because
> ICL should ideally be completely "chrono agnostic" and still
> interoperable. For the same reason duration::zero() is not an option.
> 

You can always use a duration that has a representation that default
construct to 0 and define the associated typedefs.

> T3: chrono::time_point does not implement ++ and --.
> I assume this is because of the specific maths that is designed for
> chrono::time_points (P) and durations (D) where
> - : P x P -> D
> + : P x D -> P
> + : D x P -> P
> but
> + : P x P -> P //verboten
> 
> But this should not be an argument against ++ and -- because the
> "least steppable unit" for integral rep types as well as the "unit"
> for floating point rep types, that is processed by ++ and -- is the
> same for time_points and durations.
> 

The problem with operators ++ and -- is that they should be equivalent to
x+=1 and x-=1. As you can see there is no way if we are adding minutes,
seconds, ... We could choose as default unit the one given by the duration
parameter. 

If we added operators ++ and --, we should add 
time_point + Rep, 
Rep + time_point
time_point - Rep, 

which are a little bit against the safety goals of Chrono.
 

Hoping the proposals are close to the interoperability point. If the
separated traits don't satisfy your design, maybe you could define a
specific traits that groups all your needed traits.

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/chrono-Interoperability-with-ICL-and-common-concepts-tp3357088p3357284.html
Sent from the Boost - Dev mailing list archive at Nabble.com.