Any rationale that currency codes and calendars are hard coded at compile time rather than read from a text file at runtime?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Any rationale that currency codes and calendars are hard coded at compile time rather than read from a text file at runtime?

R Yan
Thanks for answering.

And would it benefit at all if someone contributes a module that reads currency codes and calendars at runtime?

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: Any rationale that currency codes and calendars are hard coded at compile time rather than read from a text file at runtime?

Luigi Ballabio
On Sun, 2011-10-02 at 09:08 +0800, R Yan wrote:
> And would it benefit at all if someone contributes a module that reads
> currency codes and calendars at runtime?

As for calendars, the rationale is having rules (for example, "each 25
december" or "the third Wednesday in October") that remain valid for
each year, instead of having to generate and distribute the data files.
The possibility of creating a calendar at runtime is given by the
BespokeCalendar class, whose instances take a list of dates (to be read
from a file or otherwise) and build the corresponding calendar.  I'd
leave out the part where one reads the file, especially since it depends
on locales (today's date is written as 03/10/2011 in Italy and
10/03/2011 in the US).

For currencies, you might add a constructor to the Currency class that
takes the needed data and thus instantiates a currency at runtime.
Again, I'd prefer to leave out the "read from a text file" part (or from
a database, or from any other source) that can be done easily by any
application using the library.

Luigi


--

Never mistake motion for action.
-- Ernest Hemingway



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: Any rationale that currency codes and calendars are hard coded at compile time rather than read from a text file at runtime?

R Yan
Your points are perfectly valid. My point is that reading from a text file improves the extendibility of the library as it doesn't require rebuilding the source code (of course I'm sure you're well aware of that). And for date format we can easily require that the text file be encoded in utf-8 and the date in yyyy-mm-dd ISO format.
Cheers.
On Mon, Oct 3, 2011 at 6:42 PM, Luigi Ballabio <[hidden email]> wrote:
On Sun, 2011-10-02 at 09:08 +0800, R Yan wrote:
> And would it benefit at all if someone contributes a module that reads
> currency codes and calendars at runtime?

As for calendars, the rationale is having rules (for example, "each 25
december" or "the third Wednesday in October") that remain valid for
each year, instead of having to generate and distribute the data files.
The possibility of creating a calendar at runtime is given by the
BespokeCalendar class, whose instances take a list of dates (to be read
from a file or otherwise) and build the corresponding calendar.  I'd
leave out the part where one reads the file, especially since it depends
on locales (today's date is written as 03/10/2011 in Italy and
10/03/2011 in the US).

For currencies, you might add a constructor to the Currency class that
takes the needed data and thus instantiates a currency at runtime.
Again, I'd prefer to leave out the "read from a text file" part (or from
a database, or from any other source) that can be done easily by any
application using the library.

Luigi


--

Never mistake motion for action.
-- Ernest Hemingway




------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: Any rationale that currency codes and calendars are hard coded at compile time rather than read from a text file at runtime?

Luigi Ballabio
On Mon, 2011-10-03 at 20:14 +0800, R Y wrote:
> Your points are perfectly valid. My point is that reading from a text
> file improves the extendibility of the library as it doesn't require
> rebuilding the source code (of course I'm sure you're well aware of
> that).

Yes, and you can do it already.  Read a list of dates in whatever way
you like, build a BespokeCalendar instance, pass it the dates you read,
it's done.  In case a new holiday is added to an existing calendar, you
can use the addHoliday method instead of modifying the code.  So you
have extendibility.

In the context of a library, data files are somewhat prone to problems.
For instance, how should the library know where the data files are?  On
windows, you might have a preferred location for those.  On Linux
systems, there are a number of preferred locations which are used
depending on whether one installs the library as user or superuser.
Then the library might be linked statically to one's program, which
means that suddenly a developer using the library has to ship the
calendar files together with his program.  The added migraines just
don't seem worth the effort...

Luigi


--

When I was a boy of fourteen, my father was so ignorant I could hardly
stand to have the old man around. But when I got to be twenty-one, I
was astonished at how much the old man had learned in seven years.
-- Mark Twain



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev