quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Draft documentation

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

Hi all,
	I started describing the architecture of QuantLib. A draft of a chapter
is available at the C(omp)++ site, namely, at the address
<http://www.compplusplus.com/2007/04/luigi_ballabio__2.html>.

You're all welcome to read it and comment on it. Comments on the
architecture of the library should be sent to this mailing list;
comments on the draft as such should be sent to me directly so that the
mailing list doesn't get polluted.

Thanks,
	Luigi


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

No, I'm not interested in developing a powerful brain. All I'm after 
is just a mediocre brain, something like the president of American 
Telephone and Telegraph Company. 
-- Alan Turing on the possibilities of a thinking machine, 1943. 

[Quantlib-dev] New math libraries in Boost

[Piter D. <pit...@ma...>]

Guys,

We have already told about GSL, but the GPL license was allways a problem.
Today I visited Boost in order to see if there is some news and found the
Math Toolkit library under review.
GSL is much more complete but Math Toolkit seems to be a very good first step
for some Quantlib math algorithms and functions standardization.
Once GSL guys don´t want to move to LGPL license (you can read it in their
site), this alternative could grow up once there is a lot of projects and
products that can´t be GPL.

Regards,



Piter Dias
pit...@ca...

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10372]trunk/QuantLib

[DU V. DE V. F. G. P. <fra...@ca...>]

> shouldn't they be removed from SegmentIntegral's constructor?

Sure I will fix that asap,
Fran=E7ois

Re: [Quantlib-dev] QuantLib 0.4.0 test suite fails

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

Hi Luigi,

> Eric, can you change permissions to faq.shtml on the site so that it's
> group-writable?

Done.

Regards,
Eric

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10372] trunk/QuantLib

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

On Tue, 2007-04-24 at 10:04 -0700, fd...@us... wrote:
> Revision: 10372
> 
> http://quantlib.svn.sourceforge.net/quantlib/?rev=10372&view=rev
> Author:   fdv1
> Date:     2007-04-24 10:04:52 -0700 (Tue, 24 Apr 2007)
> 
> Log Message:
> -----------
> SegmentIntegral adapted to the new framework
> 
> Modified: trunk/QuantLib/ql/models/shortrate/twofactormodels/g2.cpp
> ===================================================================
> --- trunk/QuantLib/ql/models/shortrate/twofactormodels/g2.cpp	2007-04-24 16:01:25 UTC (rev 10371)
> +++ trunk/QuantLib/ql/models/shortrate/twofactormodels/g2.cpp	2007-04-24 17:04:52 UTC (rev 10372)
> @@ -219,9 +219,9 @@
>  
> -        SegmentIntegral integrator(intervals);
> -
> +        Size maxEvaluations = 1; // dummy value
> +        Real absoluteAccuracy = .1; // dummy value
> +        SegmentIntegral integrator(absoluteAccuracy, maxEvaluations, intervals);

If the parameters are dummy, shouldn't they be removed from
SegmentIntegral's constructor?

Later,
	Luigi


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

Newton's Law of Gravitation: 
What goes up must come down. But don't expect it to come down 
where you can find it. Murphy's Law applies to Newton's. 

Re: [Quantlib-dev] Subversion glitches

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

On Mon, 2007-04-16 at 10:36 +0200, Luigi Ballabio wrote:
> a) due to non-ASCII characters in a few past commit messages, "svn log"
> is currently broken. I can fix it, but I'll need to take the repository
> down for a day or two. I might be able to do it during the next weekend
> or the one after, which means that you won't be able to commit on those
> Saturday and Sunday. Any objections?

As you might have noticed, this is now fixed.

On a related note, do you think that it still makes sense to include the
ChangeLog in the release? With the switch to Subversion, we might just
point the interested user to, say,
<http://quantlib.svn.sf.net/viewvc/quantlib/trunk/QuantLib/?view=log>
(or the equivalent URL for the release branch) and make the distributed
tarball 200k slimmer.

Later,
	Luigi


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

Humphrey's Requirements Uncertainty Principle: 
For a new software system, the requirements will not be 
completely known until after the users have used it. 

Re: [Quantlib-dev] QuantLib 0.4.0 test suite fails

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

On Sun, 2007-04-08 at 13:13 +0200, eric ehlers wrote:
> > Testing flat-volatility stripping...
> > ./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping":
> 
> I added this to the FAQ:
>     http://quantlib.org/faq.shtml#Testing%20QuantLib1
> 
> François, your comment on the ticket suggests that you understand the
> cause of the bug but gives no indication of a resolution, do you have
> one in mind?

The fix for the test would be to adjust today's date so that it's a
business day. i just committed it.

Eric, can you change permissions to faq.shtml on the site so that it's
group-writable?

Thanks,
	Luigi


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

The first rule of intelligent tinkering is to save all the parts. 
-- Paul Erlich 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10348] trunk/QuantLib

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

On Tue, 2007-04-24 at 10:06 +0200, Ferdinando Ametrano wrote:
> On 4/24/07, Luigi Ballabio <lui...@gm...> wrote:
> > for instance, the subfolders basissystems,
> > exercisestrategies, exercisevalues and nodedataproviders could as well
> > disappear and the files in them could be moved into a single folder
> > named callability.
> fine with me if you prefer this way, and I agree that in the current
> situation this might be better. Anyway my personal preference would be
> for sub-folder to reflect class hierarchies: imho this helps code
> browsing very much, especially since I forecast more BasisSystem and
> ExerciseStrategy classes being developed in the next months

It helps only if you know what class hierarchies are used (and how) for
a particular domain. In the current situation, a new user is more likely
to look into the marketmodels folder and say "nodedataproviders? What
are those for?" At which point he should hunt in other browsers (without
much help from the file structure) to find out to what other hierarchies
it is related and how it should be used.

On the other hand, if all files were in a callability folder (and
honestly, I don't have much of a problem with, say, 30 files in the same
folder as long as they're aptly named) it would be clear that the
corresponding hierarchies are related.

As for documenting class hierarchies for code navigation, that is easier
to do than documenting relationships between hierarchies. Exploring a
hierarchy is a mechanical process and can be done automatically (see <
http://quantlib.org/reference/class_quant_lib_1_1_market_model_evolver.html> for an example.) Your IDE does it too if you open its class browser.

Thoughts? Should I make the changes and branch?

Later,
	Luigi


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

Academic: a term of opprobrium applied to those that do their job well 
by those who cannot. 
-- Sir Ernest Gowers 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10331] trunk/QuantLib

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

On Tue, 2007-04-24 at 10:05 +0200, Ferdinando Ametrano wrote:
> > Were we to choose, I'd go for the short format since the files are
> > contained in the marketmodel directory anyway. I wouldn't worry that the
> > class name doesn't match exactly the file name---and after all, it does
> > match if we take the parent folder into account.
> I prefer whenever possible the file name to match the class name. Any
> alternative can easily have some ambiguity, e.g. for classes as
> ParametricExercise (in the montecarlo folder) and
> MarketModelParametricExercise (in the marketmodel folder)

Nando,
	true, but my point was that marketmodel/parametricexercise.hpp does
match MarketModelParametricExercise. Since we use the full path in
header inclusions, marketmodel/marketmodelparametricexercise.hpp is
redundant.

Later,
	Luigi


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

It is better to know some of the questions than all of the answers. 
-- James Thurber 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10348] trunk/QuantLib

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

On 4/24/07, Luigi Ballabio <lui...@gm...> wrote:
>         are we really going to have a marketmodels subfolder for each class
> hierarchy? Of course I'm not against structuring the source tree, but
> hierarchies are just an implementation detail (the clearest example of
> this being the nodedataproviders folder.) I'd rather structure it
> according to the domain; for instance, the subfolders basissystems,
> exercisestrategies, exercisevalues and nodedataproviders could as well
> disappear and the files in them could be moved into a single folder
> named callability.
fine with me if you prefer this way, and I agree that in the current
situation this might be better. Anyway my personal preference would be
for sub-folder to reflect class hierarchies: imho this helps code
browsing very much, especially since I forecast more BasisSystem and
ExerciseStrategy classes being developed in the next months

Anyway the main goal was just to clean up the top level marketmodels
folder: I wanted to clean up the former status where files had
obsolete names, including classes with different names, etc. The
former situation was quite hard to navigate even for me who's been
developing this material since day 1.

ciao -- Nando

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10331] trunk/QuantLib

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

On 4/23/07, Luigi Ballabio <lui...@gm...> wrote:
> Is there any reason why on the one hand the header
> marketmodelconstrainedevolver.hpp became constrainedevolver.hpp while on
> the other hand exercisevalue.hpp became marketmodelexercisevalue.hpp?
The classes were named ConstrainedEvolver and MarketModelExerciseValue
respectively, so I just renamed the files from the classes, to fix the
confusion. I agree that MarketModelExerciseValue could be renamed just
ExerciseValue...

> Were we to choose, I'd go for the short format since the files are
> contained in the marketmodel directory anyway. I wouldn't worry that the
> class name doesn't match exactly the file name---and after all, it does
> match if we take the parent folder into account.
I prefer whenever possible the file name to match the class name. Any
alternative can easily have some ambiguity, e.g. for classes as
ParametricExercise (in the montecarlo folder) and
MarketModelParametricExercise (in the marketmodel folder)

ciao -- Nando

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10348] trunk/QuantLib

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

On Mon, 2007-04-23 at 08:47 -0700, na...@us... wrote:
> Revision: 10348
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10348&view=rev
> Author:   nando
> Date:     2007-04-23 08:47:20 -0700 (Mon, 23 Apr 2007)
> 
> Log Message:
> -----------
> - adopted lower case filters in VC8 project
> - in folder marketmodels: moved all derived classes in their proper sub-folder

Hi,
	are we really going to have a marketmodels subfolder for each class
hierarchy? Of course I'm not against structuring the source tree, but
hierarchies are just an implementation detail (the clearest example of
this being the nodedataproviders folder.) I'd rather structure it
according to the domain; for instance, the subfolders basissystems,
exercisestrategies, exercisevalues and nodedataproviders could as well
disappear and the files in them could be moved into a single folder
named callability.

Later,
	Luigi


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

standards, n.: 
The principles we use to reject other people's code. 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10329] trunk/QuantLib

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

On Mon, 2007-04-23 at 06:19 -0700, gi...@us... wrote:
> Revision: 10329
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10329&view=rev
> Author:   giorfa
> Date:     2007-04-23 06:19:45 -0700 (Mon, 23 Apr 2007)
> 
> Log Message:
> -----------
> floater range accrual added
> 
> Added Paths:
> -----------
>     trunk/QuantLib/ql/cashflows/rangeaccrual.cpp
>     trunk/QuantLib/ql/cashflows/rangeaccrual.hpp

Hi all,
	just a few notes. They're not intended to bash the unfortunate
committer of these particular files (which just happened to be the
latest one) but rather to point out a few common mistakes that we all
let slip in the code from time to time, and that can be avoided with a
bit of attention. So:

> Added: trunk/QuantLib/ql/cashflows/rangeaccrual.hpp
> ===================================================================
> +
> +#include <ql/TermStructures/Volatilities/smilesection.hpp>
> +#include <ql/Indexes/iborindex.hpp>
> +#include <ql/CashFlows/all.hpp>

The above won't compile under Linux or Mac OS X. All folder names are
now lowercase.


> +    //! RangeAccrualFloatersCoupon
> +    /*!
> +
> +    */
> +     class RangeAccrualFloatersCoupon: public IborCoupon{

Just repeating the name of the class is not very useful as a comment. It
will show up in the reference manual as:

RangeAccrualFloatersCoupon:   RangeAccrualFloatersCoupon

It might work as a placeholder, but we all know that we won't come back
to expand it once the class works...


> +      public:
> +          
> +        double startTime_;                               // S
> +        double endTime_;                                 // T
> +
> +        const boost::shared_ptr<Schedule> observationsSchedule_; 
> +        std::vector<Date> observationDates_;                    
> +        std::vector<double> observationTimes_;                  
> +        int observationsNo_;
> +        
> +        double lowerTrigger_;
> +        double upperTrigger_;

These data member are in the public section, but that's not the main
problem. We should use Real, Integer, Size etc. instead of int and
double. This way, the corresponding variables will automatically change
their precision when a user redefines QL_DOUBLE and QL_INTEGER.


> Added: trunk/QuantLib/ql/cashflows/rangeaccrual.cpp
> ===================================================================
> +    RangeAccrualPricerByBgm::RangeAccrualPricerByBgm(
> +            double correlation,
> +            const  boost::shared_ptr<SmileSection>& smilesOnExpiry,
> +            const  boost::shared_ptr<SmileSection>& smilesOnPayment,
> +            bool withSmile,
> +            bool byCallSpread)
> +    :correlation_(correlation),
> +    smilesOnExpiry_(smilesOnExpiry),
> +    smilesOnPayment_(smilesOnPayment),
> +    withSmile_(withSmile),
> +    byCallSpread_(byCallSpread){
> +        
> +    }

Data members should be initialized in the same order in which they're
declared. Not doing so may result in a warning in the best case; in
hard-to-track bugs in the worst case. 


> \ No newline at end of file

This is harmless, but still it causes a warning in gcc when -Wall is
enabled.


Thanks,
	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] [QuantLib-svn] SF.net SVN: quantlib: [10331] trunk/QuantLib

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

On Mon, 2007-04-23 at 06:29 -0700, na...@us... wrote:
> Revision: 10331
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10331&view=rev
> Author:   nando
> Date:     2007-04-23 06:29:10 -0700 (Mon, 23 Apr 2007)
> 
> Log Message:
> -----------
> renamed files in accordance with their current actual content

Is there any reason why on the one hand the header
marketmodelconstrainedevolver.hpp became constrainedevolver.hpp while on
the other hand exercisevalue.hpp became marketmodelexercisevalue.hpp?

Were we to choose, I'd go for the short format since the files are
contained in the marketmodel directory anyway. I wouldn't worry that the
class name doesn't match exactly the file name---and after all, it does
match if we take the parent folder into account.

Later,
	Luigi


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

Just remember what ol' Jack Burton does when the earth quakes, the 
poison arrows fall from the sky, and the pillars of Heaven shake. Yeah, 
Jack Burton just looks that big old storm right in the eye and says, 
"Give me your best shot. I can take it." 
-- Jack Burton, "Big trouble in Little China" 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10324]trunk/QuantLib

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

On Mon, 2007-04-23 at 15:22 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> >Francois,
> >	may you describe the new framework? What do we gain with respect to >the
> >previous implementation?
> 
> Well, maybe new framework  was a bit exagerated, however here are the improvements you should gain:
> 
> ->all the cumbersome implementation code will be moved in cpp file

Yes, that's a big plus. Switching to boost::function was a good idea.

> ->all Integrators will derive from the same base class and share some common code.

Ok. I'm still not sure whether or not the base class should be virtual,
but the principle is sound.

> I intend to ask people to review this new framework when it will be
> finished. If you want to start now please feel free... :-)

No, just go ahead. I'll have a look at it when it's finished.

Later,
	Luigi


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

Cogito ergo I'm right and you're wrong. 
-- Blair Houghton 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10324]trunk/QuantLib

[DU V. DE V. F. G. P. <fra...@ca...>]

>> Integration refactoring in progress:
>> the old GaussKronrod class has been renamed in =
GaussKronrodNonAdaptive >and adapted to the new framework, client code =
and tests updated accordingly

>Francois,
>	may you describe the new framework? What do we gain with respect to =
>the
>previous implementation?

Well, maybe new framework  was a bit exagerated, however here are the =
improvements you should gain:

->all the cumbersome implementation code will be moved in cpp file
->all Integrators will derive from the same base class and share some =
common code.

This standardization might help users to use and compare different =
integrations algorithms in a more convenient way. I intend to ask people =
to review this new framework when it will be finished. If you want to =
start now please feel free... :-)
Fran=E7ois

Re: [Quantlib-dev] Array vs std::vector + free operators

[DU V. DE V. F. G. P. <fra...@ca...>]

Hi Mark,

Thanks for your reply, I fully agree with you, And to tell the truth I =
would even dare to say that I don't find this so ugly, if it was only up =
to me it's likely that I would code linear operations this way ...

Fran=E7ois=20


-----Original Message-----
From: qua...@li... =
[mailto:qua...@li...] On Behalf Of Mark =
joshi
Sent: Saturday, April 21, 2007 12:08 AM
To: qua...@li...
Subject: [Quantlib-dev] Array vs std::vector + free operators

Re the vector + array operations. If you want true efficiency, you
have to do one of the following:
Define a function plus

void plus(const Array& left, const Array& right, Array& target);

this is ugly but efficient

or use expression templates which always struck me as very fiddly (but
are in stroustrup assuming it's survived the slapping...)

Mark



On 21/04/07, qua...@li...
<qua...@li...> wrote:
> Send QuantLib-dev mailing list submissions to
>         qua...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> or, via email, send a message with subject or body 'help' to
>         qua...@li...
>
> You can reach the person managing the list at
>         qua...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of QuantLib-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Array vs std::vector + free operators (Luigi Ballabio)
>    2. Market-model tests (Luigi Ballabio)
>    3. Re: Array vs std::vector + free operators
>       (DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI)
>    4. Re: Array vs std::vector + free operators (Luigi Ballabio)
>    5. Re: Array vs std::vector + free operators
>       (DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI)
>    6. Re: [QuantLib-svn] SF.net SVN: quantlib: [10251]
>       trunk/QuantLib (Ferdinando Ametrano)
>    7. Re: [QuantLib-svn] SF.net SVN: quantlib:  [10251]
>       trunk/QuantLib (Luigi Ballabio)
>    8. Re: Array vs std::vector + free operators (Luigi Ballabio)
>    9. Re: [QuantLib-svn] SF.net SVN: quantlib: [10231]
>       trunk/QuantLib (Ferdinando Ametrano)
>   10. Re: [QuantLib-svn] SF.net SVN: quantlib: [10219]
>       trunk/QuantLib (Ferdinando Ametrano)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Apr 2007 16:36:28 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
>         <fra...@ca...>
> Cc: qua...@li...
> Message-ID: <1176993388.4980.186.camel@ITSUP001>
> Content-Type: text/plain; charset=3Dutf-8
>
> On Thu, 2007-04-19 at 15:47 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
> GASAPRD PHI wrote:
> > I have tried to removing the dependency on Array class from the
> > optimization framework. One change leading to another it turns out
> > that Arrray dependencies could be removed in the whole QL !
> > The only change I had to do was to provide missing operators an
> > independent header file and all worked fine. As a result I?m =
wondering
> > if using plain std::vector instead of Arrray wouldn?t be more
> > efficient in terms of compilation efficiency and flexibility of use.
> > (if one want to use linear algebra he has just to include a file
> > defining new operators?).
>
> Fran?ois,
>         it doesn't sound right to me, for a couple of reasons:
>
> - you're changing the std::vector interface by adding operators. I'm =
not
> sure that it is legal C++.  Moreover, this might be done without the
> user knowing it if he happens to include a file which in turn includes
> your new operators. Thus, code which according to the C++ standard is
> not valid (such as w =3D u+v if u,v,and w are std::vectors) would =
silently
> become legal. I'm not comfortable with this.
>
> - there's a conceptual difference between the two classes, and using
> std::vector for both would confuse the issue. std::vector is a
> container; Array is the linear-algebra concept of an array. I, too, =
had
> been thinking of replacing Array with an STL class, but the right one
> would be std::valarray---which models the right concept and already
> defines the required operators.
>
> Later,
>         Luigi
>
>
> ----------------------------------------
>
> If you can't convince them, confuse them.
> -- Harry S. Truman
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 Apr 2007 17:08:01 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: [Quantlib-dev] Market-model tests
> To: QuantLib developers <qua...@li...>
> Message-ID: <1176995281.4980.195.camel@ITSUP001>
> Content-Type: text/plain
>
>
> Hi all,
>         now that the market-model tests for the callable-swap were =
re-enabled,
> the test suite seems to take forever (as in more than one hour on a
> recent machine.) Is it because CurveState's methods are now virtual?
>
> Later,
>         Luigi
>
> ----------------------------------------
>
> I'd never join any club that would have the likes of me as a member.
> -- Groucho Marx
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 19 Apr 2007 17:11:22 +0200
> From: "DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI"
>         <fra...@ca...>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: "Luigi Ballabio" <lui...@gm...>
> Cc: qua...@li...
> Message-ID:
>         =
<EA1...@S0...>
> Content-Type: text/plain;       charset=3D"iso-8859-1"
>
>
> Fran?ois,
>         it doesn't sound right to me, for a couple of reasons:
>
> >- you're changing the std::vector interface by adding operators. I'm =
not
> >sure that it is legal C++.  Moreover, this might be done without the
> >user knowing it if he happens to include a file which in turn =
includes
> >your new operators. Thus, code which according to the C++ standard is
> >not valid (such as w =3D u+v if u,v,and w are std::vectors) would =
silently
> >become legal. I'm not comfortable with this.
>
> We could provide only specialized templates implementation. (for =
double, even if it some of them might also make sense with other data =
like Date,...) Anyway I'm pretty sure that any decent compiler would =
squeal if the corresponding elementwise operation doesn't exist.
>
> >- there's a conceptual difference between the two classes, and using
> >std::vector for both would confuse the issue. std::vector is a
> >container; Array is the linear-algebra concept of an array. I, too, =
had
> >been thinking of replacing Array with an STL class, but the right one
> >would be std::valarray---which models the right concept and already
> >defines the required operators.
>
> I agree with you that a general purpose container and an Array are two =
different beasts. About the valarray Josuttis doesn't seem to be a great =
fan:
> "At the time of this writing, no such implementation is known, and =
standard valarrays are, generally speaking, quite inefficient at =
performing the operations for which they were designed." (C++ templates: =
The complete guide)
>
> Maybe they have improved it since ... :-)
>
> Rgds,
> Fran?ois
>
> PS: here is an example of the operators I have defined:
>
> inline const Disposable<std::vector<Real> > operator+(const =
std::vector<Real>& v1, const std::vector<Real>& v2) {
>         QL_REQUIRE(v1.size() =3D=3D v2.size(),
>                    " vectors with different sizes (" << v1.size() << =
", "
>                    << v2.size() << ") cannot be added");
>         std::vector<Real> result(v1.size());
>         std::transform(v1.begin(),v1.end(),v2.begin(),result.begin(),
>                        std::plus<Real>());
>         return result;
>     }
>
> PPS: I don't want to be pushy about this. It is just an idea I'm =
playing with.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 19 Apr 2007 17:32:14 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
>         <fra...@ca...>
> Cc: qua...@li...
> Message-ID: <1176996734.4980.206.camel@ITSUP001>
> Content-Type: text/plain
>
> On Thu, 2007-04-19 at 17:11 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
> GASAPRD PHI wrote:
> > >- you're changing the std::vector interface by adding operators. =
I'm not
> > >sure that it is legal C++.  Moreover, this might be done without =
the
> > >user knowing it if he happens to include a file which in turn =
includes
> > >your new operators. Thus, code which according to the C++ standard =
is
> > >not valid (such as w =3D u+v if u,v,and w are std::vectors) would =
silently
> > >become legal. I'm not comfortable with this.
> >
> > We could provide only specialized templates implementation. (for =
double, even if it some of them might also make sense with other data =
like Date,...) Anyway I'm pretty sure that any decent compiler would =
squeal if the corresponding elementwise operation doesn't exist.
>
> You would still be changing the interface of that particular
> specialization of std::vector. The problem remains. I'm not referring =
to
> the possibility of adding vectors of non-numeric types; the compiler
> would reject that. I'm saying that the C++ standard states that w =3D =
u+v
> doesn't work with std::vector, and you're making it work.
>
>
> > I agree with you that a general purpose container and an Array are =
two different beasts. About the valarray Josuttis doesn't seem to be a =
great fan:
> > "At the time of this writing, no such implementation is known, and =
standard valarrays are, generally speaking, quite inefficient at =
performing the operations for which they were designed." (C++ templates: =
The complete guide)
> >
> > Maybe they have improved it since ... :-)
>
> Maybe. Or maybe we could implement Array _in terms of_ std::vector. =
But
> there should be no conceptual confusion between the two.
>
>
> > PS: here is an example of the operators I have defined:
> >
> > inline const Disposable<std::vector<Real> > operator+(const =
std::vector<Real>& v1, const std::vector<Real>& v2) {
> >         QL_REQUIRE(v1.size() =3D=3D v2.size(),
> >                    " vectors with different sizes (" << v1.size() << =
", "
> >                    << v2.size() << ") cannot be added");
> >         std::vector<Real> result(v1.size());
> >         =
std::transform(v1.begin(),v1.end(),v2.begin(),result.begin(),
> >                        std::plus<Real>());
> >         return result;
> >     }
>
> Apart from adding operations to std::vector, the above is not as
> efficient as Array:operator+. if you write
>
> std::vector<Real> w =3D u+w;
>
> the addition returns a Disposable, but the std::vector constructor
> doesn't know what to do with it, so it copies its contents instead of
> swapping. If you want full efficiency, you have to write:
>
> std::vector<Real> w;
> w.swap(u+v);
>
> which is more awkward. On the other hand, Array defines a constructor
> taking a Disposable, so there's no moving in
>
> Array w =3D u+v;
>
>
> > PPS: I don't want to be pushy about this. It is just an idea I'm =
playing with.
>
> Same here.
>
> Later,
>         Luigi
>
>
> ----------------------------------------
>
> Quote me as saying I was misquoted.
> -- Groucho Marx
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 19 Apr 2007 18:52:43 +0200
> From: "DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI"
>         <fra...@ca...>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: "Luigi Ballabio" <lui...@gm...>
> Cc: qua...@li...
> Message-ID:
>         =
<EA1...@S0...>
> Content-Type: text/plain;       charset=3D"iso-8859-1"
>
>
>
> >Apart from adding operations to std::vector, the above is not as
> >efficient as Array:operator+. if you write
>
> >std::vector<Real> w =3D u+w;
>
> >the addition returns a Disposable, but the std::vector constructor
> >doesn't know what to do with it, so it copies its contents instead of
> >swapping. If you want full efficiency, you have to write:
>
> >std::vector<Real> w;
> >w.swap(u+v);
>
> >which is more awkward. On the other hand, Array defines a constructor
> >taking a Disposable, so there's no moving in
>
> >Array w =3D u+v;
>
> I badly missed this point, I will slap myself with bjarne's book ;-)
>
> Fran?ois
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 19 Apr 2007 19:25:07 +0200
> From: "Ferdinando Ametrano" <na...@am...>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
>         [10251] trunk/QuantLib
> To: qua...@li...
> Message-ID:
>         <864...@ma...>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>
> On 4/19/07, lba...@us...
> <lba...@us...> wrote:
> > Delta, gamma and theta added to binomial engine for vanilla options =
(thanks to Steve Cook.)
> > Theta is currently not close enough to analytic values. =
Investigation would be needed.
>
> why theta isn't just deduced from Delta and Gamma using Black
> equation? This approach is used elsewhere in QuantLib.
>
> ciao -- Nando
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 20 Apr 2007 08:49:19 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
>         [10251] trunk/QuantLib
> To: Ferdinando Ametrano <na...@am...>
> Cc: qua...@li...
> Message-ID: <1177051759.4980.218.camel@ITSUP001>
> Content-Type: text/plain
>
> On Thu, 2007-04-19 at 19:25 +0200, Ferdinando Ametrano wrote:
> > On 4/19/07, lba...@us...
> > <lba...@us...> wrote:
> > > Delta, gamma and theta added to binomial engine for vanilla =
options (thanks to Steve Cook.)
> > > Theta is currently not close enough to analytic values. =
Investigation would be needed.
> >
> > why theta isn't just deduced from Delta and Gamma using Black
> > equation? This approach is used elsewhere in QuantLib.
>
> Yes, I can try that.
>
> 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
>
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 20 Apr 2007 08:52:36 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
>         <fra...@ca...>
> Cc: qua...@li...
> Message-ID: <1177051956.4980.220.camel@ITSUP001>
> Content-Type: text/plain
>
> On Thu, 2007-04-19 at 18:52 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
> GASAPRD PHI wrote:
> > I badly missed this point, I will slap myself with bjarne's book ;-)
>
> I doubt it's an effective way to transfer its contents to one's brain =
:)
>
> Luigi
>
>
> ----------------------------------------
>
> fix, n.,v.
> What one does when a problem has been reported too many times
> to be ignored.
> -- the Jargon file
>
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 20 Apr 2007 22:10:42 +0200
> From: "Ferdinando Ametrano" <na...@am...>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
>         [10231] trunk/QuantLib
> To: "Luigi Ballabio" <lui...@gm...>
> Cc: qua...@li...
> Message-ID:
>         <864...@ma...>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>
> On 4/19/07, Luigi Ballabio <lui...@gm...> wrote:
> > Just a thought: isn't the name TimeDependantCorrelationStructure
> > redundant? (the general case being time dependence, and the constant
> > case being a specialized one.) Maybe just CorrelationStructure?
>
> I've just renamed TimeDependantCorrelationStructure class and folder
> as PiecewiseConstantCorrelation. This should convey that all derived
> classes are required to be piecewise constant in time.
>
> hope it helps
>
> ciao -- Nando
>
>
>
> ------------------------------
>
> Message: 10
> Date: Fri, 20 Apr 2007 23:27:06 +0200
> From: "Ferdinando Ametrano" <na...@am...>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
>         [10219] trunk/QuantLib
> To: "Luigi Ballabio" <lui...@gm...>
> Cc: qua...@li...
> Message-ID:
>         <864...@ma...>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>
> On 4/19/07, Luigi Ballabio <lui...@gm...> wrote:
> > On Wed, 2007-04-18 at 16:02 +0200, Luigi Ballabio wrote:
> > > Aren't we going a bit too far? I mean, there's one evolver per =
subfolder
> > > right now---with some subfolders being empty, too. At this point, =
this
> > > much structure looks to me like a burden more than a =
help---especially
> > > since using Doxygen, we can easily generate a reference page where =
all
> > > the evolvers are listed and where it is stated whether each one is
> > > normal/lognormal and what rate type they evolve.
> >
> > I just stumbled into another problem with an elaborate folder
> > structure---"make dist" currently fails to produce the tarball of =
the
> > library (tar insists on file paths being no longer than 99 =
characters.)
>
> ok, this seems a final argument: I've put back all evolver files in
> the plain evolver folder.
>
> I've also renamed classes and files using the pattern Normal/LogNormal
> + FwdRate/CotSwapRate/CmSwapRate + Pc/Ipc/Euler + _/Constrained
>
> ciao -- Nando
>
>
>
> ------------------------------
>
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
>
> ------------------------------
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
> End of QuantLib-dev Digest, Vol 11, Issue 8
> *******************************************
>


--=20
Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

-------------------------------------------------------------------------=

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10324] trunk/QuantLib

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

On Mon, 2007-04-23 at 03:22 -0700, fd...@us... wrote:
> Revision: 10324
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10324&view=rev
> Author:   fdv1
> Date:     2007-04-23 03:22:48 -0700 (Mon, 23 Apr 2007)
> 
> Log Message:
> -----------
> Integration refactoring in progress:
> the old GaussKronrod class has been renamed in GaussKronrodNonAdaptive and adapted to the new framework, client code and tests updated accordingly

Francois,
	may you describe the new framework? What do we gain with respect to the
previous implementation?

Later,
	Luigi


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

Humphrey's Requirements Uncertainty Principle: 
For a new software system, the requirements will not be 
completely known until after the users have used it. 

Re: [Quantlib-dev] Market-model tests

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

On Fri, 2007-04-20 at 23:48 +0200, Ferdinando Ametrano wrote:
> On 4/19/07, Luigi Ballabio <lui...@gm...> wrote:
> >         now that the market-model tests for the callable-swap were re-enabled,
> > the test suite seems to take forever (as in more than one hour on a
> > recent machine.) Is it because CurveState's methods are now virtual?
> 
> unfortunately we didn't check the performance hit of having virtual
> methods in CurveState when we introduced them. My impression anyway is
> that the current test-suite overall timing of about 52 minutes (on my
> workstation) is to be compared with 40-something in the previous state
> of affairs.

You're right. I tried coding CurveState as a non-virtual class, and the
performance doesn't seem to change much. It might be worth committing it
anyway, as it removes the CurveState hierarchy. What do you think?

Later,
	Luigi


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

Blessed is the man who, having nothing to say, abstains from giving 
wordy evidence of the fact. 
-- George Eliot 

Re: [Quantlib-dev] market models

[Ametrano F. <fer...@ca...>]

Dear Mark,

Glad to hear back from you.

> so how's it going?
Fine. I've worked on Market Models:
- cleaned up the code (checking for increasing times, avoided crashes
due to null input vectors),
- the AbcdVol and FlatVol MarketModel classes are now using
PiecewiseConstantCorrelation base class interface and while integrating
the covariance matrices I've managed to take into account the different
correlation matrices. Since it is only between two evolution times that
we can apply factor reduction, there is no more factor reduction in the
PiecewiseConstantCorrelation derived classes. Next step would be to have
a base class for volatility models as we now have for correlation
models, so that AbcdVol and FlatVol would just collapse in a single
generic class
- moved our calibration code into CapletCoterminalSwaptionCalibration
class, and took into account that factor reduction is not done in
PiecewiseConstantCorrelation aymore. The function it's still there, but
the Excel interface (i.e. results) is richer using the class with just
one iteration. The Excel workbook has been updated accordingly

I'm CC-ing qua...@li... so that everybody is
updated

Stay in touch

Ciao -- Nando

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[10219] trunk/QuantLib

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

On Mon, 2007-04-23 at 12:39 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> Don't you want to consider delaying a little the next release since it won't be backward compatible. IMO this is the moment to do the changes that we would never undertake if we had to ensure backward compatibility.

We can make further changes after next release. Which ones do you have
in mind?

Later,
	Luigi


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

Green's Law of Debate: 
Anything is possible if you don't know what you're talking about. 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[10219] trunk/QuantLib

[DU V. DE V. F. G. P. <fra...@ca...>]

Hi Luigi,

Don't you want to consider delaying a little the next release since it =
won't be backward compatible. IMO this is the moment to do the changes =
that we would never undertake if we had to ensure backward =
compatibility.
Rgds,
Fran=E7ois

-----Original Message-----
From: qua...@li... =
[mailto:qua...@li...] On Behalf Of Luigi =
Ballabio
Sent: Monday, April 23, 2007 12:08 PM
To: Ferdinando Ametrano
Cc: qua...@li...
Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[10219] =
trunk/QuantLib

On Fri, 2007-04-20 at 23:27 +0200, Ferdinando Ametrano wrote:
> On 4/19/07, Luigi Ballabio <lui...@gm...> wrote:
> > I just stumbled into another problem with an elaborate folder
> > structure---"make dist" currently fails to produce the tarball of =
the
> > library (tar insists on file paths being no longer than 99 =
characters.)
>=20
> ok, this seems a final argument: I've put back all evolver files in
> the plain evolver folder.

Ok, thanks.

Speaking of tarballs, how about branching for release?

Later,
	Luigi


----------------------------------------=20

Hofstadter's Law:=20
It always takes longer than you expect, even when you take=20
Hofstadter's Law into account.=20



-------------------------------------------------------------------------=

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10219] trunk/QuantLib

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

On Fri, 2007-04-20 at 23:27 +0200, Ferdinando Ametrano wrote:
> On 4/19/07, Luigi Ballabio <lui...@gm...> wrote:
> > I just stumbled into another problem with an elaborate folder
> > structure---"make dist" currently fails to produce the tarball of the
> > library (tar insists on file paths being no longer than 99 characters.)
> 
> ok, this seems a final argument: I've put back all evolver files in
> the plain evolver folder.

Ok, thanks.

Speaking of tarballs, how about branching for release?

Later,
	Luigi


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

Hofstadter's Law: 
It always takes longer than you expect, even when you take 
Hofstadter's Law into account. 

[Quantlib-dev] Array vs std::vector + free operators

[Mark j. <ma...@ma...>]

Re the vector + array operations. If you want true efficiency, you
have to do one of the following:
Define a function plus

void plus(const Array& left, const Array& right, Array& target);

this is ugly but efficient

or use expression templates which always struck me as very fiddly (but
are in stroustrup assuming it's survived the slapping...)

Mark



On 21/04/07, qua...@li...
<qua...@li...> wrote:
> Send QuantLib-dev mailing list submissions to
>         qua...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> or, via email, send a message with subject or body 'help' to
>         qua...@li...
>
> You can reach the person managing the list at
>         qua...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of QuantLib-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Array vs std::vector + free operators (Luigi Ballabio)
>    2. Market-model tests (Luigi Ballabio)
>    3. Re: Array vs std::vector + free operators
>       (DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI)
>    4. Re: Array vs std::vector + free operators (Luigi Ballabio)
>    5. Re: Array vs std::vector + free operators
>       (DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI)
>    6. Re: [QuantLib-svn] SF.net SVN: quantlib: [10251]
>       trunk/QuantLib (Ferdinando Ametrano)
>    7. Re: [QuantLib-svn] SF.net SVN: quantlib:  [10251]
>       trunk/QuantLib (Luigi Ballabio)
>    8. Re: Array vs std::vector + free operators (Luigi Ballabio)
>    9. Re: [QuantLib-svn] SF.net SVN: quantlib: [10231]
>       trunk/QuantLib (Ferdinando Ametrano)
>   10. Re: [QuantLib-svn] SF.net SVN: quantlib: [10219]
>       trunk/QuantLib (Ferdinando Ametrano)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Apr 2007 16:36:28 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
>         <fra...@ca...>
> Cc: qua...@li...
> Message-ID: <1176993388.4980.186.camel@ITSUP001>
> Content-Type: text/plain; charset=utf-8
>
> On Thu, 2007-04-19 at 15:47 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
> GASAPRD PHI wrote:
> > I have tried to removing the dependency on Array class from the
> > optimization framework. One change leading to another it turns out
> > that Arrray dependencies could be removed in the whole QL !
> > The only change I had to do was to provide missing operators an
> > independent header file and all worked fine. As a result I?m wondering
> > if using plain std::vector instead of Arrray wouldn?t be more
> > efficient in terms of compilation efficiency and flexibility of use.
> > (if one want to use linear algebra he has just to include a file
> > defining new operators?).
>
> Fran?ois,
>         it doesn't sound right to me, for a couple of reasons:
>
> - you're changing the std::vector interface by adding operators. I'm not
> sure that it is legal C++.  Moreover, this might be done without the
> user knowing it if he happens to include a file which in turn includes
> your new operators. Thus, code which according to the C++ standard is
> not valid (such as w = u+v if u,v,and w are std::vectors) would silently
> become legal. I'm not comfortable with this.
>
> - there's a conceptual difference between the two classes, and using
> std::vector for both would confuse the issue. std::vector is a
> container; Array is the linear-algebra concept of an array. I, too, had
> been thinking of replacing Array with an STL class, but the right one
> would be std::valarray---which models the right concept and already
> defines the required operators.
>
> Later,
>         Luigi
>
>
> ----------------------------------------
>
> If you can't convince them, confuse them.
> -- Harry S. Truman
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 Apr 2007 17:08:01 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: [Quantlib-dev] Market-model tests
> To: QuantLib developers <qua...@li...>
> Message-ID: <1176995281.4980.195.camel@ITSUP001>
> Content-Type: text/plain
>
>
> Hi all,
>         now that the market-model tests for the callable-swap were re-enabled,
> the test suite seems to take forever (as in more than one hour on a
> recent machine.) Is it because CurveState's methods are now virtual?
>
> Later,
>         Luigi
>
> ----------------------------------------
>
> I'd never join any club that would have the likes of me as a member.
> -- Groucho Marx
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 19 Apr 2007 17:11:22 +0200
> From: "DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI"
>         <fra...@ca...>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: "Luigi Ballabio" <lui...@gm...>
> Cc: qua...@li...
> Message-ID:
>         <EA1...@S0...>
> Content-Type: text/plain;       charset="iso-8859-1"
>
>
> Fran?ois,
>         it doesn't sound right to me, for a couple of reasons:
>
> >- you're changing the std::vector interface by adding operators. I'm not
> >sure that it is legal C++.  Moreover, this might be done without the
> >user knowing it if he happens to include a file which in turn includes
> >your new operators. Thus, code which according to the C++ standard is
> >not valid (such as w = u+v if u,v,and w are std::vectors) would silently
> >become legal. I'm not comfortable with this.
>
> We could provide only specialized templates implementation. (for double, even if it some of them might also make sense with other data like Date,...) Anyway I'm pretty sure that any decent compiler would squeal if the corresponding elementwise operation doesn't exist.
>
> >- there's a conceptual difference between the two classes, and using
> >std::vector for both would confuse the issue. std::vector is a
> >container; Array is the linear-algebra concept of an array. I, too, had
> >been thinking of replacing Array with an STL class, but the right one
> >would be std::valarray---which models the right concept and already
> >defines the required operators.
>
> I agree with you that a general purpose container and an Array are two different beasts. About the valarray Josuttis doesn't seem to be a great fan:
> "At the time of this writing, no such implementation is known, and standard valarrays are, generally speaking, quite inefficient at performing the operations for which they were designed." (C++ templates: The complete guide)
>
> Maybe they have improved it since ... :-)
>
> Rgds,
> Fran?ois
>
> PS: here is an example of the operators I have defined:
>
> inline const Disposable<std::vector<Real> > operator+(const std::vector<Real>& v1, const std::vector<Real>& v2) {
>         QL_REQUIRE(v1.size() == v2.size(),
>                    " vectors with different sizes (" << v1.size() << ", "
>                    << v2.size() << ") cannot be added");
>         std::vector<Real> result(v1.size());
>         std::transform(v1.begin(),v1.end(),v2.begin(),result.begin(),
>                        std::plus<Real>());
>         return result;
>     }
>
> PPS: I don't want to be pushy about this. It is just an idea I'm playing with.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 19 Apr 2007 17:32:14 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
>         <fra...@ca...>
> Cc: qua...@li...
> Message-ID: <1176996734.4980.206.camel@ITSUP001>
> Content-Type: text/plain
>
> On Thu, 2007-04-19 at 17:11 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
> GASAPRD PHI wrote:
> > >- you're changing the std::vector interface by adding operators. I'm not
> > >sure that it is legal C++.  Moreover, this might be done without the
> > >user knowing it if he happens to include a file which in turn includes
> > >your new operators. Thus, code which according to the C++ standard is
> > >not valid (such as w = u+v if u,v,and w are std::vectors) would silently
> > >become legal. I'm not comfortable with this.
> >
> > We could provide only specialized templates implementation. (for double, even if it some of them might also make sense with other data like Date,...) Anyway I'm pretty sure that any decent compiler would squeal if the corresponding elementwise operation doesn't exist.
>
> You would still be changing the interface of that particular
> specialization of std::vector. The problem remains. I'm not referring to
> the possibility of adding vectors of non-numeric types; the compiler
> would reject that. I'm saying that the C++ standard states that w = u+v
> doesn't work with std::vector, and you're making it work.
>
>
> > I agree with you that a general purpose container and an Array are two different beasts. About the valarray Josuttis doesn't seem to be a great fan:
> > "At the time of this writing, no such implementation is known, and standard valarrays are, generally speaking, quite inefficient at performing the operations for which they were designed." (C++ templates: The complete guide)
> >
> > Maybe they have improved it since ... :-)
>
> Maybe. Or maybe we could implement Array _in terms of_ std::vector. But
> there should be no conceptual confusion between the two.
>
>
> > PS: here is an example of the operators I have defined:
> >
> > inline const Disposable<std::vector<Real> > operator+(const std::vector<Real>& v1, const std::vector<Real>& v2) {
> >         QL_REQUIRE(v1.size() == v2.size(),
> >                    " vectors with different sizes (" << v1.size() << ", "
> >                    << v2.size() << ") cannot be added");
> >         std::vector<Real> result(v1.size());
> >         std::transform(v1.begin(),v1.end(),v2.begin(),result.begin(),
> >                        std::plus<Real>());
> >         return result;
> >     }
>
> Apart from adding operations to std::vector, the above is not as
> efficient as Array:operator+. if you write
>
> std::vector<Real> w = u+w;
>
> the addition returns a Disposable, but the std::vector constructor
> doesn't know what to do with it, so it copies its contents instead of
> swapping. If you want full efficiency, you have to write:
>
> std::vector<Real> w;
> w.swap(u+v);
>
> which is more awkward. On the other hand, Array defines a constructor
> taking a Disposable, so there's no moving in
>
> Array w = u+v;
>
>
> > PPS: I don't want to be pushy about this. It is just an idea I'm playing with.
>
> Same here.
>
> Later,
>         Luigi
>
>
> ----------------------------------------
>
> Quote me as saying I was misquoted.
> -- Groucho Marx
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 19 Apr 2007 18:52:43 +0200
> From: "DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI"
>         <fra...@ca...>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: "Luigi Ballabio" <lui...@gm...>
> Cc: qua...@li...
> Message-ID:
>         <EA1...@S0...>
> Content-Type: text/plain;       charset="iso-8859-1"
>
>
>
> >Apart from adding operations to std::vector, the above is not as
> >efficient as Array:operator+. if you write
>
> >std::vector<Real> w = u+w;
>
> >the addition returns a Disposable, but the std::vector constructor
> >doesn't know what to do with it, so it copies its contents instead of
> >swapping. If you want full efficiency, you have to write:
>
> >std::vector<Real> w;
> >w.swap(u+v);
>
> >which is more awkward. On the other hand, Array defines a constructor
> >taking a Disposable, so there's no moving in
>
> >Array w = u+v;
>
> I badly missed this point, I will slap myself with bjarne's book ;-)
>
> Fran?ois
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 19 Apr 2007 19:25:07 +0200
> From: "Ferdinando Ametrano" <na...@am...>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
>         [10251] trunk/QuantLib
> To: qua...@li...
> Message-ID:
>         <864...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/19/07, lba...@us...
> <lba...@us...> wrote:
> > Delta, gamma and theta added to binomial engine for vanilla options (thanks to Steve Cook.)
> > Theta is currently not close enough to analytic values. Investigation would be needed.
>
> why theta isn't just deduced from Delta and Gamma using Black
> equation? This approach is used elsewhere in QuantLib.
>
> ciao -- Nando
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 20 Apr 2007 08:49:19 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
>         [10251] trunk/QuantLib
> To: Ferdinando Ametrano <na...@am...>
> Cc: qua...@li...
> Message-ID: <1177051759.4980.218.camel@ITSUP001>
> Content-Type: text/plain
>
> On Thu, 2007-04-19 at 19:25 +0200, Ferdinando Ametrano wrote:
> > On 4/19/07, lba...@us...
> > <lba...@us...> wrote:
> > > Delta, gamma and theta added to binomial engine for vanilla options (thanks to Steve Cook.)
> > > Theta is currently not close enough to analytic values. Investigation would be needed.
> >
> > why theta isn't just deduced from Delta and Gamma using Black
> > equation? This approach is used elsewhere in QuantLib.
>
> Yes, I can try that.
>
> 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
>
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 20 Apr 2007 08:52:36 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
>         <fra...@ca...>
> Cc: qua...@li...
> Message-ID: <1177051956.4980.220.camel@ITSUP001>
> Content-Type: text/plain
>
> On Thu, 2007-04-19 at 18:52 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
> GASAPRD PHI wrote:
> > I badly missed this point, I will slap myself with bjarne's book ;-)
>
> I doubt it's an effective way to transfer its contents to one's brain :)
>
> Luigi
>
>
> ----------------------------------------
>
> fix, n.,v.
> What one does when a problem has been reported too many times
> to be ignored.
> -- the Jargon file
>
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 20 Apr 2007 22:10:42 +0200
> From: "Ferdinando Ametrano" <na...@am...>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
>         [10231] trunk/QuantLib
> To: "Luigi Ballabio" <lui...@gm...>
> Cc: qua...@li...
> Message-ID:
>         <864...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/19/07, Luigi Ballabio <lui...@gm...> wrote:
> > Just a thought: isn't the name TimeDependantCorrelationStructure
> > redundant? (the general case being time dependence, and the constant
> > case being a specialized one.) Maybe just CorrelationStructure?
>
> I've just renamed TimeDependantCorrelationStructure class and folder
> as PiecewiseConstantCorrelation. This should convey that all derived
> classes are required to be piecewise constant in time.
>
> hope it helps
>
> ciao -- Nando
>
>
>
> ------------------------------
>
> Message: 10
> Date: Fri, 20 Apr 2007 23:27:06 +0200
> From: "Ferdinando Ametrano" <na...@am...>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
>         [10219] trunk/QuantLib
> To: "Luigi Ballabio" <lui...@gm...>
> Cc: qua...@li...
> Message-ID:
>         <864...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/19/07, Luigi Ballabio <lui...@gm...> wrote:
> > On Wed, 2007-04-18 at 16:02 +0200, Luigi Ballabio wrote:
> > > Aren't we going a bit too far? I mean, there's one evolver per subfolder
> > > right now---with some subfolders being empty, too. At this point, this
> > > much structure looks to me like a burden more than a help---especially
> > > since using Doxygen, we can easily generate a reference page where all
> > > the evolvers are listed and where it is stated whether each one is
> > > normal/lognormal and what rate type they evolve.
> >
> > I just stumbled into another problem with an elaborate folder
> > structure---"make dist" currently fails to produce the tarball of the
> > library (tar insists on file paths being no longer than 99 characters.)
>
> ok, this seems a final argument: I've put back all evolver files in
> the plain evolver folder.
>
> I've also renamed classes and files using the pattern Normal/LogNormal
> + FwdRate/CotSwapRate/CmSwapRate + Pc/Ipc/Euler + _/Constrained
>
> ciao -- Nando
>
>
>
> ------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
>
> ------------------------------
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
> End of QuantLib-dev Digest, Vol 11, Issue 8
> *******************************************
>


-- 
Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

Re: [Quantlib-dev] Market-model tests

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

Hi Luigi

On 4/19/07, Luigi Ballabio <lui...@gm...> wrote:
>         now that the market-model tests for the callable-swap were re-enabled,
> the test suite seems to take forever (as in more than one hour on a
> recent machine.) Is it because CurveState's methods are now virtual?

unfortunately we didn't check the performance hit of having virtual
methods in CurveState when we introduced them. My impression anyway is
that the current test-suite overall timing of about 52 minutes (on my
workstation) is to be compared with 40-something in the previous state
of affairs.

ciao -- Nando