QuEP 5

[Vadim Ogranovich-3]

Hi,

I think this is an important proposal (meaning that today I realized I
needed it yesterday  :-)). Here is some feedback:

I am not sure that option specification parameters, e.g. put/call, exercise
style, strike, expiration date should be part of a pricing engine. These are
intrinsic properties of a traded instrument and are independent of the
theoretical framework used to price the option. In addition to the above
"philosophical" argument consider the following scenario: for whatever
reasons I need to first construct an option instance and only later decide
which pricer I want to use to price it. In the proposed framework I will
need to a) create a dummy pricer at the option construction, then later b)
extract option info (strike, expiration date, etc.) from the dummy pricer,
destroy the dummy pricer and then create a new one using the option info of
the old one. This is not how the nature intended it to be.

BTW, I couldn't find expiration date in the proposed class hierarchy, only
residualTime. Did I miss it?

Also I don't see discrete dividends on UnderlyingParams class. What about
them?


My understanding is that the QuEP is (at least partially) implemented. Could
someone point me to the files? (The  ql/Pricers/europeanengine.hpp file
mentioned in the QuEP doesn't exist)


In the end let me ask a general question probably stemming from the lack of
understanding of the purpose of the Instrument class. Suppose I have a book
(portfolio) of stocks and options that I carry from day to day and all I
need to do is to compute end of day PnL based on closing prices of the
securities, their dividends, and option exercise (if any). How does QL help
me do this? I thought I'd just need to sum the NAV-s of all securities, but
it seems like NAV is more like a "theoretical" value rather than the market
price.

Thanks, Vadim

--------------------------------------------------
DISCLAIMER
This e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information.  If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly prohibited.
If you have received this e-mail in error, please immediately notify me and
permanently delete the original and any copy of any e-mail and any printout
thereof.

E-mail transmission cannot be guaranteed to be secure or error-free.  The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.

NOTICE REGARDING PRIVACY AND CONFIDENTIALITY

Knight Trading Group may, at its discretion, monitor and review the content
of all e-mail communications.

[Luigi Ballabio-2]

Hi Vadim,
         I haven't much time, but here's the beginning of an answer:

At 02:50 AM 8/14/02 -0500, Vadim Ogranovich wrote:
>I am not sure that option specification parameters, e.g. put/call, exercise
>style, strike, expiration date should be part of a pricing engine. These are
>intrinsic properties of a traded instrument and are independent of the
>theoretical framework used to price the option.

By all means. In fact, this is how the current implementation works.
I guess my fault was not to add the slots for strike etc. to the
ConcreteOption box in the quep. However, here's how I intended it:
- the option keeps its arguments (strike, exercise date, whatever);
- when he option needs to be priced, it takes the parameters, possibly
   converting them (e.g., exercise date -> residual time) and stores them in
   the pricing engine;
- having been fed the arguments, the pricing engine crunches them and stores
   the results in its, well, results.
- the option takes the results back from the engine.

What might be confusing is the presence of the Arguments instance inside
the engine. It's not intended as an ownership thing, but only as a way to
pass any number and type of parameters to the engine.
In short,

     Arguments* args = engine->arguments();
     ... /* store argument values into args */
     engine->calculate();
     Results* res = engine->results();
     ... /* read them */

is just a more flexible (type-wise) way to write:

     Arguments* args = new (what? and who owns the pointer?);
     ... /* store argument values into args */
     Results* res = new (what? and who owns the pointer?);
     engine->calculate(args,res);
     ... /* read them */


>My understanding is that the QuEP is (at least partially) implemented. Could
>someone point me to the files? (The  ql/Pricers/europeanengine.hpp file
>mentioned in the QuEP doesn't exist)

ql/option.[c|h]pp
ql/pricingengine.hpp
ql/Instruments/*vanillaoption.[c|h]pp
ql/PricingEngines/*engine.[c|h]pp


>In the end let me ask a general question probably stemming from the lack of
>understanding of the purpose of the Instrument class. Suppose I have a book
>(portfolio) of stocks and options that I carry from day to day and all I
>need to do is to compute end of day PnL based on closing prices of the
>securities, their dividends, and option exercise (if any). How does QL help
>me do this? I thought I'd just need to sum the NAV-s of all securities, but
>it seems like NAV is more like a "theoretical" value rather than the market
>price.

Yes, it is the calculated price. For quoted instruments, you might be
better off simulating them with Instruments::Stock. But we'll have to go
into this.

Bye for now,
                 Luigi