Le 04/05/13 01:13, Anurag Kalia a écrit :
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. 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" 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? The paper states clearly that interested people could request them. I would expect there is no problem for GSoC.
Best, Vicente