bug report: negative price for an American put option using Bjerksund and Stensland approximation

[jan.willem.bikker]

Hello,

I have a bug report: I encountered a  negative price for an American put option using Bjerksund and Stensland approximation.

I used the setting of the example from QuantLib-0.3.8\Examples\AmericanOption\AmericanOption.cpp  as a basis for my program.

The settings are

SettlementDate=38353
ExerciseDate=42003 = SettlementDate +10*365
strike=100
spot=125
vol=0.05
interest=0.1
dividend=0.05
option type = put

and

        option.setPricingEngine(boost::shared_ptr<PricingEngine>(
                new BjerksundStenslandApproximationEngine));
        aBjStprice = option.NPV();

yields

        aBjStprice =-25

Furthermore, changing the spot to 100 yields a price of 0, which also seems incorrect.

I've checked in total 85 american options in various scenarios, and these are the only two behaving strangely (the rest is comparable to the binomial CCR method).

I hope somebody finds this message useful. I couldn't find this bug on sourceforge.

Kind regards,

Jan Willem Bikker

---------------------------------------------------------------------------
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change.
ABN AMRO Bank N.V. (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.
---------------------------------------------------------------------------

[Luigi Ballabio]

On 11/08/2005 02:41:40 PM, [hidden email] wrote:
> I have a bug report: I encountered a  negative price for an American
> put option using Bjerksund and Stensland approximation.
>
> Furthermore, changing the spot to 100 yields a price of 0, which also
> seems incorrect.

Yes, I reproduced the problem. I'll get back when I have some news.

Thanks,
        Luigi


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

Newton's Law of Gravitation:
        What goes up must come down.  But don't expect it to come down
        where you can find it.  Murphy's Law applies to Newton's.

[Luigi Ballabio]

On 11/08/2005 02:41:40 PM, [hidden email] wrote:
> I have a bug report: I encountered a  negative price for an American
> put option using Bjerksund and Stensland approximation.

Jan,
        it seems that there are values (typically, small volatilities,  
large cost of carry and/or far-away maturities) for which the trigger  
price is less than the strike; this causes the approximation to break  
down. For the time being, I added a check which raises an exception if  
such a condition occurs (so that at least incorrect values are not  
returned silently.) I'll try and get more information on the problem.

Later,
        Luigi


P.S. If you want to patch your sources, look for the line

Real I = B0 + (BInfinity - B0) * (1 - std::exp(ht));

in bjerksundstenslandengine.cpp and add the following check after it:

QL_REQUIRE(I >= X, "broken Bjerksund-Stensland approximation");


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

The nice thing about standards is that there are so many of them to
choose from.
-- Andrew S. Tanenbaum

[Toyin Akin]

Hi,

It looks like the rebate variable is not being used within the MCBarrier
pricing class.
You can see this if you price the same option with rebate using the
analytical engine.

Also a question on the test condition used within the MCBarrier pricing
classes.
What's the reasoning between using a different test variable instead of the
one stored within the path object (ie - line 76 of the cpp file).

I notice you also have the BiasedBarrierPathPricer version below this which
has the logic I that I would expect (ie -  line 178 of the cpp file). No
doubt Biased!! ... but why?

Is there a great difference between the two if using a large number of
simulations?

Also, looks like the biased version of the mcbarrier class also has the
missing rebate logic.

Finally, for the test cases where you have the variable 'isOptionActive' set
to false it would probably be a good idea to break out of the loop as the
'asset_price' variable is never used after this point and thus you'll get a
speed increase (ie - line 111 of the cpp file).

Also, if the difference is great between the biased and unbiased variables,
should this new variable also be used as a test condition within the
MCBasket class ( ie - line 64 of the cpp file.)

Best Regards,
Toyin Akin.

[Toyin Akin]

Hi all,

Let's say we have the following situation.

A 10 year swap starting from spot (ValueDate+SettleDays).

Let's also have a swaption structure where we want to have the option
(European let's say) of
cancelling this swap at year 5.

It looks like if you were simply to pass in the 10 year swap object created
above to the swaption() class, the swaption class (along with all it's
various pricing engines) assumes that the swap starts after the exercise
date and simply uses all the cashflows within the swap, even those before
the first exercise date. Thus mispricing the option.

(At least that is what I think is happening!)

Looks like under the above specification, to price the swap and the swaption
together, you would have to build 2 swaps and a swaption object. A 10 year
swap, the forward starting 5 year into 5 year swap and a swaption object on
this forward starting swap.

If what I have presented above is true, could you either put in a check to
detect whether there are flows that are after the ValueDate but before the
first exercise date and throw an error if true.

Even sexier exclude these flows during the pricing of the swaption (European
and Bermudan.)
The latter approach might be a little tricky if the first exercise date lies
in the middle of one of the valid legs accural period.

Best Regards,
Toyin Akin.

[Toyin Akin]

Hi,

When pricing a swap structure which starts in the past and thus requires a
fixing value for the first period (payment date is after the ValueDate), if
you specify ACTACT as a daycount, the swap will report an error.

This happens, for example, on lines #104 and #130 within the
setupArguments() function call.

This is because the call to yearfraction() within the ACTACT daycounter
class checks to see if the dates passed in are passed in the correct order.
If not it throws an exception.

In the case of this fixing scenario, the dates will be passed in, will be of
the incorrect order because the ValueDate is after the fixing date (line
#130).

However all the other daycounter classes do not check for this. I understand
that the code following the call to yearfraction() would take the correct
action if a negative value is returned (ie - PricingEngines).

Best Regards,
Toyin Akin.

[Luigi Ballabio]

On 11/14/2005 05:37:39 AM, Toyin Akin wrote:
> ...the call to yearfraction() within the ACTACT
> daycounter class checks to see if the dates passed in are passed in  
> the correct order. If not it throws an exception.

Toyin,
        you're right. I fixed this in CVS.
As for the Bermudan pricing issue, I'll look at it as soon as I get  
some time.

Later,
        Luigi

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

This gubblick contains many nonsklarkish English flutzpahs, but the
overall pluggandisp can be glorked from context.
-- David Moser

[Toyin Akin]

Thanks,

Toy out.

>From: Luigi Ballabio <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: [Quantlib-users] Re: Possible ACT/ACT DayCounter problem
>Date: Mon, 14 Nov 2005 16:12:03 +0000
>
>
>On 11/14/2005 05:37:39 AM, Toyin Akin wrote:
>>...the call to yearfraction() within the ACTACT
>>daycounter class checks to see if the dates passed in are passed in  the
>>correct order. If not it throws an exception.
>
>Toyin,
> you're right. I fixed this in CVS.
>As for the Bermudan pricing issue, I'll look at it as soon as I get  some
>time.
>
>Later,
> Luigi
>
>----------------------------------------
>
>This gubblick contains many nonsklarkish English flutzpahs, but the
>overall pluggandisp can be glorked from context.
>-- David Moser
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server.
>Download
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On 11/13/2005 05:40:05 PM, Toyin Akin wrote:

> A 10 year swap starting from spot (ValueDate+SettleDays).
>
> Let's also have a swaption structure where we want to have the option  
> (European let's say) of cancelling this swap at year 5.
>
> It looks like if you were simply to pass in the 10 year swap object  
> created above to the swaption() class, the swaption class (along with  
> all it's various pricing engines) assumes that the swap starts after  
> the exercise date and simply uses all the cashflows within the swap,  
> even those before the first exercise date. Thus mispricing the option.

Right (except for TreeSwaptionEngine, which prices the swaption  
correctly.)

I'll see what I can do.

Luigi

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

Every solution breeds new problems.
-- unknown