Daily Fibonacci Signals

[snailbeard]

Hi.

Very hard to judge without knowing your code. On the other hand very easy to verify. First let only one EA run. Then add a second one. If it works flawlessly with one and starts creating those errors after adding the second one, it is worth a serious investigation.

I am fairly sure I would have noticed this problem in the past. In the log file the errors start appearing in the EA working on EURJPY after the EA working on USDJPY opens a trade. If I made a mistake in the EA code it would be forgetting to filter by OrderSymbol or finishing a loop then leaving the function while pointing to the last order according OrderSelect()

This could still be a bug in the EA, however, those of you who remember my testing and debugging of one of the early Nanningbob EAs, might remember my introduction of:

Code: Select all

	SaveOrRestoreSelectedOrder(SELECTEDTICKET_SAVE);

       ... do something here with orders ...

	SaveOrRestoreSelectedOrder(SELECTEDTICKET_RESTORE);

[/size]

to overcome accidental changes to the currently selected order being processed at a higher level, this has worked well, but I could have failed to use it in one of the many functions which make use of OrderSelect().

So I have gone through all occurrences of OrderSelect() and hopefully avoided a bullet in the foot.
However, I won't know until the EA starts entering some trades again.
It only affects the movement or not of a stop loss and is not currently serious enough to be the main focus.

Finding more good entry patterns is a higher priority.

[snailbeard]

Clearly I am not talking about current market conditions which have been challenging for many traders.

There have been a few good days here and there. Sometimes it is just better to go away until conditions improve, but SRT was designed to work in more difficult conditions, but the danger of curve fitting to current conditions is that it won't work well in good trading conditions.

So I went back and found a good month for USDJPY (November 2016):

USDJPY-test-SRT-on-trending-period-Nov2016.png

From this we can see that November was a great month for buying, buying and more buying of USDJPY and I was worried that recent changes to the EA would prevent SRT from sucking up pips in an easy month.

Perhaps it can do better, but without any back peddling or tweaking we get a nice fat profit:

USDJPY-CSV-results-for-Nov2016.png

For such a good month the failure rate is quite high and surely we can achieve more than 3 wins. It doesn't make sense to focus effort on trading in poor conditions at the expense of good months, even if good conditions are relatively rare.

Perhaps this is just the nature of this particular algorithm, like a lion that hunts and misses a lot, but occasionally pulls down a buffalo?

Those of you who follow my posts will remember there is already a trend trading method in the EA.

After so many changes will the old trend trader still work for months like November 2016?
...
Going back to a previous algorithm after changes is usually a frustrating process of repairing damage as old logic is 'improved'. However, this is one of those rare occasions when revisiting an old method is a shock but in a pleasant and interesting way:

USDJPY-price-action-trader-method-for-Nov2017.png

Not only has it survived intact but has somehow taken on some properties of the new algorithm.

The next step is to automatically switch between methods for super-trends and reduce trading in poor market conditions.

[snailbeard]

2017.07.25 10:00 Daily: Alert: AUDUSD: Y1JOARMA M15CtOAboveNearToSma200

Alerts are useful for drawing our attention to a particular pair at a particular time, and more flexible than an automatic entry, which as we know from experience EAs only get it right part of the time.

So
10:00 means 08:00 UK local time
Y1OARMA means the daily bars are generally rising.
M15CtOAboveNearToSma200 means price is close and above M15 200 MA

From this information we can usually enter a buy trade with a stop loss just below the slow MA and a daily range target:

AUDUSD-M15-M15CtONearAboveSma200-1000-25Jul2017.png

However, the OBV for the day so far seems to be telling a different story. It often happens that price moves the opposite way before the main move of the day, but this looks a bit more significant.

During a strong trend we can enter just about anywhere with a larger stop loss and ride out the bumps but it can be hard to differentiate a pause from the precursor to a reversal. The candle patterns in relation to a MA can be a big help:

AUDUSD-D1-meeting-long-term-resistance-25Jul2017.png

The green slow MA is a significant barrier and continues to prevent the price rising, we don't know if it is due to algorithms or market dynamics but the resistance is real and we might want to go and look else where until the market has reversed or continued beyond this barrier.

One of my weaknesses is that I have a persistently negative view against the Euro and so end up shorting it too early. Analysts have been predicting the collapse of the EURO for years but it took the South Sea Company about 9 years to reach popping point. Other currencies are in trouble, so who knows which one will pop first?

[snailbeard]

It has been a while since I experimented with my own version of the currency slope strength indicator, it's main value is deciding which pairs have the best prospects for a price swing and could complement FBATT (Find best assets to trade).

The Price action EA is running on many charts and this is starting to be a drag on memory and CPU. It would be great if I could wake them up only when they are needed by other criteria such as FBATT or CSS.

I was pleased to find that Mazmazz had created an open source C++ version on github, however, when I came to use it I had a couple of issues with the code. The first one was spotted by the compiler because of strict type checking, but then Empty4 became CPU bound, froze and I had to kill it. So I had to go back to my old code from 2013 and blow off the cob webs.

In the end I had to re-factor the code significantly so that common code between EA, script and indicator would compile without warnings and errors. I also needed to produce some additional output in a CSV like format which can be read by an EA. This can be produced on several time-frames and consists of current value and rate of change, for example:

CSS_H4_all_pairs_max_change_late_July2017.png

There are two aspects to this data
a) the bar just closed for live analysis
b) previous bars for other analysis

So in the top line where it read 20:00 'sell': it means JPY is getting stronger and CAD is getting weaker, however, this is not very useful by itself. The first two values can be read off from inspecting a CSS chart and the last value is the rate of change between bars.

CadJpy is one of those ugly expensive pairs to trade, so we wouldn't want to jump in on a whim. It is the kind of pair that needs a week to allow for the chance of making some pips. Therefore, what we really need to know is the start and end of a weekly move.

In one sense, when we see CADJPY as the strongest moving pair it means price has already moved significantly, so the direction could be right but the timing wrong.

The following chart shows how CadJpy went from bull to bear over several days:

CADJPY-H4-end-of-july-bull-to-bear-01Aug2017.png

From this chart we can see that price swings up and down making it difficult to trade without using a large stop loss.

Going back to the table of strongest CSS differences, CADJPY first arrives on the radar at 20:00 on the 27July, but after price has already moved. We need price to retrace before making an entry. 'A' and 'B' are times where we could enter to sell but where do we get an entry signal from?

Firstly, the EA is not going to suggest short range entries on this pair. Nevertheless, the log file does contain some interesting analysis:

Code: Select all

12:00 CADJPY: :   giH4Lwma10Direction: -1
12:00 CADJPY: :   H4TrendFilter: bH4Lwma5Lwma10PriceUp: 0; bH4Lwma5Lwma10PriceDown: 1
12:00 CADJPY: :   H4TrendFilter: bH4BarOC_AboveRisingLwma10: 0; bH4BarOC_BelowFallingLwma10: 1
12:00 CADJPY: :   H4TrendFilter: bH4BarOC_AboveRisingLwma5: 0; bH4BarOC_BelowFallingLwma5: 1
12:00 CADJPY: :   H4JustOpenAboveRisingLwma10: 0; H4JustOpenBelowFallingLwma10: 1
12:00 CADJPY: :   gbH4Lwma10Lwma60DivergingUp: 0;  gbH4Lwma10Lwma60DivergingDown: 1
12:00 CADJPY: :   gbH4BarNearToUnderLwma10: 1;
 gbH4Lwma10Rising: 0, gbH4Ma20Lwma60Rising: 0,
    (gdH4Lwma5 > gdH4Lwma10): 0,  (gdH4Lwma10 > gdH4Sma20): 0
    gbH4Lwma10Falling: 1, gbH4Ma20Lwma60Falling: 0, 
    (gdH4Lwma5 < gdH4Lwma10): 1,  (gdH4Lwma10 < gdH4Sma20): 1

[/size]

From the above analysis it is clear that the H4 trend is down, in particular note
a) H4JustOpenBelowFallingLwma10: 1
b) gbH4Lwma10Lwma60DivergingDown: 1
c) (gdH4Lwma5 < gdH4Lwma10): 1, (gdH4Lwma10 < gdH4Sma20): 1

We have the basis of a slow moving entry method for longer lasting trades, we don't need CSS to tell us about the price direction, but perhaps it can help confirm the quality of a trend.

So this does not help the short range entries but opens up other possibilities for new entry methods.

In the following H4 close-up we can relate the EA analysis to the chart:

CADJPY_H4_A_closeup_1200_entry_31Jul2017.png

We can see that bars are generally moving down followed by a retrace up to the intersection of two moving averages. Then we see a doji bar close just under the MAs. Our area of interest is 12:00 because this H4 bar opens under a falling moving average. There is often a limited price reverse for these kind of entries, which might give us a 3 or 4 to 1 win/loss ratio. The orange-brown rising slow MA can be expected to provide support to price and could be a good place to take profits.

Perhaps the way to interpret the CADJPY strong reading as confidence that price is not going to go far in the opposite direction?

In the past I have discussed an entry method (which I termed ORFB (Open, Reverse, Forward, Break)). This can be better understood on an M15 chart:

CADJPY_M15_3_sell_entry_points_12noon_31July2017.png

Now we can see 3 potential entry points A(-), A and A(+)
Each entry point has a common characteristic of opening near-under a moving average.
H4 ORFB is the sequence of H4 open at 12 then we have two 'reverse' M15 bars followed by a 'forward' bar which closes below the H4 open ('break') and we have completed an ORFB sequence.
In this particular case we can perhaps shave off a few pips from the stop-loss but since it is a fat spread pair we still need to allow 20 to 30 pips for the trade be successful.

There is no short term signal for this pair from the EA and I have been diverted from my original agenda of helping the EA to make better short range entries into thinking about longer lasting trades. I need to look somewhere else to answer question of what best to trade over a day or two...

[snailbeard]

In order to trade efficiently we need to be selective, and part of that process is looking back to see if we traded the right time-frames and right pairs.

CrappyTester can tell us some useful things about our EAs, but it doesn't tell us that we should have traded GBPCHF on H4 for the week beginning 23July2017. So I added the following snippet to FBATT:

Code: Select all

extern bool ExtCalcBestPipsAnyTfFromPast = false;
extern int ExtCalcBestPipsTimeframe = PERIOD_W1;
extern int ExtNumOfPastAnyTfBarsToCalc = 52; 

//======================================================================
void DoCalcBestPipAnyTf()
{
	// for a number of back bars
	// and for each active pair
	
	if( ExtCalcBestPipsAnyTfFromPast == false )
		return;
	
	int limit = ExtNumOfPastAnyTfBarsToCalc;
	int timeframe = ExtCalcBestPipsTimeframe;
	
	int symbolCount = bwaGetCountedPairs();
	
	int bestAnyTfPairIndex = 0;
	double bestAnyTfChangeInPips = 0;
	double bestAbsAnyTfChangeInPips = 0;
	
	string strTime;
	string strBestPair;
	string strSymbol;
	string strBestPipChange;
	string strAbsBestPipChange;
	
	datetime dtAnyTfBackDate = 0;
	
	Print( "Best past pip change per pair/back-bars for timeframe: " + IntToStr(timeframe) );
	
	for (int iBackBarShift = limit; iBackBarShift > 0; iBackBarShift-- )
	{
		strBestPair = "";
		bestAnyTfPairIndex = 0;
		
		bestAnyTfChangeInPips = 0;
		bestAbsAnyTfChangeInPips = 0;
	
		dtAnyTfBackDate = iTime( NULL, timeframe, iBackBarShift );
		
		bool bTraceAllPairs = false;
		if( iBackBarShift == 1 )
			bTraceAllPairs = true;
		
		for( int iPairIndex = 0; iPairIndex < symbolCount; iPairIndex++ )
		{
			strSymbol = Pairs[ iPairIndex ];
			
            changeSymbol( iPairIndex );
            
			refreshPipsAndTicks(); 

			//strSymbol = symbolNames[iPairIndex];
			dtAnyTfBackDate = iTime( strSymbol, timeframe, iBackBarShift );
			double dAnyTfClose = iClose( strSymbol, timeframe, iBackBarShift );
			double dAnyTfOpen = iOpen( strSymbol, timeframe, iBackBarShift );
			
			double dAnyTfChange = dAnyTfClose - dAnyTfOpen;
			double dAnyTfAbsChange = MathAbs( dAnyTfChange );

			double dAnyTfChangeInPips = convDecimalToPips( dAnyTfChange );
			double dAbsAnyTfChangeInPips = MathAbs(dAnyTfChangeInPips);
			
			if(bTraceAllPairs)
			{
				Print(
					TimeToStr( dtAnyTfBackDate, TIME_DATE|TIME_MINUTES )
					+ ", " + strSymbol
					+ ", Pips: " + DoubleToStr( dAnyTfChangeInPips, 2)
					+ ", Abs Pips: " + DoubleToStr( dAbsAnyTfChangeInPips, 2)
				);
			}
			
			if( dAbsAnyTfChangeInPips > bestAbsAnyTfChangeInPips )
			{
				strBestPair = strSymbol;
				bestAnyTfPairIndex = iPairIndex;
				bestAnyTfChangeInPips = dAnyTfChangeInPips;
				bestAbsAnyTfChangeInPips = dAbsAnyTfChangeInPips;
				
			}
		}
		//--------------------------------------------------
		strTime = TimeToStr( dtAnyTfBackDate, TIME_DATE|TIME_MINUTES );

		strBestPipChange = " Best Pips: " + DoubleToStr( bestAnyTfChangeInPips, 2);
		strAbsBestPipChange = " Best Abs Pips: " + DoubleToStr( bestAbsAnyTfChangeInPips, 2);

		strBestPair = strTime + " " + strBestPair + "," + strBestPipChange + "," + strAbsBestPipChange;
		//--------------------------------------------------
		Print( strBestPair );
		//--------------------------------------------------
	}
	
}

[/size]

The output could be saved as a CSV file for reference. A more verbose version could rank all pairs for each past bar. We might want to know what were the best 5 or 10 pairs to trade each week. So there is more work required.

With tracing turned on it is possible to see how much each pair moved (change not range):

CSV-BestPipWeek-GBPCHF-For23Jul2017.png

So from this we see that GBPCHF was a good pair to enter and hold for a week (in theory) and so were several other pairs (CHF pairs). Those of you using CSS effectively must have sucked up lots of pips. I need to kick myself for not paying attention and this is exactly what this output is for, so that I can beat myself up, until I stop looking at the wrong pairs and wrong time-frames and make sure I trade (and the EA trades effectively).

So I have revisited both my CSS variant and Baluda's very professional looking version. Mine must be quite out of date, so I put them both GBPCHF to find out which one suits me the most:

GBPCHF_H4_CSS_crossing_old_and_new.png

Form this we can see:
1) Just after 'A' someone using a reversion strategy would go long, which makes sense if this was a pull back in a longer up-trend
2) The old CSS indicator goes into strength at B which means price can break through strong resistance levels just above the H4 bars.
2(b) is actually before (B) based on price action where the falling SMA20 crosses the rising LWMA5 in combination with ORFB: without CSS we can still expect to at the least reach the orange SMA and with growing strength continue further with a buy trade.
3) The new CSS doesn't show as strong until C.
From this we can expect a return of 345 or 255 pips depending on which CSS indicator we use.

However, we still haven't answered the question of how it would be predicted that GBPCHF would the best pair to trade for a week. Can we ever make such a prediction? What moved the most last week is not a reliable indication of what will move the most in the current week.

Nevertheless, we do need some basis for making decisions.
We also need a history of which were the best days to trade particular pairs:

EURNZD-Best-D1-pip-change-07Aug2017.png

From this table we can see that EURNZD was a good mover on 7th August 2017 and GBPNZD the next one. So it was the Kiwi's big day and non-NZD pairs had a sleepy day. It is obvious from the history but when did it become apparent during a live session?

[snailbeard]

Following on from the previous post: I am interested to know what would have been the flag for buying EURNZD or GBPNZD.
In the following chart we can see both price action and two variants of CSS:

EUNZD-H4-CSS-strength-0400-7Aug2017.png

According to Baluda's CSS: EUR is already strong and NZD week, the same information is given by the arrangement of MAs. What we need is an indication that this is a candidate pair with better prospects than other pairs.

Looking at the multi-pair CSS at this time, we can make out that EUR and GBP have switched to going up and NZD is accelerating downwards:

GBPNZD-H4-fastest-change-at-0400-07Aug2017.png

Does my new CSS output capture this information at the right time?
The following table gives a slightly lagging overview:

CSS_H4_all_pairs_strongest_change_for_0400_7Aug2017.png

From this we can see that GBPNZD was top before EURNZD, however, GBP was recently a strong sell according to C(p-n), whereas C(p-n) is positive for EURNZD and dPN goes to 11.39 but not until H4 08:00 is over which means price action has already happened.

Perhaps we need to combine information from multiple time frames:

CSS-H1-multi-pair-priority-0400-7Aug2017.png

This time we see EURNZD in pole position more frequently, in particular 'EUR' is clearly dominating the table and so is 'NZD' but not until part of the price action is over.
The first occurrence is at the end of 00:00 so the start of 01:00, but after that other pairs are masking the EURNZD opportunity.

How does the table correspond to actual price action?
Looking at the H1 chart shows us that there are several key places to enter:

EURNZD-H1 CSS-best-entry-at-0500-07Aug2017.png

The first clue is the Monday morning gap up, but this is at the Witching Hour when bad stuff happens. Gapping is sometimes an example of the banks cheating the the rest of us and NZD is one of worst currencies to trade. New Zealand is essentially an island attached to a volcano and potentially could explode at any moment, so its probably a good thing that it is usually too expensive to trade.

Some time ago I posted a table of hot and cold currency pairs: AT 02:00 UTC USDJPY is often the hottest with a score of 300! Whereas EURNZD starts at around a very frosty 14 and rarely reaches 40 and then add the swap and you'll be wondering why we are even discussing this pair.

Nevertheless, for the purpose of relating price action to strongest pairs: without CSS the yellow and orange moving averages tell us that price is generally climbing and that we have had what could be a pull-back. I don't like to enter on the wrong side of a significant MA and we can see that bears are having a good time until 5am. Now the bears seem to have given up at the confluence of multiple MAs. Without additional information I still would not enter a trade at 'A' because we are immediately hitting another significant MA. The only thing that could convince me to enter a buy trade here is an indication of currency strength. It would be good to have that indication at the start of 05:00, but in the table above we would have to wait until the end of 05:00 to pick up this value. So should we be trading AUDUSD or should we demote AUDUSD and promote EURNZD?
So on what basis would you remove AUDUSD from the hotlist?
We might be able to use data from FBATT which calculates the best pip pairs, and if you look at the AUDUSD chart for this time: AUDUSD was not moving much, which is also reflected in the D1 ATR values, so we do have a method of removing AUDUSD from our list.

So now we need the code to pull all these pieces of information together.

[snailbeard]

The following code enables the 'change in price' data for any time-frame and back-bar to be processed and sorted. It should be possible to do something similar with currency slope strength.
We should end up with the best candidate pairs for trading, to be passed to the EA's which control the choice and timing of trades.

Code: Select all

class CBestPipRecord {
	
	// 'friend' NOT implemented in Empty4
	//friend class CArrayBestPips;
	// work around:
	public:
		int m_iPairIndex;
		double m_dRealPipChange;
		//double dAbsPips;
	
	void setBestPips(int index, int iPairIndex, double dRealPipChange );
	void getBestPips(int index, int& riPairIndex, double& rdRealPipChange );

};

CBestPipRecord TmpPipRecord;


class CArrayBestPips {
	int m_iActivePairs;
	int m_iTimeframe;
	int m_iBackshift;
	datetime m_dtTime;
	CBestPipRecord aBestPips[MAXBESTPAIRS];
	
	public:

		void init(int activePairs, int timeframe, int backshift, datetime dtTime );
		void myinit() {};
		
		void setBestPips(int index, int iPairIndex, double dRealPipChange );
		void getBestPips(int index, int& riPairIndex, double& rdRealPipChange );

		int compare(CBestPipRecord& left, CBestPipRecord& right);
		void swap(CBestPipRecord& left, CBestPipRecord& right);
		
		void sort();
		void printone(int iElement);
		void printall();

};


void CBestPipRecord::setBestPips(int index, int iPairIndex, double dRealPipChange )
{
	m_iPairIndex = iPairIndex;
	m_dRealPipChange = dRealPipChange;
}

void CBestPipRecord::getBestPips(int index, int& riPairIndex, double& rdRealPipChange )
{
	riPairIndex = m_iPairIndex;
	rdRealPipChange = m_dRealPipChange;
}
//======================================================================

void CArrayBestPips::setBestPips(int index, int iPairIndex, double dRealPipChange )
{
	aBestPips[index].m_iPairIndex = iPairIndex;
	aBestPips[index].m_dRealPipChange = dRealPipChange;
}

void CArrayBestPips::getBestPips(int index, int& riPairIndex, double& rdRealPipChange )
{
	riPairIndex = aBestPips[index].m_iPairIndex;
	rdRealPipChange = aBestPips[index].m_dRealPipChange;
}

int CArrayBestPips::compare(CBestPipRecord& left, CBestPipRecord& right )
{
	double leftAbs = MathAbs( left.m_dRealPipChange );
	double rightAbs = MathAbs( right.m_dRealPipChange );
	
	if( leftAbs > rightAbs ) return +1;
	if( leftAbs < rightAbs ) return -1;
	return 0;
}

void CArrayBestPips::swap(CBestPipRecord& left, CBestPipRecord& right )
{
	TmpPipRecord.m_iPairIndex = left.m_iPairIndex;
	TmpPipRecord.m_dRealPipChange = left.m_dRealPipChange;

	left.m_iPairIndex = right.m_iPairIndex;
	left.m_dRealPipChange = right.m_dRealPipChange;
	
	right.m_iPairIndex = TmpPipRecord.m_iPairIndex;
	right.m_dRealPipChange = TmpPipRecord.m_dRealPipChange;
}


void CArrayBestPips::init(int activePairs, int timeframe, int backshift, datetime dtTime)
{
	m_iActivePairs = activePairs;
	m_iTimeframe = timeframe;
	m_iBackshift = backshift;
	m_dtTime = dtTime;
	
	for( int element=0; element < MAXBESTPAIRS; element++ )
	{
		aBestPips[element].m_iPairIndex = 0;
		aBestPips[element].m_dRealPipChange = 0;
	}
}

void CArrayBestPips::sort()
{
	int total = m_iActivePairs;
	int ltgteq = 0;
	int countpasses = 0;
	int countSwaps = 0;
	bool needSwap = false;
	bool keepGoing = false;
	bool bReportMetrics = false;
	
	for( int loop=0; loop < 31; loop++ )
	{
		needSwap = false;

		for( int element=0; element < (total-1); element++ )
		{
			ltgteq = compare( aBestPips[element], aBestPips[element+1]  );
			if( ltgteq > 0 ) {
				swap( aBestPips[element], aBestPips[element+1] );
				needSwap = true;
			}
		}
		countpasses++;
		
		if( needSwap ) {
			keepGoing = true;
			countSwaps++;
		}
		else keepGoing = false;
		
		if( keepGoing == false )
			break;
	}
	
	bReportMetrics = true;
	
	if( bReportMetrics )
	{
		Print( "CArrayBestPips::sort(): countpasses: ", IntToStr(countpasses), ", countSwaps: ", IntToStr(countSwaps) );
	}
}

void CArrayBestPips::printone(int iElement)
{
	int iPairIdx = aBestPips[iElement].m_iPairIndex;
	
	string strSym = bwaGetPairByIndex(iPairIdx);
	
	Print( 
		IntToStr( iPairIdx )
		+ ", " + strSym
		+ ", " + DoubleToStr( aBestPips[iElement].m_dRealPipChange, 2 )
		+ ", " + DoubleToStr( MathAbs( aBestPips[iElement].m_dRealPipChange), 2 )
	);
}

void CArrayBestPips::printall()
{
	int total = m_iActivePairs;
	
	string strTime = TimeToStr( m_dtTime, TIME_DATE|TIME_MINUTES );
	Print(
		"CArrayBestPips: pairs, tf, bshft, date : "
		+ ", " + IntToStr( m_iActivePairs )
		+ ", " + IntToStr( m_iTimeframe )
		+ ", " + IntToStr( m_iBackshift )
		+ ", " + strTime
	);

	for( int element=0; element < (total); element++ )
	{
		printone(element);
	}
}

[/size]
After including the code in the script FBATT, the sorted output can be seen along side the unsorted output in the following screenshot:

FBATT-sorted-best-pairs-table-for-11Aug2017.png

So now we can use this data to remove misleading strong-pairs from our currency slope strength data.
We are therefore only interested in looking at the pairs where price is likely to move by a significant number of pips.

[snailbeard]

Now that the code for collecting the best pip movers seems to be working, it's time to see if reading back the generated data helps review the previous weeks precursors to trading:

BestPips_W1_D1_H4_for_13Aug2017.png

For the W1 row we get a quick overview and see that the GBP came top followed by EUR in sellers and this was a week for strong commodity currencies (CAD, AUD, NZD). So when did we become aware these pairs were turning into good pip runners?

From the D1 rows we had no clue about this on Monday or Tuesday. There were significant falls for two GBP pairs in the Tuesday row, so could that be a sign that GBP is going have a bad week?
However, on Wednesday GBP seems to be dropping like a stone, but not against EUR or USD, it's AUD, NZD and CAD moving up. now by the time we see this on Wednesday D1 we already missed some great trades.

However, looking at the H4 rows we get some early warnings about GBP weakness on Tuesday. We see that GBP has crossed over to falling by lunch time on Tuesday but not against EUR, which is also slipping and we see CAD popping up several times. Here is our first clue about GBPCAD, but according to a H4 chart GBPCAD was ranging in the previous week:

GBPCAD-H4-best-pip-perfromer-wk14Aug17.png

We can see strong support at the yellow moving average and it would be good to have some confirmation of a genuine breakout. Both GBP and CAD are in our H4 rows of best movers, so perhaps we can be optimistic about a breakout, but what does ATR generally indicate about GBPCAD?
Our long term W1 range is about 400 pips but last week was a mere 150 pips due to ranging, so we hope that GBPCAD will revert to a more normal range.

On Wednesday everyone is dumping GBP and EUR and it seems that AUD, CAD and NZD are hot for most of the day. On Thursday GBP gets a breather then takes another hammering on Friday.

Did we need CSS to help trade the right pairs or did these pip swings tell us the same story as CSS?
The following magnification of CSS should help us chose pairs at the right times:

multicurrency_CSS_for_week14Aug2017.png

Looking at the early part of Tuesday we would see USD going higher and JPY going lower. This is not much help to those of us in Europe. If we are awake in time we could see CHF and EUR dropping against AUD and CAD rising, by 12 on the CSS chart we see GBP also turn down. Since CHF, EUR and USD are going down, AUD and CAD look more interesting. Going back to the GBPCAD chart we would see that there has been a period of ranging and price has twice before bounced off the yellow support. Do we have any confidence that the same thing won't happen again?

The 12:00 H4 appears to open below and stay below the MA, although waiting too long would lose the chance to capture most of the bar.

It would interesting to know what my EA thinks about this configuration and the opportunities later in the week. I don't run SRT (Short Range Trades) on GBPCAD because it has fat spreads, so in order to force the analysis I have to pretend that the spread is only 2 pips. So without any other tweaking I copied the set file from USDCAD and ran a backtest:

GBPCAD-FxOpen-SRT-trade-results-table-Aug2017.png

This was an interesting surprise, although it has missed the breakouts on the 15th and 18th.
I suspect that by 12am on Tuesday it has calculated that too many pips have already been missed, which is correct for SRT but not for a multi-day trade. The entries do not correspond to the H4 chart which requires detection of triangular breakout (small H4 bars going up followed by a strong breakout down).

The following extract from the log file tells us the longer term H4 price direction is falling:

Code: Select all

12:00 GBPCAD: :   giH4Sma5HighDirection: 1, giH4Sma5LowDirection: -1
 gbH4Bk1WasUp: 0, gbH4Bk1WasDown: 1
 gbH4BarUpSma5Up: 0, gbH4BarDownSma5Down: 0
 bH4Sma20Ma60PriceUp: 0, bH4Sma20Ma60PriceDown: 1, bH4Sma20Lwma60Diverging: 0,
  giH4Sma20Direction: -1, giH4Sma60Direction: -1, giH4Lwma60Direction: -1

[/size]
However, we also get a warning about recent ranging:

Code: Select all

bH4NormSlopeFlat && bH4Ma60Flatish && bH4Ma60MiddlingLastW1

[/size]

Inorder to adapt the existing EA to make use of CSS for H4 based entries we would need an MRT module (medium range trades) which can make use of the relevant analysis and ignore the lagging analysis about ranging, along with a combination of a breakout with appropriate CSS.

[snailbeard]

Following on from the previous post:
There was a significant pip movement (starting at 08:00) and breakout of the yellow MA, following the close of H4 at 12:00.

Looking back at my CSS analysis it becomes clear that it is too narrowly focused on the top pair
H4: 2017.08.15 00:00 Buy NZDJPY PC:5.99 NC:-5.17 C(p-n):11.16 dPC:4.10 dNC:-6.89 dpn:10.99
H4: 2017.08.15 04:00 Buy NZDJPY PC:9.08 NC:-11.69 C(p-n):20.77 dPC:3.09 dNC:-6.53 dpn:9.62
H4: 2017.08.15 08:00 Sell GBPCHF PC:-11.16 NC:-0.99 C(p-n):-10.18 dPC:5.88 dNC:-3.50 dpn:9.38
H4: 2017.08.15 12:00 Sell GBPUSD PC:17.90 NC:-6.82 C(p-n):24.72 dPC:6.81 dNC:-5.83 dpn:12.63

With reference to CSS chart below several pairs are active:

CSS_strongest_pairs_0000_to_1200_15Aug2017.png

Instead of picking the strongest pair, I need to hang on to the top group of pairs.
Although NZDJPY is top twice, it does not justify it's ranking according to it's price movement.
I am inclined to label anything containing NZD as a red herring and remove it from the analysis altogether.

Therefore, I have added a bit more code to hang on to all CSS values and sort them based on fastest change, for now, ignoring which side of strong/weak threshold it is on.

Here is an example for H4 1200 29Aug2017:

sorted-CSS-live-H4-juicy-pairs-1200-29Aug2017.png

From this we can see that CHF was strong and getting stronger, but also similar for EUR.
However, at the wrong side of zero: GBP is strong but going weaker, where as USD was already weak and going weaker.
This information is too late to help us because price has already moved:

Best-CSS-pairs-side-by-side-1200-29Aug2017.png

This is just telling us what price action has already done.
The price chart already tells us what is likely to happen but some pairs are better than others. For example, EURGBP had limited price action compared to the other 3 pairs. It would have been useful to know which currencies to follow at 9am on the charts, but does H1 CSS give us what we need?

CSS_H1_best_currencies_combinations_0900_29Aug2017.png

From this chart we would expect the EUR to provide more 'pipage' and the chart suggests 'buy EURUSD' as first priority, then other pairs. What we can see is that CSS H1 and our good pairs are consistent and therefore perhaps we can use H1 CSS to help confirm the entries.

So now there are two challenges:
a) does the EA find the entry patterns for each of these pairs?
b) can we pass the CSS confirmation to the EAs in time?

[snailbeard]

I was just looking at the live demo result of the EA running on GlobalPrime, despite some good winners I was concerned by the number of recent losers:

EA_on_GP_live_demo_results_partSep2017.png

Without going into to too much detail:
we can see that the net profit was £303.93 but there was a sequence of losers. I was confused when I ran the back test for EURUSD because I didn't get any entries. It was only when I compared the live log file with the back test that I realised that I was looking at two different versions!

It was also good that my machine was running so slowly that I restarted everything so that Empty4 loaded the latest version of the EA.

From the log file extracts below we can see that the first case is not inhibited, whereas as the later version skips most of the calculations (saving some CPU):

Code: Select all

Live run log info

11:30 EURUSD: :   calcM15PreBreakoutParams(): H1BarReflectedUp
11:30 EURUSD: :   Y1JOARMA-M15CtOAboveNearToSma200
11:30 EURUSD: :  Alert M15PreBreakoutParams:  M=1b  ?Buy?  (Ask?Sl?Tp?),1.20240,1.20040,1.20740, P/L=2.50

========================================================================
CrappyTester: using the lasted version:

00:00 EURUSD: :   calcM15PreBreakoutParams(): (bTodaysSwingBetweenMinMax==FALSE)
00:00 EURUSD: :   calcM15PostBreakoutParams(): PriceInsideW1OC Ranging

< snip >

10:45 EURUSD: :  TRACE   3M15 Bias:   1 , Priority:  2M15BreakHigher  d1v<<^M15: +1  M15>>d1: +1  i3M15_YCYL: +1  ^|^|^P  ^Tails^: +1
11:00 EURUSD: :  updateH1Doji() H1Doji: fraction: 0.63 H1DojiAtSpt: 1
11:00 EURUSD: :   gbH1Bk1DownAfterHigh5: 1 gbH1Bk1UpAfterLow5: 1
11:00 EURUSD: :  TRACE   3H1 Bias:   1 , Priority:  2H1BreakHigher  H1>>d1: +1  i3H1_YCYL: -1  V||v||  VTopsV: -1
11:00 EURUSD: :   3H1BarPriceStall
11:00 EURUSD: :  updateH1_SmaRangingCheck()...
11:00 EURUSD: :   check H1MaCrossPotential:  gbH1MaCrossPotentialBuy: 0 gbH1MaCrossPotentialSell: 0
 gbH1Bk1AcrossSma100: 0 gbH1Bk1AcrossSma60: 0 gbH1Bk1AcrossLwma60: 0 gbH1Bk1AcrossSma20: 0
 gbH1Bk1AcrossLwma10: 1 gbH1Bk1AcrossLwma5: 1
11:00 EURUSD: :  updateM15Doji() M15Doji: fraction: 0.35 M15DojiAtSpt: 1
11:00 EURUSD: :  TRACE   3M15 Bias:   1 , Priority:  2M15BreakHigher  M15>>d1: +1  ^|^|^P  ^Tails^: +1
11:15 EURUSD: :  updateM15Doji() M15Doji: fraction: 0.38 M15DojiAtSpt: 1

[/size]

I now have another improved version to force Empty4 to load, always a headache as it often seems to forget which set file each instance of the EA was last using

Perhaps I could get round this problem?
Only a few parameters are specific to each pair, I could load these from a separate specific file containing the pair name.