MTF + out range index value + BarsRequiredToTrade : problem

[NinjaTrader_ChelseaB]

Hello Amedeus,

In a test script, reduce the code to just what is causing the error.

To export a NinjaTrader 8 NinjaScript so this can be shared and imported by the recipient do the following:

1. Click Tools -> Export -> NinjaScript...
2. Click the 'add' link -> check the box(es) for the script(s) and reference(s) you want to include
3. Click the 'Export' button
4. Enter a unique name for the file in the value for 'File name:'
5. Choose a save location -> click Save
6. Click OK to clear the export location message

By default your exported file will be in the following location:

• (My) Documents/NinjaTrader 8/bin/Custom/ExportNinjaScript/<export_file_name.zip>

Below is a link to the help guide on Exporting NinjaScripts.
http://ninjatrader.com/support/helpG...-us/export.htm


However, I recommend instead, providing the output from the output window saved to a text file.

Prints with the information showing the issue from the reduced script.
The print you have have looks ok but is commented out, and would be good information.
Print(string.Format("{0} | From OnBarUpdate BarsInProgress: {1}, {2} {3} {4} {5} {6}", Time[0], BarsInProgress, CurrentBar, Instrument.FullName, BarsPeriod.Value, BarsPeriod.BarsPeriodType, Count ));

Then which ever condition is causing the error would be the only condition that remains and everything else would be deleted.

Prints would be added for the remaining single condition an error. Just as an example:

Print(string.Format("{0} | CurrentBars[2]: {1} > 150", Time[0], CurrentBars[2] ));
Print(string.Format("{0} | CrossAbove(Closes[2], KC2.Lower, 200): {1} > 150", Time[0], CrossAbove(Closes[2], KC2.Lower, 200)));
if ((CurrentBars[2] > 150) && (CrossAbove(Closes[2], KC2.Lower, 200) == true) )

This particular condition I would expect to cause an error. The check is only that CurrentBars[2] has gotten to 150 and the CrossAbove() is using a lookback period of 200. So immediately on bar 151 an error would be hit from an invalid index.

You are correct in that when using added series, MaximumBarsLookBack must be set to MaximumBarsLookBack.Infinite to prevent errors with indexes larger than 256.

https://ninjatrader.com/support/helpGuides/nt8/maximumbarslookback.htm

[Amedeus]

Hey Chelsea, thank you,

if ((CurrentBars[2] > 150) && (CrossAbove(Closes[2], KC2.Lower, 200) == true) )

This particular condition I would expect to cause an error. The check is only that CurrentBars[2] has gotten to 150 and the CrossAbove() is using a lookback period of 200. So immediately on bar 151 an error would be hit from an invalid index.

Attached is this condition. I would expect to cause an error too.
Because we miss 50 bars of lookback to call KC2.Lower.
An error should be hit at 151th.
This script causes no error...

An error should be hit is what we've been trying to point out since we know post4 and executed post5.

Allthough I could find hilarious if I just were missing an elementary point about how c# NS objects interact,
Are we not like breaking the matrix here, if like me you expect this script to cause an error ?
Why is this script not as good as the one you would have me exported if another result few posts back ?

I understood we should use prints when an index is calling the error,
and in our previous examples finally concluded that barsRequiredToTrade is less than the requiered lookback. Thus our post5 adaptation.

here there is no error.

[NinjaTrader_PaulH]

Hello Amedeus,

Thanks for your reply.

This is Paul responding for Chelsea who is out of the office today.

To try to help I performed this test in a strategy, with a single time frame:

protected override void OnBarUpdate()
{
if (CrossAbove(Close, SMA(200), 200))
{
Print (Time[0]+" Test");
}
}

No errors were produced and many print statements were produced.

If you look at the code for the SMA indicator you will see that it adjusts for the current bar count relative to Period to prevent bar access errors.

The code for the CrossAbove code is not exposed but the fact that it does not error out hints that it also prevents prior bar access errors by comparing the lookback to the current bar.

[Amedeus]

Hi Paul, thank you very much,

Of course it helps. Previous reducing was poor : I did not realized or consider that ANY referencing to an abject can/could count as a Call. Even before OnBarUpdate. That's what I took from your last note, but we'll see it'not really well taken.
And the slightly higher MTF complexity does not help for now.

But I am not really sure that ANY referencing to an abject can count as a Call, because going on with your test this condition outputs the attached .txt ( the last line is in the following block ) :

protected override void OnBarUpdate()
{
Print(string.Format("{0} | New OnBarUpdate : BarsInProgress: {1}, CurrentBar: {2}, {3} {4} {5}, Count: {6}", Time[0], BarsInProgress, CurrentBar, Instrument.FullName, BarsPeriod.Value, BarsPeriod.BarsPeriodType, Count ));

if (CrossAbove(Close, SMA(10), 71))
{
Print(string.Format("{0} | in Action : CurrentBars[0]: {1} < 10", Time[0], CurrentBars[0] ));
Print(string.Format("{0} | in Action : (CrossAbove(Close, SMA(10), 71)): {1} < 10", Time[0], CrossAbove(Close, SMA(10), 71)));
}

09/06/2021 22:59:41 | New OnBarUpdate : BarsInProgress: 0, CurrentBar: 247812, MGC 08-21 90 Tick, Count: 247814
09/06/2021 22:59:41 | in Action : CurrentBars[0]: 247812 < 10
09/06/2021 22:59:41 | in Action : (CrossAbove(Close, SMA(10), 71)): True < 10

As we can see, CurrentBar are a lot higher that the supposed Loockback of 10. Also there is no error. Were we not all expecting an error at the 11th CurrentBar... ?

Is this output lighting out why the 71th double from CurrentBars[0] collection was accesible ?

[Amedeus]

Hey everyone,

I am sorry, I did misconstruct post34 :

ANY referencing to an abject DOES NOT count as a Call is not the conclusion of post34 observation.
(post 34 or 6 still remains an active topic)
**

ANY referencing to an abject count as a Call : was the hypothesis
But on a simpler MTF, I did test these 2 conditions when the indicator loockback is higher than the Standard CurrentBar Check like in the attached .txt :

// if (CrossAbove(Closes[2], KC2.Lower, 19) == true) // working
if (CrossAbove(Closes[2], KC2.Lower, 21) == true) // analyzer error

it appears that the Standard CurrentBar Check would be ruling over a potential indicator lookback call.

here below attached are the scipt for this condition from (State == State.Configure) to the condition, and the print that goes with the 2nd uncommentd condition.
the print confirms the error occurs on CurrentBar 62 wich is during the 20th CurrentBars[2] historical processing.

[NinjaTrader_ChelseaB]

Hello Amedeus,

Yes, calling a reference is using a variable that holds an object in memory. We are calling the object from memory.

Any time that variable is used, this is calling the object that variable references from memory.

In post #26, I let you know you are calling the object before checking that there is a valid index, then you check CurrentBars after its called.
https://ninjatrader.com/support/foru...44#post1160244

In post #32, likely the code above the line you interested in is causing the unexpected behavior.

https://ninjatrader.com/support/forum/forum/ninjatrader-8/strategy-development/1159749-mtf-out-range-index-value-barsrequiredtotrade-problem?p=1160525#post1160525

As previously suggested, remove all code that is not the condition you are interested in. Reduce the script.

[Amedeus]

Hey Chelsea, thank you very much,

Allthough I realize the words I use just shine and can even be inspirational sometimes, it feels like I've been overestimated. Until lately I did not have any practical clue regarding such a basic characteristic of coding regardless of the language.
Yet a simple Crossabove or gtreater/lesser condition is a very simple thing for anybody to understand, it can be used by anybody thanks to the very specific and evolved configuration of code that NS allows. In other words, it has been made easy but implies so much.

To contextualize, I've started NS just a few weeks back with a MTF... after partially realizing what a strategy can be, then a MTF strategy... thanks to the MTF video with the builder that is around btw.
I've updated my profile status regarding this. . I do not need to mention this explains the excessive break down all the way, or the repetitions under different angles.


**


Now that this exercice has led us to a very slightly better consideration of how, why and were a line is placed and how it could impact the following code.
We've been able to present clearly in the attached .txt, and narrow down a little bit better which condition was causing the previous //analyzer error - chart Working phenomenon that was so disturbing for everyone.

First, is this not a methodical enough reducing ?
We have here all the problems : analyzer/chart divergent results, while way over the CurrentBar Check.
What makes the chart not error out at the 21th CurrentBars[2] ?
What about the prints ? could we target our troubles better ?

[NinjaTrader_ChelseaB]

Hello Amedeus,

The script in your post is not reduced. This has a great many lines of code in it.

A reduced test script would have one line of logic code in it. Any necessary objects to support that one line of logic would be added so the script can compile, or get variables to hold the values they need for this one line.

Then that one line would be reduced to a specific variable or specific value or specific comparison or a specific index.

You stated you are experiencing an error?

What line of code is causing an error? Make a new script and copy that one line of code to the new script.

[Amedeus]

Hi Chelsea, thank you,

It was not the right file.
Attached is the code plus the two outputs.

Is this better ?

[Amedeus]

Hey Chelsea,

going further with this same sample,

we can see that when we add CurrentBars[4]'s Check, like in test4 and tes4B in the attached file,
without changing CurrentBars[2]'s Check,
It allows CurrentBars[2] to have access to it's far away collection even in the analyzer. It's not causing any error.

This suggests that the CurrentBars[2] check is not necessary for the analyzer anymore, unlike indicated in post #4...
or does this suggests something else too ?
Do each index need to be superior or the biggest CurrentBars rules over the Lookback "lenght" ?

***

Also, unrelated or undirectly related,
how come the ratios from the CurrentBars[1] print in if (BarsInProgress == 1) is not found again in the output ?
the ratio between the series period is the same used in the print but the output gives us a difference. Do you have a clue as of why ?
example : in test4B we print under BarsInProgress == 1 :

Print(string.Format(" CurrentBars[1] : {0} | = {1}th CurrentBars[2] | = {2}th CurrentBars[3] | = {3}th CurrentBars[4]" , CurrentBars[1], CurrentBars[1]/3, CurrentBars[1]/6 , CurrentBars[1]/60 ) );

But the result of this ratio is unequal to the real CurrentBars[4] number which is 4308

 CurrentBars[1] : 247812 | = 82604th CurrentBars[2] | = 41302th CurrentBars[3] | = 4130th CurrentBars[4]
CurrentBars[2] : 82722
CurrentBars[4] : 4308 | CurrentBars[4] > BarsRequiredToTrade = True

[NinjaTrader_ChelseaB]

Hello Amedeus,

As a tip for the print, print the actual value of currentbar..

Print(string.Format("{0} | BIP: {1}, {2} {3} {4}, CurrentBar: {5}", Time[0], BarsInProgress, Instrument.FullName, BarsPeriod.Value, BarsPeriod.BarsPeriodType, CurrentBar));

With the conditions:
if (CurrentBars[0] < 1
|| CurrentBars[1] < 1
|| CurrentBars[2] < 1
) return;

And
if (BarsInProgress == 1)
{
if (CrossAbove(Closes[2], KC2.Lower, 200) == true)
{

I am only seeing that CurrentBars 0 through 2 are checked to be greater than 1, and only Closes[2] is called both directly and as the input series for KC2.

I would expect that if this script updates when CurrentBars[2] is less than 200 there will be an index error. If CurrentBar is greater than 200 when BarsInProgress is 2, then there will be no index error. This means if the print above shows the last index of BarsInProgress 2 to have CurrentBar at less than 200. (edit, that last bit wasn't useful information for this)

[Amedeus]

Hey Chelsea, thank you,

as expected, when there is only :
if (CurrentBars[0] < 1 || CurrentBars[1] < 1 || CurrentBars[2] < 1 ) return;
before this confdition :
if (CurrentBars[2] < 200) , we get an error, on both chart and analyzer.
or this condition :
if (CurrentBars[2] > 200) , we do not get an error, on both chart and analyzer.

***

This means if the print above shows
the last index of BarsInProgress 2 to have CurrentBar at less than 200.
When this script starts processing OnBarUpdate data will depend on the series added to the script.

Could you please rephrase ?
How would it not depend on the series added ?

[NinjaTrader_ChelseaB]

Hello Amedeus,

When using multiple series, data processing will not begin until all series have data.

This actually wasn't relevant to say. It's not related to the indexing error.

[Amedeus]

hey Chelsea, thanks,

Then we are left with these conditions :
if (CurrentBars[0] < BarsRequiredToTrade
|| CurrentBars[1] < BarsRequiredToTrade
|| CurrentBars[2] < BarsRequiredToTrade
) return; //

the strategy behaves differently on chart or analyzer as soon as this is added to the script.
Do you have a clue as of why the strategy does not errors out at the 21th CurrentBar of the 3rd series ([2]) anymore when on the chart ?
Do the prints tell ?

below is the script and output when CurrentBars[2] is less than 200.

[NinjaTrader_ChelseaB]

Hello Amedeus,

Use prints to understand behavior. Print the values used in the condition set.

Print the value of BarsRequiredToTrade.

Print(string.Format("{0} | BIP: {1}, {2} {3} {4}, BarsRequiredToTrade: {5}, CurrentBar: {6}", Time[0], BarsInProgress, Instrument.FullName, BarsPeriod.Value, BarsPeriod.BarsPeriodType, BarsRequiredToTrade, CurrentBar));