Phoenix 2007 (new thread) | Page 46 | Forex Factory

Options

Go to
Permalinks
Print Thread

Similar Threads

Phoenix Forex Manager trading journal 25 replies

Phoenix Foundation 1 reply

Can someone fix the Phoenix EA? 0 replies

Automated Trading Championship 2007: New Challenge! 33 replies

Phoenix is here! 848 replies

Attachments: Phoenix 2007 (new thread)
Exit Attachments

Phoenix 2007 (new thread)

  • #901
  • Nov 18, 2006 10:08am Nov 18, 2006 10:08am
Hi everybody.

About my previous post "Consecutive signals" for Phoenix, I've found a "small" bug in my changes to a code

if (CurTime()-s_time>900) {ss=ss+1; bs=0;}
if (ss>=signal_count) {
res=OrderSend(...SELL....);
ss=0; s_time=CurTime();}

it's counting "ticks" during signal is "ON", means not counting signals 1 per 15min bar, instead counting ticks during active signal. That's why such amounts of consecutive signals (100,200, etc.) are working.

The code should be :
...if (CurTime()-s_time>900) {ss=ss+1; bs=0; s_time=CurTime();}...

Then even 2 or 3 as signal_count reduces number of trades significantly.
On the other hand, this buggy "tick counter" instead of "signal counter" works too, at least at tester. Now testing it live, let's see...
  • #902
  • Nov 18, 2006 11:11am Nov 18, 2006 11:11am
Excellent! Great way to organize a thread. I'm going over right now to post my results for this past week (which were quite good with USDJPY using Phoenix 5.6.3).

Cheers

Bill

Quoting daraknor
5.6.4 relesed with 1 major code fix, 1 enhancement to trade logic and a setting to be used in research have been added.
http://www.forex-tsd.com/phoenix/463...-post-1-a.html

All modes may be working now, please backtest all 3 modes and post results:
http://www.forex-tsd.com/phoenix/464...imization.html

Your weekly Live Testing results are needed!
http://www.forex-tsd.com/phoenix/465...g-reports.html

Thank you all for staying with us. Hendrick represented a great example to our forums, programming and trading. I hope the community that formed around a selfless person will endure, and Phoenix will improve as we grow and work together.
  • #903
  • Nov 18, 2006 11:28am Nov 18, 2006 11:28am
Is it just me or does it look like everybody is deserting this thread…
  • #904
  • Nov 18, 2006 1:41pm Nov 18, 2006 1:41pm
Quoting VinceTheBeast
Is it just me or does it look like everybody is deserting this thread…
One thing of note, negativity breeds negativity which breeds disinterest, especially when we're all here to learn from one another.

I think comments I've seen posted here recently such as:

"No, I'm not gonna post the statement, back test it yourself."

tend to scare people away (e.g. wondering, heck is this really a friendly place?)

Yep, newbie chatter can cause veterans on any topic to get irrate. And newbies caught in the midst of lots of inconclusive and/or meandering info/data will sputter off at times before doing all of their due diligence...

It's all sort of like price meeting resistance and deciding to turn the other way!

And Hendrick saying bye-bye was one huge point of resistance! (I guess his Fibonacci tolerance level was hit!)

Cheers!

Bill
  • #905
  • Nov 18, 2006 2:31pm Nov 18, 2006 2:31pm
Quoting Dagnar
Hi everybody.

About my previous post "Consecutive signals" for Phoenix, I've found a "small" bug in my changes to a code

if (CurTime()-s_time>900) {ss=ss+1; bs=0;}
if (ss>=signal_count) {
res=OrderSend(...SELL....);
ss=0; s_time=CurTime();}

it's counting "ticks" during signal is "ON", means not counting signals 1 per 15min bar, instead counting ticks during active signal. That's why such amounts of consecutive signals (100,200, etc.) are working.

The code should be :
...if (CurTime()-s_time>900) {ss=ss+1; bs=0; s_time=CurTime();}...

Then even 2 or 3 as signal_count reduces number of trades significantly.
On the other hand, this buggy "tick counter" instead of "signal counter" works too, at least at tester. Now testing it live, let's see...

Dagnar, thank you for the original idea.

Allow me 1 suggestion:
A stricter way of testing 1 signal per bar is by using the Time[0] element (=open time of current bar) to check if it's still the same bar.
The code can then be simplified a bit by using:

Inserted Code
 
datetime CurBar;
 
.....
 
if (CurBar!=Time[0])
{
ss++;
bs=0;
CurBar=Time[0];
}
 
if (ss>=signal_count)
{ 
...OrderSend....
 
ss=0;
CurBar=Time[0];
}

Regards
  • #906
  • Nov 18, 2006 6:14pm Nov 18, 2006 6:14pm
Quoting HerbertH

Allow me 1 suggestion:
A stricter way of testing 1 signal per bar is by using the Time[0] element (=open time of current bar) to check if it's still the same bar.
The code can then be simplified a bit by using:
HerbertH, thank you for fixing Mode 3!
And Dagnar, thank you for your improvements.

I suppose, you both are part of development team, righ? So I don't need to copy/paste this msg and code into 'development thread', correct?

Mario
  • #907
  • Nov 18, 2006 8:16pm Nov 18, 2006 8:16pm
I watch both forums. The main reason for the separation was so Developers weren't plagued with user questions, and could find a friendly place to go.

Different users have different needs...
  • #908
  • Nov 18, 2006 11:17pm Nov 18, 2006 11:17pm
Quoting wackena
I found a post on this forum that has a link to a tick data file for eurusd. It is a zip file just over 18 mb. Here is the link:

http://rapidshare.com/files/1333387/EURUSD1_0.zip
I've downloaded the file and will be bactesting to see if % Model Quality improves over the present 90% level.
I've tried and I'm getting 25% modeling quality.
Did you get any better numbers?

Mario
  • #909
  • Nov 19, 2006 4:15am Nov 19, 2006 4:15am
I've already posted a similar variant here:


if (Bars>s_bars) {ss=ss++; bs=0;s_bars=Bars;}
if (ss>=signal_count) {
res=OrderSend(...OP_SELL...);
ss=0; s_bars=0;}

and then deleted my post, because it dosn't work. Just think. We must to wait N signals on N bars of the same signal. That only meens, that we'ra missing N-1 signals. That's all.
  • #910
  • Nov 19, 2006 4:44am Nov 19, 2006 4:44am
Besides, guys, I do not trus in Mode3. Already 2 weeks I have P4 on 8 pairs (Alpari). And all the time

I have 4-6 oepn trades on diff. pairs. That meens, if we'll double/trible our pos's we'll only increase our risks and we'll miss other trades on over pairs because of free margin.
---
P.S. For now results on acc are bad. Now I'm workin' on optimization of settings. I've already posted my set's for USDJPY, now - GBPUSD

SMAPeriod = 3;
SMA2Bars = 14;
Percent = 0.0023;
TakeProfit = 42;
StopLoss = 80;
TrailingStop = 0;
OSMAFast = 26;
OSMASlow = 18;
OSMASignal = 15;
EnvelopePeriod = 6;
Fast_Period = 28;
Slow_Period = 36;
DVBuySell = 0.0003;
DVStayOut = 0.0017;
  • #911
  • Nov 19, 2006 4:53am Nov 19, 2006 4:53am
Hendrick wrote here about a sinhronization of working of Phoenix. I think it's very important to begin at a time. So, I made a little adding to the code, to start working exectly with a begining of a new bar. Look:

int Cntbars;
int init()
{Cntbars=Bars+1;
return(0);
}
..............
//======================Start function=======================

void start()
{
if(Cntbars<=Bars)
{
.......
  • #912
  • Nov 19, 2006 8:34am Nov 19, 2006 8:34am
Quoting Artemos
I've already posted a similar variant here:


if (Bars>s_bars) {ss=ss++; bs=0;s_bars=Bars;}
if (ss>=signal_count) {
res=OrderSend(...OP_SELL...);
ss=0; s_bars=0;}

and then deleted my post, because it dosn't work. Just think. We must to wait N signals on N bars of the same signal. That only meens, that we'ra missing N-1 signals. That's all.
Thanks Artemos (Is that you in the Avatar? )

In theory Yes, but we all do backtesting to optimize and test (to avoid to fiddle around for month in life sessions)
If backtesting with a 6 month period shows increased profits on average or less risk, then the idea itself deserves further investigation.
And although I think backtesting currently s*(beep)**s in MT build 200, I rather put my money on backtesting than on my gut feelings.

BTW. using 'Bars' for checking most of the time will work. The No. of history bars however could vary, e.g if you manually scroll back while the EA is activated, more history may become available and thus increase 'bars'. That's why I'd rather use Time[0] as a unique identifier. It's a bit stricter.

Regards
  • #913
  • Nov 19, 2006 8:37am Nov 19, 2006 8:37am
Quoting Artemos
Besides, guys, I do not trus in Mode3. Already 2 weeks I have P4 on 8 pairs (Alpari). And all the time

I have 4-6 oepn trades on diff. pairs. That meens, if we'll double/trible our pos's we'll only increase our risks and we'll miss other trades on over pairs because of free margin.
Please give mode3 another try; in this weeks build 5.6.04 it was changed to work like Hendrick designed it in the first place. Initial backtests looked promissing.
  • #914
  • Nov 19, 2006 5:32pm Nov 19, 2006 5:32pm
The version of signal_count parameter in the 5.6.04 download listed above is based on sequential tick counts, not bar counts (I didn't alter from original code). This means the time counter is not used at all.

Back testing this parameter is very strange at the moment, because MT4 just changed how the ticks are calculated. The Bar version should (*should but not verified*) have the same results in both MT198 and MT200 on the same data. If there are differences, it probably isn't the fault of the Bar version. Testing Build 198 vs 200 using tick calculations should have varied results.

In testing the Bar version with 900 seconds, we have seen the maximum drawdown shoot up drastically in backtest. We're trying again with smaller delays between bars, and with the tick based version. It is possible none of these methods will achieve an increased balance *but still be useful* because they might make data signals more reliable. That means a single result may be lower, but (possibly) over time the EA would be more reliable. I think it deserves attention and study.

The only change in the default behavior in 5.6.04 is HerbertH's Mode 3 fix, endorsed by Hendrick very strongly.
  • #915
  • Nov 19, 2006 7:13pm Nov 19, 2006 7:13pm
Quoting daraknor
The version of signal_count parameter in the 5.6.04 download listed above is based on sequential tick counts, not bar counts (I didn't alter from original code). This means the time counter is not used at all.

Back testing this parameter is very strange at the moment, because MT4 just changed how the ticks are calculated. The Bar version should (*should but not verified*) have the same results in both MT198 and MT200 on the same data. If there are differences, it probably isn't the fault of the Bar version. Testing Build 198 vs 200 using tick calculations should have varied results.

In testing the Bar version with 900 seconds, we have seen the maximum drawdown shoot up drastically in backtest. We're trying again with smaller delays between bars, and with the tick based version. It is possible none of these methods will achieve an increased balance *but still be useful* because they might make data signals more reliable. That means a single result may be lower, but (possibly) over time the EA would be more reliable. I think it deserves attention and study.

The only change in the default behavior in 5.6.04 is HerbertH's Mode 3 fix, endorsed by Hendrick very strongly.
Does the new mode 3 still open three trades?
  • #916
  • Nov 19, 2006 7:52pm Nov 19, 2006 7:52pm
yup, mode 3 in 3 trades, and look more better now, just wait n see.....
  • #917
  • Nov 19, 2006 9:41pm Nov 19, 2006 9:41pm
Hi can any one give me the best setting and fixs for this EA
cos reading +60 pages is very hard

~Walid
  • #918
  • Nov 19, 2006 9:46pm Nov 19, 2006 9:46pm
It really is worth the read, and would be respectful to Hendrick to read the thread...
  • #919
  • Nov 19, 2006 11:22pm Nov 19, 2006 11:22pm
http://www.forex-tsd.com/phoenix/

Almost all questions answered in the stickied posts.
  • #920
  • Nov 20, 2006 2:33am Nov 20, 2006 2:33am
<HR style="COLOR: #d1d1e1" SIZE=1> <!-- / icon and title --><!-- message -->What do you think about using Phoenix to trade CFD and Gold? Any ideas?
2 traders viewing now