What caused a trade without a signal?

[arieal]

Hi
1. I lost money by having a trade that was not prompted by any obvious signal.
- On 7/26/05, Russell 2000 emini (esignal symbol AB), 8 minutes chart, I was long from a signal at 13:04:02 (price > MA(15) + 0.2). I had a Stop Loss of 2.
The system is continuously in the market depending on price being above/below MA(20).
At Stop Loss being hit, when I have 1 contract only, the system re-enters according to the price position relative to MA(20).
- At 13:39:47, in the middle of a big up candle, I got a Sell trade and I went Short. When I should have kept going long.
This is quite frightening because I do not know the cause.
This happened more than once but yesterday it was a big loser.
I suspect maybe the Internet connection went down temporarily and when it came back the first signal was short for some reason? I didn’t watch my PC while trading.
2. What happens when the connection with eSignal comes down in the middle of efs running? It starts from scratch, i.e. the globals are initialized etc. ?
3. I have a Button ‘System OFF’ (see function ONOFFButton() in my code) to start running my efs, so can an Internet disconnect/reconnect restart my efs?
In Backtesting, this short signal didn’t occur, obviously.
Can anybody, please, have a look at my code and maybe give me a hint?
Please see attached file.
Thanks a lot
Arie

[eSignal_JasonK]

Re: What caused a trade without a signal?

Hello Arie,

Originally posted by arieal
Hi
1. I lost money by having a trade that was not prompted by any obvious signal.
- On 7/26/05, Russell 2000 emini (esignal symbol AB), 8 minutes chart, I was long from a signal at 13:04:02 (price > MA(15) + 0.2). I had a Stop Loss of 2.
The system is continuously in the market depending on price being above/below MA(20).
At Stop Loss being hit, when I have 1 contract only, the system re-enters according to the price position relative to MA(20).
- At 13:39:47, in the middle of a big up candle, I got a Sell trade and I went Short. When I should have kept going long.
This is quite frightening because I do not know the cause.
This happened more than once but yesterday it was a big loser.
I suspect maybe the Internet connection went down temporarily and when it came back the first signal was short for some reason? I didn’t watch my PC while trading.

The only way for a line of code to execute that submits a trade is if the conditional statements surrounding it evaluate to true. Formula logic that contains a nested structure of conditional statements can become very complex and difficult to keep track of in your head. You received a trade signal that you didn't understand, but the nested conditional statements in your code had to have evaluated to true, which may have been contrary to your expectations. You need to start with the line of code that sent the trade and then analyze each conditional statement going up stream. By doing this you will discover the path of logic that allowed the trade to occur. Based on your description of what happened, I can see how the scenario could have occurred in your code logic. For example, let's look at line 549.



This is a line of code that could reverse your long position and open a short position. First, let's look at the conditional statement on line 548. The first question to ask is: Was it possible for the formula logic to get to this condition to evaluate its statements? To answer this question, you need to start going upstream through the upper levels of conditions that must evaluate to true before this one and ask yourself if it is possible that they could evaluate to true.

The next level upstream is line 538.

Was the strategy in a trade? Yes, this was possible as you indicated you were already in a long position. What I look for specifically during this process is if there are any lines of code in the formula that can set the value of StrategyisInTrade to true. There are many instances of this throughout your code. No need to investigate if those lines are being executed yet. Simply continue up the stream to see if the path of conditions is possible.

Then next level above in line 536.

Is it possible that nNewTrade is being set to a value of 1. Yes, I can see two instances of this on lines 523 and 528.

The next level above is line 231.

This would be true unless you were using setComputeOnClose(), which you are not.

There's only one other condition upstream from line 231 on line 207, which if evaluates to true will exit with a return statement on line 210. We have to assume this is not happening because you were already in a long position, which wouldn't have been possible otherwise.

The first conclusion that I've made is that there is a path of logic that can allow the reversal trade you've encountered. Now you need to go back to the first conditional statement on line 548 and start confirming that the conditions and statements could be set to values that would result in the conditional statement evaluating to true and continue doing so going upstream as before and analyzing there statements accordingly. Looking at line 548, assuming your strategy was currently long as you indicated, StrategyisLong must have been true. nsignal must also have been less than 0 for this condition to be true. To confirm this, what I do is click on the nsignal variable and then click on the Find (search) icon in the formula editor (the binoculars). Then select "Up" for direction, since we want to see where nsignal is getting its value upstream. Then continue to click on the Find Next button (small binoculars with blue arrow to the right of the Find button) until we find all the possible lines of code that assign a value to the variable. The first line that I come to is on line 529.


Consequently the value is -1, which would allow the condition on 548 to evaluate to true. Also note that nNewTrade is getting set to a value of 1, which would allow the condition on line 536 to be true as well.

Now you need to check the path of logic for the condition on line 527. Is this possible? Yes, the previous close could be less than the value of study - crossOffset. !StrategyisShort would evaluate to true if you were currently in a long position. The variable, study, is being established with a valid value based on the default parameters of your study. It is being assigned a value on line 318.


The default value of nMovingAvg is set to 500 at line 158 in preMain(), which assigns the kwik pop return value to study. Therefore, the previous bar's close could be less than the value of study - crossOffset. Where crossOffset is set to a constant value of .2 on line 214, which comes from the default value of ncrossOffset established at line 163 in preMain().

Upstream from 527, we have the condition on line 520.

TradingSystemONOFF can be set to true on line 660, if the text button that calls this function is clicked. This code works. ButtonSignal must also be false for this condition to be true. On line 93, the variable is initialized as false. Also on line 516 it can be set to false. There are two instances where this variable can be set to true on lines 642 and 649. However, on the next BARSTATE_NEWBAR, ButtonSignal is being reset to false and remains false until one of the two previous conditions occur at 642 and 649. Therefore, this condition on 520 is possible.


The next level up from 520 is 231 and 207. We've already established that these two can evaluate to true.

These steps confirm that the formula logic would allow for the reversal trade that you've experienced. My only suggestion at this point is to reevaluate these conditions I've identified and make a determination as to which area should not be evaluating to true and add additional condition(s) to correct the problem. It appears that your formula logic is not currently covering all the possible scenarios where you want to prevent a reversal trade.

Originally posted by arieal

2. What happens when the connection with eSignal comes down in the middle of efs running? It starts from scratch, i.e. the globals are initialized etc. ?

The formula is not restarted in this case. It will pick up where it left off once the connection returns. The globals will retain their values prior to an internet disconnect. The formula will only reinitialize if you perform a chart refresh, manual reload or restart the eSignal application.

Originally posted by arieal

3. I have a Button ‘System OFF’ (see function ONOFFButton() in my code) to start running my efs, so can an Internet disconnect/reconnect restart my efs?
In Backtesting, this short signal didn’t occur, obviously.
Can anybody, please, have a look at my code and maybe give me a hint?
Please see attached file.
Thanks a lot
Arie

Regarding your TradingSystemONFF routine... The code in your ONOFFButton() function works properly for setting the value of the variable when clicking on the text button on your chart. However, how you are using the variable within your code is not doing what I think you intended. There are some trade conditions that are improperly using or not checking this variable before submitting a trade. For example, take a look at line 476.


The first portion of the condition, close(0) <= nStopLevel, could evaluate to true, which in turn will call the trade two lines below even if TradingSystemONOFF was false. This condition evaluates to true because of the "or" (ie || ) operator. This allows the condition to be true if either of its statements evaluate to true. If you change the operator to "&&" it should solve prevent this trade from occurring when your TradingSystemONOFF variable is set to false. I would suggest you either add a condition to line 231 like below or add/modify the other conditions that may be using the variable improperly.

if (getCurrentBarIndex() == 0 && TradingSystemONOFF == true) { 

Regarding back testing... Formula code is only processing completed bars and not tick-by-tick data as it will in real time. Your formula logic when evaluating only on completed bars cannot produce the intra-bar reversal scenario that you experience in real time. From my experience, because of the difference in logic required to analyze real time data vs. completed bars during back testing, most back testing formulas will not perform in an identical fashion when using the same set of logic in real time. Back testing should only be used to test the basic principles of a strategy to help determine if it has value. Once you determine that it does, the code needs to be adapted to process real time data scenarios that will also stay within the formulas strategy principles used for the initial back testing process. You cannot expect code logic that works in back testing to do exactly the same thing when processing real time data.

[arieal]

Dear Jason
The amount of time and information you put in your response is absolutely incredible and invaluable.
I have never seen such a thorough code review.
I'll take my time to analyze my code following your advice.
Many many thanks
Arie
PS. I used MA(20) for study, not the default kwik.

[eSignal_JasonK]

Hello Arie,

My pleasure. Thank you for posting your code. For the MA(20), this could also still allow the scenario to evaluate to true. Keep us posted on the progress with your study.

[arieal]

Dear Jason
I couldn’t find anything wrong with my code (yet) except spaghettis and a lot of redundant wording in logic statements, left as is for readability reasons or frugal coding.
But, I have a wild suspicion: the MA(20) changed its value for the bar Before the current bar that generated a reversal.
Look at the chart of AB, 8min, 7/26/05:
- The arrow points to the Green bar with the Reversal (Time = 13:36).
- The Red bar before the reversal bar (Time = 13:28), has Close = 673.80 and MA(15, C) = 673.89.
- but see the green MA is stretching lower after consolidation starting at 14:00.
I assume that immediately after the Two Big Green Bars, the MA was sitting Higher than 673.89, enough to satisfy the condition in Line 527 to generate a Short signal.

Line 527: if ((close(-1) < study - crossOffset) &&
!StrategyisShort) {
nNewTrade = 1; // New Trade Trigger
nsignal = -1; // Sell Signal - Trade Type
}

And this Reversal occurred in the middle of the Green Reversal bar, at 13:39:47.
After many consolidating bars afterwards, the MA shaped downwards giving the value of MA = 673.89 for the Red Bar..
- If my suspicion is correct, then the only solution would be to increase the crossOffset from default of 0.2 to maybe 0.4.

- Regarding your other suggestion:
------------------------------------------------
There are some trade conditions that are improperly using or not checking this variable before submitting a trade. For example, take a look at line 476.
if (close(0) <= nStopLevel || (TradingSystemONOFF == false)) {

The first portion of the condition, close(0) <= nStopLevel, could evaluate to true, which in turn will call the trade two lines below even if TradingSystemONOFF was false. This condition evaluates to true because of the "or" (ie || ) operator. This allows the condition to be true if either of its statements evaluate to true. If you change the operator to "&&" it should solve prevent this trade from occurring when your TradingSystemONOFF variable is set to false.
-------------------------------------------------------------------
I need the above condition to accomplish two things:
- to close open positions when a Stop was breached, OR
- to close open position when the ONOFFButton was clicked to deactivate the efs.
The && operator instead of || will not be right.
In addition, if TradingSystemONOFF == false, the line 474, will prevent entering line 476.
Line 474: if ((StrategyisInTrade == true) && (StrategyisLong == true)) {

What do you think (if you still have enough patience to read my long and boring reply)?
Many thanks
Arie

[eSignal_JasonK]

Hello Arie,

Originally posted by arieal
Dear Jason
I couldn’t find anything wrong with my code (yet) except spaghettis and a lot of redundant wording in logic statements, left as is for readability reasons or frugal coding.
But, I have a wild suspicion: the MA(20) changed its value for the bar Before the current bar that generated a reversal.
Look at the chart of AB, 8min, 7/26/05:
- The arrow points to the Green bar with the Reversal (Time = 13:36).
- The Red bar before the reversal bar (Time = 13:28), has Close = 673.80 and MA(15, C) = 673.89.
- but see the green MA is stretching lower after consolidation starting at 14:00.
I assume that immediately after the Two Big Green Bars, the MA was sitting Higher than 673.89, enough to satisfy the condition in Line 527 to generate a Short signal.

Line 527: if ((close(-1) < study - crossOffset) &&
!StrategyisShort) {
nNewTrade = 1; // New Trade Trigger
nsignal = -1; // Sell Signal - Trade Type
}

And this Reversal occurred in the middle of the Green Reversal bar, at 13:39:47.
After many consolidating bars afterwards, the MA shaped downwards giving the value of MA = 673.89 for the Red Bar..
- If my suspicion is correct, then the only solution would be to increase the crossOffset from default of 0.2 to maybe 0.4.

The problem with your strategy does not revolve around the moving average study. I have not seen the behavior you are describing. In other words, its values on previous bars that have already closed are not changing values after a new bar has started. Your strategy logic is not looking at the historical values of the MA study anyway, so that couldn't be the source of the problem. When looking at what the condition is taking into account on line 527, it's checking to see if the previous bar's close is less than the current bar's MA value minus the crossOffset. Looking at your chart image it appears that this condition was true. As the prices moved higher on that green reversal bar, the current bar's MA value reached a value that was high enough to satisfy the condition, which triggered the trade. Perhaps it is this condition on 527 that needs to be revised. However, changing the crossOffset to .4 would trigger the reversal earlier because that would lower the value of (study - crossOffset) more than a value of .2 would. I'm not sure what your strategy rules are supposed to accomplish so I'm not certain what your solution would be. I think you're looking in the right places now though.

- Regarding your other suggestion:
------------------------------------------------
There are some trade conditions that are improperly using or not checking this variable before submitting a trade. For example, take a look at line 476.
if (close(0) <= nStopLevel || (TradingSystemONOFF == false)) {

The first portion of the condition, close(0) <= nStopLevel, could evaluate to true, which in turn will call the trade two lines below even if TradingSystemONOFF was false. This condition evaluates to true because of the "or" (ie || ) operator. This allows the condition to be true if either of its statements evaluate to true. If you change the operator to "&&" it should solve prevent this trade from occurring when your TradingSystemONOFF variable is set to false.
-------------------------------------------------------------------
I need the above condition to accomplish two things:
- to close open positions when a Stop was breached, OR
- to close open position when the ONOFFButton was clicked to deactivate the efs.
The && operator instead of || will not be right.
In addition, if TradingSystemONOFF == false, the line 474, will prevent entering line 476.
Line 474: if ((StrategyisInTrade == true) && (StrategyisLong == true)) {

Your explanation makes it clear what you are trying to do here and your logic is correct since the TradingSystemONOFF would have to have previously been set to true before entering a position.