quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] How to copy a Boost::Matrix into a Quantlib::Matrix

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

Hi,

jrviala <jea...@am...> writes:

> I'm trying to use std::copy but it fails to compile
> It seems a rather simple problem I'm confident someone has used it somewhere
> could you tell me the correct wording?

Something like this should work:

 boost::numeric::ublas::matrix<double> m (3, 3);                                                                                                            
 QuantLib::Matrix mm(3,3);
 std::copy(m.begin1(), m.end1(), mm.begin());           

Although you need to check the column/row convention (I believe this
will transpose the matrix).

Best,
Bojan

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

Re: [Quantlib-dev] How to copy a Boost::Matrix into a Quantlib::Matrix

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

On Mon, 2011-11-07 at 04:40 -0800, jrviala wrote:
> I'm trying to use std::copy but it fails to compile It seems a rather
> simple problem I'm confident someone has used it somewhere could you
> tell me the correct wording? 

It depends on how you initialize the matrices, I guess.  What did you
try?

Luigi



-- 

The first rule of intelligent tinkering is to save all the parts. 
-- Paul Erlich 

[Quantlib-dev] qlYieldTSZeroRate on Cpp

[Son, D. Jung-B. (I. GmbH) <JUN...@IN...>]

Hello,

Has anyone tried to "unlock" qlYieldTSZeroRate for Cpp on QuantLib 1.1? I uncommented  <!--SupportedPlatform name='Cpp'/--> but receive compiling errors from gensrc:

2>>
2>> gensrc has encountered a fatal error.
2>>
2>> >>>>>>>>>> BEGIN STACK TRACE >>>>>>>>>>
2>>
2>>   File "c:\QuantLib-1_1\gensrc\gensrc.py", line 125, in <module>
2>>     addinList.generate()
2>>   File "c:\QuantLib-1_1\gensrc\gensrc\addins\addinlist.py", line 74, in generate
2>>     self.generateCode()
2>>   File "c:\QuantLib-1_1\gensrc\gensrc\addins\addinlist.py", line 83, in generateCode
2>>     addin.generate(self.categoryList_, self.enumerationList_)
2>>   File "c:\QuantLib-1_1\gensrc\gensrc\addins\cpp.py", line 55, in generate
2>>     self.generateFunctions()
2>>   File "c:\QuantLib-1_1\gensrc\gensrc\addins\cpp.py", line 71, in generateFunctions
2>>     bufferCpp += self.generateFunction(func)
2>>   File "c:\QuantLib-1_1\gensrc\gensrc\addins\cpp.py", line 92, in generateFunction
2>>     'functionBody' : func.generateBody(self),
2>>   File "c:\QuantLib-1_1\gensrc\gensrc\functions\member.py", line 43, in generateBody
2>>     return self.behavior_.generateBody(addin)
2>>   File "c:\QuantLib-1_1\gensrc\gensrc\functions\behaviorloop.py", line 50, in generateBody
2>>     'inputParam' : addin.loopName(self.loopParamRef_),
2>>   File "c:\QuantLib-1_1\gensrc\gensrc\addins\cpp.py", line 110, in loopName
2>>     if param.type() == common.STRING:
2>>
2>> <<<<<<<<<<  END STACK TRACE  <<<<<<<<<<
2>>
2>> gensrc error:
2>> 'Parameter' object has no attribute 'type'
2>>
2>> NMAKE : fatal error U1077: '..\..\gensrc\gensrc.py' : return code '0x1'

Cheers,
Jung-Bae


Dr. Jung-Bae Son
Market Data Development

InvestmentDataServices
Phone: +49 89 3800 19184
Fax: +49 89 3800 15150
E-mail: jun...@In...<mailto:jun...@In...>

Please visit our new website:
www.InvestmentDataServices.com<http://www.investmentdataservices.com/>

Office:
Ludwigstraße 7
80539 Munich, Germany

Post address:
IDS GmbH - Analysis and Reporting Services
Königinstraße 28, 80802 Munich, Germany

Chairman of the Advisory Board: Dr. Claus Stickler
Managing Directors: Dr. Wolfgang Dietl, Dr. Bernd Fischer, Holger Haun, Werner Kieferle
Registered Office: Munich, Germany; Register: HRB 13 69 82; Local court: Munich; VAT-Id No: DE813776224
A company of Allianz

This message is intended only for the use of person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not an intended recipient, you may not read, copy or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.

[Quantlib-dev] How to copy a Boost::Matrix into a Quantlib::Matrix

[jrviala <jea...@am...>]

I'm trying to use std::copy but it fails to compile
It seems a rather simple problem I'm confident someone has used it somewhere
could you tell me the correct wording?
-- 
View this message in context: http://old.nabble.com/How-to-copy-a-Boost%3A%3AMatrix-into-a-Quantlib%3A%3AMatrix-tp32788720p32788720.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] erf and inverse erf

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

Hi Keith,
	what's the license on that code?

Luigi


On Wed, 2011-10-12 at 07:49 -0400, Keith A. Lewis wrote:
> Here is a link to high precision routines by T. Ooura for these
> functions:
> http://xllbms.codeplex.com/SourceControl/changeset/view/9909#143295.
> 
>  
> 
> And some not so high precision routines:
> http://xllbms.codeplex.com/SourceControl/changeset/view/9909#143299.
> 
>  
> 
> kal
> 
>  
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________ QuantLib-dev mailing list Qua...@li... https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 

Vin: It's like this fellow I knew in El Paso. One day, he just took 
all his clothes off and jumped in a mess of cactus. I asked him that 
same question, "Why?" 
Calvera: And? 
Vin: He said, "It seemed like a good idea at the time." 
-- The Magnificent Seven 

[Quantlib-dev] [ quantlib-Bugs-3426042 ] Sobol 18th inizialization polinomial

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

Bugs item #3426042, was opened at 2011-10-19 18:47
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3426042&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: Invalid
Priority: 5
Private: No
Submitted By: giulio (giulioggg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sobol 18th inizialization polinomial

Initial Comment:
I have an old Sobol code.
Very clear implementation, but poor performance.
I tried to switch to QuantLib\'s one, as it should be better implemented.
But first, I checked they were the same (I mean, different implementation but same results).

I generated 8000 random vectors of dimension between 1 and 32 (because in my old Sobol code I can\'t use more than 32 dimensions).
All output are exactly the same except on the 18th dimension.
i.e.: the 8000 realizations of random vectors with dimension from 1 and 17 are exactly the same, while the 8000 realization of random vector of dimension between 18 and 32 differ only at the 18th component.

If I remember well (sorry but many years have passed since I deal with Sobol sequence), this may be caused from a different 18th inizialization polinomial.

I checked mine, and it is the same as publiched by Jaeckel at page 85 (table 8.3), i.e. 1101101.

Of course I\'m not sure the bug is in your library, but maybe a check can be a good idea ;-)

I attached two files for your convenience, old.txt and new.txt.
Both contain 8000 random vectors of dimension 20.
By comparing such files (for example with WinMerge) you can see the difference on the 18th dimension (the others being exactly the same).

Bye, Giulio

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2011-10-21 11:30

Message:
Ok, glad it's solved.  Thanks for putting effort into this.

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

Comment By: giulio (giulioggg)
Date: 2011-10-20 13:04

Message:
Solved.
The problem was in my old code.
The initializers polinomials were correct. The problem was in the
direction integers.
At the row 18, instead of (1, 1, 1, 3, 13, 39) I had (1, 1, 1, 3, 13,
13).
Correcting that single istruction was sufficient to reproduce exactly the
same numbers of QuantLib.

Now I don't know. Do I have to put the keyword SOLVED in same place within
this bug report? 

In this case, let me know...

Bye

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

Comment By: giulio (giulioggg)
Date: 2011-10-19 18:49

Message:
For size limit the files actually attached contain 3000 rows, instead of
8000 (as I wrongly wrote in the post above).

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

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

[Quantlib-dev] [ quantlib-Bugs-3426042 ] Sobol 18th inizialization polinomial

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

Bugs item #3426042, was opened at 2011-10-19 18:47
Message generated for change (Comment added) made by giulioggg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3426042&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: giulio (giulioggg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sobol 18th inizialization polinomial

Initial Comment:
I have an old Sobol code.
Very clear implementation, but poor performance.
I tried to switch to QuantLib\'s one, as it should be better implemented.
But first, I checked they were the same (I mean, different implementation but same results).

I generated 8000 random vectors of dimension between 1 and 32 (because in my old Sobol code I can\'t use more than 32 dimensions).
All output are exactly the same except on the 18th dimension.
i.e.: the 8000 realizations of random vectors with dimension from 1 and 17 are exactly the same, while the 8000 realization of random vector of dimension between 18 and 32 differ only at the 18th component.

If I remember well (sorry but many years have passed since I deal with Sobol sequence), this may be caused from a different 18th inizialization polinomial.

I checked mine, and it is the same as publiched by Jaeckel at page 85 (table 8.3), i.e. 1101101.

Of course I\'m not sure the bug is in your library, but maybe a check can be a good idea ;-)

I attached two files for your convenience, old.txt and new.txt.
Both contain 8000 random vectors of dimension 20.
By comparing such files (for example with WinMerge) you can see the difference on the 18th dimension (the others being exactly the same).

Bye, Giulio

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

>Comment By: giulio (giulioggg)
Date: 2011-10-20 13:04

Message:
Solved.
The problem was in my old code.
The initializers polinomials were correct. The problem was in the
direction integers.
At the row 18, instead of (1, 1, 1, 3, 13, 39) I had (1, 1, 1, 3, 13,
13).
Correcting that single istruction was sufficient to reproduce exactly the
same numbers of QuantLib.

Now I don't know. Do I have to put the keyword SOLVED in same place within
this bug report? 

In this case, let me know...

Bye

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

Comment By: giulio (giulioggg)
Date: 2011-10-19 18:49

Message:
For size limit the files actually attached contain 3000 rows, instead of
8000 (as I wrongly wrote in the post above).

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

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

[Quantlib-dev] [ quantlib-Bugs-3426042 ] Sobol 18th inizialization polinomial

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

Bugs item #3426042, was opened at 2011-10-19 18:47
Message generated for change (Comment added) made by giulioggg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3426042&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: giulio (giulioggg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sobol 18th inizialization polinomial

Initial Comment:
I have an old Sobol code.
Very clear implementation, but poor performance.
I tried to switch to QuantLib\'s one, as it should be better implemented.
But first, I checked they were the same (I mean, different implementation but same results).

I generated 8000 random vectors of dimension between 1 and 32 (because in my old Sobol code I can\'t use more than 32 dimensions).
All output are exactly the same except on the 18th dimension.
i.e.: the 8000 realizations of random vectors with dimension from 1 and 17 are exactly the same, while the 8000 realization of random vector of dimension between 18 and 32 differ only at the 18th component.

If I remember well (sorry but many years have passed since I deal with Sobol sequence), this may be caused from a different 18th inizialization polinomial.

I checked mine, and it is the same as publiched by Jaeckel at page 85 (table 8.3), i.e. 1101101.

Of course I\'m not sure the bug is in your library, but maybe a check can be a good idea ;-)

I attached two files for your convenience, old.txt and new.txt.
Both contain 8000 random vectors of dimension 20.
By comparing such files (for example with WinMerge) you can see the difference on the 18th dimension (the others being exactly the same).

Bye, Giulio

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

>Comment By: giulio (giulioggg)
Date: 2011-10-19 18:49

Message:
For size limit the files actually attached contain 3000 rows, instead of
8000 (as I wrongly wrote in the post above).

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

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

[Quantlib-dev] [ quantlib-Bugs-3426042 ] Sobol 18th inizialization polinomial

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

Bugs item #3426042, was opened at 2011-10-19 18:47
Message generated for change (Tracker Item Submitted) made by giulioggg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3426042&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: giulio (giulioggg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sobol 18th inizialization polinomial

Initial Comment:
I have an old Sobol code.
Very clear implementation, but poor performance.
I tried to switch to QuantLib\'s one, as it should be better implemented.
But first, I checked they were the same (I mean, different implementation but same results).

I generated 8000 random vectors of dimension between 1 and 32 (because in my old Sobol code I can\'t use more than 32 dimensions).
All output are exactly the same except on the 18th dimension.
i.e.: the 8000 realizations of random vectors with dimension from 1 and 17 are exactly the same, while the 8000 realization of random vector of dimension between 18 and 32 differ only at the 18th component.

If I remember well (sorry but many years have passed since I deal with Sobol sequence), this may be caused from a different 18th inizialization polinomial.

I checked mine, and it is the same as publiched by Jaeckel at page 85 (table 8.3), i.e. 1101101.

Of course I\'m not sure the bug is in your library, but maybe a check can be a good idea ;-)

I attached two files for your convenience, old.txt and new.txt.
Both contain 8000 random vectors of dimension 20.
By comparing such files (for example with WinMerge) you can see the difference on the 18th dimension (the others being exactly the same).

Bye, Giulio

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

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

[Quantlib-dev] Error building CppWrapper dll using files generated using latest swig files

[manas b. <ma...@ho...>]

Hi, I checked out the latest quantlib code from svn and built successfully the quantlib dll. When I tried to build CppWrapper dll using the quantlib.cpp, a file that gets generated by skwash plugin using the interfaces files preseint in Quantlib-SWIG/SWIG directory, for loading in java projects, the build has started failing with the following errors:
cl /c /EHs /MD /Zi /IC:\Boost\include\boost-1_43 /IC:\Program Files\Java\jdk1.6.0_27\include /IC:\Program Files\Java\jdk1.6.0_27\include\win32 /IC:\work\quantlib\QuantLib /nologo /Foquantlib.obj ..\quantlib.cppquantlib.cpplink /DLL /debug /nologo /libpath:C:\work\quantlib\QuantLib\lib /libpath:C:\program files\microsoft sdks\windows\v6.0a\lib /OUT:QuantLibCppWrapper.dll quantlib.obj QuantLib-vc100-mt-gd.lib   Creating library QuantLibCppWrapper.lib and object QuantLibCppWrapper.expquantlib.obj : error LNK2019: unresolved external symbol "public: __thiscall QuantLib::FixedRateLeg::operator class std::vector<class boost::shared_ptr<class QuantLib::CashFlow>,class std::allocator<class boost::shared_ptr<class QuantLib::CashFlow> > >(void)const " (??BFixedRateLeg@QuantLib@@QBE?AV?$vector@V?$shared_ptr@VCashFlow@QuantLib@@@boost@@V?$allocator@V?$shared_ptr@VCashFlow@QuantLib@@@boost@@@std@@@std@@XZ) referenced in function "class std::vector<class boost::shared_ptr<class QuantLib::CashFlow>,class std::allocator<class boost::shared_ptr<class QuantLib::CashFlow> > > __cdecl _FixedRateLeg(class QuantLib::Schedule const &,class QuantLib::DayCounter const &,class std::vector<double,class std::allocator<double> > const &,class std::vector<double,class std::allocator<double> > const &,enum QuantLib::BusinessDayConvention,class QuantLib::DayCounter const &)" (?_FixedRateLeg@@YA?AV?$vector@V?$shared_ptr@VCashFlow@QuantLib@@@boost@@V?$allocator@V?$shared_ptr@VCashFlow@QuantLib@@@boost@@@std@@@std@@ABVSchedule@QuantLib@@ABVDayCounter@4@ABV?$vector@NV?$allocator@N@std@@@2@2W4BusinessDayConvention@4@1@Z)

I had earlier built the wrapper dll correctly and was able to load it in java. Can someone please let me know what has changed in the new interfaces files. regards,Manas  		 	   		  

Re: [Quantlib-dev] 'dev_tools/' in source

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

On Tue, 2011-10-18 at 10:57 +0000, YuHong wrote:
> 
> Hello, all.  I see 'dev_tools/' directory in the recent quantLib
> source.  Is it some new source component?  Just curious.

No, they've been here for a long time.  It's just some scripts that help
setting up and packaging for releases.

Luigi


-- 

Things should be made as simple as possible, but no simpler. 
-- Albert Einstein 

[Quantlib-dev] 'dev_tools/' in source

[YuHong <hy...@ho...>]

Hello, all.  I see 'dev_tools/' directory in the recent quantLib source.  Is it some new source component?  Just curious.

Best regards,

Hong Yu

 		 	   		  

Re: [Quantlib-dev] using special functions and statistical distributions from boost::math?

[Kim K. T. <kue...@vo...>]

Am 14.10.2011 10:53, schrieb Luigi Ballabio:
> On Thu, 2011-10-13 at 22:25 +0200, Kim Kuen Tang wrote:
>>> I investigated the issue of using boost functions a while ago. If I recal it
>>> correctly the conclusion was that using the boost distribution functions would
>>> make QuantLib depend on some boost lib files, which wasn't regarded as
>>> desirable.
>> Dont understand this point. QuantLib already depends on boost.
> He means that we would have to link to a Boost library.  Right now, we
> just include header-only Boost modules, so there's no linking involved
> and compilation is simpler.

Hmmm QuantLib::testsuite is already using boost::testing. So the linking 
is already there and no additional work needs to/ should be done.

> Anyway, I'm in favour of using more Boost modules (not only math, but
> for instance signals instead of the current observer/observable
> classes).  However, we have backward compatibility to think of, so we
> can't just remove the existing functions because people might be using
> them.  Let's keep it in the list of things we'll do for QuantLib 2.0.
>
> Luigi
>
>
>

Re: [Quantlib-dev] using special functions and statistical distributions from boost::math?

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

On Thu, 2011-10-13 at 22:25 +0200, Kim Kuen Tang wrote:
> > I investigated the issue of using boost functions a while ago. If I recal it
> > correctly the conclusion was that using the boost distribution functions would
> > make QuantLib depend on some boost lib files, which wasn't regarded as
> > desirable.
> Dont understand this point. QuantLib already depends on boost.

He means that we would have to link to a Boost library.  Right now, we
just include header-only Boost modules, so there's no linking involved
and compilation is simpler.

Anyway, I'm in favour of using more Boost modules (not only math, but
for instance signals instead of the current observer/observable
classes).  However, we have backward compatibility to think of, so we
can't just remove the existing functions because people might be using
them.  Let's keep it in the list of things we'll do for QuantLib 2.0.

Luigi



-- 

A human being should be able to change a diaper, plan an invasion, 
butcher a hog, conn a ship, design a building, write a sonnet, balance 
accounts, build a wall, set a bone, comfort the dying, take orders, 
give orders, cooperate, act alone, solve equations, analyze a new 
problem, pitch manure, program a computer, cook a tasty meal, fight 
efficiently, die gallantly. Specialization is for insects. 
-- Robert A. Heinlein 

Re: [Quantlib-dev] using special functions and statistical distributions from boost::math?

[Kim K. T. <kue...@vo...>]

Am 13.10.2011 12:57, schrieb Nicolai Lassesen:
> Luigi Ballabio<luigi.ballabio<at>  gmail.com>  writes:
>
>> On Sun, 2011-10-02 at 09:13 +0800, R Yan wrote:
>>> For example, in ql/math/distributions, many distributions are
>>> implemented.
>>>
>>> However, the same functionalities are already implemented in
>>> boost::math.
>>>
>>> Maybe it's a good idea to use the boost impl?
>> Yes, if we can do so without losing backward compatibility and
>> precision.
>>
>> Luigi
>>
> I investigated the issue of using boost functions a while ago. If I recal it
> correctly the conclusion was that using the boost distribution functions would
> make QuantLib depend on some boost lib files, which wasn't regarded as
> desirable.
Dont understand this point. QuantLib already depends on boost.

>   Furthermore someone (I don't remember who) tested the QuantLib
> functions to be more efficient (less time-consuming) than the boost ones
Hard to believe. Do you have a standalone example where i am able to 
test the performance?
> The conclusion was to keep using current QL implementation and leave it to
> users to do the changes if they desired to use the boost ones instead
>
> Br,
> Nicolai
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] using special functions and statistical distributions from boost::math?

[Nicolai L. <ni...@ny...>]

Luigi Ballabio <luigi.ballabio <at> gmail.com> writes:

> 
> On Sun, 2011-10-02 at 09:13 +0800, R Yan wrote:
> > For example, in ql/math/distributions, many distributions are
> > implemented.
> >  
> > However, the same functionalities are already implemented in
> > boost::math.
> > 
> > Maybe it's a good idea to use the boost impl?
> 
> Yes, if we can do so without losing backward compatibility and
> precision.
> 
> Luigi
> 

I investigated the issue of using boost functions a while ago. If I recal it 
correctly the conclusion was that using the boost distribution functions would 
make QuantLib depend on some boost lib files, which wasn't regarded as 
desirable. Furthermore someone (I don't remember who) tested the QuantLib 
functions to be more efficient (less time-consuming) than the boost ones

The conclusion was to keep using current QL implementation and leave it to 
users to do the changes if they desired to use the boost ones instead

Br,
Nicolai

Re: [Quantlib-dev] erf and inverse erf

[Kim K. T. <kue...@vo...>]

Using another library will add complexity into the project which is then 
harder to maintain.

Since boost::math already provides these functions the existing 
functions should just be replaced.


Am 12.10.2011 13:49, schrieb Keith A. Lewis:
>
> Here is a link to high precision routines by T. Ooura for these 
> functions: 
> http://xllbms.codeplex.com/SourceControl/changeset/view/9909#143295.
>
> And some not so high precision routines: 
> http://xllbms.codeplex.com/SourceControl/changeset/view/9909#143299.
>
> kal
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
>
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] erf and inverse erf

[Keith A. L. <ka...@ka...>]

Here is a link to high precision routines by T. Ooura for these functions:
http://xllbms.codeplex.com/SourceControl/changeset/view/9909#143295.

 

And some not so high precision routines:
http://xllbms.codeplex.com/SourceControl/changeset/view/9909#143299.

 

kal

 

Re: [Quantlib-dev] Two files are broken in the trunk

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

On Oct 12, 2011, at 12:12 PM, Piter Dias wrote:

> Guys,
>
> The files below cannot be used under Windows due to “:” in the name.  
> Tortoise complains about it. May you change?
>
> QuantLib\ql\experimental\finitedifferences\fdhestonbarrierengine.hpp:
> QuantLib\ql\experimental\finitedifferences\fdhestonbarrierengine.cpp:

They've been removed.  It should work now.

Luigi

[Quantlib-dev] Two files are broken in the trunk

[Piter D. <pit...@pi...>]

Guys,

 

The files below cannot be used under Windows due to ":" in the name.
Tortoise complains about it. May you change?

 

QuantLib\ql\experimental\finitedifferences\fdhestonbarrierengine.hpp:

QuantLib\ql\experimental\finitedifferences\fdhestonbarrierengine.cpp:

Re: [Quantlib-dev] re "BS call option price lower than intrinsic value - bug #3417114"

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

> A simple solution is to use put-call parity to compute ITM option price from
> OTM option price.

I've always been in love with this approach and I haven't tackled it
just for lack of time (i.e. cronic lazyness). As a matter of fact it's
10 years now I keep advocating to calibrate models to OTM (vega
weighted) options, and I cannot understand why such a simple and
crucial point is always neglected.

This said what seems just a one-line patch might have so many far
fetched consequences that it has to be approached with care

> One thing that does seem desirable is to ensure the normal CDF is
> monotonically increasing, and bounded by [0,1]. This is not always true in
> the current implementation, e.g. N(10.41) < N(10.29). That's why I suggest
> using the library from boost::math. Now that using boost is probably good in
> its own right and we already have a thread for that, no need to talk more
> here.

The QuantLib implementation is Abramowitz-Stegun. I'm not aware of
better algorithms, but if they are available they could be adopted
provided that (a) they are computationally efficient and (b) play well
with Acklam's inverse CDF

Anyway my opinion when it comes to (inverse) CDF finance usage is that
robustness and efficiency are much more relevant than extreme tail
precision

ciao -- Nando

Re: [Quantlib-dev] Asset swap test error

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

> It doesn't look like anyone is addressing this failure in the tests.

fixed now on the trunk


On Mon, Oct 3, 2011 at 9:43 PM, Ferdinando Ametrano <na...@am...> wrote:
> Hi Matt
>
> glad you cannot live with error in the test-suite. Me too!
>
> I fixed an existing bug and introduced a new one: use the latest
> release in the meantime please.
> Take it for granted I'll get back to this issue as I'm working on
> related subjects... or I might leave the fix as exercise to you ;-)
>
>
> On Mon, Oct 3, 2011 at 5:45 PM, Luigi Ballabio <lui...@gm...> wrote:
>> On Mon, 2011-10-03 at 09:36 -0600, Matt Fair wrote:
>>> It doesn't look like anyone is addressing this failure in the tests.
>>
>> True.  Last week I reported it to the author, but he's busy with his
>> real work at the moment so it will be a few days before the test is
>> fixed.  I'm afraid it happens in the best families...
>>
>> Later,
>>        Luigi
>>
>>
>>> The test failure was introduced in revision 18001.  It alters the way
>>> the price values are computed and therefore doesn't pass the test that
>>> existed.  If the test is wrong, then fix it so the tests pass,
>>> otherwise the asset swap code needs to be fixed.
>>> I don't know too much about this code, so I don't know what is right
>>> or wrong, just know when the test that existed started to fail.
>>>
>>> Index: ql/instruments/assetswap.cpp
>>> ===================================================================
>>> --- ql/instruments/assetswap.cpp      (revision 18000)
>>> +++ ql/instruments/assetswap.cpp      (revision 18001)
>>> @@ -243,12 +243,12 @@
>>>              // backpayment on the floating leg
>>>              // (accounts for non-par redemption, if any)
>>>              Real backPayment = notional;
>>> -            shared_ptr<CashFlow> backPaymentCashFlow (new
>>> +            shared_ptr<CashFlow> backPaymentCashFlow(new
>>>                  SimpleCashFlow(backPayment, finalDate));
>>>              legs_[1].push_back(backPaymentCashFlow);
>>>          } else {
>>>              // final notional exchange
>>> -            shared_ptr<CashFlow> finalCashFlow (new
>>> +            shared_ptr<CashFlow> finalCashFlow(new
>>>                  SimpleCashFlow(notional, finalDate));
>>>              legs_[1].push_back(finalCashFlow);
>>>          }
>>> @@ -349,12 +349,12 @@
>>>                         "fair clean price not available for seasoned deal");
>>>              Real notional = bond_->notional(upfrontDate_);
>>>              if (parSwap_) {
>>> -                fairCleanPrice_ = bondCleanPrice_ -
>>> +                fairCleanPrice_ = bondCleanPrice_ - payer_[0] *
>>>                      NPV_*npvDateDiscount_/startDiscounts_[1]/(notional/100.0);
>>>              } else {
>>>                  Real accruedAmount = bond_->accruedAmount(upfrontDate_);
>>>                  Real dirtyPrice = bondCleanPrice_ + accruedAmount;
>>> -                Real fairDirtyPrice = - legNPV_[0]/legNPV_[1] * dirtyPrice;
>>> +                Real fairDirtyPrice = - payer_[0] *
>>> legNPV_[0]/legNPV_[1] * dirtyPrice;
>>>                  fairCleanPrice_ = fairDirtyPrice - accruedAmount;
>>>              }
>>>
>>> @@ -370,7 +370,7 @@
>>>              QL_REQUIRE(endDiscounts_[1]!=Null<DiscountFactor>(),
>>>                         "fair non par repayment not available for expired leg");
>>>              Real notional = bond_->notional(upfrontDate_);
>>> -            fairNonParRepayment_ = nonParRepayment_ -
>>> +            fairNonParRepayment_ = nonParRepayment_ + payer_[0] *
>>>                  NPV_*npvDateDiscount_/endDiscounts_[1]/(notional/100.0);
>>>              return fairNonParRepayment_;
>>>          }
>>>
>>>
>>> On Sat, Sep 17, 2011 at 3:49 PM, Matt Fair <mat...@gm...> wrote:
>>> > I noticed this in the tests:
>>> >
>>> > Testing consistency between fair price and fair spread...
>>> > assetswap.cpp(181): fatal error in
>>> > "QuantLib::detail::quantlib_test_case(&AssetSwapTest::testConsistency)":
>>> > par asset swap fair clean price doesn't zero the NPV:
>>> >   clean price:      95.0000
>>> >   fair clean price: 107.0805
>>> >   NPV:              24.1511
>>> >   tolerance:        0.0000
>>> >
>>> > This is the only test that fails.
>>> >
>>> > Matt
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>> --
>>
>> Present to inform, not to impress; if you inform, you will impress.
>> -- Fred Brooks
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>

Re: [Quantlib-dev] TreeLattice with different discounting and forwarding curves

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

On Tue, 2011-09-20 at 10:54 +0200, SK A wrote:
> By following your suggestion, we can not take into account the
> correlation between two curves, right? This is exactly what I want to
> have. That's why I constructed two trinomial trees and combined them
> as in G2++ tree  implementation. On this grid I want to have the
> freedom to forward and discount with different curves. Does it make
> sense? 

Yes, it does.  My mistake: I didn't get that you wanted to combine the
two trees, not keep them separate.

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] re "BS call option price lower than intrinsic value

[Keith A. L. <ka...@ka...>]

Regarding floating point comparison, Units in the Last Place is very
efficient and takes scale into account.
ftp://ftp.inria.fr/INRIA/publication/publi-pdf/RR/RR-5504.pdf is an
excellent reference.

 

In boost Math it is called float_distance. Here is a simple C
implementation:
http://xllfloat.codeplex.com/SourceControl/changeset/view/9774#135918. 

Re: [Quantlib-dev] re "BS call option price lower than intrinsic value - bug #3417114"

[R Y <fan...@gm...>]

Thanks for the detailed reply! Indeed this problem is more of theoretical
interest than practical usefulness, so let me wrap up...

At first I was trying to test the BSImpliedVol routine. To do that, I fixed
stdev, enumerated a few F and K, computed the call option price c and put
option price p, and fed that into the BSImpliedVol routine. Then I got a few
error messages from the newton solver complaining f(xmin)*f(xmax)>=0 for
xmin=0.0 and xmax=3.0 (hardcoded stdev bounds). Unsurprisingly the errors
only occur for deep in-the-money strikes where the numerical precision
becomes an issue. So I followed in the code to see what could be done to
mitigate the issue. Quite naturally I found if we can ensure BS(F,K,"call")
>= F-K, we won't get an error from BSImpliedVol. [However I don't mean it's
good or even useful practice to imply vol from deep ITM options; it's better
to compute the OTM option price of the same strike and imply vol from that
for numerical reason.]

Now for the requirements on the BS(F,K,sigma) function, it is really bit of
a design-goal issue. Of course it would be good if BS(F,K)>=F-K, but would
it be useful to tweak around the numerical tricks to achieve that strictly
while a clean implementation can achieve that to machine epsilon precision
readily? Well I guess the answer is yes, if someone has nothing better to
do... like me :-)

Your test case showing (double)1.35 - (double)0.39 < (double)0.96
demonstrates that testing floating equality is problematic. (Indeed, if the
left hand side cannot be exactly represented, then either < or > will hold.)
But that is a bit different from requiring BS(F,K)>=F-K because here both
sides are computed from the same input doubles.

A simple solution is to use put-call parity to compute ITM option price from
OTM option price. That will satisfy the boundary constraint but whether the
solution is desirable needs to be further investigated. (in particular
whether the function will be numerically smooth at K=F).

One thing that does seem desirable is to ensure the normal CDF is
monotonically increasing, and bounded by [0,1]. This is not always true in
the current implementation, e.g. N(10.41) < N(10.29). That's why I suggest
using the library from boost::math. Now that using boost is probably good in
its own right and we already have a thread for that, no need to talk more
here.

Finally, for your test case F = 1.98 and K = 0.74 that fails with my sketch
of code using boost::math, it's not surprising as the last statement c = F *
nd1 - K * nd2 in my code is not robust. That expression is equal to c =
(F-K)*nd2+F*(nd1-nd2). When nd1-nd2 is almost zero, and nd2<1, c may be less
than F-K. That's why I would recommend using the put-call parity for ITM
option if we really want to ensure the bound.

Best regards.


On Tue, Oct 4, 2011 at 12:00 AM, Luigi Ballabio <lui...@gm...>wrote:

> On Mon, 2011-10-03 at 20:31 +0800, R Y wrote:
> > The bug report was invalidated and closed too soon that I haven't been
> > able to put a comment on that one, so let me post it here...
> >
> > The bug was that the result of BS() formula, c=BS(F,K,sigma,"call")
> > for a call option doesn't satisfy c>=F-K for certain K<<F (i.e. deep
> > in the money strike).
>
> Yes.  The returned value was below the lower bound by about 1e-16, which
> suggested a floating-point issue.  Indeed, this turned out to be the
> case.
>
>
> > The issue is caused by floating point precision. That is true. But I
> > was hoping the dev team could dig a bit further for the cause but it
> > seems I have to do that myself and lay out the answer here...
> >
> > The root cause is that there is a flaw in the implementation of the
> > cumulative normal CDF function such that the function f(x) is not
> > monotonically increasing in x.
>
> I did dig for the cause.  The root cause is simply that tests for strict
> floating-point equality are ill-formed.  The same problem is triggered
> by the following program, which is similar to yours, has the same input
> data, but does not use a cdf at all:
>
> #include <iostream>
>
> int main() {
>        double F = 1.35;
>        double K = 0.39;
>        double diff = 0.96;
>        if (diff < F-K)
>        {
>                std::cerr << "Error: diff = " << diff << ", F-K = "
>                        << (F - K) << std::endl;
>        }
> }
>
> The above fails when compiled with VC++10 Express.  QuantLib is not even
> included.
>
>
> > I'm not an expert in numerical analysis so I don't know what's wrong
> > exactly with the implementation. But if we use the cdf function in
> > boost::math, we fix the problem.
>
> We do fix this particular test case, but not the problem.  The
> boost::math implementation passes the test with F = 1.35 and K = 0.39,
> but fails, for instance, for F = 1.98 and K = 0.74.  The implementation
> is different, so it results in different roundings and the error is
> triggered by different values; but the problem is not in either
> implementation, but underneath both of them.
>
> Unfortunately, the punchline is that floating-point comparisons must
> allow for rounding.  A simplistic way to do this would be to write the
> test like:
>
> if (c < (F - K) - epsilon)
>
> with epsilon depending on the byte size of the floating point numbers on
> one's machine.  A more sophisticated approach can be found by googling
> for "Knuth floating-point comparison".
>
> Later,
>        Luigi
>
>
> P.S.  I'm afraid I've rejected at least a couple of suggestions of yours
> in the past few days.  That's just an accident---please don't be
> discouraged by this and keep them coming.  I might seem a cranky old
> conservative, but I do appreciate the effort you're putting into this.
>
>
> >  A sketch of code below (assuming discount factor 1.0):
> >
> >   // Compute call value manually.
> >   double d1 = std::log(F/K)/(sigma*sqrt(T)) + 0.5*sigma*sqrt(T);
> >   double d2 = d1 - sigma*sqrt(T);
> >   boost::math::normal N;
> >   double nd1 = boost::math::cdf(N, d1);
> >   double nd2 = boost::math::cdf(N, d2);
> >   double c = F * nd1 - K * nd2;
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________ QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> --
>
> All generalizations are dangerous, even this one.
> -- Alexandre Dumas
>
>
>