Phoenix 2007 (new thread) - page 105

 

I do like the idea of having a Phoenix Fund. I can see a few things being done with it. #1 We donate some of our profits from using Phoenix back to Hendrick. (Something I had intended to do anyway, we can make the process easier for others.) #2 We can have Phoenix traded on 1-3 mini accounts with different brokers, and maybe 1 normal account with the top performing broker. A large percentage of profits would be sent to Hendrick. #3 We can have the Phoenix Community sign up as an Introducing Broker with the top performing brokers, with the proceeds going into the Phoenix Fund. (A zero cost way to donate!) #4 People can donate directly using paypal or credit card to support the Phoenix Fund.

If we do this, it may make sense to have a fund for "Phoenix on Real Account" and a separate fund for "Hendrick Direct." 100% of funds sent to Hendrick Direct (minus processing fees taken by banks) would be sent to Hendrick. This would be another way for people who download and appreciate the code but can't program to help out and show their appreciation. I don't think money is the best way to do this, but I had intended to send a % of my profits back when I first read Hendrick's philsophy of freely sharing. This is reciprocal sharing in my eyes.

Hendrick, we love you man! Not all of us are Takers!

Unless key people are very opposed to this, I'm thinking about starting a poll in a separate thread. Please, feel free to flame me in this thread or in a PM on this topic. (I will pay more attention to flames from people with more than 3 posts.)

Edit: The "Phoenix on Real Account" reports would be posted for all to see.

 

Darak

100% agree to donate a % to an "Phoenix/Hendrick (whatever!) Fund" It's the minor thing we can do... Tell me where and when : I will be (virtually) there...

100% DESAGREE about a web site : the things are for the moment a bit stormy and complicated in the moind of lot of people...I think (huuum!) it will be better to stay like that a while, 2 mounth at least.

We don't NEED a web site.

What we need :

a/ Test, statements, test, statements, test, statements, test.... etc

b/ News ideas, comments, line code ...to stabilise, bug free and a strong P56XXX

c/ Crazy guys testing new settings (tests, statements, test... etc)

c/ Coders and developpers and new version of P5 to P6 with benediction of Hendrick

(btw Hendrick send us just ONE word a week to let us know that you are ok)

Then we have a lot TO DO right now. No need have to something more....

Flame you ? HA ! HA !

Why ???????????????????????

 
bertbin:
100% agree to donate a % to an "Phoenix/Hendrick (whatever!) Fund" It's the minor thing we can do... Tell me where and when : I will be (virtually) there...

if i can get this EA trade my live account just a little as hendrick's contest account, i'm more than willing to give up some of my winnings. the matter of fact is that my live account only produces losses, therefore i don't have anything to share.

AZBOfin

 
cockeyedcowboy:
O, the trade show in Las Vega this week was great, and the social hours after ward was even better. Have to get back to work again.

oh man! i completely forgot about this! shame on me.

 

Thanks for those as well.

Francoc

HerbertH:
Here's an alternate link to the UK Alpari History Centre:

http://www.alpari.co.uk/en/dc/databank.html

and the US History Centre:

http://www.alpari-idc.com/en/dc/databank.html
 
cockeyedcowboy:
There is something here that sounds like......ummm Think about this. The CockeyedCowboy

It could be that I have thought about it entirely way too much, which is why it sounds so strange. Like Jung's collective unconscious theory, you need to read the data before understanding the result.

 
AZBOfin:
if i can get this EA trade my live account just a little as hendrick's contest account, i'm more than willing to give up some of my winnings. the matter of fact is that my live account only produces losses, therefore i don't have anything to share. AZBOfin

With who do you have a live account with? Are using Phoenix to trade with and if so, what version?

 

iOsMA in Phoenix code

Hi,

Thanks to Hendrick for sharing such a good system.

I wonder if this is an error in the code or not: iOsMA function syntax, first gets fast_ema_period then slow_ema_period. But in the code OSMASlow is before OSMAFast.

Phoenix code:

double OsMABar2=iOsMA(NULL,0,OSMASlow,OSMAFast,OSMASignal,PRICE_CLOSE,2);

double OsMABar1=iOsMA(NULL,0,OSMASlow,OSMAFast,OSMASignal,PRICE_CLOSE,1);

MQL4 Reference - Technical indicators - iOsMA:

double iOsMA( string symbol, int timeframe, int fast_ema_period, int slow_ema_period, int signal_period, int applied_price, int shift)

I know that optimization was based on the OSMASlow and OSMAFast values and the signal rule which is followed:

if(OsMABar2 > OsMABar1) {SellSignal3 = true;}

if(OsMABar2 < OsMABar1) {BuySignal3 = true;}

So this misplacement is compensated through input param optimization. But after all, is it better to exchange OSMASlow and OSMAFast places in iOsMA function and find new optimized values for them?

Best,

Yashil.

 
cockeyedcowboy:

By the way when I said to hendrick that his system was missing an entry trigger (and exit signal) and that what he had was two setups and two filters with no entry trigger. what I ment was that with out one, you will be getting all kinds of signals to enter at different points along the way, in the same direction when all the setups and filters line up. with out a deffinent trigger you will get multiple signals. As an example, when two MAs cross its a trigger point that can only happen once in one direction. It is impossible to get multiple sell signals with a ma cross in a row. There is the problem with different start times and different returns.

I highly valued your critique that you provided to Hendrick. I hope that we can continue to improve the basic concepts of Phoenix, embodied in a more consistent method. Consistency is key, and taking a quasirandom sample of multitudes of signals chosen through time delays isn't my preference. I wouldn't call the signals themselves random per se, more of a series of oscillating relative values without magnitude. I thought about using the same indicators, but checking for magnitude thereby filtering out minor noise.

I have been describing the Forex market as a potentially calculable system since there are photon interactions beyond encountering Heisenburg's Uncertainty Principle. It is calculable in that sense, but it would require ascertaining the trading principles (small joke there) of millions of traders, and knowing how each would react. Worse yet, there is no official set of numbers, and each broker releases different prices, each news source provides different spin and each advice column says something different. The signal is nearly completely lost in the noise. Therefore, any indicator to work on multiple brokers needs to have a high filter to separate signals from noise. Sadly, I don't think Phoenix 5.6.x is capable of this.

I haven't embodied all of your critiques, but I hope this long winded explanation is sufficient to demonstrate that "I get it" and we do need to approach design issues. I didn't want to make major changes right out of the gate, but this is something I consider a bug. Phoenix is not only market dependent, it is broker dependent. Hendrick optimized against Alpari data stream, Alpari data stream is being used in the contest.

 

Yashil, thank you for such a great observation. I think it is good to use standard interfaces in standard ways, so changes made to one system don't create bugs in another. We likely need to change parameters if we make this change. I'm hoping to just "switch some values" and make it work, but that may mean settings files made for the previous version wouldn't work with the bug fix. If someone can determine a migration path, please let me know!

yashil:
Hi,

Thanks to Hendrick for sharing such a good system.

I wonder if this is an error in the code or not: iOsMA function syntax, first gets fast_ema_period then slow_ema_period. But in the code OSMASlow is before OSMAFast.

Phoenix code:

double OsMABar2=iOsMA(NULL,0,OSMASlow,OSMAFast,OSMASignal,PRICE_CLOSE,2);

double OsMABar1=iOsMA(NULL,0,OSMASlow,OSMAFast,OSMASignal,PRICE_CLOSE,1);

MQL4 Reference - Technical indicators - iOsMA:

double iOsMA( string symbol, int timeframe, int fast_ema_period, int slow_ema_period, int signal_period, int applied_price, int shift)

I know that optimization was based on the OSMASlow and OSMAFast values and the signal rule which is followed:

if(OsMABar2 > OsMABar1) {SellSignal3 = true;}

if(OsMABar2 < OsMABar1) {BuySignal3 = true;}

So this misplacement is compensated through input param optimization. But after all, is it better to exchange OSMASlow and OSMAFast places in iOsMA function and find new optimized values for them?

Best,

Yashil.