Price Per pip - page 8

 
cloudbreaker:

I disagree with this one. For the reason I explained above, MODE_TICKVALUE is not quite reliable on its own. I think it is reliable when used in a formula which is divided by MODE_TICKSIZE.

What do you propose that people do if they want to calculate something like a 100-pip stop-loss?
 

jjc I've built formulas which:

- no. of pips S/L and desired risk % of balance as inputs and calculate lotsize using TV/TS ratio in the formula

- of pips S/L and lotsize as inputs and calculate actual risk % of balance using TV/TS ratio in the formula

Works for me.

CB

 
cloudbreaker:

jjc I've built formulas which: [...]

Sure, but what about the very common scenario where lot-size and s/l are treated as fixed; size of cash loss is variable; and it's purely a question of turning a number of pips into a price differential? (I'm not saying that this approach is necessarily a good one, but lots of people do it.) If MODE_TICKSIZE can't be relied upon, how do you suggest that people translate n pips into y price differential? Use Point instead of MODE_TICKSIZE? Have you checked and logged the value of Point as well as MODE_TICKSIZE?
 
I'm not saying MODE_TICKSIZE is unreliable. I'm saying that MODE_TICKVALUE is unreliable when used in isolation. So rather than using TV in your formula, use (TV*Point)/TS instead. CB
 
cloudbreaker:
I'm not saying MODE_TICKSIZE is unreliable. I'm saying that MODE_TICKVALUE is unreliable when used in isolation. So rather than using TV in your formula, use (TV*Point)/TS instead. CB

  CB, I haven't had a chance to observe TV & TS. But I imagine the logic of your opinion is because TS will be in n multiple of Point. So when TS is  n times Point where n >1 then Reliable_TV = (TV*Point)/TS ? This would imply that TV doesn't scale along with TS when TS is not equal Point.
 
jjc:

Great summary. Two points:

  • I wouldn't say that Point is the "smallest possible price movement". I'd use that as a description of what MODE_TICKSIZE is. For example, on most gold contracts, Point is 0.01. That doesn't mean that the price can move in 0.01 increments; it can usually only move in increments of 0.05. Point is an expression of the number of digits to which prices are quoted.
  • Consistency of broker symbol-naming: I've not seen any MT4 brokers who express currency pairs as e.g. EUR/USD. I've only ever seen suffixes such as EURUSDFXF or EURUSDcx. Some brokers have multiple different suffixes depending on the type of your account.

Thanks jjc...

  • I'm interested in what Gordon have to say about this. I'm relenting toward his definition after our last discussion. 
  • I have to thank Phillip for defending my case. But the impending is doomed to happen. I've spotted (albeit not in pure forex pair) EUR_JPY_fut as a Symbol name on GCI. I don't have knowledge of forex future as opposed to forex so don't know how this would play in MODE_TICKVALUE. But the in-between affixes do exist. 
 
cameofx:
  • I'm interested in what Gordon have to say about this. I'm relenting toward his definition after our last discussion.

My definition loses it's original meaning when quoted out of context. To clarify - the word 'price' in the definition for MODE_TICKSIZE refers to the actual possible price quotes whereas in the definition for Point it refers to any price.

 
cloudbreaker:
I'm not saying MODE_TICKSIZE is unreliable. [...]
The log you've posted in this thread and previously shows both TICKSIZE and TICKVALUE varying. Taking the example from earlier in this thread, if you calculated a 100-pip s/l from TICKSIZE while it was briefly being reported as 0.0002 rather than 0.0001, you'd obviously end up with a stop at twice the desired range. I can't see how your samples don't say that TICKSIZE is unreliable. TICKSIZE should be a constant feature of the financial instrument, excepting only seismic events like a broker change from 4DP to 5DP pricing.
 

cameofx:

I've spotted (albeit not in pure forex pair) EUR_JPY_fut as a Symbol name on GCI.
All bets are off if we're going to start talking about futures contracts. For example, FXPro have futures contracts in the near-normal format #AAmy where "my" is a standard expiry code such as M0. EUR_JPY_fut sounds like some weird synthetic contract.
 
The reason I refer only to reliability of TV is that I don't use TS for anything other than as a divisor for TV. CB
Reason: