quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] [ quantlib-Patches-1954409 ] Copulas library proposal

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

Patches item #1954409, was opened at 2008-04-29 21:27
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=1954409&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Marek Glowacki (lfiarz)
>Assigned to: Ferdinando Ametrano (nando)
Summary: Copulas library proposal

Initial Comment:
Copulas might be useful as a part of math library and for some models
I attached zipped proposal for:
ql/math/copulas/farliegumbelmorgensterncopula
ql/math/copulas/frankcopula
ql/math/copulas/gaussiancopula
ql/math/copulas/gumbelcopula
ql/math/copulas/independentcopula
ql/math/copulas/marshallolkincopula
ql/math/copulas/maxcopula
ql/math/copulas/mincopula

M.Glowacki
mgl...@gm...

p.s. Sorry for inconveniance, If I put this in wrong place, I'm quite new to sourceforge.



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

Comment By: Luigi Ballabio (lballabio)
Date: 2008-05-07 17:44

Message:
Logged In: YES 
user_id=75450
Originator: NO

The patch was applied to the code repository.
It will be included in next release.
Thank you.


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

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

[Quantlib-dev] [ quantlib-Patches-1954409 ] Copulas library proposal

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

Patches item #1954409, was opened at 2008-04-29 21:27
Message generated for change (Settings changed) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=1954409&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marek Glowacki (lfiarz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Copulas library proposal

Initial Comment:
Copulas might be useful as a part of math library and for some models
I attached zipped proposal for:
ql/math/copulas/farliegumbelmorgensterncopula
ql/math/copulas/frankcopula
ql/math/copulas/gaussiancopula
ql/math/copulas/gumbelcopula
ql/math/copulas/independentcopula
ql/math/copulas/marshallolkincopula
ql/math/copulas/maxcopula
ql/math/copulas/mincopula

M.Glowacki
mgl...@gm...

p.s. Sorry for inconveniance, If I put this in wrong place, I'm quite new to sourceforge.



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

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

Re: [Quantlib-dev] [Quantlib-users] copulas library proposal

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

Hi Marek

> Copulas might be useful as a part of math library and for some models
>  I attached proposal for:
>  ql/math/copulas/[...]

thanks for the contribution, I've just added it in the trunk code base.
I've pruned redundant inclusions, move inclusion to cpp file when
possible, expanded error messages to be more informative, and avoided
instantiating objects in the GaussianCopula::operator() method since
they could be instantiated once for all in the constructor.

It would be nice if you would contribute a unit test which reproduces
known tabulated values. This way I could have checked that I didn't
introduce any error ;-)

One question: you contributed bidimensional copulas. Is there an
efficient standard approach how to generalize to arbitrary dimensions?

>  Sorry for inconveniance, If I put this in wrong place, I'm quite new
>  to sourceforge and quantlib.
using the quantlib-dev mailing list would have been better, but I am
aware that the line between users and developers is blurred when it
comes to a C++ library.
You might want to reply only to the quantlib-dev address for further
discussions in this thread.

Thank you again

ciao -- Nando

[Quantlib-dev] Error after calling quantlib-c++-dll via swig-c#-interface

[Frank H. <fho...@gm...>]

Hi there,
I think this is a matter of unproper garbage collection or something similar
but I need some guru advice: A properly coded function (in C++, some double*
serve as input, and a .txt or .csv file is the output but the function call
is like "void func_name(double *input, char *path)" so nothing is actually
returned) which does some calculations using some QuantLib objects somehow
changes its behaviour under /clr compiler option. This I need to be able to
use it via SWIG under C#. Calculations are done as supposed to, but upon C#
program termination an "unknown software exception" (0xc0020001) at
0x7c81eb33 pops up. I googled a bit and indications point to a too quick
(unmanaged) object disposal where the program terminates before the C++
object does. Does this sound familiar to one of you? Are there any hints to
prevent this?

Thanks in advance for any hints and best regards

Re: [Quantlib-dev] [Quantlib-users] seasonality for inflation termstructures

[Bianchetti M. <mar...@ba...>]

Quotes allows optimal sensitivity calculation, and sensitivity to inflation seasonality factors - even if they are not properly quoted market data - is of great interest if you manage an inflation derivative book, especially when:

1.	you update your factors; 
2.	you occasionally observe the quotation of a seasonal factor through CPI Futures or - better - a calendar spread (a swap with two inflation-linked legs based on different months)

and you want to know the impact on your book.
 
Quotes are already used in QL for "not properly quoted market data" as SABR parameters. 
 
Following this line of reasoning, any model parameter in general could be thought as "metamarket data" and described in QL as a quote, such that changing the market data at the beginning of the notification chain would allow for proper - and efficient- recalculation of the NPV of the derivative through recalibration of the model in the middle (4 people interested in this topic a good reference can be "Model Calibration, Risk Measurement, and the Hedging of Derivatives", by Anlong Li", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=899081, unpublished - if anyone has some other reference please let me know).
 
ciao
M.

	-----Original Message-----
	From: qua...@li... [mailto:qua...@li...] On Behalf Of Chris Kenyon
	Sent: venerdì 2 maggio 2008 09.58
	To: Ferdinando Ametrano
	Cc: qua...@li...; lui...@gm...; qua...@li...
	Subject: Re: [Quantlib-users] [Quantlib-dev] seasonality for inflation termstructures
	
	
	Hi Nando,
	
	that makes sense.  This also makes setSeasonality methods safer because if you are using Quotes it is a signal that you may be changing all sorts of other things.  OK lets go that way because:
	1) helps avoids unexpected side effects (i.e. given the QuantLib setup you know that if you change a quote, or if you have to make new ones, then you are doing something drastic);
	2) permits sensitivity analysis (which is also what get/set are about).
	This implies:
	1) Instead of vector<Real> we use a vector<Handle<Quote> > for seasonality factors.
	
	Have I understood what you meant? 
	Any objections anyone?
	
	Regards,
	Chris
	
	
	
	----- Original Message ----
	From: Ferdinando Ametrano <na...@am...>
	To: Chris Kenyon <chr...@ya...>
	Cc: lui...@gm...; qua...@li...; qua...@li...
	Sent: Thursday, May 1, 2008 6:19:32 PM
	Subject: Re: [Quantlib-dev] seasonality for inflation term structures
	
	Hi Chris
	
	On Thu, May 1, 2008 at 10:01 AM, Chris Kenyon <chr...@ya...> wrote:
	>    I don't favor using Quotes for seasonality data since seasonality
	> should not be changing on short timescales (there are no market
	> quotes - this is exactly why this feature was invented).
	>    Comments anyone?
	
	I understand your reasons but I am in favor of Quotes, especially
	since they would be the main hook for sensitivity analysis, i.e. in
	order to calculate sensitivity with finite differences you just tweak
	the Quote value, recalculate the NPV of your portfolio, then restore
	the original value.
	
	The observability combined with the lazyness ensure optimal
	performances and general easiness for this approach, which is probably
	one of best features of the QuantLib design.
	
	ciao -- Nando
	

Re: [Quantlib-dev] seasonality for inflation term structures

[Chris K. <chr...@ya...>]

Hi Nando,

that makes sense.  This also makes setSeasonality methods safer because if you are using Quotes it is a signal that you may be changing all sorts of other things.  OK lets go that way because:
1) helps avoids unexpected side effects (i.e. given the QuantLib setup you know that if you change a quote, or if you have to make new ones, then you are doing something drastic);
2) permits sensitivity analysis (which is also what get/set are about).
This implies:
1) Instead of vector<Real> we use a vector<Handle<Quote> > for seasonality factors.

Have I understood what you meant? 
Any objections anyone?

Regards,
Chris



----- Original Message ----
From: Ferdinando Ametrano <na...@am...>
To: Chris Kenyon <chr...@ya...>
Cc: lui...@gm...; qua...@li...; qua...@li...
Sent: Thursday, May 1, 2008 6:19:32 PM
Subject: Re: [Quantlib-dev] seasonality for inflation term structures

Hi Chris

On Thu, May 1, 2008 at 10:01 AM, Chris Kenyon <chr...@ya...> wrote:
>     I don't favor using Quotes for seasonality data since seasonality
> should not be changing on short timescales (there are no market
> quotes - this is exactly why this feature was invented).
>    Comments anyone?

I understand your reasons but I am in favor of Quotes, especially
since they would be the main hook for sensitivity analysis, i.e. in
order to calculate sensitivity with finite differences you just tweak
the Quote value, recalculate the NPV of your portfolio, then restore
the original value.

The observability combined with the lazyness ensure optimal
performances and general easiness for this approach, which is probably
one of best features of the QuantLib design.

ciao -- Nando

Re: [Quantlib-dev] seasonality for inflation term structures

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

Hi Chris

On Thu, May 1, 2008 at 10:01 AM, Chris Kenyon <chr...@ya...> wrote:
>     I don't favor using Quotes for seasonality data since seasonality
> should not be changing on short timescales (there are no market
> quotes - this is exactly why this feature was invented).
>    Comments anyone?

I understand your reasons but I am in favor of Quotes, especially
since they would be the main hook for sensitivity analysis, i.e. in
order to calculate sensitivity with finite differences you just tweak
the Quote value, recalculate the NPV of your portfolio, then restore
the original value.

The observability combined with the lazyness ensure optimal
performances and general easiness for this approach, which is probably
one of best features of the QuantLib design.

ciao -- Nando

Re: [Quantlib-dev] seasonality for inflation term structures

[Chris K. <chr...@ya...>]

I like the idea that curves are immutable.  However, I'm not keen on
introducing another level of coding structure.  A simple solution
would be to remove the setter.  This way curves are immutable,
and if a user wants different seasonalities they can just provide
different curves ... this does seem like a normal way to go about
things (to me).
    I don't favor using Quotes for seasonality data since seasonality
should not be changing on short timescales (there are no market
quotes - this is exactly why this feature was invented).
   Comments anyone?

Regards,
Chris



----- Original Message ----
From: Luigi Ballabio <lui...@gm...>
To: Chris Kenyon <chr...@ya...>
Cc: qua...@li...; qua...@li...
Sent: Wednesday, April 30, 2008 12:19:00 PM
Subject: Re: [Quantlib-dev] seasonality for inflation term structures

On Tue, 2008-04-29 at 01:50 -0700, Chris Kenyon wrote:

> We want to give users with the ability to provide a seasonality
> correction to the term structures.
> 
> The get/set is defined in the base InflationTermStructure class as:
> 
> public:
>     void setSeasonality(const boost::shared_ptr<Seasonality>
> &seasonality = boost::shared_ptr<Seasonality>());
>     boost::shared_ptr<Seasonality> seasonality() const;        
>     bool hasSeasonalityCorrection() const;

I'm not sure that I like the setter. Of course observability can be
implemented correctly, but I'd prefer curves to be immutables. What I'm
worried about is the following scenario:

Handle<InflationTermStructure> ts;

InflationInstrument I1(..., ts);
InflationInstrument I2(..., ts);

I1.someResult(...);  // for some reason, calls setSeasonality()

at which point the value of I2 changes. We had such a bug in the past
when calculating the implied volatility of an option would modify the
underlying equity process for other instruments. It wasn't pretty.

My proposal of adding seasonality by wrapping the curve was so that I1
could (if needed) take the passed term structure, wrap it, and use the
wrapped curve without modifying the original one.

Thoughts?

Later,
    Luigi


-- 

All parts should go together without forcing. You must remember that 
the parts you are reassembling were disassembled by you. Therefore, if 
you can't get them together again, there must be a reason. By all 
means, do not use a hammer. 
-- IBM maintenance manual, 1925 

Re: [Quantlib-dev] seasonality for inflation term structures

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

On Tue, 2008-04-29 at 01:50 -0700, Chris Kenyon wrote:

> We want to give users with the ability to provide a seasonality
> correction to the term structures.
> 
> The get/set is defined in the base InflationTermStructure class as:
> 
> public:
>     void setSeasonality(const boost::shared_ptr<Seasonality>
> &seasonality = boost::shared_ptr<Seasonality>());
>     boost::shared_ptr<Seasonality> seasonality() const;        
>     bool hasSeasonalityCorrection() const;

I'm not sure that I like the setter. Of course observability can be
implemented correctly, but I'd prefer curves to be immutables. What I'm
worried about is the following scenario:

Handle<InflationTermStructure> ts;

InflationInstrument I1(..., ts);
InflationInstrument I2(..., ts);

I1.someResult(...);  // for some reason, calls setSeasonality()

at which point the value of I2 changes. We had such a bug in the past
when calculating the implied volatility of an option would modify the
underlying equity process for other instruments. It wasn't pretty.

My proposal of adding seasonality by wrapping the curve was so that I1
could (if needed) take the passed term structure, wrap it, and use the
wrapped curve without modifying the original one.

Thoughts?

Later,
	Luigi


-- 

All parts should go together without forcing. You must remember that 
the parts you are reassembling were disassembled by you. Therefore, if 
you can't get them together again, there must be a reason. By all 
means, do not use a hammer. 
-- IBM maintenance manual, 1925 

[Quantlib-dev] [ quantlib-Feature Requests-1954409 ] Copulas library proposal

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

Feature Requests item #1954409, was opened at 2008-04-29 21:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=1954409&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Marek Glowacki (lfiarz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Copulas library proposal

Initial Comment:
Copulas might be useful as a part of math library and for some models
I attached zipped proposal for:
ql/math/copulas/farliegumbelmorgensterncopula
ql/math/copulas/frankcopula
ql/math/copulas/gaussiancopula
ql/math/copulas/gumbelcopula
ql/math/copulas/independentcopula
ql/math/copulas/marshallolkincopula
ql/math/copulas/maxcopula
ql/math/copulas/mincopula

M.Glowacki
mgl...@gm...

p.s. Sorry for inconveniance, If I put this in wrong place, I'm quite new to sourceforge.



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

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

Re: [Quantlib-dev] Disposable<T>

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

On Apr 29, 2008, at 5:55 PM, Luigi Ballabio wrote:

> On Mon, 2008-04-21 at 08:19 -0700, snovik wrote:
>> I am on the team to port ql to c# .net and trying to understand the 
>> reasons
>> behind Disposable<T> class. It looks to me like a tricky memory-saving
>> excercise and I wonder if it really is or there are other reasons.
>
> It's not for saving memory---it's for performance. C++ has pass-by-copy
> semantics.

Also, the same applies to assignment. In C++, when we write

a = b;

you don't end up with two references (a and b) referring to the same 
instance. You end up with a being a new copy of b.

Luigi

P.S. I almost forgot---good luck with your C# port...

Re: [Quantlib-dev] Disposable<T>

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

On Mon, 2008-04-21 at 08:19 -0700, snovik wrote:
> I am on the team to port ql to c# .net and trying to understand the reasons
> behind Disposable<T> class. It looks to me like a tricky memory-saving
> excercise and I wonder if it really is or there are other reasons.

It's not for saving memory---it's for performance. C++ has pass-by-copy
semantics. If we write:

Array operator*(Matrix, Array) {
    ...
    return a;
}

and then

u = M*v;

there will be at least one allocation and one copy of the array
elements, possibly two if the compiler doesn't optimize aggressively.
Disposable<T> removes some of them; not for saving memory, but for
saving time.  If C# returns values by reference, you don't need it in
your port.

Luigi


-- 

There are two ways of constructing a software design. One way is to 
make it so simple that there are obviously no deficiencies. And the 
other way is to make it so complicated that there are no obvious 
deficiencies. 
-- C. A. R. Hoare 

[Quantlib-dev] [ quantlib-Bugs-1947215 ] MS VS 2k3 complie error

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

Bugs item #1947215, was opened at 2008-04-20 07:26
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1947215&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: MS VS 2k3 complie error

Initial Comment:
When I try to complie the quantlib C++ source file, the following message came into error log like
Below is the one of the error log. What should I do?
I am a dummy in C++. Help!



:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\vector(1112) : error C2065: '_Myoff' : undeclared identifier
        c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\vector(1102) : while compiling class-template member function 'std::vector<_Ty,_Ax>::const_iterator &std::vector<_Ty,_Ax>::const_iterator::operator +=(std::vector<_Ty,_Ax>::const_iterator::difference_type)'
        with
        [
            _Ty=bool,
            _Ax=std::allocator<bool>
        ]
        c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\vector(1455) : see reference to class template instantiation 'std::vector<_Ty,_Ax>::const_iterator' being compiled
        with
        [
            _Ty=bool,
            _Ax=std::allocator<bool>
        ]
        c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\vector(1454) : while compiling class-template member function 'std::vector<_Ty,_Ax>::const_reference std::vector<_Ty,_Ax>::operator [](std::vector<_Ty,_Ax>::size_type) const'
        with
        [
            _Ty=bool,
            _Ax=std::allocator<bool>
        ]
        c:\documents and settings\copolayuki\바탕 화면\quantlib\quantlib\ql\termstructures\volatility\swaption\swaptionvolcube1.hpp(148) : see reference to class template instantiation 'std::vector<_Ty,_Ax>' being compiled
        with
        [
            _Ty=bool,
            _Ax=std::allocator<bool>
        ]

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-04-22 22:59

Message:
Logged In: NO 

This happened to me as well when I first tried to compile with 2003. I had
to actually edit the vectorr header file and replace the reference to
_Myoff with this->_Myoff. I think this is an actual error with this header,
that might have beeen corrected in a service pack I have not yet installed
at teh time, but i am not sure.

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

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

[Quantlib-dev] Disposable<T>

[snovik <sn...@gm...>]

Hi,

I am on the team to port ql to c# .net and trying to understand the reasons
behind Disposable<T> class. It looks to me like a tricky memory-saving
excercise and I wonder if it really is or there are other reasons.

would be very grateful.

rgds
s
-- 
View this message in context: http://www.nabble.com/Disposable%3CT%3E-tp16807986p16807986.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] [ quantlib-Bugs-1904433 ] complie bug or misunderstood?

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

Bugs item #1904433, was opened at 2008-02-28 20:44
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1904433&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: complie bug or misunderstood?

Initial Comment:
everytime I compile the example in the quontlib, the following message I've seen. Is this misunderstood or complie bug or something different?

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

cannot find -lQuoantlib-mgw-0_9_0
Id returned 1 exit status
[Build Error] [bin/FRA-mwg.exe] Error 1

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-04-20 07:27

Message:
Logged In: NO 

You might have to update your compiler first. I got that message, too.

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

Comment By: Luigi Ballabio (lballabio)
Date: 2008-02-29 01:36

Message:
Logged In: YES 
user_id=75450
Originator: NO

Did you succesfully compile the library first? (The corresponding project
is QuantLib.dev)

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

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

[Quantlib-dev] [ quantlib-Bugs-1947215 ] MS VS 2k3 complie error

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

Bugs item #1947215, was opened at 2008-04-20 07:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1947215&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: MS VS 2k3 complie error

Initial Comment:
When I try to complie the quantlib C++ source file, the following message came into error log like
Below is the one of the error log. What should I do?
I am a dummy in C++. Help!



:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\vector(1112) : error C2065: '_Myoff' : undeclared identifier
        c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\vector(1102) : while compiling class-template member function 'std::vector<_Ty,_Ax>::const_iterator &std::vector<_Ty,_Ax>::const_iterator::operator +=(std::vector<_Ty,_Ax>::const_iterator::difference_type)'
        with
        [
            _Ty=bool,
            _Ax=std::allocator<bool>
        ]
        c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\vector(1455) : see reference to class template instantiation 'std::vector<_Ty,_Ax>::const_iterator' being compiled
        with
        [
            _Ty=bool,
            _Ax=std::allocator<bool>
        ]
        c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\vector(1454) : while compiling class-template member function 'std::vector<_Ty,_Ax>::const_reference std::vector<_Ty,_Ax>::operator [](std::vector<_Ty,_Ax>::size_type) const'
        with
        [
            _Ty=bool,
            _Ax=std::allocator<bool>
        ]
        c:\documents and settings\copolayuki\바탕 화면\quantlib\quantlib\ql\termstructures\volatility\swaption\swaptionvolcube1.hpp(148) : see reference to class template instantiation 'std::vector<_Ty,_Ax>' being compiled
        with
        [
            _Ty=bool,
            _Ax=std::allocator<bool>
        ]

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

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

[Quantlib-dev] [ quantlib-Bugs-1947150 ] inflationPeriod incorrect for SemiAnnual and Quarterly frequ

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

Bugs item #1947150, was opened at 2008-04-20 04:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1947150&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: inflationPeriod incorrect for SemiAnnual and Quarterly frequ

Initial Comment:
Hi, 


inflationPeriod incorrect for SemiAnnual and Quarterly frequencies.  It should read:


case Semiannual:
   startMonth = Month(6*((month-1)/6) + 1)


and


case Quarterly:
   startMonth = Month(3*((month-1)/3) + 1)


with the other lines unchanged.

Best regards,
chr...@ya...

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

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

[Quantlib-dev] about QuantLib\test-suite\fastfouriertransform.*pp

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

Hi all

the QuantLib\test-suite\fastfouriertransform.*pp files are excluded
from the test-suite build (and would not compile if included).
What is their status?

ciao -- Nando

Re: [Quantlib-dev] South Korea Calendar - modification proposed

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

On Fri, 2008-04-11 at 09:20 +0900, Chongseok wrote:
>           I am proposing to modify the South Korea Calender,
>                         QuantLib::SouthKorea.
>                                    
>            Attached files cantain my proposed modification.
>                                    
>         There are also testing routines of the modified class

Hi Charles,
	I'm adding your modifications. However, the tests fail because of two
dates not included in the expected-holiday list.
They are January 26th, 2004 and January 31st, 2006.  Both are listed in
the calendar implementation as Lunar New Year days.  May you confirm
whether or not they are holidays?

Thanks,
	Luigi


-- 

Hanlon's Razor: 
Never attribute to malice that which is adequately explained 
by stupidity. 

Re: [Quantlib-dev] Non copyable curves.

[Simon I. <Sim...@st...>]

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:lui...@gm...] 
Sent: 18 April 2008 09:31
To: Simon Ibbotson - Straumur
Cc: op; qua...@li...
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 

Re: [Quantlib-dev] Non copyable curves.

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

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 

Re: [Quantlib-dev] independent use of objecthandler

[Slava M. <Sla...@ro...>]

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

Message: 1
Date: Sun, 13 Apr 2008 16:57:05 -0700 (PDT)
From: Ole Peng <ole...@ya...>
Subject: [Quantlib-dev] independent use of objecthandler
To: qua...@li...
Cc: qua...@li...
Message-ID: <525...@we...>
Content-Type: text/plain; charset="us-ascii"

Hi, 

do any of you use the objecthandler independently of quantlib for addin
development? 

If yes, then I would like to pick your brain in order to assess how
manageable that is and if it can be 
used for maintainable and scalable addin applications?

Thanks, Ole



__________________________________________________

Hi Ole,

Yes I do. It is manageable and can be used for maintainable and scalable
addin applications. Let me know if you have any specific questions.

Regards,

Slava

-----Original Message-----
From: qua...@li...
[mailto:qua...@li...] On Behalf Of
qua...@li...
Sent: Thursday, April 17, 2008 12:59 PM
To: qua...@li...
Subject: QuantLib-dev Digest, Vol 23, Issue 2

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. independent use of objecthandler (Ole Peng)
   2. Re: [QuantLib-svn] SF.net SVN: quantlib: [14708]
      branches/serialization_enhancements2 (Ferdinando Ametrano)
   3. Re: [QuantLib-svn] SF.net SVN: quantlib:	[14708]
      branches/serialization_enhancements2 (Plamen Neykov)
   4. [ quantlib-Feature Requests-1941916 ] Asian Average	Strike
      Option (SourceForge.net)
   5. Non copyable curves. (Simon Ibbotson)
   6. Re: Non copyable curves. (op)


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

Message: 1
Date: Sun, 13 Apr 2008 16:57:05 -0700 (PDT)
From: Ole Peng <ole...@ya...>
Subject: [Quantlib-dev] independent use of objecthandler
To: qua...@li...
Cc: qua...@li...
Message-ID: <525...@we...>
Content-Type: text/plain; charset="us-ascii"

Hi, 

do any of you use the objecthandler independently of quantlib for addin
development? 

If yes, then I would like to pick your brain in order to assess how
manageable that is and if it can be 
used for maintainable and scalable addin applications?

Thanks, Ole



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...

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

Message: 2
Date: Mon, 14 Apr 2008 10:10:15 +0200
From: "Ferdinando Ametrano" <na...@am...>
Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
	[14708]	branches/serialization_enhancements2
To: qua...@li...
Cc: pla...@us...
Message-ID:
	<864...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

Hi Plamen

>  Log Message:
>  -----------
>  small project file changes to allow for boost installed in an
arbitrary directory
>
>  Modified Paths:
>  --------------
>
branches/serialization_enhancements2/ObjectHandler/Examples/C++/ExampleC
pp_vc8.vcproj
>
branches/serialization_enhancements2/ObjectHandler/Examples/xl/ExampleXl
lDynamic1_vc8.vcproj
>
branches/serialization_enhancements2/ObjectHandler/Examples/xl/ExampleXl
lDynamic2_vc8.vcproj
>
branches/serialization_enhancements2/ObjectHandler/Examples/xl/ExampleXl
lStatic_vc8.vcproj
>
branches/serialization_enhancements2/QuantLibAddin/Clients/Cpp/ClientCpp
Demo_vc8.vcproj
>
>  Modified:
branches/serialization_enhancements2/ObjectHandler/Examples/C++/ExampleC
pp_vc8.vcproj
>  ===================================================================
>  ---
branches/serialization_enhancements2/ObjectHandler/Examples/C++/ExampleC
pp_vc8.vcproj       2008-04-13 16:08:51 UTC (rev 14707)
>  +++
branches/serialization_enhancements2/ObjectHandler/Examples/C++/ExampleC
pp_vc8.vcproj       2008-04-13 21:31:49 UTC (rev 14708)
>  @@ -75,7 +75,7 @@
>
OutputFile="bin\ExampleCpp-vc80-mt-0_9_5.exe"
>                                 LinkIncremental="1"
>                                 SuppressStartupBanner="true"
>  -
AdditionalLibraryDirectories="..\..\lib,..\..\..\log4cxx\msvc\Lib"
>  +
AdditionalLibraryDirectories="..\..\lib;..\..\..\log4cxx\msvc\Lib;&quot;
$(BOOST_DIR)\lib&quot;"

I would prefer no to have environment variable for the boost library
resolution. In my opinion it should up to the developer to configure
properly its Visual Studio IDE (Tools | Options | Project and
Solutions | VC++ Directories) to point to its favorite boost version.
Am I missing something? Do you agree?

ciao -- Nando



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

Message: 3
Date: Mon, 14 Apr 2008 08:28:35 +0000 (GMT)
From: Plamen Neykov <pla...@re...>
Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:
	[14708]	branches/serialization_enhancements2
To: na...@am..., qua...@li...
Message-ID:
	<212...@vu...>
Content-Type: text/plain; charset=utf-8

Hi Ferdinando,

no problem - I'll revert the change asap (tonight) - I wasn't aware of
this policy - obviously not following the discussions here on the list -
sorry.

cheers,
Plamen

-----Original Message-----

From: "Ferdinando Ametrano" <na...@am...>
Sent: Mon, 14 Apr 2008 10:10:15 +0200
To: qua...@li...
CC: pla...@us...
Received: 14-Apr-2008 10:10:54 +0200
Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [14708]
branches/serialization_enhancements2

* 0 RECENT
* 1210 FETCH (UID 41427 BODY[1] {2395}
Hi Plamen

>  Log Message:
>  -----------
>  small project file changes to allow for boost installed in an
arbitrary directory
>
>  Modified Paths:
>  --------------
>
branches/serialization_enhancements2/ObjectHandler/Examples/C++/ExampleC
pp_vc8.vcproj
>
branches/serialization_enhancements2/ObjectHandler/Examples/xl/ExampleXl
lDynamic1_vc8.vcproj
>
branches/serialization_enhancements2/ObjectHandler/Examples/xl/ExampleXl
lDynamic2_vc8.vcproj
>
branches/serialization_enhancements2/ObjectHandler/Examples/xl/ExampleXl
lStatic_vc8.vcproj
>
branches/serialization_enhancements2/QuantLibAddin/Clients/Cpp/ClientCpp
Demo_vc8.vcproj
>
>  Modified:
branches/serialization_enhancements2/ObjectHandler/Examples/C++/ExampleC
pp_vc8.vcproj
>  ===================================================================
>  ---
branches/serialization_enhancements2/ObjectHandler/Examples/C++/ExampleC
pp_vc8.vcproj       2008-04-13 16:08:51 UTC (rev 14707)
>  +++
branches/serialization_enhancements2/ObjectHandler/Examples/C++/ExampleC
pp_vc8.vcproj       2008-04-13 21:31:49 UTC (rev 14708)
>  @@ -75,7 +75,7 @@
>
OutputFile="bin\ExampleCpp-vc80-mt-0_9_5.exe"
>                                 LinkIncremental="1"
>                                 SuppressStartupBanner="true"
>  -
AdditionalLibraryDirectories="..\..\lib,..\..\..\log4cxx\msvc\Lib"
>  +
AdditionalLibraryDirectories="..\..\lib;..\..\..\log4cxx\msvc\Lib;&quot;
$(BOOST_DIR)\lib&quot;"

I would prefer no to have environment variable for the boost library
resolution. In my opinion it should up to the developer to configure
properly its Visual Studio IDE (Tools | Options | Project and
Solutions | VC++ Directories) to point to its favorite boost version.
Am I missing something? Do you agree?

ciao -- Nando

------------------------------------------------------------------------
-
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
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev




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

Message: 4
Date: Mon, 14 Apr 2008 03:19:05 -0700
From: "SourceForge.net" <no...@so...>
Subject: [Quantlib-dev] [ quantlib-Feature Requests-1941916 ] Asian
	Average	Strike Option
To: no...@so...
Message-ID: <E1J...@sc...>
Content-Type: text/plain; charset="UTF-8"

Feature Requests item #1941916, was opened at 2008-04-14 15:49
Message generated for change (Tracker Item Submitted) made by Item
Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=1941916&gro
up_id=12740

Please note that this message will contain a full copy of the comment
thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: abhishek Srivastava (abhiabhi001)
Assigned to: Nobody/Anonymous (nobody)
Summary: Asian Average Strike Option

Initial Comment:
Hi

in the instrument list "Asian Average Strike Option" is not avaialable.

Thanks
Abhishek

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=1941916&gro
up_id=12740



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

Message: 5
Date: Thu, 17 Apr 2008 07:48:49 -0000
From: "Simon Ibbotson" <Sim...@st...>
Subject: [Quantlib-dev] Non copyable curves.
To: <qua...@li...>
Message-ID:
	<B2E...@CL...>
Content-Type: text/plain; charset="us-ascii"

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

 

-------------- next part --------------
An HTML attachment was scrubbed...

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

Message: 6
Date: Thu, 17 Apr 2008 09:58:44 -0700 (PDT)
From: op <ole...@ya...>
Subject: Re: [Quantlib-dev] Non copyable curves.
To: Simon Ibbotson <Sim...@st...>
Cc: "<qua...@li...>"
	<qua...@li...>
Message-ID: <505...@we...>
Content-Type: text/plain; charset="windows-1252"

An HTML attachment was scrubbed...
-------------- next part --------------
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"
<Sim...@st...> 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/j
avaone
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev



 
________________________________________________________________________
____________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

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

------------------------------------------------------------------------
-
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
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev


End of QuantLib-dev Digest, Vol 23, Issue 2
*******************************************

Re: [Quantlib-dev] Non copyable curves.

[Simon I. <Sim...@st...>]

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:ole...@ya...] 
Sent: 17 April 2008 17:59
To: Simon Ibbotson - Straumur
Cc: <qua...@li...>
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"
<Sim...@st...> 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/j
avaone

	_______________________________________________
	QuantLib-dev mailing list
	Qua...@li...
	https://lists.sourceforge.net/lists/listinfo/quantlib-dev

 

________________________________

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
it now.
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62
sR8HDtDypao8Wcj9tAcJ%20> 

Re: [Quantlib-dev] Non copyable curves.

[op <ole...@ya...>]

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" <Sim...@st...> 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
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Quantlib-dev] Non copyable curves.

[Simon I. <Sim...@st...>]

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