|
PureBytes Links
Trading Reference Links
|
Thank you Wayne, I think you're onto something in the Tracking Center there.
After all, when you look at what happens, there are only so many possible
answers.
The fact is, I've been trading now with the "cludgy" addition of all the
false conditions, and the bottom line is, it works.
If I attempt to revert back to a simple if, then, else structure... same
problem crops up.
I had never seen this before because in the past, my conditions were
mutually exclusive, this was the first time I attempted toggles where more
than one in the list could be "on" at the same time, and I was relying on
the else separation to force an exclusive execution order.
Sometimes TS is "stranger than fiction".
Best regards,
Gene Pope
----- Original Message -----
From: "Wayne Mathews" <wayne@xxxxxxxxx>
To: <gene@xxxxxxxxxxxxx>; <davestan@xxxxxxxxxx>
Cc: "=omega list" <omega-list@xxxxxxxxxx>
Sent: Monday, June 17, 2002 6:46 PM
Subject: Re: Multiple Alerts in Indicators
> Gene:
>
> You have read the manual correctly. Once an "else" condition is true,
> code execution will move to the code right after the immediate next
> semicolon. Only one of the "else" (Flags) should be executed in your
> case per tick.
>
> If both Flag1 and Flag3 are true at the same time then you will not see
> the alert for Flag3 (it is strange you only see Flag3). But with
> updating on every tick, the Flags can change from true to false and visa
> versa within a current minute bar. This can (will) cause any or all the
> alerts to trigger within the current bar. If you plot the Flags in a
> minute chart (if Flag1 then plot1(c - .005*c), etc.) with a ShowMe you
> can see when they trigger.
>
> David, I do not see how your solution fixes the problem. Your code just
> mimics "if .then else" code and will give the same result if the two
> "else" are replaced with a semicolon (and should match the "else" code).
>
> What is dangerous here is that two equivalent pieces of code seem not to
> give the same results for you. This may mean that there is another
> problem (such as, missing minutes which I recently found to be the cause
> of total volumes not matching in some tick and minute charts).
>
> More of your code would have to be revealed to understand this paradox.
>
>
> In a 1 minute chart, I tested the code below in a ShowMe three different
> ways. 1.) as is, 2. the brackets removed and 3. the brackets removed
> and "else" replaced with a semicolon. All three gave the same results.
>
> if o>c then alert("Y") else
> if c>c[1] {and o<=c} then alert("YY") else
> if c>o[1] {and o<=c and c<=c[1]} then alert("YYY");
>
> (o<=c is the same as o>c being false)
>
> I used a camcorder (15f/s) to capture many minutes of data from the 1
> tick chart and the Tracking Center together. The playback can be one
> frame at a time.
>
> If "Update every tick" is enabled for the above ShowMe in a 1 minute
> chart and one tries correlating the alert sequence in the Tracking
> Center with a one tick chart it will be found that there is no
> correlation. The sequence shown in the Tracking Center for a 1 minute
> interval can change as new ticks trigger new alerts. Many times, there
> are more alerts shown than would be indicated from the 1 tick chart!
>
> My conculsion is that the Tracking Center can not be relied on to
> denote time sequence or number of alerts.
>
> I used the indicator code below in the 1 tick chart to help follow the
> results. It draws a horizontal lines during a minute for c[1] and o[1].
> This like Omega's indicator "Day Open-Close line" in a minute chart but
> for Minute open-close in a tick chart.
>
>
>
> var: x(0),cl(0);
> array: op[10](0);
>
> If DataCompression <= 1 Then Begin
> If t<>t[1] Then Begin
> cl=c[1];
> for x=0 downto 0 begin
> op[x+1]=op[x];
> end;
> op[0]=o;
> plot3(c+.001*c); {style: histogram}
> End;
> plot1(op[1] ); {style: line}
> plot2[1](cl); {style: line}
> End;
>
>
>
>
> On Mon, 10 Jun 2002 10:53:42 -0700 David b. stanley wrote
>
> >If Flag1 then Alert ("Your zipper is down") else
> >If Flag2 and Flag1=false then Alert ("Your zipper is caught") else
> >If Flag3 and Flag1=false and Flage2=false then Alert ("You need to go to
>Emergency");
>
> >Have you tried it like this to see what happens? Even on ticks where
>multiple Flags are true, it should give the priorty to the earliest hit
>flag.
>
>
> On Mon, 10 Jun 2002 12:05:06 -0400 Gene Pope wrote
>
> >Thank you very much David, that appears to have done the trick.
> >Any other variations are of course, welcome.
>
>
>
> On Mon, 10 Jun 2002 11:13:12 -0400 Gene wrote
>
> > I'm encountering with multiple Alerts in a single Indicator intraday.
> > Let's say I'm using flags as toggles:
> >
> > Flag1 = Blah>Blah[4] and Blech[4]<Blech;
> > Flag2 = Blech>Blech[1] and Blimey<Blah;
> > Flag3 = BiteMe[1]>Blah[2];
> >
> > Now, assume that the indicator is updated on a tick by tick basis. > At
anyone tick, Flag1 and Flag3 might both be True.
> > I had coded an Alert as follows in order to have only one toggle be able
> togenerate an Alert at one time:
> >
> > If Flag1 then Alert ("Your zipper is down") else
> > If Flag2 then Alert ("Your zipper is caught") else
> > If Flag3 then Alert ("You need to go to Emergency");
> >
> > In this case, even with the else statements, only the Alert triggered by
>Flag3 will trigger. The Flag1 Alert never triggers. It's as if only the
>last True Alert counts, even if nested within If Else statements. My
>reading of the manual led me to believe that else conditions could isolate
>the Alerts.
>
|