stevehopwoodforex.com
https://www.stevehopwoodforex.com/phpBB3/
Print view

ShelleyJem. Fantastic collision of accident and analysis
https://www.stevehopwoodforex.com/phpBB3/viewtopic.php?t=610		 Page 17 of 20
Author:  SteveHopwood [ Tue Jun 12, 2012 9:12 pm ]
Post subject:  Re: ShelleyJem. Fantastic collision of accident and analysis
I am abandoning SJ for the rest of this week. I am fed up with her.

Every time I fix a thingy here, it creates a problem there. When I fix that problem there, it creates a problem elsewhere. When I.................................

I no longer understand how the bot I created works. I am going to start again from scratch, but only when I feel strong enough.

So Jem. Here is your challenge. Put together a spec that I can code. You need to consider all the stuff you want included and put it all in one place so I can code it from the bottom upwards. "Oh, and by the way..........." later on will not be welcome.

You do not need to think like a coder; I will do that, sort of. Just make sure your trading system is robust.

No need for further SJ bug reports guys. I shall do nothing with them. We are talking one tired bunny here.

:D
Author:  hammondnz [ Tue Jun 12, 2012 10:09 pm ]
Post subject:  Re: ShelleyJem. Fantastic collision of accident and analysis
SteveHopwood wrote:I am abandoning SJ for the rest of this week. I am fed up with her.

Every time I fix a thingy here, it creates a problem there. When I fix that problem there, it creates a problem elsewhere. When I.................................

I no longer understand how the bot I created works. I am going to start again from scratch, but only when I feel strong enough.

So Jem. Here is your challenge. Put together a spec that I can code. You need to consider all the stuff you want included and put it all in one place so I can code it from the bottom upwards. "Oh, and by the way..........." later on will not be welcome.

You do not need to think like a coder; I will do that, sort of. Just make sure your trading system is robust.

No need for further SJ bug reports guys. I shall do nothing with them. We are talking one tired bunny here.

:D
Good on you Steve

I lurk in the background trying to absorb all the changes and amendments made and I am in constant wonderment as to how you manage it all what with family, piano teaching, moderating the forum, trading, coding EAs and then all of the other life's incidentals as well. Take the well earned break and un-frazzle the brain, I'm sure we'll manage!! :D

Graham

PS. Jemook, I think I read in a thread somewhere you're in Aussie. If that is so, whereabouts?
Author:  fxshadow [ Tue Jun 12, 2012 10:59 pm ]
Post subject:  Re: ShelleyJem. Fantastic collision of accident and analysis
Jemook mentioned trading SJ 24/5. I'm finding a few pips if you combine the latest version with session openings. Trade only 1 basket per session. Start time about 30 minutes before session and end time about 1.5 hrs into session. Shoot for about 20 pips adaptive TP and 40 pips adaptive SL. You could also try 50 pips adaptive with BE at 20 pips with 5 pips profit. Just something to play with while we are waiting.
Author:  Lifesys [ Wed Jun 13, 2012 1:55 am ]
Post subject:  Re: ShelleyJem. Fantastic collision of accident and analysis
Not sure what the Janet & John stuff is about but we have converted a number of indicators/EAs with PipFactor style function because -
1. Most attempts to solve pip/point are based on a false premise (& hence only work sometimes).
I have noticed a motley mix of digits/point/pips solutions in these threads, none systematic, hence merry-go-round problems.
2. Pip has a definition - 1/100 of US cent, digit/point do not and are, therefore, arbitrary.
3. Calculations based on the significant figures (2,4,5 etc.) of a b_roker makes no sense. PipFactor works on magnitude, where the decimal point resides, not arbitrary dec places.
4. For what we are trading, most pairs are expressed as 10000 pip, all JPY pairs & XAGUSD are 100 pip and XAUUSD 10pip. So conversion becomes simple. [Silver does have a x5 volume factor.] A single line addition to the function can be used for specific commodities.
5. Use 'digits' only for DoubleToStr screen formatting.

Steve, who does an amazing job, has a fuller explanation.
I came here after finding MPTM - which I use, have converted and corrected in a couple of minor places. [eg MissingTakeProfitPips was initialised but never assigned in 4.29]. MPTM is an excellent tool.
I also think Shelley -0.8>Slope>0.8 is an excellent trend system but watering to 0.4 weakens it considerably.
Having taught senior mathematics for >20 years & written many commercial software packages, if that is related to Janet & John then so be it - I will just keep banking the real pips (& $).
Trust this helps - Paul.
Author:  garyfritz [ Wed Jun 13, 2012 2:04 am ]
Post subject:  Re: ShelleyJem. Fantastic collision of accident and analysis
Glad you were successful, Paul. I agree, the confusion stems because people try to think in points, which is ill-defined and different for different crims. Multiply non-JPY FX pairs by 10000, JPY FX pairs by 100, full stop. If you have e.g. a 5-digit crim, that just means you (correctly) end up with fractional pips. E.g. if you make 0.00156 profit in EURUSD, that is 0.00156 * 10000 = 15.6 pips profit.
Author:  Lifesys [ Wed Jun 13, 2012 5:14 am ]
Post subject:  Re: ShelleyJem. Fantastic collision of accident and analysis
Exactly Gary.
PipFactor is initialised,
PFactor(pair) declared as a public function then -
(i) for single pair applications : PipFactor = PFactor(Symbol()); can be called in int init()
(ii) for multipair applications : each separate Routine requiring conversions must have a call to -
PipFactor = PFactor(OrderSymbol()); at the start, to get PipFactor for specific pair.
Then simply multiply or divide by PipFactor as required.
Pips = price * PipFactor; & Price = Pips / PipFactor;
PipSpread = (Ask-Bid) * PipFactor; etc.
No use of digits or points at all until display.
Print("Close Price : "+DoubleToStr(Close[0], Digits));

I have watched Shelley variations and pips/points seemed to be argued by guesstimation.
eg use a JumpStop = 40; but BreakEven = 200; because they were calculated differently.
Steve H really impresses me and hope this helps refine his work.
Author:  phil_trade [ Wed Jun 13, 2012 6:19 am ]
Post subject:  Re: ShelleyJem. Fantastic collision of accident and analysis
Lifesys wrote:Exactly Gary.
PipFactor is initialised,
PFactor(pair) declared as a public function then -
(i) for single pair applications : PipFactor = PFactor(Symbol()); can be called in int init()
(ii) for multipair applications : each separate Routine requiring conversions must have a call to -
PipFactor = PFactor(OrderSymbol()); at the start, to get PipFactor for specific pair.
Then simply multiply or divide by PipFactor as required.
Pips = price * PipFactor; & Price = Pips / PipFactor;
PipSpread = (Ask-Bid) * PipFactor; etc.
No use of digits or points at all until display.
Print("Close Price : "+DoubleToStr(Close[0], Digits));

I have watched Shelley variations and pips/points seemed to be argued by guesstimation.
eg use a JumpStop = 40; but BreakEven = 200; because they were calculated differently.
Steve H really impresses me and hope this helps refine his work.
I agree Steve really impresses
.
So to avoid confuse him, I propose we all agree about one robust and exaustif module to convert pips or deci-pips to point and vice versa. As a majority of broker are using deci-pips, I suggest that all parameters would have to be in deci-pips -> SL = 500 stand for 50 pips.
and for simplify Steve job (not an Apple joke !), I suggest that user with broker in pips or centi-pips, just adapt there parameters themself in .set file.

so Steve would have 2 simple functions, 1 to convert pips parameters in point and 1 to convert point in pips.
Author:  Lifesys [ Wed Jun 13, 2012 10:06 am ]
Post subject:  Re: ShelleyJem. Fantastic collision of accident and analysis
Hi Phil_Trade,
the PipFactor function 8 lines of code may seem a lot for one instance (Shelley_Now) but in MPTM it replaces 60 lines of code and is referred to in over 50 instances. I believe it gives a consistency no matter what the resolution of the data source price and correctly solves a problem often railed at b_rokers.
Author:  phil_trade [ Wed Jun 13, 2012 10:45 am ]
Post subject:  Re: ShelleyJem. Fantastic collision of accident and analysis
Jemook

to accept Retrace Trade, you ask Steve that price must cross TMA upper/lower line. So he code it like this.

But, as in example (see chart NZDUSD) price can just approch TMA because of a bounce upon Sx support, and then you miss the retrace. As we also wait to price for crossing after MA 5.1 line, I suggest we just look for an approch of this line ( about 15 pips )
Author:  phil_trade [ Wed Jun 13, 2012 10:50 am ]
Post subject:  Re: ShelleyJem. Fantastic collision of accident and analysis
Lifesys wrote:Hi Phil_Trade,
the PipFactor function 8 lines of code may seem a lot for one instance (Shelley_Now) but in MPTM it replaces 60 lines of code and is referred to in over 50 instances. I believe it gives a consistency no matter what the resolution of the data source price and correctly solves a problem often railed at b_rokers.
I'm fine with your code, but this line below assume this is with a 5 digits brokers no ?

Code: Select all

 int PipFactor=10000
may be at least, set a parameter for that 10000 that everyone could adjust to it's broker ?
All times are UTC Page 17 of 20

Powered by phpBB® Forum Software © phpBB Limited