Posted by
Joel Nelson-3 on
Jan 03, 2002; 12:49am
URL: http://quantlib.414.s1.nabble.com/currency-quep-tp1814p1823.html
this is just a quick reply to your latest comments.
as you have done, i have omitted anything that we've agreed on. it will
all resurface in the QuEP anyway.
>
> I agree. To wrap it into DateTime won't make any harm to any existing
> code.
> We'll have time to debate whether to collapse date and time-of-day
> _into_ Date.
i have another mail i've typed up with some ideas on the DateTime class.
i may send it out tomorrow (still playing around with some ideas). to
give you a quick preview: i think it might be good to create a DateTime
abstract class and then let the DateTime wrapper be just one
implementation of DateTime. the reason being that 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. Anyway, I will expand on this in the other mail to which i keep
eluding.
if we did go down that track, wouldn't that be a fit for using the Pimpl
idiom that i see you using with the Calendar classes?
>
>> If so, it might make sense to implement the EUR so that it
>> initializes that exchange rates of all the member currencies and adds
>> them to the ExchangeRateManager as well. (That is, if i have gotten
>> your drift.)
>
>
> I hadn't thought of that, but I think it could be done. The only thing
> I'm afraid of is the possibility of the dreadful "static
> initialization order fiasco" (see
>
http://www.parashift.com/c++-faq-lite/ctors.html). It might make sense
> to write a function which does the work and leave it to the
> application to call it, instead of calling it during library
> initialization.
i totally agree. i was just getting a little carried away once i got
the point your made. but i do think we should include some kind of
"init static rates" function for the benefit of the euro currencies.
>
>> > ExchangeRateDateBased:
>> > I have to think about this. One possibility is to keep it as is.
>> Another
>> > is to implement the same functionality by using ExchangeRateManager
>> for
>> > storing ExchangeRates with an associated start and end date, and add
>> > methods to the former to retrieve the stored ExchangeRate instances.
>>
>> i don't like the ExchangeRate without the dates. I don't think the
>> conversion factor is any good without a start/end date to qualify it.
>> if you need constant conversions you could add a member flag that
>> specifies that. Then again, I need to take a closer look at the
>> MarketElement class before going much further. I will come back to
>> you on this.
>
>
> You are right. I have been collapsing two concepts in my head which
> should be kept separated instead. The ExchangeRate class with a
> MarketElement would model the concept of "the current exchange
> rate"---an object whose value dynamically changes so that you are
> notified of changes and always get the most recent rate when you
> inspect it. The ExchangeRateDateBased would model static values, and
> as such can store its value as a simple double variable.
exactly. since you brought it to my attention, i have been taking a
look at the MarketElement class. it seems that most of the added power
comes from the observer pattern you've used and the different subclasses
that can set up complex/interdependent MarketElements. like you said,
the MarketElement is obviously meant to be dynamic, whereas the
ExchangeRateDateBased is historic and immutable.
still 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?
later on,
joel