Backtest with only 1 indicator

[ChuckAllen]

I can get backtests to work comparing one indicator to another.
For example: when the 3 bar crosses over the 8 bar average.
If I want to go long when the SAME indicator is used (today's indicator's value > the same indicator's value for yesterday's), the analyzer just chews through the data for a long time & all screens, charts, etc. are blank. If I change the 2nd indicator to any other indicator, it works fine.
Basically, on a 4 tick range chart, if this bar's LinReg(6) > the LinReg(6) of the previous bar...go long. Same logic, but reverse for going short.
Could someone please just supply the 4-8 lines of code that works.
The code I am trying is automatically created by NT.
I have also tried the same exact code that works when running an actual strategy, but it won't work in the analyzer.

[NinjaTrader_Austin]

ChuckAllen, are there are any errors in the logs (right-most tab of Control Center)? Can you please copy + paste the code from "view code" so we can see if anything looks out of place?

[ChuckAllen]

Here are the 2 files that were requested.

LinReg4Tick.Cs - The file NT created for the backtest. I did not change anything that NT created.

NT-LogFileErrors.Jpg - The log file. 3 errors were generated while trying to run the backtest. NO ERRORS WERE DISPLAYED DURING THE TEST!!! You definitely should tell us that something went wrong & to check the log file. The ton of other errors are from ShadowTraders software. Your tech support showed me how to ignore/disable their code/dll, so these errors should not matter. Nothing from ShadowTraders is used in any code or on any chart.

[NinjaTrader_Austin]

ChuckAllen, could you try specifying a signal name for your entry signals? I looked at the code and it looks like it should be fine.

Can you please try re-posting the LogFileErrors.jpg file? I don't think it worked the first time...

[ChuckAllen]

Naming the Entries Does Not Help!

I named the long & short entries.
It still does the same thing! NOTHING.
It chews on the data for a while...1 month, 2+ minutes, then
just acts like it did something. No error message, Nothing that says it could not work, No message to see the log file, no indication at all!
Please fix in the next version and tell us that something is wrong when a
backtest doesn't do anything, or trade anything.
In case the log file does not make it again...

The following log message was generated 3 TIMES in the log file.

Error on getting/setting property 'Bars' for strategy 'LinReg4Tick'. Item has already been added. Key in dictionary: 'Int32 Bars'. Key being added: 'Int32 Bars'.

Please actually run the same code & duplicate the error.
I do not do ANY custom coding. All coding is done from your wizard.
Again, this basic code works fine everywhere except in your backtesting.
Is the work Bars something that cannot be used here?
If so...Please Tell Us During Compilation!

That's the only thing I can see that would possibly cause problems.

Files I am trying to submit to you:
LinReg4Tick.Cs - Latest source code, with Named Entries.
NTNamedEntries.Jpg - Screen dump after running the backtest & getting nothing.
NT-LogFileErrors.Jpg - Screen dump of the log file.

[ChuckAllen]

Several Bugs That Should Be Fixed!!


Since you told me in your response to send the log files, I took the time to try something silly.
In the logic, I want 1 indicator...LinReg(6).
If this bar's LinReg >= the previous bar's LinReg...Go Long If this bar's LinReg < the previous bar's LinReg...Go Short

There is NO REASON why I should have to use 4 variables for the same indicator...
But this seems to work.

If I name the 'Go Long' number of bars 'BarL1' and BarL2'...
and name the 'Go Short' number of bars 'BarS1' and BarS2'...
it works.

Please make it a HIGH PRIORITY to fix the following bugs in the next version.

1) We should be able to use the same variable more than once without having to
name the exact same value several different ways.
I had to name 'Bars'...BarsL1, BarsL2, BarsS1, and BarsS2, just to get the backtest
to work. With this bug...
How would we do an optimization with this limitation????
How can I say All 4 Of These Variables Are The Same & Must Be Incremented
To The Same Value For Each Optimization Loop?

2) When there is a problem in the backtesting...Tell us!!!

3) If no trades are generated in the backtesting...Tell us!!!

4) If we should/must look to the log files for information on problems...Tell us!!!

5) If we can't use 'Bars' multiple times or as a variable...Tell us!!!
The compilation worked inside and outside the backtesting wizard.

The following code changes worked!

protected override void OnBarUpdate()
{
// Condition set 1
if (LinReg(BarsL1)[0] >= LinReg(BarsL2)[1])
{
EnterLong(DefaultQuantity, "LongEntry");
}
// Condition set 2
if (LinReg(BarsS1)[0] < LinReg(BarsS2)[1])
{
EnterShort(DefaultQuantity, "ShortEntry");
}
}

[NinjaTrader_JoshP]

1. Please see response to #5.

2. Please clarify what you mean by "problem".

3. When there are no trades in a backtest it simply means none of your trade conditions were true 90% of the time. If an error occurred while running your code to prevent trades, you would see the error in the Control Center logs. If there was a trade specific reason why orders were ignored you would see them in the Output Window if you use TraceOrders = true.

4. You should always look to the log files for runtime errors with your script. This is the first thing you should look into when you feel something is behaving unexpected.

5. There is no issue using a variable multiple times provided you created the variable correctly. Issue you ran into is because you used a reserved word that you cannot use. Please use a word that is not "Bars".

[ChuckAllen]

Backtest &amp; Compiler Bugs--In my opinion

I am going to write my responses in a text file and attach later.

[NinjaTrader_JoshP]

Chuck,

Thank you. For #5, we realize that there was no way for you to know "Bars" was a reserved word, but you should be able to do what you were attempting when you use another word. Generally, the reserved words are words you see in the Help Guide. So something like Close, Open, High, etc. would be reserved words. Indicator names like SMA would also be reserved. Hopefully that information would reduce the occurrences of this for your future use of the Strategy Wizard.

[ChuckAllen]

Responses to Reserved Words &amp; Compilation Errors, etc.

1) You said: 1. Please see response to #5.
5. There is no issue using a variable multiple times
provided you created the variable correctly. Issue
you ran into is because you used a reserved word that
you cannot use. Please use a word that is not "Bars".
1) My Response:
I DID NOT CREATE THE CODE, NT DID!!
Everything was created in the Strategy Wizard.
There are several problems & bugs when your compilation
and/or wizard lets reserved words get through, and
especially when you keep the reasons a secret!
I wasted the better part of a week trying to figure out
anything on this issue that would solve the problem.
I would never have guessed that the problem was a lack
of communication.
Your compilation programmer needs to tell us something!!!
* If there is a problem with using reserved words...Tell us!
* If there is an error/warning during the backtest or
compilation that will cause a problem later...Tell us!
* If no trades are generated during a backtest and there
are no errors...Tell us!
* If we need to look at a log file for more information...
especially during compilation...Tell us!
The basic code is:
if there is a problem worth logging
LoggedProblems += 1;
...
if LoggedProblems > 0
Message(There were problems, see the log file.)
2) You said: 2. Please clarify what you mean by "problem".
2) My Response:
This is what I said originally:
"When there is a problem in the backtesting...Tell us!!!"
I believe this says it all!
When there is a problem Tell us!!!
If a reserved word is used...Tell us
If there is an error/warning...Tell us
If no trades are generated during a backtest...Tell us
If we need to look in the log file...Tell us
If you honestly don't see the problem, please feel free to
contact me. I will be glad to help you create a product and
run real QA tests on it.
I have been in the field for over 30 years...everything from
Real Technical Customer Support, Supervisor of Tech Support,
Senior Systems Software Engineer, VP of Software Development,
Systems Analyst, Consultant, etc.
3) You Said:
3. When there are no trades in a backtest it simply means none
of your trade conditions were true 90% of the time. If an
error occurred while running your code to prevent trades,
you would see the error in the Control Center logs. If there
was a trade specific reason why orders were ignored you would
see them in the Output Window if you use TraceOrders = true.
3) My Response:
Same thing again and again.
If nothing is told to us, how do we know if there was an
unknown error, compilation problem, reserved word problem,
logic problem, trade logic problem, etc.
If no trades were generated AND there were no errors or
warnings that could have caused it...Tell us!!!
Just post a simple message box that says something like:
"No trades were generated with the given logic.
No errors or warnings occured during the test.
For more information on a specific reason why the trades
were ignored...please set TraceOrders to true (on the XXX screen)
run the test again, and look at the Output Window."
Pretty simple and it says everything.
4) You Said:
4. You should always look to the log files for runtime errors
with your script. This is the first thing you should look
into when you feel something is behaving unexpected.
4) My Response:
Same thing again and again!!
NO COMPILATION OR RUNTIME ERRORS WERE LISTED!!!
NO mention of looking into the log file when by ALL indications
everything worked fine.
The normal response by the user in the field is that there is
a trade logic error...so hours, if not days are spent trying
to figure out what went wrong.
5) You Said:
5. There is no issue using a variable multiple times provided
you created the variable correctly. Issue you ran into is
because you used a reserved word that you cannot use.
Please use a word that is not "Bars".
5) My Response:
SAME AGAIN AND AGAIN.
Please quit blaming the users for creating code problems.
If you read any of my previous submitted problem notes...
I DID NOT CREATE ANYTHING, NT DID.
NT did not flag any problems.
Compilation was completely successful in the wizard and
if you compiled the code separately.
We have NO WAY of knowing what the problem could be without
some comments from the compilation and/or runtime execution.
I would NEVER have thought about using the same variable
more that once would cause a problem, except I had to grasp
for straws because no other information was put forth!!

[NinjaTrader_JoshP]

I understand you are frustrated, but this is the nature of debugging programming and code.

1. There is no way the compiler can tell you you are using a reserved word. When code is evaluated and you use such a word it thinks you are using it in the context in which it is reserved, hence the misbehavior. The way NT can hint you something is wrong is through weird, unexpected behavior you have seen. Unfortunately this is the nature of working with programming and code. The Strategy Wizard is there to help you have a layer of convenience on top of the code, but there is no way it will be able to cover all case scenarios you may come across. As mentioned before, should you feel unexpected behavior you should always look at the Log tab as the first thing you do.

2. What is the problem with backtesting? When you used a reserved word the error came up when you tried to press Finish in the Strategy Wizard. You were already informed with a message along the lines of Int32. The issue has nothing to do with backtesting. The issue was much farther upstream when you were making the strategy. As mentioned, the Strategy Wizard is a convenience layer on top of the code. You create what you want to do with the Wizard and after it is created it generates it into the exact NT code specified. Whether that code works or not is a different story. In this particular case, reserved words were unfortunately used. When such words are used the code compiler has no way to decipher what the intent was. All it knows is that "Bars" was trying to be used as an integer, but "Bars" is already used for other purposes and that is why it could not make sense as to what was going on in respect to Int32. This is the exact same error you would receive if you tried to hand code the same thing with a reserved word. Compilers unfortunately are not able to guess what the human intent was for "Bars". It can only inform you as to the confusion and it is ultimately up to the human to figure out the rest. In this case, we are glad you sent in a support request as we were able to help you identify this as the issue since it is definitely a hard one to spot.

3. Everything is already told to you in the Log tab should a runtime error occur. A backtester has no way of knowing what you would expect from a backtest. It simply evaluates the code of the strategy and does what the strategy tells it to do. It is impossible for it to know whether the end result is what you would expect or not. That is up to the human to interpret.

When you are developing a strategy debugging a strategy may be necessary. When debugging is necessary you will simply have to switch over to the debugging tools available (Log tab, Output Window). We will not be adding a popup message as this drastically slows down the development process for everyone who then all of a sudden needs to keep clicking OK on popup messages when they can already see everything they need to see in the Log tab.

4. Your screenshot is showing specifically the error that was ran into. Int32 Bars. This was seen in the Log tab and listed several times the moment it ran into issues.

5. You typed in "Bars" into the Strategy Wizard as an input in the "User Defined Inputs" page. That tells NT to create code using "Bars" as the variable name. NT does not make any code that was not user specified. Unfortunately there was no way for you to have known "Bars" was a reserved word except through experience with the error message given in the Log tab. All the proper notifications and hints were already given there.