Re: [Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL

[eric e. <eri...@gm...>]

Hi Toy,

From your message it's not clear to me whether you're responding to my
original proposal (20 April) or the revised one (24 April).

Let me reiterate that under the revised proposal, the existing
behavior of OH would be retained.  The user would additionally have
the option of retrieving objects via handle stubs.

On 4/24/06, Toyin Akin <toy...@ho...> wrote:
> I don't like the idea of the user being able to use the stub key if a uni=
que
> key is generated for him/her and this new key provides no chances of
> mispricing on the sheet (assuming that all input parameters are correct a=
nd
> the user knows the instrument they are pricing).

Under the revised proposal, OH supports retrieval of objects both by
the handle stub ("my_object") and the full handle
("my_object~_xxxxx").  Normally objects would be retrieved by their
full handle but if required the user has the option of retrieving an
object by its stub - in which case the user must respect the caveat
that Excel no longer forces the object to be refreshed before it is
referenced.

If you feel that allowing this alternative behavior is dangerous then
we could consider making the behavior configurable - you could build
OH such that retrieval of objects via the handle stub is not supported
(i.e. preserve the current behavior).

> As your library grows and many more objects are added, using the stub onl=
y
> approach makes it difficult to track unique objects.

Under the proposed approach OH throws an exception if a user attempts
to retrieve an object via its handle stub and two objects exists with
the same stub.

> Why not stick with the "my_object~_xxxxx" key?

For normal use yes.

We have a special case where we'd like to support retrieval of objects
via the stub.  Consider three sheets which
1) instantiate some rate helper objects (qlDepositRateHelper)
2) update the rates in real time (qlSetQuote)
3) bootstrap the yield curve (qlPiecewiseFlatForward)

Now imagine that we have multiple versions of #2 depending on where we
want to source the rates feed.  When we bootstrap the yield curve, we
don't want to bother about which sheet is updating the rates.  Here's
what we do:

- Load sheet #1, refresh it, and close it.
- The OH repository is now initialized with a collection of rate
helper objects ("ON", "1W", "1M", etc.)
- The sheet which created these objects (#1) is closed, so the objects
will not be reconstructed again
- Load sheets #2 and #3.  The curve is bootstrapped, the rates are
updated in real time, and the state of the curve changes accordingly
(thanks to QL's behind-the-scenes use of the Observer/Observable
pattern)
- Note that no further deconstruction/reconstruction of objects is
taking place - we are merely changing the state of the rate helper and
yield curve objects, which were constructed once

If we have to use full handles, then sheet #3 needs to know which
version of sheet #2 is in use.  This could change from one session to
the next.  Maintaining this link is not impossible but we find it more
convenient to allow objects to be referenced via handle stubs.  Sheets
#2 and #3 simply trust that rate helper objects ("ON", "1W", "1M",
etc.) exist without needing to know their full handles.  Therefore
sheet #3 doesn't need to link to sheet #2 and we can switch to a
different version of sheet #2 without editing sheet #3.

> Also using the stub key only where the object may have already have been
> created (a yieldcurve and a book object with the same name) would cause
> errors on the spreadsheet that will be very difficult to track down.
>
> The result will simply display #value, but for the user, how do you debug
> this?
>
> Visiting dependant cells may not help, because the previous object with t=
he
> same name may have been created within another pricing calculation
> (worksheet/workbook same Excel session).

Suppose the user tries to create two objects, and supplies the same
stub, "my_object", to both constructors.  This will succeed, exactly
as it does today - the first object will be created e.g. as
"my_object~_00001" and the second as "my_object~_00002".If the user
requests "my_object~_00001" or "my_object~_00002" he gets the correct
object back.  If he requests "my_object", OH sees that two objects
exist with that handle stub and throws an exception.

> What are the main issues in not using the computed key?

As discussed - normally we use the computed key.  But when we want to
reference an object and don't want to keep track of where in the Excel
session it resides - we reference it via the handle stub.

> Also, the "stub" key is static and Excel will not detect a change within
> it's calculation dependency list. One will have to resort to a global (F9=
)
> spreadsheet computation in order to ensure any new changes to the key is
> picked up (that's assuming the previously created object is not part of t=
his
> updating too!!)

I was under the same impression, until Plamen clarified things for me.

Consider two cells, A1 which constructs an object, and A2 which
references the object in A1.

Under the design proposed on 20 April, A1 would hold value "my_object".

Since Excel 2003, changes in A1 would still force a recalc of A2.=20
When the inputs to A1 change, Excel is smart enough to realize that
the dependents of A1 need to be recalculated, even though the physical
contents of A1 are unchanged.

That's with cell references.  The problem arises when you retrieve an
object via a raw string "my_object".  In this case you have no
guarantee that you're getting the latest version of "my_object".

Anyway under the revised design, the existing behavior of OH is
preserved, and cell A1 contains "my_object~_xxxxx".  Normally A2 holds
a reference to A1.  But in the special case described above we also
have the option for A2 to refer to the raw string ""my_object".  In
this case the user must ensure that a refresh of A1 is followed by a
refresh of A2.  As mentioned in our environment we accomplish this by
putting A1 on a separate sheet and closing the sheet after the object
is instantiated.

> Just my 2 cents worth...

I very much welcome your feedback.

Regards,
Eric