QuantLib › quantlib-dev

Non copyable curves.

Classic

List

Threaded

10 messages Options

Simon Ibbotson - Straumur

Non copyable curves.

Hi guys,

Why have all curves recently been derived from boost::noncopyable?

I’ve been copying yieldcurves (in external code) – and it has been working perfectly if you implement a copy constructor for the PiecewiseYieldcurve class that initializes the bootstrapper for the current curve (in the code I submitted – shown below). Surely this makes more sense than completely disabling copying?

//copy constructor

PiecewiseYieldCurve(const this_curve& o)

: base_curve(o), instruments_(o.instruments_), turnOfYearEffect_(o.turnOfYearEffect_),

accuracy_(o.accuracy_), latestReference_(o.latestReference_), turnOfYear_(o.turnOfYear_),

bootstrap_(o.bootstrap_) {

setTurnOfYear();

registerWith(turnOfYearEffect_);

bootstrap_.setup(this);

}

Simon Ibbotson

Quantitative Analytics

Capital Markets

Straumur

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Ole Peng

Re: Non copyable curves.

whether copying is right or wrong, it seems to me that you can't just go in and implement that kind of breaking behavior. I find that quite shocking.

aren't there any guidelines as to freeZing user interfaces once they are published - as one would expect of any reasonably designed multi-user software?

this messags was sent from a mobile device

On Apr 17, 2008, at 3:48 AM, "Simon Ibbotson" <[hidden email]> wrote:

Hi guys,

Why have all curves recently been derived from boost::noncopyable?

I’ve been copying yieldcurves (in external code) – and it has been working perfectly if you implement a copy constructor for the PiecewiseYieldcurve class that initializes the bootstrapper for the current curve (in the code I submitted – shown below). Surely this makes more sense than completely disabling copying?

//copy constructor

        PiecewiseYieldCurve(const this_curve& o)

            : base_curve(o), instruments_(o.instruments_), turnOfYearEffect_(o.turnOfYearEffect_),

            accuracy_(o.accuracy_), latestReference_(o.latestReference_), turnOfYear_(o.turnOfYear_),

            bootstrap_(o.bootstrap_) {

                setTurnOfYear();

                registerWith(turnOfYearEffect_);

                bootstrap_.setup(this);

        }

Simon Ibbotson

Quantitative Analytics

Capital Markets

Straumur

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

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

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Simon Ibbotson - Straumur

Re: Non copyable curves.

This change has occurred on \trunk, the library still compiles and it doesn’t break any of the test-suite, so it meets all requirements that I would have for a multi-developer library.

If you need a frozen user interface – use a published release instead.

My concern is that – as someone trying to contribute to the library – a rather restrictive ban on copying curves has been introduced. Some of the code I’ve submitted (prior to this change) relies upon being able to copy curves. If I can’t resolve conflicts between changes made by another developer and my code (because I don’t know why this ban was introduced – the descriptive message was very brief) then I have to diverge from the QuantLib code base and it becomes very difficult for me to contribute any code…

Hope you understand my meaning.

If someone can let me know why this was introduced, I can resolve the conflicts I’ve observed – and contribute these resolutions + other code that I’m working on.

All the best,

Simon

From: op [mailto:[hidden email]]
Sent: 17 April 2008 17:59
To: Simon Ibbotson - Straumur
Cc: <[hidden email]>
Subject: Re: [Quantlib-dev] Non copyable curves.

whether copying is right or wrong, it seems to me that you can't just go in and implement that kind of breaking behavior. I find that quite shocking.

aren't there any guidelines as to freeZing user interfaces once they are published - as one would expect of any reasonably designed multi-user software?

this messags was sent from a mobile device

On Apr 17, 2008, at 3:48 AM, "Simon Ibbotson" <[hidden email]> wrote:

Hi guys,

Why have all curves recently been derived from boost::noncopyable?

I’ve been copying yieldcurves (in external code) – and it has been working perfectly if you implement a copy constructor for the PiecewiseYieldcurve class that initializes the bootstrapper for the current curve (in the code I submitted – shown below). Surely this makes more sense than completely disabling copying?

//copy constructor

        PiecewiseYieldCurve(const this_curve& o)

            : base_curve(o), instruments_(o.instruments_), turnOfYearEffect_(o.turnOfYearEffect_),

            accuracy_(o.accuracy_), latestReference_(o.latestReference_), turnOfYear_(o.turnOfYear_),

            bootstrap_(o.bootstrap_) {

                setTurnOfYear();

                registerWith(turnOfYearEffect_);

                bootstrap_.setup(this);

        }

Simon Ibbotson

Quantitative Analytics

Capital Markets

Straumur

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

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

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

Luigi Ballabio

Re: Non copyable curves.

On Thu, 2008-04-17 at 17:14 +0000, Simon Ibbotson wrote:
> This change has occurred on \trunk, the library still compiles and it
> doesn’t break any of the test-suite, so it meets all requirements that
> I would have for a multi-developer library.
>
> If you need a frozen user interface – use a published release instead.

No, Ole is right---interfaces shouldn't break between releases.
Unfortunately, as we're nearing 1.0, we became aware of a few bad design
choices we made earlier. Correcting those will break something, but we
think that the resulting design will make up for the inconvenience.
After 1.0, the interfaces will be frozen.

As for this particular change:

> My concern is that – as someone trying to contribute to the library –
> a rather restrictive ban on copying curves has been introduced.

This was not based on some design principle. Simply, I suddenly noticed
that copying behavior for interpolated curves was broken---if you copied
an interpolated curve, the interpolation inside the copy would still
point to the data in the original curve. As a quick safety measure, I
disabled copying; a full solution which I haven't had the time to
implement would be to implement the correct copy constructors. We'll
have to do that before release (and, Simon, feel free to go ahead if you
want,) at which point the broken code would work again as before. No, on
second thought, not as before---it would work correctly...

Luigi

--

Present to inform, not to impress; if you inform, you will impress.
-- Fred Brooks

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Simon Ibbotson - Straumur

Re: Non copyable curves.

Okay, that makes sense. I'll implement copy-constructors for the
interpolated curves (I've got several more changes to contribute, so I
may as well make them all consistent).

Regarding "good behaviour" for development in quantitative libraries, in
the past I've worked in small development teams (up to 15 people) where
there were minimal restrictions on what a developer can/can't do:
namely, the code should compile and the test application should not fail
any tests (of course, bug fixes should never break an interface).

This method isn't perfect (by any means) but with this method, if a user
wishes to use new released functionality, it then becomes the
responsibility of them to integrate any interface changes for a new
release. Alternatively, they can get involved in the development process
and ensure that any interface changes can easily be incorporated into
their external applications.

Is there any documentation on "good practise" for QuantLib / open-source
development? Freezing an interface (at the C++ level during the
development cycle) would mean allowing only incremental additions to the
header files... is that the intention for QuantLib? Alternatively, do we
have a set of classes which form a fixed interface, behind which the
implementation structure (all other classes) can change?

All advice welcome.

Simon

-----Original Message-----
From: Luigi Ballabio [mailto:[hidden email]]
Sent: 18 April 2008 09:31
To: Simon Ibbotson - Straumur
Cc: op; [hidden email]
Subject: Re: [Quantlib-dev] Non copyable curves.

On Thu, 2008-04-17 at 17:14 +0000, Simon Ibbotson wrote:
> This change has occurred on \trunk, the library still compiles and it
> doesn't break any of the test-suite, so it meets all requirements that
> I would have for a multi-developer library.
>
> If you need a frozen user interface - use a published release instead.

No, Ole is right---interfaces shouldn't break between releases.
Unfortunately, as we're nearing 1.0, we became aware of a few bad design
choices we made earlier. Correcting those will break something, but we
think that the resulting design will make up for the inconvenience.
After 1.0, the interfaces will be frozen.

As for this particular change:

> My concern is that - as someone trying to contribute to the library -
> a rather restrictive ban on copying curves has been introduced.

This was not based on some design principle. Simply, I suddenly noticed
that copying behavior for interpolated curves was broken---if you copied
an interpolated curve, the interpolation inside the copy would still
point to the data in the original curve. As a quick safety measure, I
disabled copying; a full solution which I haven't had the time to
implement would be to implement the correct copy constructors. We'll
have to do that before release (and, Simon, feel free to go ahead if you
want,) at which point the broken code would work again as before. No, on
second thought, not as before---it would work correctly...

Luigi

--

Present to inform, not to impress; if you inform, you will impress.
-- Fred Brooks

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Simon Ibbotson - Straumur

Re: Non copyable curves.

Hi all,

For this improvement (copy-constructors for curves), I've developed some
code for this method. The current copy behaviour is to keep the linkage
to the original Interpolation::Impl object. We need to create a new
object derived from Interpolation::Impl and link the new object to a new
vector of data.
There are two possible ways (that I know of), a virtual clone method to
be implemented by the classes that derive from Interpolation::Impl or
use of the CRT pattern.
As the Interpolation::Impl class already uses pure virtual methods, I've
implemented the pure virtual function method. Does anyone have any
preferences?

Cheers,

Simon

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Simon
Ibbotson
Sent: 18 April 2008 09:54
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Quantlib-dev] Non copyable curves.

Okay, that makes sense. I'll implement copy-constructors for the
interpolated curves (I've got several more changes to contribute, so I
may as well make them all consistent).

Regarding "good behaviour" for development in quantitative libraries, in
the past I've worked in small development teams (up to 15 people) where
there were minimal restrictions on what a developer can/can't do:
namely, the code should compile and the test application should not fail
any tests (of course, bug fixes should never break an interface).

This method isn't perfect (by any means) but with this method, if a user
wishes to use new released functionality, it then becomes the
responsibility of them to integrate any interface changes for a new
release. Alternatively, they can get involved in the development process
and ensure that any interface changes can easily be incorporated into
their external applications.

Is there any documentation on "good practise" for QuantLib / open-source
development? Freezing an interface (at the C++ level during the
development cycle) would mean allowing only incremental additions to the
header files... is that the intention for QuantLib? Alternatively, do we
have a set of classes which form a fixed interface, behind which the
implementation structure (all other classes) can change?

All advice welcome.

Simon

-----Original Message-----
From: Luigi Ballabio [mailto:[hidden email]]
Sent: 18 April 2008 09:31
To: Simon Ibbotson - Straumur
Cc: op; [hidden email]
Subject: Re: [Quantlib-dev] Non copyable curves.

On Thu, 2008-04-17 at 17:14 +0000, Simon Ibbotson wrote:
> This change has occurred on \trunk, the library still compiles and it
> doesn't break any of the test-suite, so it meets all requirements that
> I would have for a multi-developer library.
>
> If you need a frozen user interface - use a published release instead.

No, Ole is right---interfaces shouldn't break between releases.
Unfortunately, as we're nearing 1.0, we became aware of a few bad design
choices we made earlier. Correcting those will break something, but we
think that the resulting design will make up for the inconvenience.
After 1.0, the interfaces will be frozen.

As for this particular change:

> My concern is that - as someone trying to contribute to the library -
> a rather restrictive ban on copying curves has been introduced.

This was not based on some design principle. Simply, I suddenly noticed
that copying behavior for interpolated curves was broken---if you copied
an interpolated curve, the interpolation inside the copy would still
point to the data in the original curve. As a quick safety measure, I
disabled copying; a full solution which I haven't had the time to
implement would be to implement the correct copy constructors. We'll
have to do that before release (and, Simon, feel free to go ahead if you
want,) at which point the broken code would work again as before. No, on
second thought, not as before---it would work correctly...

Luigi

--

Present to inform, not to impress; if you inform, you will impress.
-- Fred Brooks

------------------------------------------------------------------------
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
avaone
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Luigi Ballabio

Re: Non copyable curves.

On Thu, 2008-05-29 at 10:50 +0000, Simon Ibbotson - Straumur wrote:
> For this improvement (copy-constructors for curves), I've developed some
> code for this method. The current copy behaviour is to keep the linkage
> to the original Interpolation::Impl object. We need to create a new
> object derived from Interpolation::Impl and link the new object to a new
> vector of data.

Simon,
it's probably easier than that. We can just use the interpolator (which
the curves store) to recreate the interpolation based on the
newly-copied data vectors.

Luigi

--

If you can't convince them, confuse them.
-- Harry S. Truman

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Simon Ibbotson - Straumur

Re: Non copyable curves.

I did think of that, but the new functionality I submitted
(LocalBootstrap) relies on other information than just the data vectors
(information created during the curve-stripping process).
I'll continue testing this - unless you've got a particular preference
for factory classes over polymorphic cloning?

Simon

-----Original Message-----
From: Luigi Ballabio [mailto:[hidden email]]
Sent: 30 May 2008 15:34
To: Simon Ibbotson - Straumur
Cc: [hidden email]
Subject: RE: [Quantlib-dev] Non copyable curves.

On Thu, 2008-05-29 at 10:50 +0000, Simon Ibbotson - Straumur wrote:
> For this improvement (copy-constructors for curves), I've developed
some
> code for this method. The current copy behaviour is to keep the
linkage
> to the original Interpolation::Impl object. We need to create a new
> object derived from Interpolation::Impl and link the new object to a
new
> vector of data.

Simon,
it's probably easier than that. We can just use the interpolator
(which
the curves store) to recreate the interpolation based on the
newly-copied data vectors.

Luigi

--

If you can't convince them, confuse them.
-- Harry S. Truman

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Luigi Ballabio

Re: Non copyable curves.

On Fri, 2008-05-30 at 14:41 +0000, Simon Ibbotson - Straumur wrote:
> I did think of that, but the new functionality I submitted
> (LocalBootstrap) relies on other information than just the data vectors
> (information created during the curve-stripping process).
> I'll continue testing this - unless you've got a particular preference
> for factory classes over polymorphic cloning?

Nothing major, but the issue I have is that cloning would duplicate the
code in factory classes, and would have to be added to all
interpolations in order to cope with a single particular case (local
bootstrap and convex-monotone.) I'd rather try and adapt the single
case---for instance, could a call to ConvexMonotone::localInterpolate()
store in the interpolator the additional passed information so that it
could be retrieved after copying?

Luigi

--

Age is an issue of mind over matter. If you don't mind, it doesn't
matter.
-- Mark Twain

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Simon Ibbotson - Straumur

Re: Non copyable curves.

In reply to this post by Simon Ibbotson - Straumur

Re: [Quantlib-dev] Non copyable curves.

Good idea. I'll do that instead.

-----Original Message-----
From: Luigi Ballabio
To: Simon Ibbotson - Straumur
CC: [hidden email]
Sent: Fri Jun 06 14:54:30 2008
Subject: RE: [Quantlib-dev] Non copyable curves.

On Fri, 2008-05-30 at 14:41 +0000, Simon Ibbotson - Straumur wrote:
> I did think of that, but the new functionality I submitted
> (LocalBootstrap) relies on other information than just the data vectors
> (information created during the curve-stripping process).
> I'll continue testing this - unless you've got a particular preference
> for factory classes over polymorphic cloning?

Nothing major, but the issue I have is that cloning would duplicate the
code in factory classes, and would have to be added to all
interpolations in order to cope with a single particular case (local
bootstrap and convex-monotone.) I'd rather try and adapt the single
case---for instance, could a call to ConvexMonotone::localInterpolate()
store in the interpolator the additional passed information so that it
could be retrieved after copying?

Luigi

--

Age is an issue of mind over matter. If you don't mind, it doesn't
matter.
-- Mark Twain

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev