RE: [boost] Re: Interval Library -- Using Interval for Dates/Times

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-09-03 10:24:54

Here are some thoughts about using the interval library for dates/times.

The biggest problem using date-times with interval will be that
they do NOT behave like numbers.  An explicit distinction is
made between 'time points' and 'time durations'.  The 'duration 
type' is defined to perform arithmetic.  Consider the following:
  date d1, d2;
  d1 = d1 + d2; //won't compile -- not defined  
  date_duration dd;
  d2 = d1 + dd; // ok.

This is described in more detail in the docs.

The date_time library provides it's own template called 
'period' that performs the 'interval' functions for dates and
times.  It is more like the range library than the interval 
library.  It uses a half-open range as the fundamental construct
and has some specialized functions that are a result of the
separation of time points and time durations as concepts.

That said, I could see value in being able to use interval
arithmetic with date-times.  This might be possible by adding
an additional an additional set of overloaded operators 
to accommodate the duration_type similar to the current way
boost.operators does this:

http://www.boost.org/libs/utility/operators.htm#two_arg

Here are a couple responses to other postings:

On Mon, 2 Sep 2002, David Bergman wrote:
> > But, one might want to have arithmetics without the analytical
> > properties. I.e., one might have "numbers" such as "date", where simple
> > arithmetic could be highly useful but analytical operations, for
> > example, have no place. So, if we could bisect this abstraction in some
> > way to be able to do operations on non-analytical intervals, such as
> > date intervals, which I consider a prime application area for these
> > intervals...

On 2 Sep Guillaume Melquiond wrote:
>To use intervals for dates is something I never considered, so please
>excuse me if I miss the point. In my opinion, a date is just a number
>(maybe in a strange base). So you can use the library with it (even if I
>don't see the interest to use such a complex library on such a simple
>datatype).

I'm not sure I see the issue here.  Since a date_time type (eg: date) 
should fail to compile since sin(date) is undefined.  Since thes
operations are all defined as free template functions I don't see
a problem.

>And it's not because the library allow you to compute the sinus of an
>interval that you are forced to compute it. Moreover, if you actually try
>to compute the sinus of your date interval, you may get the constant
>answer [-1:1] (just to say that, depending on the type, the library may
>not even try to compute the sinus).

I think compilation fails, see above.

> My point was: the only arithmetic operations that I can imagine on dates
> are the operation of an additive group, and it is probably not necessary
> to use rounding mode properties to guarantee the inclusion property of
> interval arithmetic. It's why I said this library (designed for scientific
> computations) was way too complex for that.

Agreed, the additive group are the only ones defined.  Also the current
date-time library performs exact calculation so rounding modes do not
apply.

Jeff