Gamestudio Links
Zorro Links
Newest Posts
Zorro FIX plugin - Experimental
by flink. 04/21/24 07:12
Data from CSV not parsed correctly
by EternallyCurious. 04/20/24 21:39
M1 Oversampling
by 11honza11. 04/20/24 20:57
Scripts not found
by juergen_wue. 04/20/24 18:51
zorro 64bit command line support
by 7th_zorro. 04/20/24 10:06
StartWeek not working as it should
by jcl. 04/20/24 08:38
folder management functions
by VoroneTZ. 04/17/24 06:52
AUM Magazine
Latest Screens
The Bible Game
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Who's Online Now
1 registered members (rki), 405 guests, and 1 spider.
Key: Admin, Global Mod, Mod
Newest Members
EternallyCurious, howardR, 11honza11, ccorrea, sakolin
19047 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
Page 2 of 4 1 2 3 4
Re: Blame the manual [Re: krial057] #451366
05/04/15 15:23
05/04/15 15:23
Joined: Nov 2013
Posts: 123
Mithrandir77 Offline
Member
Mithrandir77  Offline
Member

Joined: Nov 2013
Posts: 123
Not sure if it is a mistake but in the manual it says for the DTREE method "The signals should be in the -100..100 range for best precision." , my question is, shouldn't it be the same for PERCEPTRON -and PATTERN maybe?- because according to what I read about neural networks, inputs should be normalized.

Re: Blame the manual [Re: Mithrandir77] #451503
05/08/15 11:48
05/08/15 11:48
Joined: Jul 2000
Posts: 27,982
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,982
Frankfurt
PERCEPTRON and PATTERN do not need normalized data. The perceptron is solved with a normal equation, not with gradient descent. Neural networks that use gradient descent or similar backprop algorithms would indeed require normalized, balanced data.

Re: Blame the manual [Re: jcl] #451727
05/18/15 06:48
05/18/15 06:48
Joined: Sep 2013
Posts: 504
California
G
GPEngine Offline
User
GPEngine  Offline
User
G

Joined: Sep 2013
Posts: 504
California
Thank you for carefully annotating many indicators with the warning, "The function internally creates series and thus must be called in a fixed order in the script." This helps me avoid Error 041: Inconsistent series calls.

Here are a few series-creating indicators/transformations which lack this annotation.

ZMA
RVI

Re: Blame the manual [Re: GPEngine] #451732
05/18/15 15:35
05/18/15 15:35
Joined: Sep 2013
Posts: 504
California
G
GPEngine Offline
User
GPEngine  Offline
User
G

Joined: Sep 2013
Posts: 504
California
Hurst.

Re: Blame the manual [Re: GPEngine] #451812
05/22/15 08:34
05/22/15 08:34
Joined: Jul 2000
Posts: 27,982
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,982
Frankfurt
Thanks! Will be corrected.

Re: Blame the manual [Re: jcl] #452598
06/18/15 15:13
06/18/15 15:13
Joined: Sep 2013
Posts: 504
California
G
GPEngine Offline
User
GPEngine  Offline
User
G

Joined: Sep 2013
Posts: 504
California
Quote:
TrailLock
'Locks' a percentage of the profit (default = 0 = no profit locking); has only an effect when Stop and Trail are set and the profit is above the trail distance. A stop loss is automatically placed at the given percentage of the current profit. Example: A long position is currently in profit by 10 pips. TrailLock = 80 would then place the stop loss at 8 pips above the entry price, thus locking 80% of the profit. TrailLock = 1 would set the stop loss at the entry price, i.e. at break even as soon as the profit reaches the Trail value. Using TrailLock is in most cases preferable to setting a profit target.
So, which is it? Is TrailLock supposed to be a percentage [0,100] or a fraction [0,1]?

Re: Blame the manual [Re: GPEngine] #452599
06/18/15 16:04
06/18/15 16:04
Joined: Jun 2013
Posts: 1,609
D
DdlV Offline
Serious User
DdlV  Offline
Serious User
D

Joined: Jun 2013
Posts: 1,609
Hi GPEngine. From my experience so far, a percentage.

HTH.

Re: Blame the manual [Re: DdlV] #452609
06/19/15 10:28
06/19/15 10:28
Joined: Jul 2000
Posts: 27,982
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,982
Frankfurt
Probably the "1" was misguiding, but any low number greater than zero would do here.

Re: Blame the manual [Re: jcl] #452615
06/19/15 12:51
06/19/15 12:51
Joined: Jun 2013
Posts: 1,609
D
DdlV Offline
Serious User
DdlV  Offline
Serious User
D

Joined: Jun 2013
Posts: 1,609
Thanks jcl. This has spawned some other thoughts:

I gather, then, that 1 isn't specifically called out in the code - it's just that 1% (or other small %) of the profit normally calculates close enough to 0 that the result is the stop being at entry?

Is this also taking into account Spread, etc.? I.e., in the example of 10 pips, that's 10 pips after costs, yes? And the TrailLock stop is placed at entry+costs+8pips?

Also, is TrailLock a one-time thing or is it re-evaluated at every tick/bar? In the example, if profit subsequently increased to 20 pips, would the TrailLock stop be moved up to 16 pips?

Thanks.

P.S. - Does it work for TrailLock >100? Can I "lock" >100% of my profit?! laugh

Re: Blame the manual [Re: DdlV] #452620
06/19/15 13:51
06/19/15 13:51
Joined: Jul 2000
Posts: 27,982
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,982
Frankfurt
Yes, it's 1% in the example, and spread is taken into account. Slippage not, as it is determined only in hindsight. TrailLock is re-evaluated at every tick, like all exit parameters.

As to locking more than 100% profit, well it is not easy, but we're working on it laugh.

Page 2 of 4 1 2 3 4

Moderated by  Petra 

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1