On May 8, 2013, at 12:08 PM, Vicente J. Botet Escriba
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