quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Handle class conversion. Open discussion.

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

Hi Kakhkhor,

I created some dynamic_handle_cast code about 2 years ago. There was
some discussion at the time: see 28th Feb 2008

http://osdir.com/ml/finance.quantlib.devel/2008-02/

I submitted an implementation but had no response - and it hasn't made
its way into the library. I can provide it again if required.

Simon

-----Original Message-----
From: Kakhkhor Abdijalilov [mailto:kab...@gm...] 
Sent: 24 December 2010 23:39
To: qua...@li...
Subject: [Quantlib-dev] Handle class conversion. Open discussion.

Dear all,
Current implementation of Handle class doesn't permit conversion from
Handle<Derived> to Handle<Base>. If we supply Handle<Base> with
converting constructor, an instance of Handle<Derived> could be
substituted where an instance of Handle<Base> is expected. For
example, an instance of Handle<SimpleQuote> could be passed  to term
structure constructors instead of Handle<Quote> instance. This
conversion makes sense, since SimpleQuote is a subtype of Quote.

Enabling conversion would allow user code use derived class features
without a need for dynamic casting. Safety of conversion can be
checked at runtime, similar to pointer down-casting.

I did some coding in this direction and so far everything looks OK.
Since it is a design decision and not a bug fix, I wanted to know what
other think before submitting my code.

Regards,
Kakhkhor Abdijalilov.

------------------------------------------------------------------------
------
Learn how Oracle Real Application Clusters (RAC) One Node allows
customers
to consolidate database storage, standardize their database environment,
and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev



This communication and any attachments contains information which is confidential and may be subject to legal privilege. It is for intended recipients only. If you are not the intended recipient you must not copy, distribute, publish, rely on or otherwise use it without our consent. Some of our communications may contain confidential information which it could be a criminal offence for you to disclose or use without authority. If you have received this email in error please notify pos...@fs... immediately and delete the email from your computer.

The FSA reserves the right to monitor all email communications for compliance with legal, regulatory and professional standards.
This email is not intended to nor should it be taken to create any legal relations or contractual relationships. This email has originated from

The Financial Services Authority (FSA)
25 The North Colonnade,
Canary Wharf,
London
E14 5HS
United Kingdom

Registered as a Limited Company in England and Wales No.1920623.
Registered Office as above

Switchboard: 020 7066 1000
Web Site: http://www.fsa.gov.uk
*****************************************************************

Re: [Quantlib-dev] Returning multiple values from a Monte-Carlo pricing engine

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

Unfortunately, that would mean producing a specialised template routine
for McSimulation::value() (and others) as we cannot instantiate both
result_type of Array and result_type of double using begin() and end()
arguments. That would take us back to the beginning of this email
chain...

I personally would go for a constructor of Array(const
std::vector<double>&) for simplicity. Would you agree?

Simon


-----Original Message-----
From: Luigi Ballabio [mailto:lui...@gm...] 
Sent: 24 December 2010 09:55
To: Simon Ibbotson
Cc: qua...@li...
Subject: RE: [Quantlib-dev] Returning multiple values from a Monte-Carlo
pricing engine

On Tue, 2010-12-14 at 12:48 +0000, Simon Ibbotson wrote:
> Unfortunately not; McSimulation::value() instantiates a result_type
> (i.e. an Array) from a vector<double> obtained from the
> sampleAccumulator at several points (also in ::valueWithSamples()).
> 
> Therefore, Array would need a new constructor either:
> 
> [...]
> 
> Which would you recommend?

Neither.  You can use the existing
Array(ForwardIterator begin, ForwardIterator end);
and pass the begin() and end() of the vector.

Luigi


-- 

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





This communication and any attachments contains information which is confidential and may be subject to legal privilege. It is for intended recipients only. If you are not the intended recipient you must not copy, distribute, publish, rely on or otherwise use it without our consent. Some of our communications may contain confidential information which it could be a criminal offence for you to disclose or use without authority. If you have received this email in error please notify pos...@fs... immediately and delete the email from your computer.

The FSA reserves the right to monitor all email communications for compliance with legal, regulatory and professional standards.
This email is not intended to nor should it be taken to create any legal relations or contractual relationships. This email has originated from

The Financial Services Authority (FSA)
25 The North Colonnade,
Canary Wharf,
London
E14 5HS
United Kingdom

Registered as a Limited Company in England and Wales No.1920623.
Registered Office as above

Switchboard: 020 7066 1000
Web Site: http://www.fsa.gov.uk
*****************************************************************

Re: [Quantlib-dev] FX Vol Term Structure

[Bojan N. <bo...@bn...>]

"tar...@li..." <tar...@li...> writes:

> My input data are:
> a list of tenors (e.g. 1W, 1M, 3M....)
> a matrix of strikes a matrix of implied volatilities.
>
> is there any possibility to build such a type of volatility surface to create 
> a forex vol term structure?

See the class BlackVarianceSurface
(ql/termstructures/volatility/equityfx/blackvariancesurface.hpp)

Best,
Bojan

-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk/ql

Re: [Quantlib-dev] Issues with C# Swig Bindings, NUnit and Settings.instance().setEvaluationDate()

[Ahmad M. <ahm...@gm...>]

Hi Luigi,

I have a similar call stack which also seems to error at
notifyObservers(Line119). I truncated the C# bits.

  msvcr90d.dll!1023c355()
  [Frames below may be incorrect and/or missing, no symbols loaded for
msvcr90d.dll]
  msvcr90d.dll!1023e1fa()
  msvcr90d.dll!102dccd7()
>> NQuantLibc.dll!QuantLib::Observable::notifyObservers()  Line 119 + 0x31
bytes C++
  NQuantLibc.dll!QuantLib::ObservableValue<QuantLib::Date>::operator=(const
QuantLib::Date & t)  Line 81 C++
  NQuantLibc.dll!QuantLib::Settings::DateProxy::operator=(const
QuantLib::Date & d)  Line 37 C++
  NQuantLibc.dll!Settings_setEvaluationDate(QuantLib::Settings * self, const
QuantLib::Date & d)  Line 5944 C++
  NQuantLibc.dll!CSharp_Settings_setEvaluationDate(void * jarg1, void *
jarg2)  Line 25380 + 0xd bytes C++
  [External Code]
  NQuantLib.DLL!QuantLib.Settings.setEvaluationDate(QuantLib.Date d) Line 57
+ 0x2d bytes C#
  XXXX.SetDates(System.DateTime settlementDate, System.DateTime todaysDate)
Line 155 + 0x10 bytes C#



On 30 December 2010 22:45, Henner Heck <hen...@tu...>wrote:

>
> Hello Luigi,
>
> here are some call stacks i managed to get.
>
> I ran the program several times and attached the Visual Studio debugger to
> the Java process.
>
> I had tried manual calls to the Java garbage collector before, to see if
> they might solve the problem, which they didn't.
> But the sets of possible call stacks seem to differ, depending on whether
> the gc was run manually or not,
> though it could also be, that i just didn't try often enough.
>
> One of these call stacks were presented when the program got the "pure
> virtual function call" error:
>
>        With the Java garbage collection run manually before each swap
> evaluation:
>
>
>        QuantLibJNI.dll!_purecall()  Line 54 + 0x7 bytes        C
> >       QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 +
> > 0x31 bytes    C++
>
>  QuantLibJNI.dll!QuantLib::BootstrapHelper<QuantLib::YieldTermStructure>::update()
> Line 153        C++
>
>  QuantLibJNI.dll!QuantLib::RelativeDateBootstrapHelper<QuantLib::YieldTermStructure>::update()
> Line 114        C++
>        QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 +
> 0x31
> bytes   C++
>
>  QuantLibJNI.dll!QuantLib::ObservableValue<QuantLib::Date>::operator=(const
> QuantLib::Date & t={...})  Line 81      C++
>        QuantLibJNI.dll!QuantLib::Settings::DateProxy::operator=(const
> QuantLib::Date & d={...})  Line 37      C++
>        QuantLibJNI.dll!Settings_setEvaluationDate(QuantLib::Settings *
> self=0x0582d970, const QuantLib::Date & d={...})  Line 4384     C++
>
>  QuantLibJNI.dll!Java_org_quantlib_QuantLibJNI_Settings_1setEvaluationDate(JNIEnv_
> * jenv=0x023b4518, _jclass * jcls=0x0229fa4c, __int64 jarg1=92461424,
> _jobject * jarg1_=0x0229fa60, __int64 jarg2=92545208, _jobject *
> jarg2_=0x0229fa54)  Line 24282 + 0xd bytes      C++
>        02499f47()
>        jvm.dll!6d8e3a9c()
>        [Frames below may be incorrect and/or missing, no symbols loaded for
> jvm.dll]
>        jvm.dll!6d976591()
>        jvm.dll!6d8e3b1d()
>        jvm.dll!6d8ed365()
>        msvcr71.dll!7c3416b3()
>        ntdll.dll!776f9d15()
>
>
>        Without the manual garbage collection:
>
>        QuantLibJNI.dll!_purecall()  Line 54 + 0x7 bytes        C
> >       QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 +
> > 0x31 bytes    C++
>        QuantLibJNI.dll!QuantLib::InterestRateIndex::update()  Line 94  C++
>        QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 +
> 0x31
> bytes   C++
>
>  QuantLibJNI.dll!QuantLib::ObservableValue<QuantLib::Date>::operator=(const
> QuantLib::Date & t={...})  Line 81      C++
>        QuantLibJNI.dll!QuantLib::Settings::DateProxy::operator=(const
> QuantLib::Date & d={...})  Line 37      C++
>        QuantLibJNI.dll!Settings_setEvaluationDate(QuantLib::Settings *
> self=0x057fd970, const QuantLib::Date & d={...})  Line 4384     C++
>
>  QuantLibJNI.dll!Java_org_quantlib_QuantLibJNI_Settings_1setEvaluationDate(JNIEnv_
> * jenv=0x00454518, _jclass * jcls=0x0024fa4c, __int64 jarg1=92264816,
> _jobject * jarg1_=0x0024fa60, __int64 jarg2=95332160, _jobject *
> jarg2_=0x0024fa54)  Line 24282 + 0xd bytes      C++
>        02509f47()
>        jvm.dll!6d8e3a9c()
>        [Frames below may be incorrect and/or missing, no symbols loaded for
> jvm.dll]
>        jvm.dll!6d976591()
>        jvm.dll!6d8e3b1d()
>        jvm.dll!6d8ed365()
>        msvcr71.dll!7c3416b3()
>        ntdll.dll!776f9d15()
>
>
>        Appeared in both cases:
>
>        QuantLibJNI.dll!_purecall()  Line 54 + 0x7 bytes        C
> >       QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 +
> > 0x31 bytes    C++
>        QuantLibJNI.dll!QuantLib::FloatingRateCoupon::update()  Line 96 +
> 0x19
> bytes   C++
>        QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 +
> 0x31
> bytes   C++
>        QuantLibJNI.dll!QuantLib::InterestRateIndex::update()  Line 94  C++
>        QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 +
> 0x31
> bytes   C++
>
>  QuantLibJNI.dll!QuantLib::ObservableValue<QuantLib::Date>::operator=(const
> QuantLib::Date & t={...})  Line 81      C++
>        QuantLibJNI.dll!QuantLib::Settings::DateProxy::operator=(const
> QuantLib::Date & d={...})  Line 37      C++
>        QuantLibJNI.dll!Settings_setEvaluationDate(QuantLib::Settings *
> self=0x057fd970, const QuantLib::Date & d={...})  Line 4384     C++
>
>  QuantLibJNI.dll!Java_org_quantlib_QuantLibJNI_Settings_1setEvaluationDate(JNIEnv_
> * jenv=0x02334518, _jclass * jcls=0x01c9fa4c, __int64 jarg1=92264816,
> _jobject * jarg1_=0x01c9fa60, __int64 jarg2=95531456, _jobject *
> jarg2_=0x01c9fa54)  Line 24282 + 0xd bytes      C++
>        02419f47()
>        jvm.dll!6d8e3a9c()
>        [Frames below may be incorrect and/or missing, no symbols loaded for
> jvm.dll]
>        jvm.dll!6d976591()
>        jvm.dll!6d8e3b1d()
>        jvm.dll!6d8ed365()
>        msvcr71.dll!7c3416b3()
>        ntdll.dll!776f9d15()
>
>
> I hope it helps.
>
> Best regards,
> Henner Heck
>
>
>
>
>
> > On Wed, 2010-12-29 at 19:05 +0100, Henner Heck wrote:
> >> i too experienced this error in Java when i did
> >> several swap evaluations in a row yesterday.
> >> The code runs nicely several times and then throws the
> >> "pure virtual function call" which crashes the JVM.
> >> It always happens on "setEvaluationDate" in the Settings class.
> >
> > Do you happen to have a traceback?  (setEvaluationDate triggers the
> > update() method of its observers.  It owuld be useful to know which one
> > is responsible, if any.)
> >
> > Luigi
> >
> >
> >
>
>
> --
> Erstellt mit Operas revolutionärem E-Mail-Modul:
> http://www.opera.com/mail/
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>



-- 
Ahmad Mahomed

[Quantlib-dev] Lis tes messages avant qu'ils ne soient effacés!

[Badoo <no...@ba...>]

Lis ton message de Hicham avant qu'il ne soit effacé!

Pour lire ton message, suis simplement ce lien:
http://eu1.badoo.com/0193192463/in/98ZoDTqMY8Q/?lang_id=6

D'autres personnes sont aussi présentes:
Aïra (Paris, France)
Camila (Paris, France)
Soynada (Paris, France)

http://eu1.badoo.com/0193192463/in/98ZoDTqMY8Q/?lang_id=6

Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur.

Tu as reçu cet email suite à un message envoyé par Hicham sur notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système.

Amuse-toi bien!
L'équipe Badoo


Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir:
http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=quantlib-dev%40lists.sourceforge.net&secret=&invite_id=18393&user_id=193192463

Re: [Quantlib-dev] Issues with C# Swig Bindings, NUnit and Settings.instance().setEvaluationDate()

[Henner H. <hen...@tu...>]

Hello Luigi,

here are some call stacks i managed to get.

I ran the program several times and attached the Visual Studio debugger to  
the Java process.

I had tried manual calls to the Java garbage collector before, to see if  
they might solve the problem, which they didn't.
But the sets of possible call stacks seem to differ, depending on whether  
the gc was run manually or not,
though it could also be, that i just didn't try often enough.

One of these call stacks were presented when the program got the "pure  
virtual function call" error:

	With the Java garbage collection run manually before each swap evaluation:
	

  	QuantLibJNI.dll!_purecall()  Line 54 + 0x7 bytes	C
> 	QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 +  
> 0x31 bytes	C++
  	QuantLibJNI.dll!QuantLib::BootstrapHelper<QuantLib::YieldTermStructure>::update()   
Line 153	C++
  	QuantLibJNI.dll!QuantLib::RelativeDateBootstrapHelper<QuantLib::YieldTermStructure>::update()   
Line 114	C++
  	QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 + 0x31  
bytes	C++
  	QuantLibJNI.dll!QuantLib::ObservableValue<QuantLib::Date>::operator=(const  
QuantLib::Date & t={...})  Line 81	C++
  	QuantLibJNI.dll!QuantLib::Settings::DateProxy::operator=(const  
QuantLib::Date & d={...})  Line 37	C++
  	QuantLibJNI.dll!Settings_setEvaluationDate(QuantLib::Settings *  
self=0x0582d970, const QuantLib::Date & d={...})  Line 4384	C++
  	QuantLibJNI.dll!Java_org_quantlib_QuantLibJNI_Settings_1setEvaluationDate(JNIEnv_  
* jenv=0x023b4518, _jclass * jcls=0x0229fa4c, __int64 jarg1=92461424,  
_jobject * jarg1_=0x0229fa60, __int64 jarg2=92545208, _jobject *  
jarg2_=0x0229fa54)  Line 24282 + 0xd bytes	C++
  	02499f47()	
  	jvm.dll!6d8e3a9c() 	
  	[Frames below may be incorrect and/or missing, no symbols loaded for  
jvm.dll]	
  	jvm.dll!6d976591() 	
  	jvm.dll!6d8e3b1d() 	
  	jvm.dll!6d8ed365() 	
  	msvcr71.dll!7c3416b3() 	
  	ntdll.dll!776f9d15() 	
		
	
	Without the manual garbage collection:
	
	QuantLibJNI.dll!_purecall()  Line 54 + 0x7 bytes	C
> 	QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 +  
> 0x31 bytes	C++
  	QuantLibJNI.dll!QuantLib::InterestRateIndex::update()  Line 94	C++
  	QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 + 0x31  
bytes	C++
  	QuantLibJNI.dll!QuantLib::ObservableValue<QuantLib::Date>::operator=(const  
QuantLib::Date & t={...})  Line 81	C++
  	QuantLibJNI.dll!QuantLib::Settings::DateProxy::operator=(const  
QuantLib::Date & d={...})  Line 37	C++
  	QuantLibJNI.dll!Settings_setEvaluationDate(QuantLib::Settings *  
self=0x057fd970, const QuantLib::Date & d={...})  Line 4384	C++
  	QuantLibJNI.dll!Java_org_quantlib_QuantLibJNI_Settings_1setEvaluationDate(JNIEnv_  
* jenv=0x00454518, _jclass * jcls=0x0024fa4c, __int64 jarg1=92264816,  
_jobject * jarg1_=0x0024fa60, __int64 jarg2=95332160, _jobject *  
jarg2_=0x0024fa54)  Line 24282 + 0xd bytes	C++
  	02509f47()	
  	jvm.dll!6d8e3a9c() 	
  	[Frames below may be incorrect and/or missing, no symbols loaded for  
jvm.dll]	
  	jvm.dll!6d976591() 	
  	jvm.dll!6d8e3b1d() 	
  	jvm.dll!6d8ed365() 	
  	msvcr71.dll!7c3416b3() 	
  	ntdll.dll!776f9d15()
	
	
	Appeared in both cases:
	
	QuantLibJNI.dll!_purecall()  Line 54 + 0x7 bytes	C
> 	QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 +  
> 0x31 bytes	C++
  	QuantLibJNI.dll!QuantLib::FloatingRateCoupon::update()  Line 96 + 0x19  
bytes	C++
  	QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 + 0x31  
bytes	C++
  	QuantLibJNI.dll!QuantLib::InterestRateIndex::update()  Line 94	C++
  	QuantLibJNI.dll!QuantLib::Observable::notifyObservers()  Line 119 + 0x31  
bytes	C++
  	QuantLibJNI.dll!QuantLib::ObservableValue<QuantLib::Date>::operator=(const  
QuantLib::Date & t={...})  Line 81	C++
  	QuantLibJNI.dll!QuantLib::Settings::DateProxy::operator=(const  
QuantLib::Date & d={...})  Line 37	C++
  	QuantLibJNI.dll!Settings_setEvaluationDate(QuantLib::Settings *  
self=0x057fd970, const QuantLib::Date & d={...})  Line 4384	C++
  	QuantLibJNI.dll!Java_org_quantlib_QuantLibJNI_Settings_1setEvaluationDate(JNIEnv_  
* jenv=0x02334518, _jclass * jcls=0x01c9fa4c, __int64 jarg1=92264816,  
_jobject * jarg1_=0x01c9fa60, __int64 jarg2=95531456, _jobject *  
jarg2_=0x01c9fa54)  Line 24282 + 0xd bytes	C++
  	02419f47()	
  	jvm.dll!6d8e3a9c() 	
  	[Frames below may be incorrect and/or missing, no symbols loaded for  
jvm.dll]	
  	jvm.dll!6d976591() 	
  	jvm.dll!6d8e3b1d() 	
  	jvm.dll!6d8ed365() 	
  	msvcr71.dll!7c3416b3() 	
  	ntdll.dll!776f9d15() 	


I hope it helps.
	
Best regards,
Henner Heck
	




> On Wed, 2010-12-29 at 19:05 +0100, Henner Heck wrote:
>> i too experienced this error in Java when i did
>> several swap evaluations in a row yesterday.
>> The code runs nicely several times and then throws the
>> "pure virtual function call" which crashes the JVM.
>> It always happens on "setEvaluationDate" in the Settings class.
>
> Do you happen to have a traceback?  (setEvaluationDate triggers the
> update() method of its observers.  It owuld be useful to know which one
> is responsible, if any.)
>
> Luigi
>
>
>


-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Re: [Quantlib-dev] Issues with C# Swig Bindings, NUnit and Settings.instance().setEvaluationDate()

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

On Wed, 2010-12-29 at 19:05 +0100, Henner Heck wrote:
> i too experienced this error in Java when i did
> several swap evaluations in a row yesterday.
> The code runs nicely several times and then throws the
> "pure virtual function call" which crashes the JVM.
> It always happens on "setEvaluationDate" in the Settings class.

Do you happen to have a traceback?  (setEvaluationDate triggers the
update() method of its observers.  It owuld be useful to know which one
is responsible, if any.)

Luigi



-- 

Steinbach's Guideline for Systems Programming: 
Never test for an error condition you don't know how to handle. 

Re: [Quantlib-dev] Issues with C# Swig Bindings, NUnit and Settings.instance().setEvaluationDate()

[Henner H. <hen...@tu...>]

Hello,

i too experienced this error in Java when i did
several swap evaluations in a row yesterday.
The code runs nicely several times and then throws the
"pure virtual function call" which crashes the JVM.
It always happens on "setEvaluationDate" in the Settings class.

I would be really happy to see this fixed, since it makes
QuantLib practically unusable in my scenario.
I will try myself, but i am far from being a SWIG expert.

Software used:
Windows 7 x64
QuantLib 1.0.1
SWIG 2.0.0
Java 1.6.0_22
QuantLib compiled with Visual Studio Express 2008

Best regards,
Henner Heck




Am 29.12.2010, 08:02 Uhr, schrieb Ahmad Mahomed <ahm...@gm...>:

> Hi Guys,
>
> I have a similar issues as described in this (1)old
> thread<http://is.gd/jGlUb> as
> well as (2)this one <http://is.gd/jGmeM> and arises when trying to set  
> the
> evaluation date of the Settings class.
>
> My current situation is as follows
> - Using the QuantLib's C# SWIG bindings;
> - NUnit 2.5.7 is being used for unit tests
>
> The issues arises when running all the unit test from the NUnit test  
> runner.
> The error is thrown when trying to set the evaluation date of the  
> Settings
> instance using the C# 'Settings.instance().setEvaluationDate()'   
> function.
>
> I get the following error in a message box.
>
> "Runtime Error!
> Program: C:\Program Files\NUnit 2.5.7\bin\net-2.0\nuit-agent.exe
>
> R6025
> - pure virtual function call"
>
> Microsoft has KB article related to this R6025
> error<http://support.microsoft.com/kb/125749> but
> I'm not sure how to relate this to the QuantLib C++ code as well the C#  
> Swig
> bindings.
>
> The error is consistent in that I am unable to run all my unit tests.
> However, the test at which it fails is always inconsistent - sometime it  
> may
> fail at the third test while other times it may run  over half the tests
> before it fails. A point to note is that if each test is run  
> individually,
> it passes.
>
> I thought the issue may be related to how the singleton is managed via  
> Swig
> which prompted this Stackoverflow question about generating singletons in
> Swig <http://stackoverflow.com/q/4069204/268667> about using a different
> Swig declaration to set the evaluation date.This yielded no positive
> results. In the linked threads above, Nathan Abbot suggests that the  
> issue
> lies with .Net AppDomains and provides a solution and provides a solution
> which I was the foundation of the  SO question.
>
> Regards,
>


-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[Quantlib-dev] FX Vol Term Structure

[<tar...@li...>]

Hello,

I am trying to build a forex volatility term structure.

My input data are:
a list of tenors (e.g. 1W, 1M, 3M....)
a matrix of strikes a matrix of implied volatilities.

is there any possibility to build such a type of volatility surface to create 
a forex vol term structure?

thx,
Paolo

[Quantlib-dev] [ quantlib-Patches-3139291 ] Enhancement to linear least squares regression

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

Patches item #3139291, was opened at 2010-12-17 21:13
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3139291&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: Slava Mazur (shlagbaum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhancement to linear least squares regression

Initial Comment:
The idea behind proposed enhancement is application of the current linear least squares regression to a wider range of containers. Currently the input data must be in std::vector<double>. However, in my particular case for example, i need to perform linear least squares on the data in boost::circular_buffer<double> and it is highly undesirable to create vector copies of the original data just to satisfy rather rigid requirements of the current linear least squares design. A proposed patch relaxes such a requirement and at the same time preserves backward compatibility. A correspondent test case is added to the test_suite.

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2010-12-29 10:10

Message:
Let's keep backward compatibility.

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

Comment By: Klaus Spanderen (klausspanderen)
Date: 2010-12-28 16:06

Message:
I have removed the swap method. Please find the recent version in the SVN
head. Even though it breaks backward compatibility I would now also remove
the ArgumentType as it is redundant. Or should we introduce a backward
compatibility stub, Luigi?

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

Comment By: Klaus Spanderen (klausspanderen)
Date: 2010-12-28 13:49

Message:
Good solution! I have submitted your last version (with a small change from
my side) to the SVN head. IMO the original intention for two classes -
LinearLeastSquaresRegression and LinearRegression - was that
LinearLeastSquaresRegression is the generic class that can take a list of
functions used for the regression whereas LinearRegression takes only
linear functions. WIth the second constructor in the current version
        template <class xContainer, class yContainer, class vContainer>
        LinearRegression(const xContainer& x, 
                         const yContainer& y, const vContainer &v);
LinearRegression now becomes a swiss jackknife. IMHO I'd either remove
this constructor or - as you already mentioned - remove the class
LinearLeastSquaresRegression completely (leaving a stub for backward
compatibility) 

I've removed the second usage of the swap method already and I think we
can remove the other swap invocation as well if LinearFcts becomes a list
of functions. 

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

Comment By: Slava Mazur (shlagbaum)
Date: 2010-12-24 19:51

Message:
With a little help from mpl i managed to simplify design significantly (see
the attached). A template argument "ArgumentType" apparently becomes
redundant (perhaps as well as the whole class
LinearLeastSquaresRegression), but they left unchanged for backward
compatibility. It is recommended to remove them in due time though - this
will simplify design even further (for example, an ugly cast in swap method
will go away).

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

Comment By: Slava Mazur (shlagbaum)
Date: 2010-12-20 19:13

Message:
I agree, but the reason for the proposed design was the current design of
the LinearRegression class, which handles both 1d and multi-dimensional
regressions. In addition to generalize wrt input data type, my goal was to
optimize the existing solution, since currently LinearRegression class
treats a one-dimensional regression as being a multi-dimensional one, which
introduces although small, but an overhead in 1d case. Such an overhead may
become significant if LinearRegression is used repeatedly in a loop. If the
LinearRegression class were a template instead, things would be much
simpler, but this would break the backward compatibility. 

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

Comment By: Klaus Spanderen (klausspanderen)
Date: 2010-12-18 17:22

Message:
Enhancing the flexibilty of the class LinearLeastSquaresRegression is a
good idea. Just a design question: instead of adding more classes would it
be better for the "end user" to stay with one LinearLeastSquaresRegression
class but add two "templatized" constructors to this class? These
constructors would allow  e.g. boost::circular_buffer<double> to be used as
input parameters.

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

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

[Quantlib-dev] [ quantlib-Patches-3139291 ] Enhancement to linear least squares regression

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

Patches item #3139291, was opened at 2010-12-17 20:13
Message generated for change (Comment added) made by klausspanderen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3139291&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: Slava Mazur (shlagbaum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhancement to linear least squares regression

Initial Comment:
The idea behind proposed enhancement is application of the current linear least squares regression to a wider range of containers. Currently the input data must be in std::vector<double>. However, in my particular case for example, i need to perform linear least squares on the data in boost::circular_buffer<double> and it is highly undesirable to create vector copies of the original data just to satisfy rather rigid requirements of the current linear least squares design. A proposed patch relaxes such a requirement and at the same time preserves backward compatibility. A correspondent test case is added to the test_suite.

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

Comment By: Klaus Spanderen (klausspanderen)
Date: 2010-12-28 15:06

Message:
I have removed the swap method. Please find the recent version in the SVN
head. Even though it breaks backward compatibility I would now also remove
the ArgumentType as it is redundant. Or should we introduce a backward
compatibility stub, Luigi?

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

Comment By: Klaus Spanderen (klausspanderen)
Date: 2010-12-28 12:49

Message:
Good solution! I have submitted your last version (with a small change from
my side) to the SVN head. IMO the original intention for two classes -
LinearLeastSquaresRegression and LinearRegression - was that
LinearLeastSquaresRegression is the generic class that can take a list of
functions used for the regression whereas LinearRegression takes only
linear functions. WIth the second constructor in the current version
        template <class xContainer, class yContainer, class vContainer>
        LinearRegression(const xContainer& x, 
                         const yContainer& y, const vContainer &v);
LinearRegression now becomes a swiss jackknife. IMHO I'd either remove
this constructor or - as you already mentioned - remove the class
LinearLeastSquaresRegression completely (leaving a stub for backward
compatibility) 

I've removed the second usage of the swap method already and I think we
can remove the other swap invocation as well if LinearFcts becomes a list
of functions. 

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

Comment By: Slava Mazur (shlagbaum)
Date: 2010-12-24 18:51

Message:
With a little help from mpl i managed to simplify design significantly (see
the attached). A template argument "ArgumentType" apparently becomes
redundant (perhaps as well as the whole class
LinearLeastSquaresRegression), but they left unchanged for backward
compatibility. It is recommended to remove them in due time though - this
will simplify design even further (for example, an ugly cast in swap method
will go away).

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

Comment By: Slava Mazur (shlagbaum)
Date: 2010-12-20 18:13

Message:
I agree, but the reason for the proposed design was the current design of
the LinearRegression class, which handles both 1d and multi-dimensional
regressions. In addition to generalize wrt input data type, my goal was to
optimize the existing solution, since currently LinearRegression class
treats a one-dimensional regression as being a multi-dimensional one, which
introduces although small, but an overhead in 1d case. Such an overhead may
become significant if LinearRegression is used repeatedly in a loop. If the
LinearRegression class were a template instead, things would be much
simpler, but this would break the backward compatibility. 

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

Comment By: Klaus Spanderen (klausspanderen)
Date: 2010-12-18 16:22

Message:
Enhancing the flexibilty of the class LinearLeastSquaresRegression is a
good idea. Just a design question: instead of adding more classes would it
be better for the "end user" to stay with one LinearLeastSquaresRegression
class but add two "templatized" constructors to this class? These
constructors would allow  e.g. boost::circular_buffer<double> to be used as
input parameters.

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

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

[Quantlib-dev] Template based Hull White model

[<seb...@sc...>]

Hi,<br /><br />I coded a Hull White model in the QuantLib framework which I would like to contribute to the experimental folder. I am aware that there is already a Hull White model in QuantLib. Nevertheless I think it is not duplicate work.<br /><br />The key feature of my approach is that the model is completely template based. That is also the reason why (unfortunately) I can not inherit from the existing model classes. The reason for the template approach is that I intent to apply Automatic Differentiation tools (see e.g. <a class="parsedLink" href="http://www.autodiff.org" target="_blank">www.autodiff.org</a>) to evaluate derivatives (i.e. Greeks), in particular w.r.t. the volatility (Bermudan Vegas).<br /><br />The model features replication of the observed yield curve (of course), constant mean reversion, and piece-wise constant short rate volatility. It allows the evaluation of and calibration to European bond options. Moreover, it allows to price Bermudan bond options by successive (numerical) evaluation of the expected payoff (and discounting). It is not intended to price these derivatives on a tree because the model allows more accurate (semi-) analytical expressions.<br /><br />In addition to the (template based) model class I coded a bond option instrument and a pricing engine which manages the calibration of the model to coterminal European swaptions (which is to my knowledge the market standard calibration approach). The Excel interface is configured and an example workbook demonstrates the approach.<br /><br />I would like to know if I should simply submit a patch and/or if you would like to discuss the approach first in the mailing list.<br /><br />I would appreciate any comments.<br /><br />Sebastian

[Quantlib-dev] [ quantlib-Patches-3139291 ] Enhancement to linear least squares regression

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

Patches item #3139291, was opened at 2010-12-17 20:13
Message generated for change (Comment added) made by klausspanderen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3139291&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: Slava Mazur (shlagbaum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhancement to linear least squares regression

Initial Comment:
The idea behind proposed enhancement is application of the current linear least squares regression to a wider range of containers. Currently the input data must be in std::vector<double>. However, in my particular case for example, i need to perform linear least squares on the data in boost::circular_buffer<double> and it is highly undesirable to create vector copies of the original data just to satisfy rather rigid requirements of the current linear least squares design. A proposed patch relaxes such a requirement and at the same time preserves backward compatibility. A correspondent test case is added to the test_suite.

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

Comment By: Klaus Spanderen (klausspanderen)
Date: 2010-12-28 12:49

Message:
Good solution! I have submitted your last version (with a small change from
my side) to the SVN head. IMO the original intention for two classes -
LinearLeastSquaresRegression and LinearRegression - was that
LinearLeastSquaresRegression is the generic class that can take a list of
functions used for the regression whereas LinearRegression takes only
linear functions. WIth the second constructor in the current version
        template <class xContainer, class yContainer, class vContainer>
        LinearRegression(const xContainer& x, 
                         const yContainer& y, const vContainer &v);
LinearRegression now becomes a swiss jackknife. IMHO I'd either remove
this constructor or - as you already mentioned - remove the class
LinearLeastSquaresRegression completely (leaving a stub for backward
compatibility) 

I've removed the second usage of the swap method already and I think we
can remove the other swap invocation as well if LinearFcts becomes a list
of functions. 

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

Comment By: Slava Mazur (shlagbaum)
Date: 2010-12-24 18:51

Message:
With a little help from mpl i managed to simplify design significantly (see
the attached). A template argument "ArgumentType" apparently becomes
redundant (perhaps as well as the whole class
LinearLeastSquaresRegression), but they left unchanged for backward
compatibility. It is recommended to remove them in due time though - this
will simplify design even further (for example, an ugly cast in swap method
will go away).

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

Comment By: Slava Mazur (shlagbaum)
Date: 2010-12-20 18:13

Message:
I agree, but the reason for the proposed design was the current design of
the LinearRegression class, which handles both 1d and multi-dimensional
regressions. In addition to generalize wrt input data type, my goal was to
optimize the existing solution, since currently LinearRegression class
treats a one-dimensional regression as being a multi-dimensional one, which
introduces although small, but an overhead in 1d case. Such an overhead may
become significant if LinearRegression is used repeatedly in a loop. If the
LinearRegression class were a template instead, things would be much
simpler, but this would break the backward compatibility. 

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

Comment By: Klaus Spanderen (klausspanderen)
Date: 2010-12-18 16:22

Message:
Enhancing the flexibilty of the class LinearLeastSquaresRegression is a
good idea. Just a design question: instead of adding more classes would it
be better for the "end user" to stay with one LinearLeastSquaresRegression
class but add two "templatized" constructors to this class? These
constructors would allow  e.g. boost::circular_buffer<double> to be used as
input parameters.

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

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

Re: [Quantlib-dev] MarketModelPathwiseDiscounter::getFactors() does not resize factors vector

[Mark j. <mar...@gm...>]

I am on holiday right now.

Andreas is probably right. I'll look into it when I get back to the office.

Happy Solstice!

Mark


-- 

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

Re: [Quantlib-dev] MarketModelPathwiseDiscounter::getFactors() does not resize factors vector

[Andreas S. <an...@sp...>]

Hi Luigi,

Am 24.12.2010 11:01, schrieb Luigi Ballabio:

> Andreas,
> 	I'm not sure, but I think it was a common theme of the market-model
> implementation that vectors should be initialized at the correct size by
> the calling code before being passed to methods (efficiency reasons and
> such.)  Adding a resize() shouldn't cost much, but I'd leave the
> decision to Mark Joshi as he's the main developer of that part of the
> library (Mark, are you reading this? Any thoughts?)

Agreed. The point here, however, is that the calling object
(PathwiseAccountingEngine), initializes the factor variable to be of
size "numberOfProducts"...

Rgds,

Andreas

Re: [Quantlib-dev] [Quantlib-users] Boost Serialization Error

[Eric E. <eri...@na...>]

Hi Nando,

Quoting Ferdinando Ametrano <na...@am...>:

>> ok at least now I've realized why you don't see the bug I'm
>> experiencing: you're probably using QuantLibXL-vc90-mt-1_1_0.xll which
>> does NOT have problems, while I'm using
>> QuantLibXLDynamic-vc90-mt-1_1_0.xll

Yes, that was the reason.  In fact that also indicates the root cause,  
in the dynamic build, the class is registered in the QLXL binary but  
the serialization instruction is implemented in the OH binary and  
BOOST_REGISTER_CLASS doesn't support this case.

There is no simple solution to this problem so for now I reverted the  
change.  Sorry for the hassle.

Regards,
Eric

===================================================
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
* Distributed computing for pricing analytics
* Use Microsoft Excel as a client to the Grid

[Quantlib-dev] Handle class conversion. Open discussion.

[Kakhkhor A. <kab...@gm...>]

Dear all,
Current implementation of Handle class doesn't permit conversion from
Handle<Derived> to Handle<Base>. If we supply Handle<Base> with
converting constructor, an instance of Handle<Derived> could be
substituted where an instance of Handle<Base> is expected. For
example, an instance of Handle<SimpleQuote> could be passed  to term
structure constructors instead of Handle<Quote> instance. This
conversion makes sense, since SimpleQuote is a subtype of Quote.

Enabling conversion would allow user code use derived class features
without a need for dynamic casting. Safety of conversion can be
checked at runtime, similar to pointer down-casting.

I did some coding in this direction and so far everything looks OK.
Since it is a design decision and not a bug fix, I wanted to know what
other think before submitting my code.

Regards,
Kakhkhor Abdijalilov.

[Quantlib-dev] [ quantlib-Patches-3139291 ] Enhancement to linear least squares regression

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

Patches item #3139291, was opened at 2010-12-17 15:13
Message generated for change (Comment added) made by shlagbaum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3139291&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: Slava Mazur (shlagbaum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhancement to linear least squares regression

Initial Comment:
The idea behind proposed enhancement is application of the current linear least squares regression to a wider range of containers. Currently the input data must be in std::vector<double>. However, in my particular case for example, i need to perform linear least squares on the data in boost::circular_buffer<double> and it is highly undesirable to create vector copies of the original data just to satisfy rather rigid requirements of the current linear least squares design. A proposed patch relaxes such a requirement and at the same time preserves backward compatibility. A correspondent test case is added to the test_suite.

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

Comment By: Slava Mazur (shlagbaum)
Date: 2010-12-24 13:51

Message:
With a little help from mpl i managed to simplify design significantly (see
the attached). A template argument "ArgumentType" apparently becomes
redundant (perhaps as well as the whole class
LinearLeastSquaresRegression), but they left unchanged for backward
compatibility. It is recommended to remove them in due time though - this
will simplify design even further (for example, an ugly cast in swap method
will go away).

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

Comment By: Slava Mazur (shlagbaum)
Date: 2010-12-20 13:13

Message:
I agree, but the reason for the proposed design was the current design of
the LinearRegression class, which handles both 1d and multi-dimensional
regressions. In addition to generalize wrt input data type, my goal was to
optimize the existing solution, since currently LinearRegression class
treats a one-dimensional regression as being a multi-dimensional one, which
introduces although small, but an overhead in 1d case. Such an overhead may
become significant if LinearRegression is used repeatedly in a loop. If the
LinearRegression class were a template instead, things would be much
simpler, but this would break the backward compatibility. 

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

Comment By: Klaus Spanderen (klausspanderen)
Date: 2010-12-18 11:22

Message:
Enhancing the flexibilty of the class LinearLeastSquaresRegression is a
good idea. Just a design question: instead of adding more classes would it
be better for the "end user" to stay with one LinearLeastSquaresRegression
class but add two "templatized" constructors to this class? These
constructors would allow  e.g. boost::circular_buffer<double> to be used as
input parameters.

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

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

Re: [Quantlib-dev] MarketModelPathwiseDiscounter::getFactors() does not resize factors vector

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

On Tue, 2010-12-21 at 08:37 +0100, Andreas Spengler wrote:
> in trying to use QLs MarketModel classes for implementing a Target
> Redemption Note, I found that MarketModelPathwiseDiscounter::getFactors()
> does not resize the "factors" parameter properly before writing into it,
> thereby overwriting members of the calling object in my environment (i.e.
> PathwiseAccountingEngine::numberCashFlowsThisIndex_).

Andreas,
	I'm not sure, but I think it was a common theme of the market-model
implementation that vectors should be initialized at the correct size by
the calling code before being passed to methods (efficiency reasons and
such.)  Adding a resize() shouldn't cost much, but I'd leave the
decision to Mark Joshi as he's the main developer of that part of the
library (Mark, are you reading this? Any thoughts?)

Luigi


-- 

When all else fails, pour a pint of Guinness in the gas tank, 
advance the spark 20 degrees, cry "God Save the Queen!", and pull 
the starter knob. 
-- MG "Series MGA" Workshop Manual 

Re: [Quantlib-dev] Invalid null pointer

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

On Tue, 2010-12-14 at 10:09 +0000, Alessandro Duci wrote:
> I downloaded boost_1_45_0 and the latest version of quantlib
> on a  Win Server 2003 (64bits) and i built all with  Visual Studio
> 2010 as WIN32.
> 
> If I run the Test Suite I get the error
> 
> File c:\...\microsoft visual studio 10.0\vc\include\xutility
> line: 2225
> Debug Assertion Failed! "Expression: invalid null pointer"
> 
> Can you please help me understanding what I did wrong?

I'm not sure (I don't have a 64-bit machine to try and replicate the
problem.)  Did you run the test suite in Debug or Release mode?  Either
way, what happens if you try in the other mode?  Also, was Boost
compiled in 32- or 64-bit mode?  And may you try modifying the solution
so that the library is built in 64-bit mode?

Luigi


-- 

Don't say "yes" until I finish talking. 
-- Darryl F. Zanuck 

Re: [Quantlib-dev] Returning multiple values from a Monte-Carlo pricing engine

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

On Tue, 2010-12-14 at 12:48 +0000, Simon Ibbotson wrote:
> Unfortunately not; McSimulation::value() instantiates a result_type
> (i.e. an Array) from a vector<double> obtained from the
> sampleAccumulator at several points (also in ::valueWithSamples()).
> 
> Therefore, Array would need a new constructor either:
> 
> [...]
> 
> Which would you recommend?

Neither.  You can use the existing
Array(ForwardIterator begin, ForwardIterator end);
and pass the begin() and end() of the vector.

Luigi


-- 

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

Re: [Quantlib-dev] Un message de Hicham t'attend...

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

Hachemi,
	not on the mailing list, please.  People subscribed to receive  
technical posts, not invitations to social networks.

Thanks,
	Luigi

[Quantlib-dev] Un message de Hicham t'attend...

[Badoo <no...@ba...>]

Un message de Hicham t'attend...

L'expéditeur et le contenu seront visibles seulement par toi et tu peux le supprimer à tout moment. Tu peux aussi y répondre directement au travers du messenger. Pour découvrir qui est à l'origine du message, suis simplement ce lien:
http://eu1.badoo.com/0193192463/in/98ZoDTqMY8Q/?lang_id=6

D'autres personnes sont aussi présentes:
Martial (Paris, France)
Kristina (Paris, France)
Mustang (Paris, France)

http://eu1.badoo.com/0193192463/in/98ZoDTqMY8Q/?lang_id=6

Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur.

Tu as reçu cet email suite à une requête de Hicham sur notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système.

Merci,
L'équipe Badoo


Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir:
http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=21&email=quantlib-dev%40lists.sourceforge.net&secret=&invite_id=18393&user_id=193192463

[Quantlib-dev] Proposed change to RangeAccrual classes

[Andreas S. <an...@sp...>]

Hi,

I am currently looking into the classes surrounding the RangeAccrualLeg;
as there are variations of those on the market which (at times) pay out a
portion of a fixed coupon instead of a portion of an index, I would
propose the addition of an "alternativeFixedRate" member as outlined
below.

Could someone give me a hint as to how I would integrate this alternative
into the "RangeAccrualPricer"s; also, how would I go about integrating the
spread into the accrual formula? [(3M-Libor + x% spread) * n/N - where n
is the # of days in the period that satisfy the range condition and N is
the total # of days in the period...]

Rgds,

Andreas


*** rangeaccrual.hpp    2010-04-19 12:49:17.000000000 +0200
--- rangeaccrual.hpp.new        2010-12-22 13:08:23.000000000 +0100
***************
*** 45,50 ****
--- 45,51 ----
                  const Date& paymentDate,
                  Real nominal,
                  const boost::shared_ptr<IborIndex>& index,
+                 Rate alternativeFixedRate,
                  const Date& startDate,
                  const Date& endDate,
                  Natural fixingDays,
***************
*** 59,64 ****
--- 60,68 ----

          Real startTime() const {return startTime_; }
          Real endTime() const {return endTime_; }
+
+         Rate alternativeFixedRate() const {return alternativeFixedRate_; }
+
          Real lowerTrigger() const {return lowerTrigger_; }
          Real upperTrigger() const {return upperTrigger_; }
          Size observationsNo() const {return observationsNo_; }
***************
*** 88,93 ****
--- 92,99 ----
          std::vector<Real> observationTimes_;
          Size observationsNo_;

+         Rate alternativeFixedRate_;
+
          Real lowerTrigger_;
          Real upperTrigger_;
       };
***************
*** 113,118 ****
--- 119,125 ----
          std::vector<Real> observationTimes_;               // U
          std::vector<Real> initialValues_;
          Size observationsNo_;
+         Rate alternativeFixedRate_;
          Real lowerTrigger_;
          Real upperTrigger_;
          Real discount_;
***************
*** 213,218 ****
--- 220,227 ----
          RangeAccrualLeg& withGearings(const std::vector<Real>& gearings);
          RangeAccrualLeg& withSpreads(Spread spread);
          RangeAccrualLeg& withSpreads(const std::vector<Spread>& spreads);
+         RangeAccrualLeg& withAlternativeFixedRates(Rate fixedRate);
+         RangeAccrualLeg& withAlternativeFixedRates(const
std::vector<Rate>& fixedRates);
          RangeAccrualLeg& withLowerTriggers(Rate trigger);
          RangeAccrualLeg& withLowerTriggers(const std::vector<Rate>&
triggers);
          RangeAccrualLeg& withUpperTriggers(Rate trigger);
***************
*** 229,234 ****
--- 238,244 ----
          std::vector<Natural> fixingDays_;
          std::vector<Real> gearings_;
          std::vector<Spread> spreads_;
+         std::vector<Rate> alternativeFixedRates_;
          std::vector<Rate> lowerTriggers_, upperTriggers_;
          Period observationTenor_;
          BusinessDayConvention observationConvention_;



*** rangeaccrual.cpp    2010-04-19 12:49:17.000000000 +0200
--- rangeaccrual.cpp.new        2010-12-22 13:11:48.000000000 +0100
***************
*** 39,44 ****
--- 39,45 ----
                  const Date& paymentDate,
                  Real nominal,
                  const boost::shared_ptr<IborIndex>& index,
+                 Rate alternativeFixedRate,
                  const Date& startDate,                                 
// S
                  const Date& endDate,                                   
// T
                  Natural fixingDays,
***************
*** 55,60 ****
--- 56,62 ----
                           fixingDays, index, gearing, spread,
                           refPeriodStart, refPeriodEnd, dayCounter),
      observationsSchedule_(observationsSchedule),
+     alternativeFixedRate_(alternativeFixedRate),
      lowerTrigger_(lowerTrigger),
      upperTrigger_(upperTrigger){

***************
*** 94,101 ****

      Real RangeAccrualFloatersCoupon::priceWithoutOptionality(
             const Handle<YieldTermStructure>& discountingCurve) const {
!         return accrualPeriod() * (gearing_*indexFixing()+spread_) *
!                nominal() * discountingCurve->discount(date());
      }


--- 96,109 ----

      Real RangeAccrualFloatersCoupon::priceWithoutOptionality(
             const Handle<YieldTermStructure>& discountingCurve) const {
!
!         if (alternativeFixedRate_ > .0) {
!             return accrualPeriod() * (alternativeFixedRate_  + spread_) *
!                 nominal() * discountingCurve->discount(date());
!         } else {
!             return accrualPeriod() * (gearing_*indexFixing() + spread_) *
!                 nominal() * discountingCurve->discount(date());
!         }
      }


***************
*** 122,129 ****
--- 130,140 ----
          startTime_ = coupon_->startTime();
          endTime_ = coupon_->endTime();
          observationTimes_ = coupon_->observationTimes();
+
+         alternativeFixedRate_ = coupon_->alternativeFixedRate();
          lowerTrigger_ = coupon_->lowerTrigger();
          upperTrigger_ = coupon_->upperTrigger();
+
          observationsNo_ = coupon_->observationsNo();

          const std::vector<Date> &observationDates =
***************
*** 590,595 ****
--- 601,616 ----
          return *this;
      }

+     RangeAccrualLeg& RangeAccrualLeg::withAlternativeFixedRates(Rate
fixedRate) {
+         alternativeFixedRates_ = std::vector<Rate>(1, fixedRate);
+         return *this;
+     }
+
+     RangeAccrualLeg& RangeAccrualLeg::withAlternativeFixedRates(const
std::vector<Rate>& fixedRates) {
+         alternativeFixedRates_ = fixedRates;
+         return *this;
+     }
+
      RangeAccrualLeg& RangeAccrualLeg::withLowerTriggers(Rate trigger) {
          lowerTriggers_ = std::vector<Rate>(1,trigger);
          return *this;
***************
*** 690,695 ****
--- 711,717 ----
                              paymentDate,
                              detail::get(notionals_, i, Null<Real>()),
                              index_,
+                             detail::get(alternativeFixedRates_, i, 0.0),
                              start, end,
                              detail::get(fixingDays_, i, 2),
                              paymentDayCounter_,

Re: [Quantlib-dev] MarketModelPathwiseDiscounter::getFactors() does not resize factors vector

[Andreas S. <an...@sp...>]

I am sorry, the context diff is obviously wrong - it should be:

*** pathwisediscounter.cpp.orig 2009-12-30 10:57:50.000000000 +0100
--- pathwisediscounter.cpp      2010-12-21 09:32:05.000000000 +0100
***************
*** 57,62 ****
--- 57,64 ----
      Real preDF = Discounts[currentStep][before_];
      Real postDF = Discounts[currentStep][before_+1];

+     factors.resize(numberRates_ + 1);
+
      for (Size i=before_+1; i<numberRates_; ++i)
          factors[i+1] =0.0;