[kepler-dev] FSMDirector and wire issues

ian.brown@hsbcib.com ian.brown at hsbcib.com
Tue Nov 13 01:04:51 PST 2007


Edward, thankyou for this. It's very much appreciated.

Ian




"Edward A. Lee" <eal at eecs.berkeley.edu> 
13/11/2007 02:13
Mail Size: 5552

To
kepler-dev at ecoinformatics.org, ian.brown at hsbcib.com, 
ptresearch at chess.eecs.berkeley.edu
cc

Subject
Re: [kepler-dev] FSMDirector and wire issues
Entity
Investment Banking Europe - IBEU







The following extreme inefficiency with DE models that include
an FSMDirector (e.g. with a ModalModel) was reported some time ago by
Ian Brown.  I've modified DE so that recomputing function dependencies
is no longer necessary, so I've removed it.  This should dramatically
improve performance of DE models using FSM.

The only other domain affected by this (I think) is SR.
In SR, function dependencies are an optimization, not an absolute
requirement, so this change should not affect correctness of execution.
A more complete fix, however, would modify ModalModel so that it
constructs a conservative approximation of the dependency information 
by merging dependency information of all state refinements.

Edward


------ original dialog:

>2) The FSMDirector changes the workspace version on a transition. I have 
a
>DEDirector with a FSM modal model in it. In this model is another
>DEDirector. Events come in at about every 50 milliseconds and for each
>event we have on average 2 state transitions. Due to the workspace
>increment (see line 579 in FSMDirector.java) when DEDirector.fireAt() is
>next called (which is called by FSMDirector.postfire()) the entire DAG is
>rebuilt by DEDirector.getDepthOfActor().
>This obviously decimates the performance (there is more than an order of
>magnitude difference than when the state transition is not taken) and I
>don't think it should be necessary. Can someone who knows the code please
>comment - I am happy to investigate the change but would like to 
understand
>the background reasoning for the current implementation first.

Yes, this is completely bogus... There is a FIXME there,
which unfortunately will be a fair amount of work to fix...
I'll take this on, however, since being able to use FSM in DE
is very important (particularly for our own PTIDES work).

Edward


------------ 
Edward A. Lee
Chair of EECS and Robert S. Pepper Distinguished Professor
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253, fax: 510-642-2845
eal at eecs.Berkeley.EDU, 
http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html 




************************************************************
HSBC Bank plc may be solicited in the course of its placement efforts for 
a new issue, by investment clients of the firm for whom the Bank as a firm 
already provides other services. It may equally decide to allocate to its 
own proprietary book or with an associate of HSBC Group. This represents a 
potential conflict of interest. HSBC Bank plc has internal arrangements 
designed to ensure that the firm would give unbiased and full advice to 
the corporate finance client about the valuation and pricing of the 
offering as well as internal systems, controls and procedures to identify 
and manage conflicts of interest.

HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom
Registered in England - Number 14259
Authorised and regulated by the Financial Services Authority.
************************************************************



-----------------------------------------
SAVE PAPER - THINK BEFORE YOU PRINT!

This transmission has been issued by a member of the HSBC Group
"HSBC" for the information of the addressee only and should not be
reproduced and/or distributed to any other person. Each page
attached hereto must be read in conjunction with any disclaimer
which forms part of it. Unless otherwise stated, this transmission
is neither an offer nor the solicitation of an offer to sell or
purchase any investment. Its contents are based on information
obtained from sources believed to be reliable but HSBC makes no
representation and accepts no responsibility or liability as to its
completeness or accuracy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20071113/6f2d2e97/attachment.htm


More information about the Kepler-dev mailing list