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
>> (they are not user-configurable). The algorithm by which they would be
>> and the hashing function have not been decided.
>> But it wouldn't give me much. My attempt is at memoization. I want to
>> data from other, already-accessed dates. For example, there can be at
>> 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
>> every year in the table and infer y, m, d, weekday, iso-year etc of
>> date in the same year from the first day of year. It would be done
>> 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
> 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"
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 ;-)
>> 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
>> not like this library is trying to set a trend; it is merely following
>> 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.
Thanks for everything!
-- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk