bug in blackcapfloorengine.cpp?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

bug in blackcapfloorengine.cpp?

Chris Kenyon-2
(Also in bug tracker.)

Hi,

in blackcapfloorengine.cpp when the type is Collar the optionletsPrice does
not appear to be updated correctly. Since the collar is long a cap and
short a floor should the optionletsPrice also have the floor subtracted as the
value does?

I.e. does a line need adding after 131 as:

    optionletsPrice.back() -= temp;

Best regards,
Chris


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: bug in blackcapfloorengine.cpp?

Ferdinando M. Ametrano-3
On Fri, Mar 7, 2008 at 11:39 AM, Chris Kenyon <[hidden email]> wrote:
> in blackcapfloorengine.cpp when the type is Collar the optionletsPrice does
> not appear to be updated correctly. Since the collar is long a cap and
> short a floor should the optionletsPrice also have the floor subtracted as the
> value does?

yes, I agree with you. You are referring to the 0.9.0 code base: this
error has been fixed in the current trunk code which has been also
refactored: would you mind taking a look at it and see if you could
spot any new mistake that might have been introduced by the
refactoring?

I exploit your observation to ask: could we remove the Collar
enumeration and force the user to instantiate the Cap and Floor
independently? I've never liked the duplication of strikes in the
CapFloor contructor.
The reason I ask is that long time ago we tried to support Straddle
together with Call and Put, but we gave up in favor of code
readability and to avoid the kind of mistake you are pointing out
about Collar. For the same reason I would remove Collar.
The only valuable feature we would lose is the ability to calculate
implied vol for a Collar. Anyway after dealing few years with these
issues I'm inclined to think that the only real beneficial addition
would be to have an easy way to calculate implied vol for straddles,
or more generically, implied vol for a collection of cap/floor
instruments, not just collar whose usage has been null in my
experience.

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev