QuantLib › quantlib-dev

Array vs std::vector + free operators

Classic

List

Threaded

2 messages Options

Mark joshi

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, [hidden email]
<[hidden email]> wrote:

> Send QuantLib-dev mailing list submissions to
> [hidden email]
>
> 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
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> 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 <[hidden email]>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
> <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]>
> Subject: [Quantlib-dev] Market-model tests
> To: QuantLib developers <[hidden email]>
> 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"
> <[hidden email]>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: "Luigi Ballabio" <[hidden email]>
> Cc: [hidden email]
> Message-ID:
> <[hidden email]>
> 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 <[hidden email]>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
> <[hidden email]>
> Cc: [hidden email]
> 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"
> <[hidden email]>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: "Luigi Ballabio" <[hidden email]>
> Cc: [hidden email]
> Message-ID:
> <[hidden email]>
> 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" <[hidden email]>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
> [10251] trunk/QuantLib
> To: [hidden email]
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/19/07, [hidden email]
> <[hidden email]> 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 <[hidden email]>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
> [10251] trunk/QuantLib
> To: Ferdinando Ametrano <[hidden email]>
> Cc: [hidden email]
> 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, [hidden email]
> > <[hidden email]> 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 <[hidden email]>
> Subject: Re: [Quantlib-dev] Array vs std::vector + free operators
> To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
> <[hidden email]>
> Cc: [hidden email]
> 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" <[hidden email]>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
> [10231] trunk/QuantLib
> To: "Luigi Ballabio" <[hidden email]>
> Cc: [hidden email]
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/19/07, Luigi Ballabio <[hidden email]> 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" <[hidden email]>
> Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
> [10219] trunk/QuantLib
> To: "Luigi Ballabio" <[hidden email]>
> Cc: [hidden email]
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/19/07, Luigi Ballabio <[hidden email]> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
> End of QuantLib-dev Digest, Vol 11, Issue 8
> *******************************************
>

DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI

Re: Array vs std::vector + free operators

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çois

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Mark joshi
Sent: Saturday, April 21, 2007 12:08 AM
To: [hidden email]
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, [hidden email]
<[hidden email]> wrote:

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev