Multiple conditions not simultaneous

[nothingtrader]

Hello! I'm working at a strategy with multiple conditions, I use bool triggers but it seems that it works only when all conditions are simultaneously met.
So, for example, the first condition would trigger when a bar has Delta < -1000 . The second condition is Close[0] > Close[1] (for the first time after condition1) and then enter long.
Just that it only works when the bar with Delta < -1000 has the Close[0] > Close[1] (pretty rare divergence). Of course, if I change Close[0] < Close[1], I can see clearly that it only works when both conditions are met simultaneously..Please help me Strategy Builder or the script editor, doesn't matter.
Thank you!!!

[NinjaTrader_ChrisL]

Hi nothingtrader, thanks for your post.

Im not sure if I have enough context here to help out. Could you please give me more details on the issue?

[bltdavid]

I've solved this problem using the concept of an 'EventBar' combined with
an 'EventWindow'.

When each event occurs, I set its EventBar to CurrentBar. An event is just an
occurrence of something you are interested in, such as Delta < -1000, or
Close[0] > Close[1]. An event is like a condition, the EventBar just records
on which bar the event happened.

(To me, an event is higher than a condition, since I may define 2 or more
boolean conditions as a single event. Defining an event being just one condition
is a nice mapping to get started with the concept)

Events are individual occurrences and constitute the building blocks of your
rules.

The EventWindow defines the 'keep alive' setting for that event. It is a number,
which means the number of bars that the event is 'alive' for purposes of asking
'is this event active?'

If you have 2 events, and you set their EventWindows both to 1, then you have
the situation where both events must occur on the same bar for the event alignment
check to return true. I almost never do that. Why? Because, well, that is your current
dilemma, where all conditions (aka events) must occur on the same bar -- that
is rare, usually not what you're wanting.

But if you set one of the EventWindows to, say 3, then you're saying that event
is active for 3 bars, so it can 'wait' for 3 bars for the other event to become alive.
When both event occurrences overlap due to their event windows, then the event
alignment check for all events is true, and wa-laah, you have your signal.

The point is, like you say, multiple events all happening together on the exact
same bar can be rare. So, what you really want is some wiggle room, where
all events happen within, say 2 or 3 bars of each other. This is more normal.
These '2 or 3 bars of each other' is the event windows at work.
When all the 'active' events overlap, you have your signal.

Make sense?

[nothingtrader]

I think I understand. But in my case I want the eventwindow to be indefinetly. So when the second condition happens it doesn't matter how many bars back the first condition was met, could be 1 bar or 50 bars.
I am waiting for a bar to have let's say delta < -1000 (this would trigger a bool). Then I am waiting for the first Close[0] to be above Close[1], this would be my signal for a long entry. But this will work only when both conditions happen simultaneously, on the same bar. I don't want that, I just want that the first condition to act like a trigger for the strategy to wait for the second condition to happen. Thank you!
This is the code:

private bool MyBoolLong;

protected override void OnBarUpdate()
{
if (BarsInProgress != 0)
return;

if (CurrentBars[0] < 1)
return;

// Set 1
if ((CrossBelow(Delta, -1000, 1))
&& (MyBoolLong == false))
{
MyBoolLong = true;
}

// Set 2
if ((MyBoolLong == true)
&& (Close[0] > Close[1]))
{
EnterLong(Convert.ToInt32(DefaultQuantity), "");
}

MyBoolLong = false;
}

[bltdavid]

No need for code yet, let's expand this idea of a 'signal engine'
and build out the model a bit more.

That is, sounds like you are ready for lesson #2.

Events are combined to produce a candidate signal.

This signal may have one or more confirmations applied.

Lesson #2 is about confirmations.

It sounds like your event is the 'Close[0] > Close[1]' condition.

When this event happens, that is your signal. You signal consists
of a single event, and that event consists of a single condition.

Only events have event windows.
In your case, I call that EventWindow=0, which means the event
window is unlimited, and the event (once it happens) is always 'alive'.
But your case also works well with EventWindow=1.

But the signal engine is not done yet.
After this candidate signal is found, your signal engine next checks
all the confirmation rules.

Confirmation rules don't have event windows. They are just a bunch
of conditions of whatever nature that must be true to confirm the
candidate signal that was found.

It sounds like you have a single confirmation rule, which is:
somewhere in the past there must have been a bar with Delta < -1000.

If the candidate signal survives all the confirmation rules,
the signal is confirmed.

Is this signal engine model any closer to expressing your situation?

[bltdavid]

Remember every time your condition Close[0] > Close[1] is true,
that is a new occurrence of the event.

Using EventWindow=1 means that on the same bar as the event
occurred, the signal engine checks that all confirmation rules are
also true.

There is nothing wrong with a confirmation rule that says
Delta < -1000 must have occurred with last, 50, or 100, or
500 bars, or minutes, or whatever

Lesson #3 is about lookback periods.
Lookback periods are up to you. It could include the entire
chart, if you wanted it to.

A lookback period is an optional component of a condition, it
usually augments the boolean operation, which is also just a
component of the condition. In fact, applying a boolean test
on the last 50 bars (aka, a lookback period) can be grouped
together as a unit and defined as a single condition. In fact,
both CrossAbove and CrossBelow are examples of conditions
that include a Lookback component.

Conditions with or without lookback periods are up to you, but
a condition with a lookback could easily be a confirmation rule.

The strategy builder encourages you to think in terms of conditions.

My point is: these are too primitive, and don't always help you think
of the overall signal engine model that matches what you see on
your charts. Entry signals can be complicated.

Conditions are elements of rules.
Rules are codified as either events or confirmations.
A candidate signal is found when all event rules are aligned.
This candidate signal is then confirmed by the confirmation rules.

The signal engine can be just a couple of lines of code, or it could
entail many hundreds of lines. Nonetheless, I've rarely found an
entry setup that could not be defined using this signal engine model
split between events and confirmations.

[bltdavid]

Also, I could have your conditions backwards.

Let's swap them around.

Maybe Delta < -1000 is your event, and so you set
its EventWindow to 0, which means the event window
is unlimited, which means (once the event happens)
it is always alive.

Your confirmation is Close[0] > Close [1].

When the event happens and is confirmed, you have your signal.

EDIT:
We first initialize EventBar to 0, which means the event has
not happened. When the event does happen, you set EventBar
to CurrentBar.

On every bar thereafter, your event is true (because EventWindow
being 0, this event is always alive, as long as EventBar != 0).

So, on every bar thereafter, the confirmation rule is being applied,
which is Close[0] > Close [1]. As soon as this is true, your signal
is confirmed, which means your candidate signal advances to
confirmed signal.

If you had more rules, like PnL checks, or Trade Hours limitations,
the confirmed signal is further filtered by these rules, at which
point, finally, if all these rules pass, you have your entry signal.

Make sense?

[nothingtrader]

Thank you for your wise answer and beautiful logic lesson! I sure have something to think about over the weekend. Lesson no.3 helped a lot, now just changing the lookback period of the CrossBelow condition brought me closer to what I want.