Swing indicator within strategies

[QuantKey_Bruce]

Yes, one learns the hard way that there are certain areas that are really solid, and others where they're solid for ad hoc use like on a chart but if you put them in a strategy that runs intrabar you can't necessarily trust them to give reproducible outcomes because they either weren't designed for intrabar or they have non-deterministic characteristics like they depend on the order some ticks arrive in OnMarketData for different series and things like that. You gradually develop a sort of second sense for where these danger areas are and learn to code defensively in this regard so you don't waste hours and hours chasing ghosts.

[Borgen]

I just don't use the Swing function - it's easier to just code up something to keep track of the siwng pivots yourself.

But, this is part of a broader context. If you regularly develop strategies that are intrabar, you necessarily must become attuned to the issue that unless you've looked at the code for the indicator and are sure it is correct for intrabar operation, you have to be very cautious. Usually, I don't worry about using simple things like SMA or EMA or RSI or Stochastics and the like but for something that has an "awareness of state" like a Swing or a ZigZag I've learned to be very cautious, and often I'll just code it in-line rather than calling the function because I don't want to risk losing hours trying to track down someone else's mistake, or worse yet, it looking like it was is my fault the strategy doesn't work when I was just relying on a functionality that I should not have relied on. It's the easiest thing in the world when writing an indicator like Swing to miss something about how to "reset" when it swings one way intrabar then swings back the other way and you have to "undo" the state flip you just did by returning to the state you were in before when the bar started. That sounds simple, but in a complex indicator it's easy to miss something and have a subtle bug.

An indicator like Swing absolutely can be fixed, and perhaps NinjaTrader will fix it. But right now, as you can see, we're still at the stage where we're trying to get a common understanding there is a problem, so if you would like to move forward, you should probably just code the swing determination. It's easy to do so. Then, you won't have to worry about whether the inbuilt one does it correctly.

QuantKey_Bruce - OMG, Thank you for writing about this and confirming things! I've been having strange bugs in indicators and strategies that use swing and ZZ. I suspected there was something buggy like this going on and it was driving me nuts in my debugging. Big thanks! I'm going to re-write pretty much all my logic based on these things.

So very annoyed that NT code can't be trusted. I'm done using Ninjacrap syntax now, gonna write everything from scratch instead.

[NinjaTrader_BrandonH]

Hello,

Thanks for your notes.

I was able to reproduce the behavior in question reguarding the Swing indicator and I reported the behavior to the Development team. They will look into the behavior as soon as they are available.

Once the Development team reaches back out to me with their findings I will update this forum thread with more information.

Thanks for reporting the behavior and providing steps to reproduce it.

[burmaz]

Hello lillomur,

Thank you for your patience.

I am unable to reproduce the same behavior on my end.

Please send me your log and trace files so that I may look into what occurred. You can do this by going to the Control Center-> Help-> Email Support. Ensuring 'Log and Trace Files' is checked will include these files. This is checked by default.

Please list 'ATTN: Patrick H' in the subject line and reference this thread in the body of the email.

I look forward to assisting you further.

Any official response from any at Ninjatrader considering the excellent recent explanations of the issue on this thread?

[QuantKey_Bruce]

Also, if you take note of where the bug happens, it's obviously when a pivot "would have" been detected and so it changed its internal state flag, but then price turned around and went back the other way intrabar, causing it to no longer be a pivot. But Swing does not go back fully to the way it was at the start of the bar - it loses track of the prior state which is why the swing high or swing low disappears. This is the sort of error that is commonplace in indicators that are not designed for intrabar operation and have an "awareness of state". They can be done correctly, it's just that there are lots of details that have to be right. The bug can often be found by noting any field variables in the indicator instance, and following those to figure out which one isn't getting reset back to the first tick of the bar value at the start of each evaluation.

[QuantKey_Bruce]

That's good. It is expected that it would not reproduce the error with tick replay disabled - there's no intrabar evlauation then. The point of the bug demonstration is that Swing does not handle intrabar updates correctly. With tick replay disabled, on historical bars, it would be the same with Calculate.OnPriceChange or Calculate.OnBarClose - one evaluation per bar.

Market replay would be the same as tick replay for this purpose - it's just another way to get the intrabar evaluations so the error can be demonstrated.

Thanks for taking the time to confirm the issue.

[bltdavid]

Excellent. Just now, I followed your steps (thanks for that).

Using just Historical minute data (no Playback) ...

With Tick Replay enabled, I reproduced your chart.

With Tick Replay disabled, the issue did not reproduce.

Here is my Tick Replay enabled chart showing the same issue,

[bltdavid]

Thanks, Bruce. I download that in a moment.

I was finally able to see the issue reproduce using Playback
Connection, it looks like the same issue in your screenshot.

I did not use Tick Replay, so I think that part is immaterial.

See below,

[QuantKey_Bruce]

bltdavid No, I did it just now, and I checked the box for Tick Replay.

These are the steps:

1. Make a new chart of ES 06-23. I chose the defaults on my system which are 1-minute bars and 5 days. Check the box for tick replay.
2. Add the Swing indicator with its default settings to the chart twice.
3. Change the second one to OnPriceChange. (The first one will remain its default OnBarClose.)
4. Change the first one to have dots size 4 for each plot and change the colors to dark blue and dark red so you can tell them apart from the defaults.
5. Click OK.

That's all there is to it. Here's a chart template though as well.

Let me know please if you are still unable to reproduce this.

Also, I doubt if this is the only bug, it is a bug.

[bltdavid]

Today, being Saturday, I was trying to recreate this using Playback
Connection, but in my testing I've not seen any issues.

Bruce, did you generate that chart using Playback Connection, or
was this a screenshot you created earlier in the week during a
live session?

I think issues w/Swing+OnEachTick do exist. But I'm not able to
reproduce the problem ... or maybe the issue doesn't manifest
in Playback?

Bruce, could you please upload a chart template for the chart
in that screenshot?

Also, could you provide the steps needed (Playback vs Live, etc)
so that everyone can reproduce the behavior you're seeing?

Thanks!

[QuantKey_Bruce]

I just don't use the Swing function - it's easier to just code up something to keep track of the siwng pivots yourself.

But, this is part of a broader context. If you regularly develop strategies that are intrabar, you necessarily must become attuned to the issue that unless you've looked at the code for the indicator and are sure it is correct for intrabar operation, you have to be very cautious. Usually, I don't worry about using simple things like SMA or EMA or RSI or Stochastics and the like but for something that has an "awareness of state" like a Swing or a ZigZag I've learned to be very cautious, and often I'll just code it in-line rather than calling the function because I don't want to risk losing hours trying to track down someone else's mistake, or worse yet, it looking like it was is my fault the strategy doesn't work when I was just relying on a functionality that I should not have relied on. It's the easiest thing in the world when writing an indicator like Swing to miss something about how to "reset" when it swings one way intrabar then swings back the other way and you have to "undo" the state flip you just did by returning to the state you were in before when the bar started. That sounds simple, but in a complex indicator it's easy to miss something and have a subtle bug.

An indicator like Swing absolutely can be fixed, and perhaps NinjaTrader will fix it. But right now, as you can see, we're still at the stage where we're trying to get a common understanding there is a problem, so if you would like to move forward, you should probably just code the swing determination. It's easy to do so. Then, you won't have to worry about whether the inbuilt one does it correctly.

[burmaz]

I don't think NinjaTrader_PatrickH is understanding the issue you are reporting. You can't run Swing on bar close within an intrabar strategy, and Swing is not designed for intrabar.

First of all, you cannot force an indicator to run in Calculate.OnBarClose within a strategy that is Calculate.OnEachTick or Calculate.OnPriceChange. So, you should not even be trying to do that.

Not every indicator is capable of running in an intrabar environment. @Swing.cs the inbuilt Swing indicator has problems intrabar.

Here's an illustration of one of the things that's wrong with it. Just add Swing twice to an ES chart with tick replay turned on, and set one instance to Calculate.OnBarClose and one to Calculate.OnPriceChange. I set the OnBarClose one to have bigger, darker dots, with the other one on top so you could see the differences.

As you can see, Swing does not return the same values in all cases if it is run intrabar. So, unless or until they fix this, you basically shouldn't use it in a strategy like this. What you should do instead is write your own little function to figure out the swing pivots that way you can be sure it is written in a way that will work intrabar.

Thanks for your detailed response!

Have you found a work around or have been using a fix that solves this problem?

[QuantKey_Bruce]

I don't think NinjaTrader_PatrickH is understanding the issue you are reporting. You can't run Swing on bar close within an intrabar strategy, and Swing is not designed for intrabar.

First of all, you cannot force an indicator to run in Calculate.OnBarClose within a strategy that is Calculate.OnEachTick or Calculate.OnPriceChange. So, you should not even be trying to do that.

Not every indicator is capable of running in an intrabar environment. @Swing.cs the inbuilt Swing indicator has problems intrabar.

Here's an illustration of one of the things that's wrong with it. Just add Swing twice to an ES chart with tick replay turned on, and set one instance to Calculate.OnBarClose and one to Calculate.OnPriceChange. I set the OnBarClose one to have bigger, darker dots, with the other one on top so you could see the differences.

As you can see, Swing does not return the same values in all cases if it is run intrabar. So, unless or until they fix this, you basically shouldn't use it in a strategy like this. What you should do instead is write your own little function to figure out the swing pivots that way you can be sure it is written in a way that will work intrabar.

[burmaz]

Are there any updates on this issue? I am also running into this same issue when I have my strategy set to 'each tick' (which it requires).

[NinjaTrader_PatrickH]

Hello lillomur,

Thank you for your patience.

I am unable to reproduce the same behavior on my end.

Please send me your log and trace files so that I may look into what occurred. You can do this by going to the Control Center-> Help-> Email Support. Ensuring 'Log and Trace Files' is checked will include these files. This is checked by default.

Please list 'ATTN: Patrick H' in the subject line and reference this thread in the body of the email.

I look forward to assisting you further.