quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] FpML

[Fabrice C. <fab...@gm...>]

Hello,

I am a French student interested in QuantLib development. I have just
finished my Master program and will take a training course, starting
next week, about risk management. I have contacted Ferdinando & Luigi
in late december, who told me they needed people for FpML development
for the QuantLib Addin.

I had no time in january to work on this task but I wanted to do start
this week and continue during my internship.

Maybe we could work together on this project.

Best regards,

Fabrice Carrega

On Mon, 7 Feb 2005 00:53:15 -0500, David Brown <doc...@gm...> wrote:
> Hello Everyone!
> 
>    My name is David Brown.  I am a graduate student in the United
> States taking an Object-Oriented Software Engineering course.  While
> browsing through the QuantLib Project's website, I saw that various
> things still need work to enhance the power of QuantLib.
>    As part of the class that I am taking, we are supposed to find
> 'customers' to design a project.  After the project is 'planned', it
> will be bid upon by our fellow classmates.  At this point the project
> will be coded and designed by a total of four or five graduate student
> computer scientists.
>    My reason for posting this to everyone is that I have a long-term
> interest in becoming involved in Financial Software Programming.
> Therefore, it was logical for me to try and help a project like
> QuantLib.
>    I do not know the status of large portions of the project.  The
> archive filled in my knowledge about a few things, but there are still
> many things I do not have the slightest idea about.  It would be very
> nice if someone on this list group could take myself and my fellow
> classmates on as 'service providers'.
>    Clearly, I am not selling anything here.  If someone wanted to be
> our 'customers', they would simply have to assist us as our mentor.
> We would develop whatever snippets of QuantLib that are feasible in
> approximately 12 man-month hours.  (I do not believe in the myth of
> the man-month nor the antiquated Waterfall development method, but my
> professor wants us to stick to it.)
> 
> In any event, thank you for all of your help and time!
> 
> David Brown
> doc...@gm...
> 
> p.s.
> I have a natural attraction towards FpML / XML interfacing with QuantLib.
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Quantlib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] FpML

[David B. <doc...@gm...>]

Hello Everyone!

   My name is David Brown.  I am a graduate student in the United
States taking an Object-Oriented Software Engineering course.  While
browsing through the QuantLib Project's website, I saw that various
things still need work to enhance the power of QuantLib.
   As part of the class that I am taking, we are supposed to find
'customers' to design a project.  After the project is 'planned', it
will be bid upon by our fellow classmates.  At this point the project
will be coded and designed by a total of four or five graduate student
computer scientists.
   My reason for posting this to everyone is that I have a long-term
interest in becoming involved in Financial Software Programming. 
Therefore, it was logical for me to try and help a project like
QuantLib.
   I do not know the status of large portions of the project.  The
archive filled in my knowledge about a few things, but there are still
many things I do not have the slightest idea about.  It would be very
nice if someone on this list group could take myself and my fellow
classmates on as 'service providers'.
   Clearly, I am not selling anything here.  If someone wanted to be
our 'customers', they would simply have to assist us as our mentor. 
We would develop whatever snippets of QuantLib that are feasible in
approximately 12 man-month hours.  (I do not believe in the myth of
the man-month nor the antiquated Waterfall development method, but my
professor wants us to stick to it.)


In any event, thank you for all of your help and time!

David Brown
doc...@gm...


p.s.
I have a natural attraction towards FpML / XML interfacing with QuantLib.

[Quantlib-dev] [ quantlib-Bugs-1116937 ] M_PI is redefined blindly for MSVC

[SourceForge.net <no...@so...>]

Bugs item #1116937, was opened at 2005-02-05 18:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1116937&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Philip Craig (philipcraig)
Assigned to: Nobody/Anonymous (nobody)
Summary: M_PI is redefined blindly for MSVC

Initial Comment:
In config.msvc.hpp, M_PI is #defined.

This is all well and good, except if another library is
used that also included. In that case, they fight.
RogueWave is such a library.

The code #define ing M_PI should read like:

#  ifndef M_PI
#    define M_PI 3.141592653589793238462643383280
#  endif

This way, it will compile without warnings even if M_PI
has been defined already.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1116937&group_id=12740

Re: [Quantlib-dev] Tracing

[Luigi B. <lui...@gm...>]

On 02/01/05 11:52:51, Luigi Ballabio wrote:
>=20
> This leads to my question: is it worthwhile to have a tracing level in =20
> the interface? Couldn't we just dump everything (or nothing if tracing is=
 =20
> disabled?)

Having had no answer, I assume I can go ahead and remove the tracing level =
=20
from the interface?

Later,
	Luigi


----------------------------------------

Greenspun's Tenth Rule of Programming:
        Any sufficiently complicated C or Fortran program contains an
        ad-hoc, informally-specified bug-ridden slow implementation of
        half of Common Lisp.

[Quantlib-dev] Tracing

[Luigi B. <lui...@gm...>]

Hi all,
	a tracing facility is of course a useful one for debugging/=20
validating calculations. However, I don't think that it should grow into a =
=20
full-fledged logging facility: users of the library should be let free to =20
choose their preferred log library and call it in their client code. The =20
tracing macros should only be used for, well, tracing calculation details =20
and code flow, and in my opinion should be kept as simple as possible.
This leads to my question: is it worthwhile to have a tracing level in the =
=20
interface? Couldn't we just dump everything (or nothing if tracing is =20
disabled?)

Later,
	Luigi

----------------------------------------

Dealing with failure is easy: work hard to improve. Success is also easy to
handle: you've solved the wrong problem. Work hard to improve.
-- Alan Perlis

Re: [Quantlib-dev] Private versus Protected

[Luigi B. <lui...@gm...>]

On 01/31/05 20:08:39, Chuck Hinman wrote:
> My question is whether there is a good reason for private scope in
> QuantLib classes.

Yes. Subclasses are not allowed to modify the private members of the base =20
class, as doing that might cause the object to be in an inconsistent state.=
 =20
Protected access would give derived classes the right to modify such =20
members besides inspecting them.

> In my specific example my financial analyst trusts nothing and always
> wants to see the intimate details of all calculations to validate correct
> operation of the classes we use from QuantLib and those classes that we
> write. We recently wrote a class to calculate the forward volatilities =20
> for caps using the CapFloor and BlackCapFloorEngine classes. Since these
> classes hide important parts in private scope I couldn=92t inherit from t=
hem
> and display their guts, so I copied the CapFloor and BlackCapFloorEngine
> classes, changed private to protected, inherited from the copies, and
> wrote subclasses with methods to save and display the caplet/floorlet
> values at each iteration and some other intimate details. Copying =20
> QuantLib classes and inheriting from them makes me feel like I am doing =20
> something foolish and shortsighted.

Depending on your compiler, adding

#define private protected

before including the relevant headers might work. But since what you =20
actually need is read-only access, there might be other ways to obtain the =
=20
same result. If the information is not too intimate--i.e., an =20
implementation detail--you might add an inspector method to the base class =
=20
returning the appropriate information; but this might not be viable for all=
 =20
the figures you need. In the next QuantLib version, you'll be able to add =20
to the base class statements such as:

QL_TRACE("caplet value =3D " << capletValue_);

Such statements would display the information in test compilations and do =20
nothing in production code. If you find them useful, we'd be happy to =20
insert them in the code base if you provide us a patch.

Later,
	Luigi

[Quantlib-dev] introducing Eric Ehlers, ObjectHandler, and how to contribute to QuantLib

[Ferdinando A. <na...@qu...>]

Hi all

following up the latest news about the release of ObjectHandler 0.1.0 
please let me welcome Eric Ehlers in the (developer) QuantLib Team.

Eric's work (both ObjectHandler and the forthcoming QuantLibAddin) marks 
the first outstanding large contribution from someone not connected with 
the original QuantLib founding team.

Besides the code he actually provided, he was also the first one to 
effectively adopt our "how to contribute to QuantLib" guidelines: 
http://quantlib.org/newdeveloper.shtml

I apologize to whoever feels that the QuantLib team has not given him 
enough support in order to help contributions, and encourage everybody to 
go ahead: read the guidelines, select a topic (scratch your itch!), write a 
QuEP (a.k.a QuantLib Enhancement Proposal), and contribute your code to 
QuantLib.

Last but not least the QuantLib team look forward to feedback about Eric's 
QuEPs:
- QuEP 11 "Object Handler" http://quantlib.org/quep/quep011.html
- QuEP 12 "QuantLibAddin" http://quantlib.org/quep/quep012.html


ciao -- Nando 

[Quantlib-dev] Announcing ObjectHandler 0.1.0

[Ferdinando A. <na...@qu...>]

QuantLib (or any generic C++ library) integration into spreadsheets and other
end user tools requires a standalone ObjectHandler component, a repository
allowing objects to be stored, shared, updated, interrogated, and destroyed.

Version 0.1.0 has been released and is available for download at
http://sourceforge.net/project/showfiles.php?group_id=12740

ObjectHandler design is sketched in QuEP 11, it will be used for QuantLib as
proposed in QuEP 12. Both QuEPs are available on-line at
http://quantlib.org/quep.shtml

ObjectHandler shares the QuantLib project structure with regard to 
distribution,
licensing, etc., all of which is documented on the main QuantLib website:
http://quantlib.org

ObjectHandler depends on the Boost library (www.boost.org). You will need a
working Boost installation in order to compile and use ObjectHandler.
Instructions for installing Boost from sources are available at
<http://www.boost.org/more/getting_started.html>.
Pre-packaged binaries might be available from other sources. Google is
your friend (or Debian, or Fink...)

Please log any problems you have with this release in the SourceForge
bug tracker at
<http://sourceforge.net/tracker/?group_id=12740&atid=112740>
specifying that you're using ObjectHandler 0.1.0

         The QuantLib group

[Quantlib-dev] Private versus Protected

[Chuck H. <cah...@ea...>]

My question is whether there is a good reason for private scope in QuantLib=
 classes. I would like QuantLib to have protected scope rather than private=
 so that developers can inherit the local variables and methods in their su=
bclasses.

In my specific example my financial analyst trusts nothing and always wants=
 to see the intimate details of all calculations to validate correct operat=
ion of the classes we use from QuantLib and those classes that we write. We=
 recently wrote a class to calculate the forward volatilities for caps usin=
g the CapFloor and BlackCapFloorEngine classes. Since these classes hide im=
portant parts in private scope I couldn=92t inherit from them and display t=
heir guts, so I copied the CapFloor and BlackCapFloorEngine classes, change=
d private to protected, inherited from the copies, and wrote subclasses wit=
h methods to save and display the caplet/floorlet values at each iteration =
and some other intimate details. Copying QuantLib classes and inheriting fr=
om them makes me feel like I am doing something foolish and shortsighted.

regards, Charles

RE: [Quantlib-dev] US Exchange Calendar

[Ferdinando A. <na...@am...>]

sent to quantlib-users instead of quantlib-dev. Sorry.

>Hasmet,
>
>I've applied your patch to the CVS and I've also included the special 
>closings available on the nyse web site.
>
>Would you mind checking if the attached file is ok with regard to what you 
>know/need?
>
>Thank you for your help.
>
>ciao -- Nando

RE: [Quantlib-dev] US Exchange Calendar

[Hasmet A. <ha...@ya...>]

Here's a diff that smooths the irregularities since 1975. More special
closings are available at http://www.nyse.com/about/1022221392381.html but
unfortunately, holiday rule changes have not been incorporated into that
document. Note that the diff corrects an error in my previous post: The
holiday in (1) is MLK's birthday, not Washington's.

Regards,

Hasmet

> -----Original Message-----
> From: Ferdinando Ametrano [mailto:na...@am...] 
> Sent: Friday, January 21, 2005 1:50 PM
> To: Hasmet Akgun; qua...@li...
> Subject: Re: [Quantlib-dev] US Exchange Calendar
> 
> Hi Hasmet
> 
> >1) Washington's birthday has been an exchange holiday
> >only since 1998.
> >2) Until 1984, US Presidential Election Days were
> >exchange holidays.
> 
> thank you for pointing this out. We will fix them
> 
> >Also, I am wondering if the intention behind leaving
> >out special closings (mainly due to presidential
> >funerals) is performance reasons: Most users are
> >expected to use the calendar for dates in the future,
> >thus anyone using this class for past dates pays a
> >small price by adding prior closings through
> >Calendar::addHoliday?
> not really. I think the penalty of adding past closing is 
> minor and could 
> be made almost null if needed. So I would include past closing.
> 
> >Anyway, I modified unitedstates.cpp to incorporate
> >what I need and would be happy to help others on this
> >issue.
> I'll fix point 1 and 2 above. Are there more exceptions?
> 
> thank you
> 
> ciao -- Nando 
> 

Re: [Quantlib-dev] US Exchange Calendar

[Ferdinando A. <na...@am...>]

Hi Hasmet

>1) Washington's birthday has been an exchange holiday
>only since 1998.
>2) Until 1984, US Presidential Election Days were
>exchange holidays.

thank you for pointing this out. We will fix them

>Also, I am wondering if the intention behind leaving
>out special closings (mainly due to presidential
>funerals) is performance reasons: Most users are
>expected to use the calendar for dates in the future,
>thus anyone using this class for past dates pays a
>small price by adding prior closings through
>Calendar::addHoliday?
not really. I think the penalty of adding past closing is minor and could 
be made almost null if needed. So I would include past closing.

>Anyway, I modified unitedstates.cpp to incorporate
>what I need and would be happy to help others on this
>issue.
I'll fix point 1 and 2 above. Are there more exceptions?

thank you

ciao -- Nando 

[Quantlib-dev] US Exchange Calendar

[Hasmet A. <ha...@ya...>]

I was doing some backtesting and noticed a slight
discrepancy betwen the business days generated by
UnitedStates::ExchangeImpl::isBusinessDay and our
pricing database. The problem results from the fact
that isBusinessDay implements current NYSE
regulations, which have not been constant. Based on
what I have:

1) Washington's birthday has been an exchange holiday
only since 1998.
2) Until 1984, US Presidential Election Days were
exchange holidays.

Also, I am wondering if the intention behind leaving
out special closings (mainly due to presidential
funerals) is performance reasons: Most users are
expected to use the calendar for dates in the future,
thus anyone using this class for past dates pays a
small price by adding prior closings through
Calendar::addHoliday?

Anyway, I modified unitedstates.cpp to incorporate
what I need and would be happy to help others on this
issue. In any case, the modifications are
straightforward once the exceptions are known.

Regards,

Hasmet

Re: [Quantlib-dev] ObjectHandler and QuantLibAddin (and QuantLibXL)

[eric e. <eri...@gm...>]

> >My preference would be for you to announce the docs and the release at
> >the same time once everything's ready.
> ok, as long as it doesn't take too long. I think that early feedback could 
> help shaping the code...

Fair point - In that case I'm happy for you to announce/release
ObjectHandler/QuantLibAddin when you see fit.

Regards
Eric

Re: [Quantlib-dev] problem on the Black Scholes Process in the QuantLibXL

[Ferdinando A. <na...@am...>]

I will take a look at it this week-end (hopefully)...


thank you

ciao -- Nando

At 07:12 PM 1/12/2005, Adjriou Belak wrote:
>WHen I use the QLPath spreadsheet, you can notice that :
>
>E(S) = S*exp((r-q)*t) should  be equal to the averages of the last values, but
>the last values are too low .. it seems that the drift is negative for the 
>function qlPathGenerator. ?

Re: [Quantlib-dev] ObjectHandler and QuantLibAddin (and QuantLibXL)

[Ferdinando A. <na...@am...>]

At 03:11 PM 1/5/2005, eric wrote:
> > We might even have an global 0.3.9 release in January
>
>I guess if that goes ahead then the first ObjectHandler/QuantLibAddin
>release will simply be included in 0.3.9?
yes this is my opinion.

>My preference would be for you to announce the docs and the release at
>the same time once everything's ready.
ok, as long as it doesn't take too long. I think that early feedback could 
help shaping the code...


ciao -- Nando 

Re: [Quantlib-dev] BermudanSwaption.cpp and QL_PATCH_DARWIN

[Luigi B. <lui...@gm...>]

On 01/14/05 09:51:47, Aurelien Chanudet wrote:
> The BermudanSwaption.cpp example file has a #if
> defined(QL_PATCH_DARWIN) block with a "to be
> investigated" comment. I'm not sure I understand
> what's going wrong here. What kind of investigation
> are you looking for ? Being a Darwin user, how can I
> help ?

Bonjour Aurelien,
	the code defined out used to segfault. It might no longer be the =20
case, since a few versions have been released in the meantime, but I =20
couldn't test it. May you try removing the #if and see what happens?

Thanks,
	Luigi

[Quantlib-dev] BermudanSwaption.cpp and QL_PATCH_DARWIN

[Aurelien C. <ral...@ya...>]

Hi,

The BermudanSwaption.cpp example file has a #if
defined(QL_PATCH_DARWIN) block with a "to be
investigated" comment. I'm not sure I understand
what's going wrong here. What kind of investigation
are you looking for ? Being a Darwin user, how can I
help ?

Thanks,
Aurelien


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

[Quantlib-dev] Re: Test case failures on OSX

[Aurelien C. <ral...@ya...>]

Hi Luigi & Mark,
 
> Hmm, I might have a suspect. Can you try the
> attached patch on ql/Patterns/singleton.hpp
> and see if this fixes the problem?

No, this does not fix the problem. However, the
problem indeed appears to stem from the singleton
pattern implementation. The reason why some test-cases
are failing is that the supposedly *unique* instance
of the Setting class is actually not unique. In the
swapvaluation.cpp example for instance, I could spot
three instance of the Setting class (only one of these
being correctly initialized). I was unsuccessful so
far at reducing the problem to a sample test case ;
this looks more like a compiler/linker bug due to the
way the static declaration is handled.

Any idea ?

Thanks for a really nice job,
Aurelien


	

	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

[Quantlib-dev] Basket Valuation with QuantLib

[Steve Y. <ya...@in...>]

Hello All,

 

I'm wondering which end of the framework to start at to add copula
capabilities to Basket Valuation. It seems that the correlation matrix
approach is baked in deeply into path generation. 

 

As an aside, there seems to be support for cholesky decomposition but no
clear use of it I see. 

 

Cheers,

 

Steve

[Quantlib-dev] Wilmott Magazine article

[Ferdinando A. <na...@qu...>]

The September issue of Wilmott Magazine [1] published an article on 
QuantLib [2]: "Four years of open source financial models" [3]. The article 
is now also available on-line in the QuantLib Documentation Page [3].

[1] <http://www.wilmott.com/magazine.cfm>http://www.wilmott.com/magazine.cfm
[2] http://quantlib.org/
[3] 
<http://quantlib.org/press/WilmottQuantLib.pdf>http://quantlib.org/press/WilmottQuantLib.pdf 

[4] http://quantlib.org/docs.shtml

ciao -- Nando

[Quantlib-dev] QuantLibXL 0.3.8

[Ferdinando A. <na...@qu...>]

QuantLibXL 0.3.8 has been released today: no big changes, it's just in 
synch with QuantLib 0.3.8
Hopefully 0.3.9 will see *many* changes

This completes the 0.3.8 "QL suite" release

ciao -- Nando

Re: [Quantlib-dev] ObjectHandler and QuantLibAddin (and QuantLibXL)

[eric <er...@eh...>]

On Tue, 2004-12-21 at 15:03 +0100, Ferdinando Ametrano wrote:
> Hi Eric

Hello

> What would be your preferences for ObjectHandler/QuantLibAddin? Would it be 
> ok to plan for its first release? Could we have a January 0.3.8 release for 
> both QuantLibXL and QuantLibAddin?

I'm moving house next week, but will be working on this after that and
can have an ObjectHandler/QuantLibAddin release ready by the end of
January.

> [My opinion is that QuantLibAddin should replace QuantLibXL in the medium 
> term.]

Cool!  I'm happy to help support QuantLibXL for as long as it's around.

> We might even have an global 0.3.9 release in January

I guess if that goes ahead then the first ObjectHandler/QuantLibAddin
release will simply be included in 0.3.9?

> Are http://www.quantlib.org/quep/quep011.html and 
> http://www.quantlib.org/quep/quep012.html updated? Do you want me to 
> announce the QuEPs before any release of ObjectHandler and QuantLibAddin?

I've made some minor clarifications to the docs today and for me they're
done - please let me know if you want any further revisions.  You can
get all the html and images at
http://www.ehlers.plus.com/quantlib/quep11-12.zip
My preference would be for you to announce the docs and the release at
the same time once everything's ready.

> Let me know your preferences and let's get the ball rolling.

Looking forward to going live!

> ciao -- Nando 

Regards,
Eric

Re: [Quantlib-dev] swap.py woes

[Dirk E. <ed...@de...>]

On Mon, Jan 03, 2005 at 10:04:22AM +0000, Luigi Ballabio wrote:
> On 12/29/04 17:53:34, Dirk Eddelbuettel wrote:
> >I was playing with the idea of making functionality akin to swap.py
> >available via my still-too-poor-on-features RQuantLib codelet.  Trouble
> >is, I can't even run swap.py reliably.  Most of the time it just seems to  
> >go away on an endless loop. I have seen seg.faults too but I am not  
> >clueful enough with Python to debug this.
> >
> >As at least Luigi is also running Debian, could some of you please
> >confirm/deny whether it works for you?
> 
> Dirk,
> 	it does works for me. However, I'm running Sarge---do I understand  
> correctly that the autobuilder machines are running Sid instead? Which  
> release are you using?

Well, my normal machine is a testing one.  The package building happens in
batch mode in an unstable chroot, but my normal dabbling around is on
testing (and a smaller/older box running unstable).

> >Related may be the fact that I still need to disable two of the  
> >regression tests for QL-Python during the Debian builds.
> 
> Yes, I think so. Again, those tests do run correctly on my machine. But  
> curiously enough, I have the same endless-loop behavior with Ruby, which  
> doesn't happen to you.

Odd.

> Cluelessly yours,

Ah, well, that is two of us then.

Dirk

> 	Luigi
> 
> 
> 

-- 
If you don't go with R now, you will someday.
  -- David Kane on r-sig-finance, 30 Nov 2004

Re: [Quantlib-dev] swap.py woes

[Luigi B. <lui...@gm...>]

On 12/29/04 17:53:34, Dirk Eddelbuettel wrote:
> I was playing with the idea of making functionality akin to swap.py
> available via my still-too-poor-on-features RQuantLib codelet.  Trouble
> is, I can't even run swap.py reliably.  Most of the time it just seems to=
 =20
> go away on an endless loop. I have seen seg.faults too but I am not =20
> clueful enough with Python to debug this.
>=20
> As at least Luigi is also running Debian, could some of you please
> confirm/deny whether it works for you?

Dirk,
	it does works for me. However, I'm running Sarge---do I understand =20
correctly that the autobuilder machines are running Sid instead? Which =20
release are you using?

> Related may be the fact that I still need to disable two of the =20
> regression tests for QL-Python during the Debian builds.

Yes, I think so. Again, those tests do run correctly on my machine. But =20
curiously enough, I have the same endless-loop behavior with Ruby, which =20
doesn't happen to you.

Cluelessly yours,
	Luigi