Re: [boost] [chrono/date] conversion between concrete dates

Subject: Re: [boost] [chrono/date] conversion between concrete dates
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2013-05-08 13:29:54

On May 8, 2013, at 12:08 PM, Vicente J. Botet Escriba <vicente.botet_at_[hidden]> wrote:

> Hi,
> 
> as the conversion between concrete dates could be expensive I guess that these conversion must be explicit.
> 
> But this has some consequences when used the implicit conversion was hidden a not efficient implementation, e.g.
> 
>  date ISO_week_start = mon <= jan/day(4)/y;
> 
> jan/day(4)/y should be ymd_date as is the efficient representation.
> 
> The date generator was declared as
> 
>   date operator<=(weekday wd, date x);
> 
> but it works efficiently only for days_date. If we provide only the functions that are efficient we should declare it as
> 
>  days_date operator<=(weekday wd, days_date x);
> 
> So the preceding expression would need an explicit conversion
> 
>  days_date ISO_week_start = mon <= days_date(jan/day(4)/y);
> 
> Do we want to go on this direction?
> 
> A radical alternative to the explicit construction, if we want to make evident that the conversion operation could be expensive, is to use a compute_ factory
> 
>  days_date ISO_week_start = mon <= compute_days_date(jan/day(4)/y);
> 
> Best,
> Vicente
> 
> P.S. the generator function is just an example needing explicit conversion.

I think we should consider the route of an explicit conversion between the serial date and the ymd date, and see where field experience takes us.

In some timings I did last weekend I was getting about 1.2ns for a field->serial conversion averaged over 200 years, and 18ns for a serial->field conversion averaged over the same range.  I was just timing the conversion function, and not any validation checks.

If experience holds that serial->field is 15X the cost of field->serial, a possibility is for a hybrid approach: implicit in one direction and explicit in the other.  However I wouldn't take these numbers as fact.  This is just one report from one machine and one implementation.

Howard