Periods and such from strings

[Luigi Ballabio-4]

Hi all,
        some idle Friday afternoon thoughts:

Andre's addition of Period(std::string) was a welcome one.
(note to Andre: it might want some more checks on the passed string, though.
  Right now, Period("dummy") parses succesfully as 0 years :)

However, I wonder if such functionalities should be made available as
external functions and not as methods of the class itself. This is part due
to simmetry with classes such as DateFormatter which provide conversion
from a date to its string representation externally, and not as a method of
Date itself; and part due to the consideration that things could easily get
messy.

An example: it would be convenient to have the same functionality for
dates, so that one could initialize a Date from, say, "12/5/2002". But is
the latter May 12th or December 5th? I would like to be able to answer "it
depends on what the user wants", meaning that _you_ choose the convention
which should be followed. To do this, we could write a DateParser class to
which a locale is set containing the rules to be used for parsing: support
for more date formats would be added by writing a new locale and plugging
it in. The same locales could then be used in DateFormatter to write dates
in the desired format, rather than the built-in US format we have now. Mr.
Smith would see Christmas as "December 25th", while Sig. Rossi would see it
as "25 Dicembre".

Implementing the above is not that messy, but it is a bit on the heavy side
in terms of lines of code. Therefore, I'd rather keep things as slim as
possible and separate concerns; namely, keep Date focused on date
arithmetics and delegate formatting and dealing with locales to external
classes (DateFormatter and DateParser or whatever we call it). The same
could be done for Period, which in principle could benefit from locales too
(i.e., the Italian short-hand for "2 days" would be "2gg"). But for the
same reason, I would move the functionality in an external class/function
(and also because a plain structure such as Period with two data members
and the corresponding inline accessors---maybe 10 lines of code---would
look a bit unbalanced to me if we attached a few times as much code for
parsing :) The overloaded constructor could be given back by a one-liner
such as
     explicit Period::Period(const std::string& s) {
         *this = PeriodParser::parse(s);
     }
which might not be terribly efficient, but then again, I/O never is. I
don't expect the above to be a bottleneck if we're already reading the
strings from a file.

Thoughts?

Bye,
        Luigi

[Vadim Ogranovich-3]

Hi,

I think Luigi has a very good point - parsers should be separated from the
classes they parse into. After all operator>>(istream &, T &) is usually
(ever?) global.

As Luigi mentioned dates have additional complexity as the same date can be
represented in multiple formats. Some formats are locale-independent, e.g.
"YYYYMMDD", and some are, e.g. "MM/DD/YYYY" vs "DD/MM/YYYY".

I found it useful to have a set of locale-independent date parsing functions
(e.g. I have setFromYyyyMmDd(std::string, Date &),
setFromMmDdYyyy(std::string, Date &)). Having such functions should allow a
programmer to bypass messing with locales while the functions themselves can
have very efficient implementation as they do not need to do any guesswork.
These functions should not be considered as a substitute to more elaborated
locale-sensitive parsers, rather as a lightweight machinery to do the job
when it suffices.

Thanks,
Vadim

P.S. I envy people who have idle Friday afternoons :)

-----Original Message-----
From: Luigi Ballabio [mailto:[hidden email]]
Sent: Friday, April 26, 2002 8:49 AM
To: QuantLib users
Subject: [Quantlib-users] Periods and such from strings



Hi all,
        some idle Friday afternoon thoughts:

Andre's addition of Period(std::string) was a welcome one.
(note to Andre: it might want some more checks on the passed string, though.
  Right now, Period("dummy") parses succesfully as 0 years :)

However, I wonder if such functionalities should be made available as
external functions and not as methods of the class itself. This is part due
to simmetry with classes such as DateFormatter which provide conversion
from a date to its string representation externally, and not as a method of
Date itself; and part due to the consideration that things could easily get
messy.

An example: it would be convenient to have the same functionality for
dates, so that one could initialize a Date from, say, "12/5/2002". But is
the latter May 12th or December 5th? I would like to be able to answer "it
depends on what the user wants", meaning that _you_ choose the convention
which should be followed. To do this, we could write a DateParser class to
which a locale is set containing the rules to be used for parsing: support
for more date formats would be added by writing a new locale and plugging
it in. The same locales could then be used in DateFormatter to write dates
in the desired format, rather than the built-in US format we have now. Mr.
Smith would see Christmas as "December 25th", while Sig. Rossi would see it
as "25 Dicembre".

Implementing the above is not that messy, but it is a bit on the heavy side
in terms of lines of code. Therefore, I'd rather keep things as slim as
possible and separate concerns; namely, keep Date focused on date
arithmetics and delegate formatting and dealing with locales to external
classes (DateFormatter and DateParser or whatever we call it). The same
could be done for Period, which in principle could benefit from locales too
(i.e., the Italian short-hand for "2 days" would be "2gg"). But for the
same reason, I would move the functionality in an external class/function
(and also because a plain structure such as Period with two data members
and the corresponding inline accessors---maybe 10 lines of code---would
look a bit unbalanced to me if we attached a few times as much code for
parsing :) The overloaded constructor could be given back by a one-liner
such as
     explicit Period::Period(const std::string& s) {
         *this = PeriodParser::parse(s);
     }
which might not be terribly efficient, but then again, I/O never is. I
don't expect the above to be a bottleneck if we're already reading the
strings from a file.

Thoughts?

Bye,
        Luigi


_______________________________________________
Quantlib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

--------------------------------------------------
DISCLAIMER
This e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information.  If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly prohibited.
If you have received this e-mail in error, please immediately notify me and
permanently delete the original and any copy of any e-mail and any printout
thereof.

E-mail transmission cannot be guaranteed to be secure or error-free.  The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.

NOTICE REGARDING PRIVACY AND CONFIDENTIALITY

Knight Trading Group may, at its discretion, monitor and review the content
of all e-mail communications.

[Kris .]

Hi,

>
> As Luigi mentioned dates have additional complexity as the same date can be
> represented in multiple formats. Some formats are locale-independent, e.g.
> "YYYYMMDD", and some are, e.g. "MM/DD/YYYY" vs "DD/MM/YYYY".
>
> I found it useful to have a set of locale-independent date parsing functions
> (e.g. I have setFromYyyyMmDd(std::string, Date &),
> setFromMmDdYyyy(std::string, Date &)). Having such functions should allow a

This separation of concerns is an interesting issue, and is often
times a context/enviroment dependant thing. In an earlier avatar
as a java programmer we had to do something simillar and ended up
using AspectJ , which cross-cuts code as aspects, so for instance
Locale is an aspect of the code , the aspect preprocessor(an understatement)
would then massage the existing cpp files to take care of all points
where locales are to be handled in a specific way. Debug messages
is another aspect, logging another aspect of the system.

Now there is a cpp port of aspects that i amnt sure how mature it is
but it should be interesting development.
http://www.aspectc.org/
&
http://www.aosd.net/

cheers,
Kris

[Luigi Ballabio-4]

At 12:49 PM -0500 4/26/02, Vadim Ogranovich wrote:
>P.S. I envy people who have idle Friday afternoons :)
>
>-----Original Message-----
>From: Luigi Ballabio [mailto:[hidden email]]
>Sent: Friday, April 26, 2002 8:49 AM
>
>Hi all,
> some idle Friday afternoon thoughts:

Oops, I didn't realize the ambiguity in concatenating the adjectives.

That would have been:
"Some idle thoughts such as those which pop into your head in Friday
afternoons regardless of the work to do, because you're unable to
focus anymore"

You know, my colleagues read this mailing-list too :)

Bye,
        Luigi

--