Re: [boost] [chrono/date] Performance goals and design summary

Subject: Re: [boost] [chrono/date] Performance goals and design summary
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-04 20:04:38

Le 05/05/13 00:05, Anurag Kalia a écrit :
>>>> * *Do we need to make the separation between absolute and relative
>>>>     dates?* IMO, yes. While relative dates are powerful they incur on
>>>>     unwanted overhead when absolute dates are needed.
>>> I can guess what you mean by relative and absolute dates, but I'd rather
>>> not.  Can you briefly describe what these types of dates are?
>>>
>>>
>> The date class of your proposal is what I call a relative date, as it
>> contains meta-data as last day of the month, 2nd sunday of month, ...
>> Arithmetic on relative dates is often quite powerful. We could call them
>> contextual dates or a better name if you find it.
>> What I call an absolute date is a date that has no meta-data, it defines
>> exactly a date without a context.
>>
>> 28/feb/2013 is an absolute date while last/feb/2013 is a
>> relative/contextual date.
>>
>> Taking one of examples in your original proposal
>>
>> // Print Feb. 28 for each year in the decade
>> for (date d = feb/day(28)/2010, e = feb/day(28)/2020; d != e; d +=
>> years(1))
>>       std::cout << d << '\n';
>>
>>
>> // Print the last day in  Feb. for each year in the decade
>> for (*rel_**date*  d = feb/*last*/2010,*date*  e = feb/*last*/2020; d !=
>> e; d += years(1))
>>       std::cout << d << '\n';
>>
>>
>> rel_date implicitly converts to date of course, so that the comparison
>> works as expected, the opposite not been true.
>>
>> So the following is valid
>>
>>     date dt = feb/last/2020;
>>
>> It is also true that this implicit conversion could result in surprising
>> behavior (as usual)
>>
>> // Print Feb. 28 and notthe last day in  Feb. for each year in the decade
>> for (***date*  d = feb/*last*/2010, e = feb/*last*/2020; d != e; d +=
>> years(1))
>>       std::cout << d << '\n';
>>
>> Maybe this implicit conversion should be explicit.
> I would suggest we stick to contextual dates. Relative dates are a different
> concept and that can be handled competently by already existing chrono
> library.
Agreed. I will use contextual dates from now on, until some one find a 
better name.
> So, as per the contextual dates, this actually depends on how much staying
> power we give to the word 'last'. I think the 'last' attribute ends when the
> date is made.
In the Howard implementation the last attribute is lost after day 
arithmetic. Is this what you meant?
What I want is a contextual date that has always a context independently 
of the year/month or day arithmetic.
And of course when a contextual date is converted to a 
(non-contextual)date the context is lost.
> As you rightly say, this should be made explicit.
Well up to us to decide. For the time been I admit the drawback of 
implicit conversion. I can change after more experimentation.
> have no other suggestion
> than saying that we adapt the make_date() syntax for this use-case scenario
> too?
the make_date and the operator/ factories should work for contextual and 
non contextual dates.
>
> And on a tangential note, I eat my old words. In this same thread, I have
> said that we should make year_month implementation defined. Now, I don't
> think so. Let me give an example:
>
> If we want to enumerate the last dates from {jul, 2013} to {jan, 2014},
> current api (names may change; what matters is functionality) allows us to
> write:
>
>
> for(date d = date(2013, aug, 1), e = date(2014, feb, 1);
>       d <= e;
>       d += month(1)
>      )
> {
>      std::cout << d - day(1) << '\n';
> }
>
> I wrote it like this because this was the cleanest I could manage. The
> comparison between months of different years is clumsy. We do need a
> year_month class for it. If there were one, it would look like:
>
> for( year_month ym(2013, jul), jan14(2014, jan);
>        ym <= jan14;
>        ym += month(1);
>      )
> {
>      std::cout << date(ym, last);
> }
I have never thought about doing it this using the year_month. I like it.
There is a single point that I intended to raise. Would a non-contextual 
date accept a contextual parameter as day of the month, or should we use 
the factory

     std::cout << make_date(ym, last);

But how a contextual date should output? Humm I really don't know yet. 
So to be sure we will need an explicit conversion

     std::cout << date(make_date(ym, last));

This is not very nice.

I think it is useful to build a non contextual date giving a context 
that is lost after construction.

So

date dt(y, m, last);

date dt(y,m, monday[_3rd]);

should be correct but not contextual.
> Suddenly I understand Howard's desire to include it.
What 'it' stands here?
> And I agree now. it
> just makes the whole syntax easier. This leads me to my next question, are
> there uses for similar class month_day?
I have a class month_day, but I didn't implemented month/year arithmetic 
on it. I guess this could be useful.
>
>
>> In your proposal, day arithmetic didn't satisfied the following
>>
>>     assert((aug/last/2011 - day(1) + day(1)) == aug/last/2011);
> How come it does not? The fact that the 'last' attribute gives us an
> absolute date guarantees it. Am I missing something?
>
>
See Howard proposal, this is explained there. The reason is that day 
arithmetic on Howard date class loss its meta-data context.

Best,
Vicente