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-01 16:33:43

My latest proposal with changes is attached.
Anurag_Kalia_chrono_date_Project_Proposal.docx
<http://boost.2283326.n4.nabble.com/file/n4646428/Anurag_Kalia_chrono_date_Project_Proposal.docx>  

Vicente Botet wrote
> 
> Anurag Kalia wrote
>> Hi Vicente,
>> 
>> Before I start, I want to ask what I should submit as a proposal to
>> Google? i know I am to implement date class. But the problem arises that
>> the design and implementation are still taking time to set in. 
>> How can I tell them details that most probably would change in one way or
>> another? What should I mention in the proposal beyond that I want to
>> implement date class.
> For me it is not enough to say you want to implement a date class.
> H.Hinnant and myself already did that.
> You need to mention what are the limitation on this proposal and how you
> plan to solve them.
>> Moreover, what am I expected to do? Should I make all the implementations
>> of major representations and then test them in the course of making the
>> date library? I think I should (and probably I would) but I am just
>> asking about the expectations.
> Again H.Hinnant and myself already do the major representations. 
> What needs to be done is to provide the interface that satisfy most of the
> user expectations (don't forget that performances was one of the main
> issues of H.H. proposal.

Thanks! Now I know which direction to take.

> You can see the project as: Given the H.Hinnant design and implementation,
> what needs to be changed so that the performances are improved? 
> * date validation versus  "sur parolle" valid dates, 
> * relative dates should not reduce the performances of absolute dates,
> * some algorithms are more efficient with one or another representation.

Okay. As I have already mentioned, an application requiring absolute
performance from date class would use its operations. And nothing can beat a
serial representation at comparisons, assignments and day/week arithmetic.

ymd represntations, OTOH, optimize I/O. And an application requiring such
optimization can simply employ a representation like:
struct date
{
    int y, m, d;
};

which serves their purpose well enough. For the vast majority however,
serial representation is good enough. After caching as you know, performance
nears ymd in these scenarios too.

>> I can see use of all constructors except the day_of_year constructor. 
> Why? This is an alternative representation.
>> Since we are making it a p. gregorian calendar, such interface shouldn't
>> be made public. It should rather be used in dayofyear_claendar where
>> concept of months doesn't exist, shouldn't it? 
> I disagree here. 125th day of 2013 is a valid date.

I agree and don't deny that such notation doesn't have use in the world.
But, I am proposing that the ordinal date should be used in its own
calendar. If it makes our programming easy, it should become a private
constructor instead. Haven't we designed our date class to belong to a
specific calendar only? I am not favouring this constructor only and only by
design.

>> I genuinely am curious why adding that fourth parameter might be a bad
>> design.
> Well, this is a taste question. I will comeback to your functional format
> later.

I myself have dropped this constructor. After all, it is not difficult for
users to check documentation for the order of the date parameters. It just
eats up the performance anyway, even if it is just a switch statement.

> I was talking about stream Input/output

I didn't know much about localization before today. I get the basic
understanding of basics of locale and facets now. I have to study more about
them.

> What I mean is that a date can not inherit from a days point, this is
> horrible.

In the new representation, I have tried less to keep synergies between
current chrono library and date class. I have provided explicit functions
instead to convert to/from time_point<clock, days>.

I have tried to address all these concerns and more.

Regards. :)
Anurag.

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