Persistancy

[Andre Louw-2]

Hi,

I have a quick question on persistancy. The way you handle persistancy on a
specific Calendar is via code (e.g johannesburg.cpp). Do you have a seperate
layer that handles it in a different way (file, database etc...) in your own
use of QuantLib? I'm tickled on how you could have generic code that prices
an instrument on different Calendars without such a layer?

Thanx

André Louw
Decillion Limited - "Your Risk Is Our Domain"

Email: [hidden email]
Office: [phone]
Mobile: [phone]
Fax: [phone]

 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

[Luigi Ballabio-4]

At 09:41 AM 4/10/02 +0200, Andre Louw wrote:
>I have a quick question on persistancy. The way you handle persistancy on a
>specific Calendar is via code (e.g johannesburg.cpp). Do you have a seperate
>layer that handles it in a different way (file, database etc...) in your own
>use of QuantLib? I'm tickled on how you could have generic code that prices
>an instrument on different Calendars without such a layer?

Hi Andre,
         I'm afraid I didn't get the question, but then again, I still
haven't had my coffee this morning. What do you mean by "persistancy on a
Calendar"?
I recognize both words, but I fail to see the connection.

Later,
         Luigi

[Rod Pienaar]

Andre/Luigi

I am new to QuantLib so I haven't looked at this in detail but at first glance I had similar thoughts to Andre.

Andre, correct me if I'm wrong, but I think you are talking about what I would call "static data".  That is any data type which may change (albeit not regularly) and for that reason it should be used by the code but not form part of the code.  Things like currencies, holidays, countries and trading locations should not really be hard-coded.  I doubt that any robust system would deal with these by hard coding the variables BUT in an open source library what type of database could be used; Oracle, Sybase, SQL Server, Interbase?  There are just too many options with different advantages and disadvantages.  For an open source library you have to make static data available without limiting the user to any particular technology or platform.

One other solution I can think of it to apply the Java approach of making these items "resources" of the code.  If they are placed in resource/text files they could be stored with the code but not in the code.  Of course that gives rise to some additional coding effort such as text parsing and manipulation.  Any other thoughts?

Rgds
Rod


---------------------------------------- Message History ----------------------------------------


From:  Luigi Ballabio <[hidden email]>@lists.sourceforge.net on 10/04/2002 10:13 CET

DELEGATED - Sent by:    [hidden email]


To:    Andre Louw <[hidden email]>; "QuantlibUsers (E-mail)" <[hidden email]>
cc:
Subject:    Re: [Quantlib-users] Persistancy


At 09:41 AM 4/10/02 +0200, Andre Louw wrote:
>I have a quick question on persistancy. The way you handle persistancy on a
>specific Calendar is via code (e.g johannesburg.cpp). Do you have a seperate
>layer that handles it in a different way (file, database etc...) in your own
>use of QuantLib? I'm tickled on how you could have generic code that prices
>an instrument on different Calendars without such a layer?

Hi Andre,
         I'm afraid I didn't get the question, but then again, I still
haven't had my coffee this morning. What do you mean by "persistancy on a
Calendar"?
I recognize both words, but I fail to see the connection.

Later,
         Luigi


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



--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

[Michael Lewis-5]

> One other solution I can think of it to apply the
> Java approach of making these items "resources" of
> the code.  If they are placed in resource/text files
> they could be stored with the code but not in the
> code.  Of course that gives rise to some additional
> coding effort such as text parsing and manipulation.
>  Any other thoughts?

This approach would suggest XML documents. Which means
defining XML Schema documents for Calendars etc,
possibly the deal types too. This would mean a
reasonable amount of code change ?

I would think that would be good approach to go for
myself ... and nicely buzzword compliant as you could
easily extrapolate this to talk of building 'web
service' components etc etc ..

Rgds
Mike

--- Rod Pienaar <[hidden email]> wrote:

>
> Andre/Luigi
>
> I am new to QuantLib so I haven't looked at this in
> detail but at first glance I had similar thoughts to
> Andre.
>
> Andre, correct me if I'm wrong, but I think you are
> talking about what I would call "static data".  That
> is any data type which may change (albeit not
> regularly) and for that reason it should be used by
> the code but not form part of the code.  Things like
> currencies, holidays, countries and trading
> locations should not really be hard-coded.  I doubt
> that any robust system would deal with these by hard
> coding the variables BUT in an open source library
> what type of database could be used; Oracle, Sybase,
> SQL Server, Interbase?  There are just too many
> options with different advantages and disadvantages.
>  For an open source library you have to make static
> data available without limiting the user to any
> particular technology or platform.
>
> One other solution I can think of it to apply the
> Java approach of making these items "resources" of
> the code.  If they are placed in resource/text files
> they could be stored with the code but not in the
> code.  Of course that gives rise to some additional
> coding effort such as text parsing and manipulation.
>  Any other thoughts?
>
> Rgds
> Rod
>
>
> ---------------------------------------- Message
> History ----------------------------------------
>
>
> From:  Luigi Ballabio
> <[hidden email]>@lists.sourceforge.net on
> 10/04/2002 10:13 CET
>
> DELEGATED - Sent by:  
> [hidden email]
>
>
> To:    Andre Louw <[hidden email]>;
> "QuantlibUsers (E-mail)"
> <[hidden email]>
> cc:
> Subject:    Re: [Quantlib-users] Persistancy
>
>
> At 09:41 AM 4/10/02 +0200, Andre Louw wrote:
> >I have a quick question on persistancy. The way you
> handle persistancy on a
> >specific Calendar is via code (e.g
> johannesburg.cpp). Do you have a seperate
> >layer that handles it in a different way (file,
> database etc...) in your own
> >use of QuantLib? I'm tickled on how you could have
> generic code that prices
> >an instrument on different Calendars without such a
> layer?
>
> Hi Andre,
>          I'm afraid I didn't get the question, but
> then again, I still
> haven't had my coffee this morning. What do you mean
> by "persistancy on a
> Calendar"?
> I recognize both words, but I fail to see the
> connection.
>
> Later,
>          Luigi
>
>
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
>

https://lists.sourceforge.net/lists/listinfo/quantlib-users

>
>
>
> --
>
> This e-mail may contain confidential and/or
> privileged information. If you are not the intended
> recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy
> this e-mail. Any unauthorized copying, disclosure or
> distribution of the material in this e-mail is
> strictly forbidden.
>
>
>
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
>

https://lists.sourceforge.net/lists/listinfo/quantlib-users


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

[Andre Louw-2]

Rod,

Sorry I missed this email before I set up my reply to Luigi!

>Andre, correct me if I'm wrong, but I think you are talking about what I
would call "static data".
>That is any data type which may change (albeit not regularly) and for that
reason it should be used by the
>code but not form part of the code.  Things like currencies, holidays,
countries and trading locations should
>not really be hard-coded.  
That's it exactly.
>I doubt that any robust system would deal with these by hard coding the
variables BUT in an open source
>library what type of database could be used; Oracle, Sybase, SQL Server,
Interbase?  There are just too many
>options with different advantages and disadvantages.  For an open source
library you have to make static data >available without limiting the user to
any particular technology or platform.
I agree, with a little bit of work this can be abstracted to repository
independant code - the way the GNU project does with their EOF framework,
but, leave that for another day! For the moment you would probably extract
to another layer.
>One other solution I can think of it to apply the Java approach of making
these items "resources" of the code.  >If they are placed in resource/text
files they could be stored with the code but not in the code.  Of course
>that gives rise to some additional coding effort such as text parsing and
manipulation.  Any other thoughts?
Could work.

Thanx, Andre.
 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

[Luigi Ballabio-4]

Hi Andre', Rod, Michael and everybody,
        I admit my mail was on the longish side, but the intent was
_not_ to run over your arguments with a caterpillar :) Nor it was to
end the discussion.

Just wanted to make sure,
        Luigi


--