Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-03 19:29:43
Le 04/05/13 01:13, Anurag Kalia a Ã©crit :
>>> 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.
Why? You need the cache to access the ymd from days and another to
validate a date when construction a days date from ymd.
Couldn't you have a cache indexed by year/month that gives you the
number of days since an epoch (for some years of course)?
>> 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?
The paper states clearly that interested people could request them. I
would expect there is no problem for GSoC.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk