Login  Register

RE: Periods and such from strings

Posted by Vadim Ogranovich-3 on Apr 26, 2002; 11:50am
URL: http://quantlib.414.s1.nabble.com/Periods-and-such-from-strings-tp2020p2021.html

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.