Re: Stale handles from objectHandler?

[rohan talwar]

I don't seem to be able to resolve where this issue is. Has anyone had this sort of issue, where the in cell call to a QL inquiry function in qlXL does not dynamically update. It does update manually.

Can you point me to the types of errors that I may have introduced (Eric) vis-a-vis the calc tree or something else? I am rebuilding the sheet piece by piece but it is slow, and I do not know which specific issues I am seeking to avoid.

The example worksheets do not seem to have the same problem, however, they are comparatively simple, whereas my sheet seeks to create a multi currency yield curve trading sheet not dissimilar to ones I have used before.

My vol calcs I have done via vba UDF within the xl environment directly.

As per last time all help appreciated.

Kind regards
Rohan Talwar

---

From: rohan talwar <[hidden email]>
To: [hidden email]
Sent: Tue, 25 January, 2011 12:48:39
Subject: Fw: [Quantlib-users] Stale handles from objectHandler?

Eric

Thanks for coming back to me. I am not sure it is a design flaw as such. But I know it is definitely not perfect.

I normally set calc to manual, due to habit, but I also don't want recalcs too often (I have some volatile functions, like offset, and index, etc.). What I can say, is that even after brute force (Ctrl-Alt-F9) cells are still not refreshing (on screen). It is only after I navigate and F2 in each [and every] cell individually that the value comes up visible (as opposed to the normal object handler error of #NUM!). This issue is that It is not errored, but will not spontaneously recalc (in visible terms into the contents of the cell). 

I create a strike curve (discrete) into cells, and then build a new =qlBlackConstantVol(...),  and then a =qlGeneralizedBlackScholesProcess(...). I then create a bumped (shifted surface) and calc prices on this also. So the effect is a large table of handles (strings), to calls and puts, and bumped calls and puts. The table measures about r60*c16), and there are explicit dependencies, which is a preference, indeed. Problem is it's full of #NUM! until I go and F2 them and then go to the inquiry cells ( =qlInstrumentNPV(...) ).

Has anyone else reported any similar issues to this sort of thing?

Kind regards

Rohan Talwar

---

From: Eric Ehlers <[hidden email]>
To: rohan talwar <[hidden email]>
Cc: [hidden email]
Sent: Sat, 22 January, 2011 4:05:21
Subject: Re: [Quantlib-users] Stale handles from objectHandler?

Hi Rohan,

Welcome to the mailing list and apologies for the delay in responding.

Do you have calculation set to manual or automatic?  The latter would be the usual choice for a workbook receiving a live data feed.

In a correctly designed workbook, under automatic calculation, any change in inputs should result in an automatic update of outputs (i.e. dependent cells).  With calculation set to manual, then after a change in inputs, hitting F9 to invoke an incremental recalculation should be sufficient to update all outputs.  You can use Ctrl-Alt-F9 to force a full recalculation of all cells, this is a brute force measure which should not normally be required during production usage, perhaps once just after opening workbook(s).  Hitting F2 to refresh individual cells shouldn't be necessary.

If a change in inputs does not result in the expected change in outputs, this almost certainly points to a flaw in the design of the workbook.  I doubt that the versions of Excel and Windows are likely to be relevant.  It is a question of ensuring that each formula refers to the cells on which it depends.  Usually explicit cell references are preferred, though in some cases triggers might be required, please see http://quantlib.org/objecthandler/references.html.

Regards,
Eric

===================================================
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
* Distributed computing for pricing analytics
* Use Microsoft Excel as a client to the Grid

Quoting rohan talwar <[hidden email]>:

> Hi all, I posted this a couple of weeks ago.
> It would be really helpful if someone could let me know whether there are
> additional configuration steps involved with getting the implementation working
> robustly. Particularly whether xl version has anything to do with it, and even
> more remotely, the vista operating system.
>
> Basically, nothing recalcs on a worksheet (reliably - vanilla options, across a
> many point strike structure, calls and puts) - I don't think it is [generally]
> an issue with XL, per se, since any user defined functions work as expected with
> appropriate behavior vis-a-vis dirty precedents [cells].
>
> Would appreciate some help/feedback, as I am at a bit of a standstill. I don't
> want to junk the sheet.
>
> Thanks in advance
> Rohan Talwar
>
>
>
> ________________________________
> From: rohan talwar <[hidden email]>
> To: [hidden email]
> Sent: Mon, 10 January, 2011 21:48:07
> Subject: Stale handles from objectHandler?
>
>
> Hi, I am a new member of the quantlib user group, and new in general to this
> type of thing. I am not sure how to address this group, as I don't know who will
> answer.
>
> My setup is a folllows:
> OS=Windows Vista (32bit)
> XL = 2010
>
> I have written a worksheet which is fairly complicated by my own admission, and
> I am having troubles with stale handles or something like that. I think there is
> some issue with dependency tree/calc tree. When I full calc a sheet (the
> workbook), many cells do not update. When I visit an individual cell (recalc via
> F2) the value is updated. Prior to that it is #NUM! and there is no error - ie
> F2 provides value. I have a large table of values, which seems to  never update.
>
> Also, I am trying to remove explicit trigger params, since I do not manually
> reference objects, but do so via reference (to cells). Does this affect
> performace - vis-a-vis dependency tracking and the calc tree?
>
> There are some related queries, but I will leave these for follow on.
>
> Kind regards
> Rohan Talwar

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users