Multi Timeframe Problem?

[gspiker]

I have noticed what I think is a bug when a function running in one interval calls another that is running at a different interval.

The problem, in this case, is that the lines drawn reflect changes in the called EFS return and not what I think should be the return of the Caller EFS. This looks to me like it could be a called by address type error in eSignal, but maybe the experts can see some error in my code I'm missing.

I have recreated the error with a pretty simple set of EFS files (the original problem was created in a much more complex set of EFS files). CallerTest.efs is the Caller, and is attached in this message...CalledTest.efs is the called EFS and will be posted in the next message.

CallerTest.efs has the instructions for running.

Thanks for any help!

Garth

[gspiker]

CalledTest,efs

Save in same directory as CalledTest.efs

[gspiker]

A few additional comments (since I'm not sure how clear the last post was):

1) When I move the debug statements out of the "check for a new day" conditional in CallerTest, the output reflects what the drawn lines do - that the array is changing before the start of a new day.

2) The way CallerTest is coded however, should limit updates to the returned array to the start of a new day...unless there is some bug in my code I'm missing...

3) I don't believe there is a bug in my code (copious debug statements show the execution stream to be what I think it should be). So that points to some sort of unexpected behavior from the eSignal Engine. This looks similar to other problems I have seen with languages that pass variables by address rather than value...I'm not sure how JavaScript/EFS passes values, so that is just a shot in the dark.

Thanks to anyone who can provide help...

Garth

[Guest]

Hi Garth,

I believe I see what you are describing, and I believe it is by design. In your callertest efs, you are returning an array of three Series objects via the getSeries() function. If this were a call to a function the array would be passed by reference, if it were a return from a regular function it would be an array object. I am not positive how this is handled when coming from a return statement in the main function, as arrays are parsed to the chart in some manner. Returning a Series object is handled in a special way however, and it is purposeful.

Anyways, I believe what you are seeing lies in the getSeries() function returning the Series object to the chart. As I remember, this command was created, at least in part, to back-correct the chart in real time for the most up to date external interval bar value. This functionality ensures repeatability between live data and historical data when external intervals were used.

When live, the data from the external efs will change until the external interval bar is completed. At that point, the efs external data for the previous bar will no longer change, and the new bar data will be changing. (i.e. the external bar is corrected from the beginning of the current bar to the end of the current bar). This is not a very good explanation, but here is a thread where Alex explains it pretty well.

[gspiker]

Ahhhhh....thanks Steve.

I hate to think of the machinations they had to go through to do that. It makes sense...even if in my case it isn't what I want.

I'm hoping a level of indirection will provide the workaround...I bet it will.

Thanks again...and have a great new year!

Garth

[gspiker]

Just in case anyone ever runs into this issue again...here is my simple fix to the caller program.

Amazingly simple really.

Thanks again Steve.

Garth

[Guest]

Hi Garth,

You are most welcome. Thanks for the followup efs.