Re: [boost] [gsoc 2013] draft proposal for chrono::date

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Anurag Kalia (anurag.kalia_at_[hidden])
Date: 2013-05-03 19:13:16

>> My lazy, default choice is to have some fixed number of dates in the
>> cache
>> (they are not user-configurable). The algorithm by which they would be
>> kept
>> and the hashing function have not been decided.
>>
>> But it wouldn't give me much. My attempt is at memoization. I want to
>> infer
>> data from other, already-accessed dates. For example, there can be at
>> most
>> 14 types of year-calendars. There are a number of properties due to
>> recurring nature of date arithmetic. Thus, I want to, say, store 1st days
>> of
>> every year in the table and infer y, m, d, weekday, iso-year etc of
>> another
>> date in the same year from the first day of year. It would be done
>> lazily.
>> And the key used would be the srial itself because they are the only
>> property we store in our date objects as well as they uniquely identify
>> any
>> date.
> You would need at least the ymd key and the days key. The first one to 
> build your days date class and the other to get the user land 
> year/month/day attributes.

I was talking about keys to the cache. I hope we are on the same page; ymd
as key just doesn't seem right in this sense.

> Have you explored the cache mechanism the Bloomberg implemented. It 
> would be great if you can request them if you can have their 
> implementation and the performances test they do for their paper " 
> Towarda Standard C++’Date’Class" 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3344.pdf

We can do that? Though who would miss a chance to see an efficient
implementation in action? I am quite interested in using the same
performance test though. It would let me compare my class directly with
other implementations in their paper.

Is it okay to do so?

> Memoization would be a bottleneck on multi-threaded systems.

Thanks! I didn't know about it.

>>> What do you see wrong with
>>>
>>>       date d(day(7),month(12),year(2013));
>>>
>>> respect to
>>>
>>>       date d = day(7) / month(12) / year(2013);
>> I think the first version is wordy.
> There is just one additional character  ;-)

Haha! true.

>> Some may think the second version is
>> "too cute" (someone in the Kona-date-lib thought so), I think it is
>> perfectly normal to try to push forward the syntax. The "<<" operator was
>> overloaded too, and how! Dates are already used with separators. So, it
>> is
>> not like this library is trying to set a trend; it is merely following
>> the
>> age-old conventions.
> I think that for the standard this syntax must be proposed separately, 
> that is it is a SHOULD feature. For Boost I think it is a MUST so that 
> we can experiment with it.

Point.

Thanks for everything!
Anurag.

--
View this message in context: http://boost.2283326.n4.nabble.com/gsoc-2013-draft-proposal-for-chrono-date-tp4646142p4646586.html
Sent from the Boost - Dev mailing list archive at Nabble.com.