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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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