quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Asset swap test error

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

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

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

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 

Re: [Quantlib-dev] Asset swap test error

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

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 

Re: [Quantlib-dev] Asset swap test error

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

It doesn't look like anyone is addressing this failure in the tests.
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

Re: [Quantlib-dev] Any rationale that currency codes and calendars are hard coded at compile time rather than read from a text file at runtime?

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

On Mon, 2011-10-03 at 20:14 +0800, R Y wrote:
> Your points are perfectly valid. My point is that reading from a text
> file improves the extendibility of the library as it doesn't require
> rebuilding the source code (of course I'm sure you're well aware of
> that).

Yes, and you can do it already.  Read a list of dates in whatever way
you like, build a BespokeCalendar instance, pass it the dates you read,
it's done.  In case a new holiday is added to an existing calendar, you
can use the addHoliday method instead of modifying the code.  So you
have extendibility.

In the context of a library, data files are somewhat prone to problems.
For instance, how should the library know where the data files are?  On
windows, you might have a preferred location for those.  On Linux
systems, there are a number of preferred locations which are used
depending on whether one installs the library as user or superuser.
Then the library might be linked statically to one's program, which
means that suddenly a developer using the library has to ship the
calendar files together with his program.  The added migraines just
don't seem worth the effort...

Luigi


-- 

When I was a boy of fourteen, my father was so ignorant I could hardly 
stand to have the old man around. But when I got to be twenty-one, I 
was astonished at how much the old man had learned in seven years. 
-- Mark Twain 

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

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

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).

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'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. 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;

Re: [Quantlib-dev] Any rationale that currency codes and calendars are hard coded at compile time rather than read from a text file at runtime?

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

Your points are perfectly valid. My point is that reading from a text file
improves the extendibility of the library as it doesn't require rebuilding
the source code (of course I'm sure you're well aware of that). And for date
format we can easily require that the text file be encoded in utf-8 and the
date in yyyy-mm-dd ISO format.
Cheers.
On Mon, Oct 3, 2011 at 6:42 PM, Luigi Ballabio <lui...@gm...>wrote:

> On Sun, 2011-10-02 at 09:08 +0800, R Yan wrote:
> > And would it benefit at all if someone contributes a module that reads
> > currency codes and calendars at runtime?
>
> As for calendars, the rationale is having rules (for example, "each 25
> december" or "the third Wednesday in October") that remain valid for
> each year, instead of having to generate and distribute the data files.
> The possibility of creating a calendar at runtime is given by the
> BespokeCalendar class, whose instances take a list of dates (to be read
> from a file or otherwise) and build the corresponding calendar.  I'd
> leave out the part where one reads the file, especially since it depends
> on locales (today's date is written as 03/10/2011 in Italy and
> 10/03/2011 in the US).
>
> For currencies, you might add a constructor to the Currency class that
> takes the needed data and thus instantiates a currency at runtime.
> Again, I'd prefer to leave out the "read from a text file" part (or from
> a database, or from any other source) that can be done easily by any
> application using the library.
>
> Luigi
>
>
> --
>
> Never mistake motion for action.
> -- Ernest Hemingway
>
>
>

Re: [Quantlib-dev] Any rationale that currency codes and calendars are hard coded at compile time rather than read from a text file at runtime?

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

On Sun, 2011-10-02 at 09:08 +0800, R Yan wrote:
> And would it benefit at all if someone contributes a module that reads
> currency codes and calendars at runtime?

As for calendars, the rationale is having rules (for example, "each 25
december" or "the third Wednesday in October") that remain valid for
each year, instead of having to generate and distribute the data files.
The possibility of creating a calendar at runtime is given by the
BespokeCalendar class, whose instances take a list of dates (to be read
from a file or otherwise) and build the corresponding calendar.  I'd
leave out the part where one reads the file, especially since it depends
on locales (today's date is written as 03/10/2011 in Italy and
10/03/2011 in the US).

For currencies, you might add a constructor to the Currency class that
takes the needed data and thus instantiates a currency at runtime.
Again, I'd prefer to leave out the "read from a text file" part (or from
a database, or from any other source) that can be done easily by any
application using the library.

Luigi


-- 

Never mistake motion for action. 
-- Ernest Hemingway 

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

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

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


-- 

Debugging is twice as hard as writing the code in the first place. 
Therefore, if you write the code as cleverly as possible, you are, 
by definition, not smart enough to debug it. 
-- Brian W. Kernighan 

[Quantlib-dev] [ quantlib-Bugs-3417114 ] BS call option price lower than intrinsic value

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

Bugs item #3417114, was opened at 2011-10-02 15:52
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3417114&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: R Y (fancidev)
Assigned to: Nobody/Anonymous (nobody)
Summary: BS call option price lower than intrinsic value

Initial Comment:
Compile and run the following program in Visual Studio 2010 produces the bug.

#include <iostream>
#include <ql/pricingengines/blackformula.hpp>

using namespace QuantLib;

static void TestBlackScholesBound()
{
	double F = 1.35;
	double K = 0.39;
	double stdev = 0.12;
	double c = blackFormula(Option::Call, K, F, stdev);
	if (c < (F - K))
	{
		std::cerr << "Error: Option price = " << c << ", Lower Bound = "
			<< (F - K) << std::endl;
	}
}

int main()
{
	TestBlackScholesBound();
	system("PAUSE");
}


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

>Comment By: Luigi Ballabio (lballabio)
Date: 2011-10-03 12:16

Message:
That also happens with g++ on Linux, but it's only caused by floating-point
precision issues. If you print out the values with more precision, you'll
find:

Option price = 0.95999999999999996447
Lower Bound = 0.9600000000000000755

due to the fact that you can't store 0.96, nor 1.35, nor 0.39 in a
floating-point number exactly.  Also, if you write the check as:

if (c < 0.96)

instead of
if (c < (F - K))

the test passes.

That's not something we can fix on the library side, and adding a check
might just cause false positives.

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

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

[Quantlib-dev] [ quantlib-Bugs-3417114 ] BS call option price lower than intrinsic value

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

Bugs item #3417114, was opened at 2011-10-02 21:52
Message generated for change (Tracker Item Submitted) made by fancidev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3417114&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: R Y (fancidev)
Assigned to: Nobody/Anonymous (nobody)
Summary: BS call option price lower than intrinsic value

Initial Comment:
Compile and run the following program in Visual Studio 2010 produces the bug.

#include <iostream>
#include <ql/pricingengines/blackformula.hpp>

using namespace QuantLib;

static void TestBlackScholesBound()
{
	double F = 1.35;
	double K = 0.39;
	double stdev = 0.12;
	double c = blackFormula(Option::Call, K, F, stdev);
	if (c < (F - K))
	{
		std::cerr << "Error: Option price = " << c << ", Lower Bound = "
			<< (F - K) << std::endl;
	}
}

int main()
{
	TestBlackScholesBound();
	system("PAUSE");
}


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

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

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

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

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?

[Quantlib-dev] Any rationale that currency codes and calendars are hard coded at compile time rather than read from a text file at runtime?

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

Thanks for answering.

And would it benefit at all if someone contributes a module that reads
currency codes and calendars at runtime?

[Quantlib-dev] [ quantlib-Bugs-3415446 ] Build error when comiling with VC11

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

Bugs item #3415446, was opened at 2011-09-29 15:12
Message generated for change (Tracker Item Submitted) made by tomsullivan34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3415446&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: Thomas A Sullivan (tomsullivan34)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build error when comiling with VC11

Initial Comment:
1>------ Build started: Project: QuantLib, Configuration: Debug Win32 ------
1>Build started 9/29/2011 3:09:10 PM.
1>ClCompile:
1>  symmetricschurdecomposition.cpp
1>ql\math\matrixutilities\symmetricschurdecomposition.cpp(123): error C2664: 'std::make_pair' : cannot convert parameter 1 from 'QuantLib::Real' to 'QuantLib::Real &&'
1>          You cannot bind an lvalue to an rvalue reference
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:03.09
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I modified this code:
            temp[col] = std::make_pair<Real, std::vector<Real> >(
                diagonal_[col], eigenVector);

to this:
            temp[col] = std::make_pair<Real, std::vector<Real> >(
                (Real&&)diagonal_[col], (std::vector<Real>&&)eigenVector);

and it built ok.


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

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

[Quantlib-dev] [ quantlib-Patches-3413982 ] IR Value At Risk via RiskMetrics

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

Patches item #3413982, was opened at 2011-09-26 12:48
Message generated for change (Tracker Item Submitted) made by miemiec
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3413982&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: Andre Miemiec (miemiec)
Assigned to: Nobody/Anonymous (nobody)
Summary: IR Value At Risk via RiskMetrics

Initial Comment:
The project contains an elementary implementation of the RiskMetrics methodology for linear interest rate instruments like bonds. The purpose is mainly to explore the ability of QuantLib to support these kind of risk calculations. Appart from the fact that the implementation actually works pretty well it points out some shortcomings. The major problem is that the generation of tweaked pricing engines is not quite handy. The study revealed that is should be solved by adding an appropriate Clone-mechanism to each of the pricing engines, which implies a lot of work. 
Inclusion of FX-risk and EQ-risk was started but stopped in an early phase. Basically there are no additionally problems to complete these exercises.

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

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

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

[SK A <ska...@go...>]

Hi Luigi,

Thanks for your comments.

I didn't exactly understand one point. What do you mean by: "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..."

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?

Regards,
Sarp Kaya

On Tue, Sep 13, 2011 at 4:24 PM, Luigi Ballabio <lui...@gm...>wrote:

> 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] Bug report, BlackScholesCalculator

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

It might not be the order you expect, but why should this be a mistake?
The parameters are used correctly. (You can check by putting some
numbers in.)

Luigi


On Sun, 2011-09-18 at 21:05 -0400, Yue Zhao wrote:

> For the constructor of BlackScholesCalculator, the declaration is:
> 
> 
> BlackScholesCalculator(Option::type optionType, Real strike, Real
> spot, ...)
> 
> 
> should it really be:
> 
> 
> BlackScholesCalculator(Option::type optionType, Real spot, Real
> strike, ...) ???
> 
> 
> I know this is a minor mistake, but since there's no complete
> documentation, you might want to fix this
> 
> 
> Best
> 
> 
> Cat Z
> 
> 
> 
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the 
> BlackBerry® mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1 
> _______________________________________________ QuantLib-dev mailing list Qua...@li... https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 

Brady's First Law of Problem Solving: 
When confronted by a difficult problem, you can solve it more 
easily by reducing it to the question, "How would the Lone 
Ranger have handled this?" 

[Quantlib-dev] Bug report, BlackScholesCalculator

[Yue Z. <yzh...@gm...>]

---------- Forwarded message ----------
From: Yue Zhao <yzh...@gm...>
Date: Sun, Sep 18, 2011 at 8:59 PM
Subject: Bug report, BlackScholesCalculator
To: QuantLib Devs <uan...@li...>


For the constructor of BlackScholesCalculator, the declaration is:

BlackScholesCalculator(Option::type optionType, Real strike, Real spot, ...)

should it really be:

BlackScholesCalculator(Option::type optionType, Real spot, Real strike, ...)
???

I know this is a minor mistake, but since there's no complete documentation,
you might want to fix this

Best

Cat Z

[Quantlib-dev] Asset swap test error

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

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

Re: [Quantlib-dev] issue with the evaluationDate

[Didrik P. <dp...@en...>]

On Thu, Sep 15, 2011 at 10:03 PM, Bojan Nikolic <bo...@bn...> wrote:
>
> Hi Didrik,
>
> A possibility which I've seen before:
>
> I would suggest checking the linking stage to make sure that symbols
> defined (through template instantiation) in multiple compilation units
> correctly get amalgamated into one. The reason is that the
> evaluationdate mechanism depends on a singleton pattern which is
> implemented in a template (and therefore in a header file, see
> ql/patterns/singleton.hpp).

Ok, I found the issue but not the real cause ;-)

Upgrading the Ubuntu's to boost 1.46 makes all the test passing smoothly.

-- Didrik

Re: [Quantlib-dev] issue with the evaluationDate

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

Hi Didrik,

A possibility which I've seen before:

I would suggest checking the linking stage to make sure that symbols
defined (through template instantiation) in multiple compilation units
correctly get amalgamated into one. The reason is that the
evaluationdate mechanism depends on a singleton pattern which is
implemented in a template (and therefore in a header file, see
ql/patterns/singleton.hpp).

Best,
Bojan


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

Re: [Quantlib-dev] issue with the evaluationDate

[Didrik P. <dp...@en...>]

On Thu, Sep 15, 2011 at 9:18 PM, Didrik Pinte <dp...@en...> wrote:
> Could it be related to the boost version ? Does anyone have an idea on
> the cause of the issue ? I have looked at the compilation flags using
> for the SWIG wrapper and we're using the same. Reading the cpp code
> generated by Cython does not give information. I have added a listener
> (using registerWith) within the code and it shows the date is changed
> properly (or at least that the event happens). On a FixedRateBond, if
> I set the evaluation_date to 15 days ago, I get a settlementDate three
> days after today.

The problem seem to be close to this one :
http://old.nabble.com/Problem-setting-the-evaluation-date-on-AIX-for-64-bit-application-tt30740503.html

-- Didrik

[Quantlib-dev] issue with the evaluationDate

[Didrik P. <dp...@en...>]

Hi,

I am working on some Cython wrappers on top of QuantLib. They do work
really nicely (and will be made available soon).

I am hitting a weird issue that some of you might have seen in the
past or could help debugging.

I am testing the code on five different machines :
- MacOSX - Python 2.7 32bit - gcc 4.2 / boost 1.46 / QuantLib 1.0.1
- Windows 64bit - Python 2.7 - mingw / boost 1.46 /QuantLib 1.0.1
- Debian SID - Python 2.7 - 64bit - gcc 4.6 / boost 1.46 / QuantLib 1.1
- Ubuntu 11.04 - Python 2.7 32bit - gcc 4.5.2 / boost 1.42 / QuantLib 1.0.1
- Ubuntu 11.04 - Python 2.7 64bit - gcc 4.5.2 / boost 1.42 / QuantLib 1.0.1

For all the machines, the code to set and get the evaluationDate works fine.

All the code depending on the evaluationDate works correctly only on
the MacOSX, Debian and Windows boxes. I am testing bond valuation,
options, etc.
The Ubuntu's do fail with the evaluationDate being always equal to
today (even if asking for Settings::instance().evaluationDate()
returns the evaluation date that we have set).

Could it be related to the boost version ? Does anyone have an idea on
the cause of the issue ? I have looked at the compilation flags using
for the SWIG wrapper and we're using the same. Reading the cpp code
generated by Cython does not give information. I have added a listener
(using registerWith) within the code and it shows the date is changed
properly (or at least that the event happens). On a FixedRateBond, if
I set the evaluation_date to 15 days ago, I get a settlementDate three
days after today.

Thanks in advance for any help/hints/suggestions.

-- Didrik

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

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

On Mon, 2011-09-12 at 14:22 +0200, Luigi Ballabio wrote:
> 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?

Also, do those files include anything else from experimental?

Luigi


-- 

Zawinski's Law: 
Every program attempts to expand until it can read mail. Those 
programs which cannot so expand are replaced by ones which can. 

Re: [Quantlib-dev] Bermudan LLM

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

Dear Aman,
I appreciate your offer to help.If you wish to contribute please, join
the Google group I created for the project.


Recently I took a closer look at QuantLib's matrix subroutines and
noticed the following:

(*) Internal implementation can be replaced with calls to BLAS
subroutines without affecting the interface.
(*) SVD class is much slower (up 50 times with large matrices) than
SVD from LAPACK when the later is linked to optimized BLAS such as
ATLAS.
(*) For the best performance SSE/SSE2 vector instructions can be used
to speedup path generations. These are available on all x86
architectures. Fallback to scalar form is the matter of simple macro
switch. Users wouldn't have to deal with SSE/SSE2 directly if they use
supplied payoffs.
(*) Overall speedup can be somewhere between 50 to 100 times when 12
or more CPU cores are used.

Regards,
Kakhkhor Abdijalilov.