quantlib-dev — Discussion of QuantLib development

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

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

On Sun, 2011-08-21 at 21:17 +0200, SK A wrote:
> I am planning to implement a lattice in QuantLib that can cope with
> different discounting and forwarding curves. [...] I think that the
> curicial point is to separate the rollback method on the payoffs (i.e.
> DiscretizedSwap and DiscretizedSwaption objects)   and on the
> DiscretizedBond object. In the first one  discounting will be done
> with Eonia and in the second one with Euribor (in order to calculate
> the Euribor forwards).
>  
> My plan is to implement a new class in numericalmethod.hpp, called
> TwoCurveTreeLattice that has two rollback and respectivley two
> partialRollback methods, calling two different stepback methods with
> corresponding discountings

It could become a mess very quickly.  How about passing two lattices to
the DiscretizedSwaption instead?  The swaption would roll itself and the
DiscretizedSwap on the Eonia lattice, and the DiscretizedBond on the
Euribor lattice.  You'll have to take care that the two lattices have
the same nodes, of course, so you'll have to use a model where they
don't depend on the underlying curve; but that's a problem you'd have
with the two-curve lattice too.  This way, you wouldn't have to modify
the Lattice class.

Luigi


-- 

Quote me as saying I was misquoted. 
-- Groucho Marx 

Re: [Quantlib-dev] Moving stable parts of ql/experimental/finitedifferences to the main tree

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

Klaus,
	apologies for the delay.  Your proposal is ok for me.  May you do it on
a branch so I can fix the VC++ and Dev-C++ projects before merging it
back to the trunk?

Luigi


On Sat, 2011-08-20 at 17:07 +0200, Klaus Spanderen wrote:
> Hi
> 
> I'd like to move the older and stable parts of the multi-dimensional finite 
> difference framework and the corresponding pricing engines in 
> ql/experimental/finitedifferences to the main tree folder. In particular I'd 
> like to move the following files as outlined in the attached file.
> 
> Any objectives or thoughts about this?
> 
> regards
>  Klaus
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
> user administration capabilities and model configuration. Take 
> the hassle out of deploying and managing Subversion and the 
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________ QuantLib-dev mailing list Qua...@li... https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 

Don't let school get in the way of your education. 
-- Mark Twain 

[Quantlib-dev] [ quantlib-Bugs-3407976 ] wrong discounting in BlackSwaptionEngine::calculate()

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

Bugs item #3407976, was opened at 2011-09-12 10:08
Message generated for change (Tracker Item Submitted) made by skaquant
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3407976&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: Sarp Kaya Acar (skaquant)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong discounting in BlackSwaptionEngine::calculate() 

Initial Comment:
In BlackSwapEngine::calculate() the variable atmForward is calculated by using the forwardingTermStructure as the DiscountingSwapEngine is initialized by it. But the discounting swap  should be intialised by the discoutCurve_ so that the fair swap rate is calculated in the \"two curve world\".

More precisely, the block 
 
// using the forecasting curve
swap.setPricingEngine(boost::shared_ptr<PricingEngine>(
new  DiscountingSwapEngine(swap.iborIndex()->forwardingTermStructure(), false))); 

should be changed with

// using the discounting curve
swap.setPricingEngine(boost::shared_ptr<PricingEngine>(
new DiscountingSwapEngine(discountCurve_, false))); 
Regards,

Sarp Kaya



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

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

[Quantlib-dev] [ quantlib-Bugs-3404882 ] Problem with Act/Act (ISDA) convention

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

Bugs item #3404882, was opened at 2011-09-06 14:03
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3404882&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: Lorenzo Pitotti (lpitotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with Act/Act (ISDA) convention

Initial Comment:
The implementation Act/Act (ISDA) day count convention seems to be wrong as it calculates the number of days w.r.t 1st January rather than 31st December. (cf. http://www.isda.org/c_and_a/pdf/ACT-ACT-ISDA-1999.pdf)

Specifically we should replace (actualactual.cpp, Ln 156):
        sum += dayCount(d1, Date(1,January,y1+1))/dib1;
        sum += dayCount(Date(1,January,y2),d2)/dib2;
with
	sum += dayCount(d1, Date(31,December,y1))/dib1;
        sum += dayCount(Date(31,December,y2-1),d2)/dib2;

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2011-09-08 15:35

Message:
dayCount(d1,d2) returns d2-d1, so if you want the number of days left in
the year you'll have to use d2=1st January as in the code you quote.  The
current implementation reproduces correctly all examples in the ISDA
document you link; here is the output of a Python session on my box:

>>> from QuantLib import *
>>> isda = ActualActual(ActualActual.ISDA)

example (a)

>>> 10000 * 0.1 * isda.yearFraction(Date(1,11,2003),Date(1,5,2004))
497.72438056740776

example (b)

>>> 10000 * 0.1 * isda.yearFraction(Date(1,2,1999),Date(1,7,1999))
410.958904109589
>>> 10000 * 0.1 * isda.yearFraction(Date(1,7,1999),Date(1,7,2000))
1001.3773486039374

example (c)

>>> 10000 * 0.1 * isda.yearFraction(Date(15,8,2002),Date(15,7,2003))
915.068493150685
>>> 10000 * 0.1 * isda.yearFraction(Date(15,7,2003),Date(15,1,2004))
504.0047907777528

example (d)

>>> 10000 * 0.1 * isda.yearFraction(Date(30,7,1999),Date(30,1,2000))
503.89250692417096
>>> 10000 * 0.1 * isda.yearFraction(Date(30,1,2000),Date(30,6,2000))
415.30054644808746

example (e)

>>> 10000 * 0.1 * isda.yearFraction(Date(30,11,1999),Date(30,4,2000))
415.54008533572875


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

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

Re: [Quantlib-dev] money comparison

[Matt F. <mat...@gm...>]

I guess the real question is do you want to be able to track fractions of
the currency (i.e. cents)?  If the currency goes to 2 decimal places, do you
want to track to 6 or larger places?  Does that make sense in any situation?

Should you floor (i.e. round down) anything past the decimal place of the
currency?  If you want to do that, then you could store everything in an
integer.  So for example  $102.38 would be stored as 10238.  That would
eliminate any rounding issues and you could do a straight == of the value to
do the comparison.
I don't think you ever want to round up, always down.  What are other
people's thoughts on this?
Matt


On Tue, Sep 6, 2011 at 5:01 AM, Luigi Ballabio <lui...@gm...>wrote:

> On Mon, 2011-09-05 at 09:31 -0600, Matt Fair wrote:
> > Luigi,
> > I understand that you can call close_enough manually if you need to,
> > but from an object oriented standpoint it doesn't make sense.  Is
> > there a reason why you have both?
>
> It was to have the same behavior as doubles, but I see your point.
> That's an implementation detail, not the behavior expected in the domain
> (actually, Money shouldn't use a floating-point number at all---we
> should store an integer number of cents---but that's for another time.)
> I wonder if one should go all the way and compare after rounding?
>
> Thoughts?
>
> Luigi
>
>
> --
>
> Better to have an approximate answer to the right question than a
> precise answer to the wrong question.
> -- John Tukey as quoted by John Chambers
>
>
>

[Quantlib-dev] [ quantlib-Bugs-3404882 ] Problem with Act/Act (ISDA) convention

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

Bugs item #3404882, was opened at 2011-09-06 13:03
Message generated for change (Tracker Item Submitted) made by lpitotti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3404882&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: Lorenzo Pitotti (lpitotti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with Act/Act (ISDA) convention

Initial Comment:
The implementation Act/Act (ISDA) day count convention seems to be wrong as it calculates the number of days w.r.t 1st January rather than 31st December. (cf. http://www.isda.org/c_and_a/pdf/ACT-ACT-ISDA-1999.pdf)

Specifically we should replace (actualactual.cpp, Ln 156):
        sum += dayCount(d1, Date(1,January,y1+1))/dib1;
        sum += dayCount(Date(1,January,y2),d2)/dib2;
with
	sum += dayCount(d1, Date(31,December,y1))/dib1;
        sum += dayCount(Date(31,December,y2-1),d2)/dib2;

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

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

Re: [Quantlib-dev] money comparison

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

On Mon, 2011-09-05 at 09:31 -0600, Matt Fair wrote:
> Luigi,
> I understand that you can call close_enough manually if you need to,
> but from an object oriented standpoint it doesn't make sense.  Is
> there a reason why you have both?

It was to have the same behavior as doubles, but I see your point.
That's an implementation detail, not the behavior expected in the domain
(actually, Money shouldn't use a floating-point number at all---we
should store an integer number of cents---but that's for another time.)
I wonder if one should go all the way and compare after rounding?

Thoughts?

Luigi


-- 

Better to have an approximate answer to the right question than a 
precise answer to the wrong question. 
-- John Tukey as quoted by John Chambers 

Re: [Quantlib-dev] money comparison

[Matt F. <mat...@gm...>]

Luigi,
I understand that you can call close_enough manually if you need to, but
from an object oriented standpoint it doesn't make sense.  Is there a reason
why you have both?  The only time you would get something that is equal is
if you were to set the same constant value to two Money objects.  So if I
have two piles of cash, one was define explicitly and the other was through
mathematical operations (i.e. interest), if they are the same amount of
money and I use ==, it should return true.  But that is not the behavior, ==
will rarely be true because of how double precision values are stored.  So
comparing my two stacks of money that should be both $100 that should be
equal but don't, and then for me to get the right answer, I need to go
beyond the basic understanding of the object API and understand, understand
it's real representation and and why there is different behaviors for
different methods that should be the same to get the right answer because
the equality operator isn't right.  Seems like way too much knowledge I need
to know in order to use the object properly.
Matt

On Mon, Sep 5, 2011 at 8:33 AM, Luigi Ballabio <lui...@gm...>wrote:

>
> Matt,
>        both behaviors are provided on purpose, same as for floats.  One can
> use m1 == m2 for exact comparison, and close_enough for fuzzy comparison
> including rounding.
>
> Regards,
>        Luigi
>
>
> On Fri, 2011-09-02 at 16:36 -0600, Matt Fair wrote:
> > I noticed that there are already functions that do exactly what I
> > described. Here is a modification to money.cpp that I think would make
> > sense:
> >
> > Index: money.cpp
> > ===================================================================
> > --- money.cpp    (revision 17937)
> > +++ money.cpp    (working copy)
> >
> > @@ -103,17 +105,7 @@
> >
> >      bool operator==(const Money& m1, const Money& m2) {
> >          if (m1.currency() == m2.currency()) {
> > -            return m1.value() == m2.value();
> > -        } else if (Money::conversionType ==
> > Money::BaseCurrencyConversion) {
> > -            Money tmp1 = m1;
> > -            convertToBase(tmp1);
> > -            Money tmp2 = m2;
> > -            convertToBase(tmp2);
> > -            return tmp1 == tmp2;
> > -        } else if (Money::conversionType ==
> > Money::AutomatedConversion) {
> > -            Money tmp = m2;
> > -            convertTo(tmp, m1.currency());
> > -            return m1 == tmp;
> > +                        return close_enough(m1, m2);
> >          } else {
> >              QL_FAIL("currency mismatch and no conversion specified");
> >          }
> >
> > Matt
> >
> >
> > On Fri, Sep 2, 2011 at 2:22 PM, Matt Fair <mat...@gm...> wrote:
> >         I'm wondering if in money.cpp for bool operator==(const Money&
> >         m1, const Money& m2), the comparison between two double values
> >         should not be a straight ==.  But instead there should be a
> >         is_equal function with an epselon to compare the two values.
> >         Because due to how the system stores numbers, double values
> >         can be shifted slightly when operations are performed on them.
> >         I'm having problems comparing two money values because of
> >         several math operations, they aren't quite the same.
> >
> >         Given:
> >         bool is_equal(double d1, double d2)
> >         {
> >                 if(abs(d1-d2)<epsilon)
> >                         return true;
> >                 return false;
> >         }
> >
> >         Where epsilon could be defined by the currency precision.
> >
> >         I would suggest:
> >         return m1.value() == m2.value();
> >
> >         be changed to:
> >         return is_equal(m1.value(), m2.value());
> >
> >         See the following links for more info:
> >         http://www.cplusplus.com/forum/articles/3827/
> >
> http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
> >
> >         Thanks,
> >         Matt
> >
> >
> ------------------------------------------------------------------------------
> > Special Offer -- Download ArcSight Logger for FREE!
> > Finally, a world-class log management solution at an even better
> > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > download Logger. Secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsisghtdev2dev
> > _______________________________________________ QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> --
>
> Steinbach's Guideline for Systems Programming:
> Never test for an error condition you don't know how to handle.
>
>
>

[Quantlib-dev] [ quantlib-Bugs-3402104 ] Act/365 Convention Wrong

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

Bugs item #3402104, was opened at 2011-09-01 09:08
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3402104&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: D W (ariakus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Act/365 Convention Wrong

Initial Comment:
As per the 2006 ISDA docs, Act/365 should be calculated on a 365 day count, even if it is a leap year.  qlDayCounterYearFraction calculates Act/365 as the proportion of days in year vs the number of days in that year (ie. uses 366 in leap years) - this should be used for Act/Act not Act/365.
Example: start date 29-Aug-2011, end date 29-Aug-2011.  It returns 1.00093569877985 = 125/365 + 241/366
The correct answer is 1.00273972602740 = (125+241)/365



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

>Comment By: Luigi Ballabio (lballabio)
Date: 2011-09-05 16:40

Message:
The behavior you refer to is implemented as the "Act/365 (Fixed)"
convention.  I'm not the one that chose the tags, but from what I'm told,
Act/365 without the "fixed" part is actually (no pun intended) an alias for
actual/actual.


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

Comment By: D W (ariakus)
Date: 2011-09-01 09:10

Message:
correction: start date 29-Aug-2011, end date 29-Aug-2012

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

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

Re: [Quantlib-dev] money comparison

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

Matt,
	both behaviors are provided on purpose, same as for floats.  One can
use m1 == m2 for exact comparison, and close_enough for fuzzy comparison
including rounding.

Regards,
	Luigi


On Fri, 2011-09-02 at 16:36 -0600, Matt Fair wrote:
> I noticed that there are already functions that do exactly what I
> described. Here is a modification to money.cpp that I think would make
> sense:
> 
> Index: money.cpp
> ===================================================================
> --- money.cpp    (revision 17937)
> +++ money.cpp    (working copy)
>  
> @@ -103,17 +105,7 @@
>  
>      bool operator==(const Money& m1, const Money& m2) {
>          if (m1.currency() == m2.currency()) {
> -            return m1.value() == m2.value();
> -        } else if (Money::conversionType ==
> Money::BaseCurrencyConversion) {
> -            Money tmp1 = m1;
> -            convertToBase(tmp1);
> -            Money tmp2 = m2;
> -            convertToBase(tmp2);
> -            return tmp1 == tmp2;
> -        } else if (Money::conversionType ==
> Money::AutomatedConversion) {
> -            Money tmp = m2;
> -            convertTo(tmp, m1.currency());
> -            return m1 == tmp;
> +                        return close_enough(m1, m2);
>          } else {
>              QL_FAIL("currency mismatch and no conversion specified");
>          }
> 
> Matt
> 
> 
> On Fri, Sep 2, 2011 at 2:22 PM, Matt Fair <mat...@gm...> wrote:
>         I'm wondering if in money.cpp for bool operator==(const Money&
>         m1, const Money& m2), the comparison between two double values
>         should not be a straight ==.  But instead there should be a
>         is_equal function with an epselon to compare the two values.
>         Because due to how the system stores numbers, double values
>         can be shifted slightly when operations are performed on them.
>         I'm having problems comparing two money values because of
>         several math operations, they aren't quite the same.
>         
>         Given:
>         bool is_equal(double d1, double d2) 
>         {
>                 if(abs(d1-d2)<epsilon)
>                         return true;
>                 return false;
>         }
>         
>         Where epsilon could be defined by the currency precision.
>         
>         I would suggest:
>         return m1.value() == m2.value();
>         
>         be changed to:
>         return is_equal(m1.value(), m2.value());
>         
>         See the following links for more info:
>         http://www.cplusplus.com/forum/articles/3827/
>         http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
>         
>         Thanks,
>         Matt
> 
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better 
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________ QuantLib-dev mailing list Qua...@li... https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 

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

Re: [Quantlib-dev] quantlib-test-suite was failed

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

It might be a combination of dates at the end of the month that  
changes the values from those expected (that is, a problem on our  
side, not yours).
Does it run correctly today?

Luigi


On Aug 31, 2011, at 5:39 AM, taesaza wrote:

>
> Hi all,
>
> I am using QuantLib 1.1-2 and Boost 1.46.1 with my fedora 14 server
> After building QuantLib(make and sudo make install), I can't find  
> error in
> build log.
> But when i trying to /test-suite/quantlib-test-suite, I have 3  
> failure....
> this is the log
>
> Running 467 test cases...
> unknown location(0): fatal error in
> "QuantLib 
> ::detail 
> ::quantlib_test_case 
> (&MarketModelSmmCapletAlphaCalibrationTest::testFunction)":
> std::ex
> ception: last caplet vol (0.1340376439125532) must be equal to last  
> swaption
> vol (0.1340657951109429); discrepancy is 2.81511983896976e-05
> utilities.hpp(78): last checkpoint
> unknown location(0): fatal error in
> "QuantLib 
> ::detail 
> ::quantlib_test_case 
> (&MarketModelSmmCapletCalibrationTest::testFunction)":
> std::excepti
> on: last caplet vol (0.1340376439125532) must be equal to last  
> swaption vol
> (0.1340657951109429); discrepancy is 2.81511983896976e-05
> utilities.hpp(78): last checkpoint
> unknown location(0): fatal error in
> "QuantLib 
> ::detail 
> ::quantlib_test_case 
> (&MarketModelSmmCapletHomoCalibrationTest::testFunction)":
> std::exc
> eption: last caplet vol (0.1340376439125532) must be equal to last  
> swaption
> vol (0.1340657951109429); discrepancy is 2.81511983896976e-05
> utilities.hpp(78): last checkpoint
>
> Tests completed in 24 m 27 s
>
>
> *** 3 failures detected in test suite "Master Test Suite"
>
>
> when i trying to /test-suite/quantlib-benchmark, therer is no error.
> I can't find what is the problem.....
>
> Please tell me some idea.....
>
> thanks,
> Bob
> -- 
> View this message in context: http://old.nabble.com/quantlib-test-suite-was-failed-tp32369059p32369059.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] money comparison

[Matt F. <mat...@gm...>]

I noticed that there are already functions that do exactly what I described.
Here is a modification to money.cpp that I think would make sense:

Index: money.cpp
===================================================================
--- money.cpp    (revision 17937)
+++ money.cpp    (working copy)

@@ -103,17 +105,7 @@

     bool operator==(const Money& m1, const Money& m2) {
         if (m1.currency() == m2.currency()) {
-            return m1.value() == m2.value();
-        } else if (Money::conversionType == Money::BaseCurrencyConversion)
{
-            Money tmp1 = m1;
-            convertToBase(tmp1);
-            Money tmp2 = m2;
-            convertToBase(tmp2);
-            return tmp1 == tmp2;
-        } else if (Money::conversionType == Money::AutomatedConversion) {
-            Money tmp = m2;
-            convertTo(tmp, m1.currency());
-            return m1 == tmp;
+                        return close_enough(m1, m2);
         } else {
             QL_FAIL("currency mismatch and no conversion specified");
         }

Matt


On Fri, Sep 2, 2011 at 2:22 PM, Matt Fair <mat...@gm...> wrote:

> I'm wondering if in money.cpp for bool operator==(const Money& m1, const
> Money& m2), the comparison between two double values should not be a
> straight ==.  But instead there should be a is_equal function with an
> epselon to compare the two values.  Because due to how the system stores
> numbers, double values can be shifted slightly when operations are performed
> on them.  I'm having problems comparing two money values because of several
> math operations, they aren't quite the same.
>
> Given:
>
> bool is_equal(double d1, double d2)
> {
>         if(abs(d1-d2)<epsilon)
>                 return true;
>         return false;
> }
>
>
> Where epsilon could be defined by the currency precision.
>
> I would suggest:
> return m1.value() == m2.value();
>
> be changed to:
> return is_equal(m1.value(), m2.value());
>
> See the following links for more info:
> http://www.cplusplus.com/forum/articles/3827/
> http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
>
> Thanks,
> Matt
>

[Quantlib-dev] money comparison

[Matt F. <mat...@gm...>]

I'm wondering if in money.cpp for bool operator==(const Money& m1, const
Money& m2), the comparison between two double values should not be a
straight ==.  But instead there should be a is_equal function with an
epselon to compare the two values.  Because due to how the system stores
numbers, double values can be shifted slightly when operations are performed
on them.  I'm having problems comparing two money values because of several
math operations, they aren't quite the same.

Given:

bool is_equal(double d1, double d2)
{
        if(abs(d1-d2)<epsilon)
                return true;
        return false;
}


Where epsilon could be defined by the currency precision.

I would suggest:
return m1.value() == m2.value();

be changed to:
return is_equal(m1.value(), m2.value());

See the following links for more info:
http://www.cplusplus.com/forum/articles/3827/
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

Thanks,
Matt

[Quantlib-dev] [ quantlib-Bugs-3402104 ] Act/365 Convention Wrong

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

Bugs item #3402104, was opened at 2011-09-01 08:08
Message generated for change (Comment added) made by ariakus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3402104&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: D W (ariakus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Act/365 Convention Wrong

Initial Comment:
As per the 2006 ISDA docs, Act/365 should be calculated on a 365 day count, even if it is a leap year.  qlDayCounterYearFraction calculates Act/365 as the proportion of days in year vs the number of days in that year (ie. uses 366 in leap years) - this should be used for Act/Act not Act/365.
Example: start date 29-Aug-2011, end date 29-Aug-2011.  It returns 1.00093569877985 = 125/365 + 241/366
The correct answer is 1.00273972602740 = (125+241)/365



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

>Comment By: D W (ariakus)
Date: 2011-09-01 08:10

Message:
correction: start date 29-Aug-2011, end date 29-Aug-2012

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

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

[Quantlib-dev] [ quantlib-Bugs-3402104 ] Act/365 Convention Wrong

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

Bugs item #3402104, was opened at 2011-09-01 08:08
Message generated for change (Tracker Item Submitted) made by ariakus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3402104&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: D W (ariakus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Act/365 Convention Wrong

Initial Comment:
As per the 2006 ISDA docs, Act/365 should be calculated on a 365 day count, even if it is a leap year.  qlDayCounterYearFraction calculates Act/365 as the proportion of days in year vs the number of days in that year (ie. uses 366 in leap years) - this should be used for Act/Act not Act/365.
Example: start date 29-Aug-2011, end date 29-Aug-2011.  It returns 1.00093569877985 = 125/365 + 241/366
The correct answer is 1.00273972602740 = (125+241)/365



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

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

[Quantlib-dev] quantlib-test-suite was failed

[taesaza <tae...@gm...>]

Hi all,

I am using QuantLib 1.1-2 and Boost 1.46.1 with my fedora 14 server
After building QuantLib(make and sudo make install), I can't find error in
build log.
But when i trying to /test-suite/quantlib-test-suite, I have 3 failure....
this is the log 

Running 467 test cases...
unknown location(0): fatal error in
"QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletAlphaCalibrationTest::testFunction)":
std::ex                                                                      
ception: last caplet vol (0.1340376439125532) must be equal to last swaption
vol (0.1340657951109429); discrepancy is 2.81511983896976e-05
utilities.hpp(78): last checkpoint
unknown location(0): fatal error in
"QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletCalibrationTest::testFunction)":
std::excepti                                                                      
on: last caplet vol (0.1340376439125532) must be equal to last swaption vol
(0.1340657951109429); discrepancy is 2.81511983896976e-05
utilities.hpp(78): last checkpoint
unknown location(0): fatal error in
"QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletHomoCalibrationTest::testFunction)":
std::exc                                                                      
eption: last caplet vol (0.1340376439125532) must be equal to last swaption
vol (0.1340657951109429); discrepancy is 2.81511983896976e-05
utilities.hpp(78): last checkpoint

Tests completed in 24 m 27 s


*** 3 failures detected in test suite "Master Test Suite"


when i trying to /test-suite/quantlib-benchmark, therer is no error.
I can't find what is the problem.....

Please tell me some idea..... 

thanks,
Bob
-- 
View this message in context: http://old.nabble.com/quantlib-test-suite-was-failed-tp32369059p32369059.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Bermudan LLM

[Daniel C. <dan...@gm...>]

2011/8/25 Kakhkhor Abdijalilov <kab...@gm...>

> Longstaff-Schwartz method doesn't need and shouldn't use full SVD.
> LAPACK has thin version of SVD, but Eigen doesn't.
>
> One possible option is to link to standard CBLAS/LAPACK interface. MKL
> 10.3 introduced C-API to LAPACK. The same interface can be built for
> ATLAS, ACML or any other implementation that provides CBLAS/LAPACK
> interface. A high level abstraction layer would separate users from
> low level implementation. This way users would be able to link to
> their favorite CBLAS/LAPACK implementation.
>
>
It has a lot of sense. User will be able to use well optimized CBLAS/LAPACK
(like MKL, Goto or GPU based), and by the way QuantLib binary will be much
smaller.

regards,
daniel



>  Regards,
> Kakhkhor Abdijalilov.
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Bermudan LLM

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

Longstaff-Schwartz method doesn't need and shouldn't use full SVD.
LAPACK has thin version of SVD, but Eigen doesn't.

One possible option is to link to standard CBLAS/LAPACK interface. MKL
10.3 introduced C-API to LAPACK. The same interface can be built for
ATLAS, ACML or any other implementation that provides CBLAS/LAPACK
interface. A high level abstraction layer would separate users from
low level implementation. This way users would be able to link to
their favorite CBLAS/LAPACK implementation.

Regards,
Kakhkhor Abdijalilov.

Re: [Quantlib-dev] Bermudan LLM

[Dirk E. <ed...@de...>]

On 24 August 2011 at 17:29, Daniel Cegiełka wrote:
| 
| 2011/8/24 Dirk Eddelbuettel <ed...@de...>
| 
| 
|     On 24 August 2011 at 16:17, Ferdinando Ametrano wrote:
|     | Hi Kakhkhor
|     |
|     | I apologize, I completely misinterpreted your question, my fault.
|     |
|     | As you wrote ATLAS would be problematic because in Windows it is
|     | available only if using cygwin, as far as I know. Besides it is plain
|     | C, isn't it?
| 
|     Atlas is one of several accelerated implementation of the BLAS.  It can
|     certainly be compiled with different Windows toolchains; there is eg a
|     binary
|     you can download for R which was built with MinGW (ie very much not Cygwin)
|     as R on Windows requires the MinGW toolchain.
| 
|     Commercial software (Matlab comes to mind) often bundles its own
|     accelerated
|     BLAS; Atlas happens to have the most liberal license (but Goto is now
|     'Open'
|     too as the original author moved on).
| 
| 
| Goto is probably one of the best implementations of BALS. Unfortunately, it is
| no longer being actively developed by Kazushige Goto. I give the address where
| you can find fresh updates.
| 
| http://prs.ism.ac.jp/~nakama/SurviveGotoBLAS2/

That are 'just' maintenance updates by Ei-Ji Nakama. The new and more
ambitious project I was referring to is on github:

   https://github.com/xianyi/OpenBLAS

but I have not tried it.

Dirk

| 
| 
|     | What about using uBLAS, the C++ boost implementation?
| 
|     AFAICT it is a pain to use, and the numerics wrapper for actual linear
|     algrebra was once again being rewritten when I last checked. It also falls
|     back to using a BLAS implementations.  FWIW I never managed to even cook
|     up a
|     simple linear regression 'from first principles' (eg using a SVD) with
|     uBlas.
| 
|     An alternative could be provided by Eigen (http://eigen.tuxfamily.org)
|     which
|     is very clever, very fast, very templated C++ --- and does not use BLAS!
|     But
|     it would add another build dependency which is a clear downside.
| 
| 
| I also thought about Eigen... but like you wrote, it means
| another dependency.
| 
| Best regards,
| daniel
| 
| 
|  
| 
| 
|     Another somewhat lighter alternative is Armadillo (http://arma.sf.net).
|     Also
|     templated, can use BLAS and a little simpler than Eigen. I quite like it --
|     and have written an package 'RcppArmadillo' that makes it a snap to use
|     this
|     from R, leveraging our Rcpp package also used to tie [parts of] QuantLib to
|     R
|     via RQuantLib.
| 
|     [ From all that, I have a number of competing 'FastLm' implementations of
|     linear model fits (ie. ordinary least squares) using Armadillo, Eigen and
|     GSL.  Armadillo does fine, Eigen does better and GSL is slowest. My blog
|     had
|     a few posts on that. ]
| 
|     | As you understand moving to uBLAS would be a major change anyway and
|     | to do it in a backward compatible way (i.e. not dropping support for
|     | QuantLib::Matrix, QuantLib::Array, etc.) would be even more
|     | challenging, so Luigi opinion on this will rule.
|     | Unfortunately as he gets older he's more and more conservative ;-)
|     |
|     | I for one would support a transition to uBLAS and removing all the
|     | QuantLib code that could be replaced by boost (e.g. math and stat
|     | functions), maybe on a QuantLib 2.x branch which would be not backward
|     | compatible with the 1.x branch
| 
|     That is probably a good design decision in the medium term but you may want
|     to really check viability of some of the required operations first.
| 
|     Hth,  Dirk
| 
|     | ciao -- Nando
|     |
|     | On Wed, Aug 24, 2011 at 12:37 AM, Kakhkhor Abdijalilov
|     | <kab...@gm...> wrote:
|     | > Longstaff-Schwartz method for Bermudan LLM requires OLS for every
|     | > early exercise opportunity, not just once.
|     | > I checked "Numerical recipes", Demel's and Golub's books and all
|     | > recommend not to use normal equations to solve OLS. Equity version of
|     | > Longstaff-Schwartz in QuantLib uses SVD too.
|     | >
|     | > The cost of SVD scales as SAMPLES*FACTORS^3, but the cost of path
|     | > generation scales as SAMPLES*FACTORS^2. SVD doesn't scale well as more
|     | > CPU cores are used, but path generation should scale almost perfectly.
|     | >
|     | > Regards,
|     | > Kakhkhor Abdijalilov.
|     | >
|     | >
|     ------------------------------------------------------------------------------
|     | > EMC VNX: the world's simplest storage, starting under $10K
|     | > The only unified storage solution that offers unified management
|     | > Up to 160% more powerful than alternatives and 25% more efficient.
|     | > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
|     | > _______________________________________________
|     | > QuantLib-dev mailing list
|     | > Qua...@li...
|     | > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
|     | >
|     |
|     |
|     ------------------------------------------------------------------------------
|     | EMC VNX: the world's simplest storage, starting under $10K
|     | The only unified storage solution that offers unified management
|     | Up to 160% more powerful than alternatives and 25% more efficient.
|     | Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
|     | _______________________________________________
|     | QuantLib-dev mailing list
|     | Qua...@li...
|     | https://lists.sourceforge.net/lists/listinfo/quantlib-dev
| 
|     --
|     Two new Rcpp master classes for R and C++ integration scheduled for
|     New York (Sep 24) and San Francisco (Oct 8), more details are at
|     http://dirk.eddelbuettel.com/blog/2011/08/04#
|     rcpp_classes_2011-09_and_2011-10
|     http://www.revolutionanalytics.com/products/training/public/
|     rcpp-master-class.php
| 
|     ------------------------------------------------------------------------------
|     EMC VNX: the world's simplest storage, starting under $10K
|     The only unified storage solution that offers unified management
|     Up to 160% more powerful than alternatives and 25% more efficient.
|     Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
|     _______________________________________________
|     QuantLib-dev mailing list
|     Qua...@li...
|     https://lists.sourceforge.net/lists/listinfo/quantlib-dev
| 
| 

-- 
Two new Rcpp master classes for R and C++ integration scheduled for 
New York (Sep 24) and San Francisco (Oct 8), more details are at
http://dirk.eddelbuettel.com/blog/2011/08/04#rcpp_classes_2011-09_and_2011-10
http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php

Re: [Quantlib-dev] Bermudan LLM

[Daniel C. <dan...@gm...>]

2011/8/24 Dirk Eddelbuettel <ed...@de...>

>
> On 24 August 2011 at 16:17, Ferdinando Ametrano wrote:
> | Hi Kakhkhor
> |
> | I apologize, I completely misinterpreted your question, my fault.
> |
> | As you wrote ATLAS would be problematic because in Windows it is
> | available only if using cygwin, as far as I know. Besides it is plain
> | C, isn't it?
>
> Atlas is one of several accelerated implementation of the BLAS.  It can
> certainly be compiled with different Windows toolchains; there is eg a
> binary
> you can download for R which was built with MinGW (ie very much not Cygwin)
> as R on Windows requires the MinGW toolchain.
>
> Commercial software (Matlab comes to mind) often bundles its own
> accelerated
> BLAS; Atlas happens to have the most liberal license (but Goto is now
> 'Open'
> too as the original author moved on).
>

Goto is probably one of the best implementations of BALS. Unfortunately, it
is no longer being actively developed by Kazushige Goto. I give the address
where you can find fresh updates.

http://prs.ism.ac.jp/~nakama/SurviveGotoBLAS2/



>
> | What about using uBLAS, the C++ boost implementation?
>
> AFAICT it is a pain to use, and the numerics wrapper for actual linear
> algrebra was once again being rewritten when I last checked. It also falls
> back to using a BLAS implementations.  FWIW I never managed to even cook up
> a
> simple linear regression 'from first principles' (eg using a SVD) with
> uBlas.
>
> An alternative could be provided by Eigen (http://eigen.tuxfamily.org)
> which
> is very clever, very fast, very templated C++ --- and does not use BLAS!
> But
> it would add another build dependency which is a clear downside.
>

I also thought about Eigen... but like you wrote, it means
another dependency.

Best regards,
daniel




>
> Another somewhat lighter alternative is Armadillo (http://arma.sf.net).
> Also
> templated, can use BLAS and a little simpler than Eigen. I quite like it --
> and have written an package 'RcppArmadillo' that makes it a snap to use
> this
> from R, leveraging our Rcpp package also used to tie [parts of] QuantLib to
> R
> via RQuantLib.
>
> [ From all that, I have a number of competing 'FastLm' implementations of
> linear model fits (ie. ordinary least squares) using Armadillo, Eigen and
> GSL.  Armadillo does fine, Eigen does better and GSL is slowest. My blog
> had
> a few posts on that. ]
>
> | As you understand moving to uBLAS would be a major change anyway and
> | to do it in a backward compatible way (i.e. not dropping support for
> | QuantLib::Matrix, QuantLib::Array, etc.) would be even more
> | challenging, so Luigi opinion on this will rule.
> | Unfortunately as he gets older he's more and more conservative ;-)
> |
> | I for one would support a transition to uBLAS and removing all the
> | QuantLib code that could be replaced by boost (e.g. math and stat
> | functions), maybe on a QuantLib 2.x branch which would be not backward
> | compatible with the 1.x branch
>
> That is probably a good design decision in the medium term but you may want
> to really check viability of some of the required operations first.
>
> Hth,  Dirk
>
> | ciao -- Nando
> |
> | On Wed, Aug 24, 2011 at 12:37 AM, Kakhkhor Abdijalilov
> | <kab...@gm...> wrote:
> | > Longstaff-Schwartz method for Bermudan LLM requires OLS for every
> | > early exercise opportunity, not just once.
> | > I checked "Numerical recipes", Demel's and Golub's books and all
> | > recommend not to use normal equations to solve OLS. Equity version of
> | > Longstaff-Schwartz in QuantLib uses SVD too.
> | >
> | > The cost of SVD scales as SAMPLES*FACTORS^3, but the cost of path
> | > generation scales as SAMPLES*FACTORS^2. SVD doesn't scale well as more
> | > CPU cores are used, but path generation should scale almost perfectly.
> | >
> | > Regards,
> | > Kakhkhor Abdijalilov.
> | >
> | >
> ------------------------------------------------------------------------------
> | > EMC VNX: the world's simplest storage, starting under $10K
> | > The only unified storage solution that offers unified management
> | > Up to 160% more powerful than alternatives and 25% more efficient.
> | > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> | > _______________________________________________
> | > QuantLib-dev mailing list
> | > Qua...@li...
> | > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> | >
> |
> |
> ------------------------------------------------------------------------------
> | EMC VNX: the world's simplest storage, starting under $10K
> | The only unified storage solution that offers unified management
> | Up to 160% more powerful than alternatives and 25% more efficient.
> | Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> | _______________________________________________
> | QuantLib-dev mailing list
> | Qua...@li...
> | https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> --
> Two new Rcpp master classes for R and C++ integration scheduled for
> New York (Sep 24) and San Francisco (Oct 8), more details are at
>
> http://dirk.eddelbuettel.com/blog/2011/08/04#rcpp_classes_2011-09_and_2011-10
>
> http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Bermudan LLM

[Dirk E. <ed...@de...>]

On 24 August 2011 at 16:17, Ferdinando Ametrano wrote:
| Hi Kakhkhor
| 
| I apologize, I completely misinterpreted your question, my fault.
| 
| As you wrote ATLAS would be problematic because in Windows it is
| available only if using cygwin, as far as I know. Besides it is plain
| C, isn't it?

Atlas is one of several accelerated implementation of the BLAS.  It can
certainly be compiled with different Windows toolchains; there is eg a binary
you can download for R which was built with MinGW (ie very much not Cygwin)
as R on Windows requires the MinGW toolchain.

Commercial software (Matlab comes to mind) often bundles its own accelerated
BLAS; Atlas happens to have the most liberal license (but Goto is now 'Open'
too as the original author moved on).

| What about using uBLAS, the C++ boost implementation?

AFAICT it is a pain to use, and the numerics wrapper for actual linear
algrebra was once again being rewritten when I last checked. It also falls
back to using a BLAS implementations.  FWIW I never managed to even cook up a
simple linear regression 'from first principles' (eg using a SVD) with uBlas.

An alternative could be provided by Eigen (http://eigen.tuxfamily.org) which
is very clever, very fast, very templated C++ --- and does not use BLAS! But
it would add another build dependency which is a clear downside.

Another somewhat lighter alternative is Armadillo (http://arma.sf.net). Also
templated, can use BLAS and a little simpler than Eigen. I quite like it --
and have written an package 'RcppArmadillo' that makes it a snap to use this
from R, leveraging our Rcpp package also used to tie [parts of] QuantLib to R
via RQuantLib.

[ From all that, I have a number of competing 'FastLm' implementations of
linear model fits (ie. ordinary least squares) using Armadillo, Eigen and
GSL.  Armadillo does fine, Eigen does better and GSL is slowest. My blog had
a few posts on that. ]

| As you understand moving to uBLAS would be a major change anyway and
| to do it in a backward compatible way (i.e. not dropping support for
| QuantLib::Matrix, QuantLib::Array, etc.) would be even more
| challenging, so Luigi opinion on this will rule.
| Unfortunately as he gets older he's more and more conservative ;-)
| 
| I for one would support a transition to uBLAS and removing all the
| QuantLib code that could be replaced by boost (e.g. math and stat
| functions), maybe on a QuantLib 2.x branch which would be not backward
| compatible with the 1.x branch

That is probably a good design decision in the medium term but you may want
to really check viability of some of the required operations first.
 
Hth,  Dirk

| ciao -- Nando
| 
| On Wed, Aug 24, 2011 at 12:37 AM, Kakhkhor Abdijalilov
| <kab...@gm...> wrote:
| > Longstaff-Schwartz method for Bermudan LLM requires OLS for every
| > early exercise opportunity, not just once.
| > I checked "Numerical recipes", Demel's and Golub's books and all
| > recommend not to use normal equations to solve OLS. Equity version of
| > Longstaff-Schwartz in QuantLib uses SVD too.
| >
| > The cost of SVD scales as SAMPLES*FACTORS^3, but the cost of path
| > generation scales as SAMPLES*FACTORS^2. SVD doesn't scale well as more
| > CPU cores are used, but path generation should scale almost perfectly.
| >
| > Regards,
| > Kakhkhor Abdijalilov.
| >
| > ------------------------------------------------------------------------------
| > EMC VNX: the world's simplest storage, starting under $10K
| > The only unified storage solution that offers unified management
| > Up to 160% more powerful than alternatives and 25% more efficient.
| > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
| > _______________________________________________
| > QuantLib-dev mailing list
| > Qua...@li...
| > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
| >
| 
| ------------------------------------------------------------------------------
| EMC VNX: the world's simplest storage, starting under $10K
| The only unified storage solution that offers unified management 
| Up to 160% more powerful than alternatives and 25% more efficient. 
| Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
| _______________________________________________
| QuantLib-dev mailing list
| Qua...@li...
| https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 
Two new Rcpp master classes for R and C++ integration scheduled for 
New York (Sep 24) and San Francisco (Oct 8), more details are at
http://dirk.eddelbuettel.com/blog/2011/08/04#rcpp_classes_2011-09_and_2011-10
http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php

Re: [Quantlib-dev] Bermudan LLM

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

Hi Kakhkhor

I apologize, I completely misinterpreted your question, my fault.

As you wrote ATLAS would be problematic because in Windows it is
available only if using cygwin, as far as I know. Besides it is plain
C, isn't it?
What about using uBLAS, the C++ boost implementation?

As you understand moving to uBLAS would be a major change anyway and
to do it in a backward compatible way (i.e. not dropping support for
QuantLib::Matrix, QuantLib::Array, etc.) would be even more
challenging, so Luigi opinion on this will rule.
Unfortunately as he gets older he's more and more conservative ;-)

I for one would support a transition to uBLAS and removing all the
QuantLib code that could be replaced by boost (e.g. math and stat
functions), maybe on a QuantLib 2.x branch which would be not backward
compatible with the 1.x branch

ciao -- Nando

On Wed, Aug 24, 2011 at 12:37 AM, Kakhkhor Abdijalilov
<kab...@gm...> wrote:
> Longstaff-Schwartz method for Bermudan LLM requires OLS for every
> early exercise opportunity, not just once.
> I checked "Numerical recipes", Demel's and Golub's books and all
> recommend not to use normal equations to solve OLS. Equity version of
> Longstaff-Schwartz in QuantLib uses SVD too.
>
> The cost of SVD scales as SAMPLES*FACTORS^3, but the cost of path
> generation scales as SAMPLES*FACTORS^2. SVD doesn't scale well as more
> CPU cores are used, but path generation should scale almost perfectly.
>
> Regards,
> Kakhkhor Abdijalilov.
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Bermudan LLM

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

Longstaff-Schwartz method for Bermudan LLM requires OLS for every
early exercise opportunity, not just once.
I checked "Numerical recipes", Demel's and Golub's books and all
recommend not to use normal equations to solve OLS. Equity version of
Longstaff-Schwartz in QuantLib uses SVD too.

The cost of SVD scales as SAMPLES*FACTORS^3, but the cost of path
generation scales as SAMPLES*FACTORS^2. SVD doesn't scale well as more
CPU cores are used, but path generation should scale almost perfectly.

Regards,
Kakhkhor Abdijalilov.

Re: [Quantlib-dev] [Quantlib-users] Curves over Eonia

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

On Tue, Aug 16, 2011 at 11:23 AM, SK A <ska...@go...> wrote:
> What about the stochastic modelling of basis spread, is there already an
> implementation or ongoing work or any plan to incorporate it?

none I know of, and without basis swap vol quotes  it would be quite
hard to really use a similar model.
Besides I am not following literature on the subject, but I would be
highly skeptical of any model not preserving time homogeneity. If
there is a time homogeneous model for the basis term structure please
point me at it

ciao -- Nando

Re: [Quantlib-dev] Bermudan LLM

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

On Sat, Aug 20, 2011 at 6:40 AM, Kakhkhor Abdijalilov
<kab...@gm...> wrote:
> my actual goal
> is to implement Bermudan LLM and integrate it into QuantLib.

do you plan a new implementation? why don't you reuse Mark Joshi's one

> There is
> one issues though.
> We need an efficient SVD algorithms. The SVD in the current version of
> QuantLib is OK for small matrices but I suspect it might be terribly
> slow for larger matrices.

I don't think Mark's code do use SVD and anyway I would be surprised
if matrix decomposition is a bottleneck: a proper implementation would
decompose the matrices once and then it's done. Hardly significant
compared to the simulations that will use the decomposed matrices

ciao -- Nando