Request for help with strategy code logic

[joemiller]

I was unclear. I should have said ---

I started the Wizard by editing the original strategy 'SwingRedBlueBars2'.
Then, within the Wizard I created strategy 'Koganam' via a 'save as Koganam'.
Now can I work entirely within the Wizard to modify strategy Koganam by visually scanning the new code you sent to make changes ... or are some changes outside the scope of the Wizard?

[koganam]

I was unclear. I should have said ---

I started the Wizard by editing the original strategy 'SwingRedBlueBars2'.
Then, within the Wizard I created strategy 'Koganam' via a 'save as Koganam'.
Now can I work entirely within the Wizard to modify strategy Koganam by visually scanning the new code you sent to make changes ... or are some changes outside the scope of the Wizard?

You would have to unlock the code before you could manually edit it. Once you unlock the code, you cannot use the wizard anymore.

The way the code is written cannot be done in the wizard. That is the essential limitation of all code generators: they can only do what they have been programmed to do, and nothing more.

You will have to use the code as I wrote it, and the wizard will not be able to edit that code.

Your simplest way would be to:

1. Start the wizard; name your file and immediately unlock the code. That will create a skeleton.
2. Delete all the text in the file.
3. Copy and paste the text from my file into the now empty file.
4. "Save as ..." to the name that you want the class and file to have.
5. Compile.

Even better, just do as I originally suggested.

1. Remove your file from the Strategy folder. (Just move it somewhere outside the NT tree).
2. Copy my file into the Strategy folder.
3. Rename the file to the same as the class name, or open the file for editing, then "Save as..." to the name that you want.
4. Compile.

Bottom line: the code is already unlocked. You cannot use the wizard on unlocked code.

[joemiller]

Got it done & everything working beautifully. Were it not for your turnkey code I would have eventually wound up in a straight jacket in a rubber room trying to make things work. I still don't understand why the difference in behavior in the Strategy Analyzer and a realtime chart, but no problem ... only 24 hours in a day ... gotta keep movin' on.

Regarding the ingrate:
I have been on this planet for 85 years but still shocked daily at how flat stupid we humans [including me] often are ... from wars to politics and everything else in between. We are our worst enemy.

Cheers & peace

[koganam]

Got it done & everything working beautifully. Were it not for your turnkey code I would have eventually wound up in a straight jacket in a rubber room trying to make things work. I still don't understand why the difference in behavior in the Strategy Analyzer and a realtime chart, but no problem ... only 24 hours in a day ... gotta keep movin' on.

From your own earlier submission regarding your understanding: "calculateonbarclose=false so bars [1] & [2] are yesterday and day before yesterday ... both bars are history and forever determined and unchanging ..."

By the same token, yesterday's bar when COBC = true is then Close[0]. So you would have to use 0 and 1. In the Strategy Analyzer, as the only data available are OHLC, all processing will have to occur as if COBC were true, regardless.

So the key is in when a tick is recognized; namely "What does Close[0] mean?" On historical bars and in the Strategy Analyzer, there can be only one tick per bar. That is not a NT issue; it is a logical issue of how data is processed by anything, computer or human brain, no difference. So that one (and only) tick logically then can only be recognized at the full formation of the bar, as the bar is all drawn at once, not built tick by tick over time. On the other hand, if COBC = false, and a bar is in realtime, current and, therefore, in the process of being built, the most recent tick is the last, and then current, tick of the building bar.

Think of it as: if COBC = false, the opening tick of a bar is recognized as distinct from the closing tick of the bar, and often has a different value, and every tick while the bar is building MAY become equal to the bar-closing tick, and was the recognized closing tick at some time during the bar : if COBC = true (or there is no way to recognize every tick in the bar), then there is no way to distinguish between the opening tick and the closing tick, albeit we can acknowledge it if they HAD different values, and that they may have occurred at different times.

Regarding the ingrate:
I have been on this planet for 85 years but still shocked daily at how flat stupid we humans [including me] often are ... from wars to politics and everything else in between. We are our worst enemy.

Cheers & peace

It is still a sad commentary when an ignoramus attacks those who know more than he does, simply because he has an anonymous forum in which to do so.

[joemiller]

Thanks Koganam ... nice explanation,

I think my problem may be that I did not realize that ''On historical bars and in the Strategy Analyzer, there can be only one tick per bar'' [i.e.] it never occurred to me that storing [for recall], tick data rather than just bar OHLC would require a humongous amount of storage?
I assumed that the tick data has been captured so would always be available for recall. Is that the reason [i.e.] does that make sense?

Even if that is correct, knowing the problem and then programming around it would have been a humongous challenge. Thus ... thanks again for the code.

[koganam]

Thanks Koganam ... nice explanation,

I think my problem may be that I did not realize that ''On historical bars and in the Strategy Analyzer, there can be only one tick per bar'' [i.e.] it never occurred to me that storing [for recall], tick data rather than just bar OHLC would require a humongous amount of storage?
I assumed that the tick data has been captured so would always be available for recall. Is that the reason [i.e.] does that make sense?

Even if that is correct, knowing the problem and then programming around it would have been a humongous challenge. Thus ... thanks again for the code.

Not quite. The issue is more in the matter of what data is available as exposed to the Strategy code itself. The Strategy code analyzes bars, pretty much all the time. NinjaTrader internally constructs the bar, from stored data. Depending on what type of bar, the bar may actually be constructed from stored tick data. However, the Strategy code simply sees a bar, through whatever properties it exposes. In NT7, this pretty much means the OHLC for the bars.

On historical bars, no other data internal to the bar is exposed, because that is how the bar object is created. If COBC is true, then at the instant that the bar will be evaluated, it in that very instant becomes in effect, historical, so again only its OHLC data is available. If COBC = false, however, then the bar is being processed as it is being constructed, so in effect, the current price, practically by definition, is dynamic, and can be analyzed in realtime, provided of course that it is being built in realtime.

[joemiller]

Not quite. The issue is more in the matter of what data is available as exposed to the Strategy code itself. The Strategy code analyzes bars, pretty much all the time. NinjaTrader internally constructs the bar, from stored data. Depending on what type of bar, the bar may actually be constructed from stored tick data. However, the Strategy code simply sees a bar, through whatever properties it exposes. In NT7, this pretty much means the OHLC for the bars.

On historical bars, no other data internal to the bar is exposed, because that is how the bar object is created. If COBC is true, then at the instant that the bar will be evaluated, it in that very instant becomes in effect, historical, so again only its OHLC data is available. If COBC = false, however, then the bar is being processed as it is being constructed, so in effect, the current price, practically by definition, is dynamic, and can be analyzed in realtime, provided of course that it is being built in realtime.

hi koganam,
just another thought if you are still in a conversational mood ...if tick data availability is not the strategy analyzer issue then is it that computational computer time to rebuild all the bars is the problem?

[koganam]

hi koganam,
just another thought if you are still in a conversational mood ...if tick data availability is not the strategy analyzer issue then is it that computational computer time to rebuild all the bars is the problem?

Kind of. Remember that NT7 was designed and built in what now, in computer terms, is the middle ages. Effectively, a design decision had to be made that took into account the average computing power then available. "Design follows function", so to speak.

It is not impossible to process tick data in the context of the Strategy Analyzer if one wants so to do. Indeed even NT7 allowed us to do so if we had the means and ability, by using as fine a timeframe as 1-tick as a secondary processing medium.

NT8 was a complete new design, and does make using tick data in the Strategy Analyzer and Historical charts a lot simpler, albeit also increasing the computer resource usage considerably. The larger amount of computer resources needed is hardly of any import, given the massive power of the average computer today.