Posted by
Luigi Ballabio-4 on
Jan 03, 2002; 2:51am
URL: http://quantlib.414.s1.nabble.com/currency-quep-tp1814p1824.html
Joel,
you've been reading my mind. The two points that I quote below are
two things I've been thinking about lately. My quick followups:
At 12:45 AM 1/3/02 -0800, Joel Nelson wrote:
>the current Date class is clearly based on an internal representation in
>the form of an Excel serial number. This seems to work fine for everyone
>using QuantLib::Date so far. It even works for DateTime because it turns
>out that Excel can represent HH:MM:SS after the decimal in the serial
>number. However, as it points out in the source code, this implementation
>also shares some bugs with Excel to purposely make it 100% compatible. It
>is very conceivable that someone will want to come along and implement
>"date-time" in a way that has nothing to do with Excel.
This has bugged me since a colleague of mine did a bit of profiling of our
application and found that a whole lot of time was spent into the
Calendar::isBusinessDay method. This is probably due to the fact that our
Date class contain a serial number, while the calendar rules are of course
expressed in terms of weekday, day of month and month---which causes the
latter to be recalculated each time isBusinessDay() is called.
I've been thinking of a few ideas for gaining a bit of speed which are not
quite clear enough to be put into QuEPs, such as adding memoization to the
Calendar implementations. One of these was to get away with the serial
number and store the actual day, month, year data. This would put a bit of
load on whoever passed or wanted serial numbers, but what the hey, if you
want to use a library from a spreadsheet you are already converting data
types and you can't expect all that speed. I guess I'll get a better grasp
of the issue when we discuss DateTime...
>i wonder if there still isn't a scope for adding start/end dates to the
>dynamic ExchangeRate. for example, as the exchange rate changes, at
>certain intervals, the ExchangeRate can be stored for conversion at some
>time in the future. then again, maybe this could be up to some client
>code watching for changes in the ExchangeRate.
>
>these are just ideas. the more i think about it, the less i think we
>should add to the dynamic ExchangeRate. With the flexibility of the
>MarketElement, it should
>be straightforward for the client to set up it's own exchange rate
>"logging". we could always add this kind of gravy later. what do you think?
Well, out of curiosity, I just implemented a Python class (using the
QuantLib-Python module) which logs to a file the times at which a
MarketElement changes and the values it gets. It took no more than 15
minutes and 20 lines of code. It shouldn't be any more difficult to do it
in C++, or to make it so that instead of logging to a file it creates an
ExchangeRateDateBased instance and adds it to ExchangeRateManager.
Later,
Luigi