|
PureBytes Links
Trading Reference Links
|
I want to take issue with one point Gary made - that there's a good reason
for this bizarre behavior. In fact, there is NOT any good reason because
there are other, better ways to have designed the program to avoid the
problem consequences Gary correctly describes. Years ago I described to
Omega the proper way to have handled this situation (as well as the
so-called "bouncing-tick" problem - I'm a retired software engineer) but
they never implemented my suggestions. Their "solution" is a kluge and it
violates a fundamental programming principle: that any value assigned to a
variable within a program RETAINS that value until the program reassigns it
or until the program exits the context in which the variable is defined;
the underlying support system should NEVER covertly alter the user's
assigned value.
Carroll Slemaker
----- Original Message -----
From: "Gary Fritz" <fritz@xxxxxxxx>
To: "Brian" <blink64@xxxxxxxxx>
Cc: "Omega list" <omega-list@xxxxxxxxxx>
Sent: Wednesday, December 12, 2001 10:31 AM
Subject: Re: Update every tick
<snip>
> Why does TS do this bizarre behavior? Believe it or not there's a
> good reason. This way, the indicator plots the same values whether
> or not UET is set. If it didn't do that, you'd see NTicks increment
> on 1 tick per bar when you apply it to historic data (since the
> indicator would run once per bar), then IF you had UET set, you'd see
> the indicator increment by some number >1 for any bars you received
> in realtime. That would be VERY confusing and non-reproduceable. By
> resetting all vars to the start-of-bar values, TS can run the
> indicator on each tick and still get the same results you'd get if
> UET was off.
|