multiple trades for the same signal

[dcook]

When backtesting, the results show multiple trades on the same day for the same long or short signal. It accurately tracks my code for the right time to go long and short, but it just makes multiple trades when I only want one at a time. Not sure what I'm doing wrong.

[ACM]

dcook
Without seeing the code it is difficult to provide a specific reason why that may be happening, however from your description it seems that the conditions may not be checking to see if the strategy is already long (or short).
Try adding adding a !Strategy.isLong() or !Strategy.isShort() to the conditions that trigger the trades (see example below) which will prevent multiple trades in the same direction.
Alex

if(!Strategy.isLong() && "your other conditions here"){
    Strategy.doLong("your parameters here");
} 

[dcook]

Thanks Alexis. I have that sort of thing in place in all places where I try to go long or go short. I even added additional checks and continue to have the same problem where multiple trades execute at the same time when I run backtesting. What's strange is that when I put it on the advanced chart with the red and green background colors, it all looks fine. It's only when I run backtesting that it comes back strange like that.

I've attached the efs if you want to run it on something like EBAY. You'll see what I mean. The code in the attachment is a simplified version, but it still has the same problem. After looking at this for countless hours, I believe this is an eSignal bug.

Any help or guidance you can provide would be greatly appreciated.

[eSignal_JasonK]

Hello dcook,

The modified version of your formula you posted cannot be loaded on a chart. Whatever mods you made to simplify it is causing some problems. Please revisit your formula and post a working example if you'd like a more thorough code review.

At any rate, based on the code you've provided, I see some logic that allows for multiple trades to occur on the same bar. Remember that the code is going to be evaluated one line at a time from the top down. Any if() statement that evaluates to true will execute it's corresponding block of code.

Let's look at the nested if() block that starts at line 80. If the NewTrade trigger is set to 1 on the previous bar, or execution of the formula, this code block will be executed.



Now on line 84, .isInTrade() == true could be true. If it is, then line 85 could also be true, which would close the current short position on line 86. Immediately following, line 87 could be true which would enter a long position on line 88. This is fine, because it executes a reversing trade.




Moving on down the code to line 132 you are now testing for a profit target exit on the same bar, which could also be true depending on the symbol, interval and the value used for ProfitTargetPercent. This could result in an exit of the long position that was taken on the same bar.



Let's assume that the profit target condition was false, you then evaluate for a trailing stop breach at line 159. Again, this could also be true, which could close the long position on the same bar.



The end result is an short exit, long entry and a long exit all on the same bar.

This is just one example of how your current logic is allowing for multiple trades to occur on the same bar. There are several things you can do to fix your code logic to prevent this. One option is to create another global variable called bTradeOccured, or something of that nature. Set it to false at the top of main before evaluating any trade conditions. Then you would need to add a check for a false value of the variable in any trade conditions that you would not want to occur on the same bar if a trade occurred in a condition prior to it. So any where you have a strategy call that enters and/or exits a position, set this flag to true. This will prevent subsequent conditions from executing until the next bar because the flag gets reset at the top of main(). Depending on your specific needs you could also use two flags where one is used to prevent multiple entries and the other is used to prevent multiple exits on the same bar.

Another possible option is to move all of your profit target and stop logic above your entry logic and place all of that code inside an if block that looks for NewTrade == 0. This would indicate in your formula logic that a new entry signal was not generated on the previous bar so that it is safe to evaluate for a profit target or stop breach. This would also prevent the exit, entry and exit on the same bar scenario.

Try some of these options and if you continue to have problems, please post a working formula example.

[dcook]

Thanks Jason for your timely response. I attached a newer version of the code. I see that multiple trades can occur on each bar - there are situations as you point out where it's possible to enter a trade and then exit on the same day. That is a problem, but it's not the problem that I've been seeing. I went ahead and added a condition for the Profit Target and Trailing Stop exits to only occur if the variable DaysSinceEntry > 1. This variable is set to 1 on the bar when the trade occurs (line 83) and then increments each subsequent day. But again, this still does not address the original issue I've seen and continue to see.

I see multiple long entries or short entries occur on the same day when I run "Back Testing..." from the Tools menu. This just can't be with the code I have - the only conditions that allow for initiating new positions are on lines 80-112. Checks are in place to only initiate new longs when we're not in a trade or when we're short. And we don't initiate new short trades unless we're not in a trade or when we're long. But "Back Testing..." results shows 3 or 4 different instances of going long on the same day. Some of these exit a few days later, some a few months later. And then it screws up the entries and exits of the subsequent trade results.

And again, when I apply this formula to an Advanced Chart, it shows the red and green background colors for the shorts and longs. And everything is exactly as it should be. So why am I getting different results between applying the formula to a chart and running Back Testing?

You also mentioned that load it on to a chart. Try it with a daily chart of EBAY. That works for me. I've had difficulty using this code on some stocks and not others.

[dcook]

Well, I finally found the problem. There's something wrong with the function "lowest()" in line 176 and "highest()" in line 182. That's the only time I use these functions. They greatly slow down the performance and they somehow cause the bug that I've described below when performing Back Testing.

To verify it, I first just commented out those 2 lines. That works. Then I tried tried a fixed integer instead of the variable DaysSinceEntry like this:

old: lowest(DaysSinceEntry, low())
new: lowest(5, low())

Problem persists.

Then I just got rid of lowest() and used low(-1) in the formula. Problem went away. There's a huge difference in performance when I don't use lowest() and highest().

I still need to use these functions or something similar to them. Any ideas for alternatives? I'm just trying to do a trailing stop %based on the highest high while in a long position or the lowest low while in a short position.

[eSignal_JasonK]

Hello dcook,

First, let me say, nice work on the DaysSinceEntry logic for your exit conditions. That is another handy method for resolving the problem of entering and exiting positions on the same bar.

Regarding the problem with lowest() and highest(), here's the solution. Replace those calls with lowerDonchian() and upperDonchian(). Here's the exact code you should use.



Now, let me explain what the problem was with the way lowest() and highest() work. These two series functions are basically wrappers for the Donchian built-ins. The two series functions do not have a bar index parameter, however. When you call lowest() or highest(), they create a Series object rather than return a single number that is needed for the trailing stop calculation. Calling them within a math operation is not invalid syntax, but it is a very inefficient process. The EFS2 engine basically recognizes that a Series object is being used within a math equation and automatically retrieves the current value from the series so that the calculation can produce a valid number for the TrailingStop variable. This would normally be an acceptable way to code this routine. The problem is that the DaysSinceEntry parameter is constantly changing. When a different set of parameters are specified for these series functions, a new instance of Series object has to be created. This is a memory killer. Also, because these series functions are being called locally inside main rather than be assigned to some global variables, it may be creating new Series objects for every bar in the chart. This process is creating a ton of objects in memory that are not needed. To prevent the initialization of a series object from a series function like lowest(), you just need to specify the bar index of the value from the series you want to use. This can't be done with lowest() and highest() because the bar index parameter was mistakenly left out. Development knows about this and these functions will be improved for a future version. The Donchian series functions do the exact same thing as highest() and lowest(), but we can reference the bar index of 0 directly, which should solve the problem.

I tested the code on EBAY 5 minute chart over 5 days with your default parameters. It appears to be fine. I'm not seeing any multiple entries on the same bars. That problem you were experiencing may have been caused by the inefficiency related to the use of lowest() and highest() somehow.

Here's what I see on my end now. Try out the new code and let me know if this resolves the issues for you.