size of price impacts *performance* of option pricing??

[Tito Ingargiola]

Hi,

At the risk of asking a patently dumb question...  I've noticed a
weird behavior in quantlib (v.081) which I hope someone could kindly explain to me.

It can be illustrated by taking the sample program EquityOption from
the distribution and simply incrementing the underlying and strike by
some largish number.  For example, if you modify the underlying from
36 to 1436 and the strike from 40 to 1440 and leave everything else in
the program exactly the same, you'll see what I'm talking about.  The
program in its initial form takes some few (3-5) seconds to run;
modified as I've described it takes several *minutes* to run.

The time seems to be spent in the monte carlo parts of the program,
but I haven't dug further into it than that in the hope that someone
might know off the top of their head what's going on...  Or perhaps
I'm just misunderstanding that the absolute size of the price should
have a grave impact on performance (?)

Many thanks in advance for any insights!  Regards,

     Tito.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Wed, 2007-08-29 at 16:55 -0700, Tito Ingargiola wrote:

> At the risk of asking a patently dumb question...  I've noticed a
> weird behavior in quantlib (v.081) which I hope someone could kindly
> explain to me.
>
> It can be illustrated by taking the sample program EquityOption from
> the distribution and simply incrementing the underlying and strike by
> some largish number.  For example, if you modify the underlying from
> 36 to 1436 and the strike from 40 to 1440 and leave everything else in
> the program exactly the same, you'll see what I'm talking about.  The
> program in its initial form takes some few (3-5) seconds to run;
> modified as I've described it takes several *minutes* to run.

Tito,
        I admit you had me flabbergasted for a while. And I had to look into
the code to see what was happening...

The problems is that the engine is aiming at an *absolute* error of 0.02
(see where the MC engines are instantiated.) With the old values, that
corresponds to about 0.5% error. With the increased values, the same
tolerance corresponds to a relative error about 20 times smaller.
Therefore, the Monte Carlo has to run about 400 times as much samples to
reach it.

Later,
        Luigi


--

Humphrey's Requirements Uncertainty Principle:
For a new software system, the requirements will not be
completely known until after the users have used it.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users