Price Per pip - page 7

New comment
 
gordon:
This seems like a matter of semantics... Common convention states that when we say a 'value is in x', we mean that x is the 'unit' used. In this case Point is not the unit used, so MODE_TICKSIZE is not in Points.

Ah... yes, when you put it like that. I agree. Point is not the unit used. And now I also get what you meant by 'in price terms'

... I agree that it's a multiple of Point, but that's just cause Point is the smallest possible price change, so by definition it must a multiple of Point.

Yes. I need to emphasize this as opposed to multiple of MODE_TICKSIZE of which should be observed when sending order price. Thanks Gordon...

 
1005phillip:

Checkout the include files contained in the rar file I attached on page 5...it does both of these unless I am misunderstanding your question.

edit: specifically the following code snips.

For tickvalue using the include file titled "Analyze Currency Symbol 2010.06.07.mqh" you would:

1. call the int SymbolType() function

2. call the CounterPairForCross() function


3. then you'd compute the tickvalue at current market price for the symbol:



For leverage using the include file titled "Analyze Currency Symbol 2010.06.07.mqh" you would:

1. call the int SymbolType() function

2. call the BasePairForCross() function


3. then you'd compute the symbol-specific leverage at current market price for the symbol by calling SymbolLeverage():


I'm gonna take a look at this and give it a shot.
 
LEHayes:

I'm gonna take a look at this and give it a shot.
Amazing that a simple question like this can take up so much room.
 
engcomp:
Amazing that a simple question like this can take up so much room.
This thread grew to explore a lot of aspects aside from MODE_TICKVALUE that turned out to be the source of LEHayes original problem. If you have full grasp of currency pairs' MarketInfo calculations and all its ramifications. Then you are well ahead of myself engcomp.
 
cameofx:
This thread grew to explore a lot of aspects aside from MODE_TICKVALUE that turned out to be the source of LEHayes original problem. If you have full grasp of currency pairs' MarketInfo calculations and all its ramifications. Then you are well ahead of myself engcomp.

Point taken, cameofx

I took time to go through the whole thread and lost my way.

Can someone please explain what was the gain in this issue?

No harm if no one can, it's still a great discussion, Helmut

 

Summary :

  • MODE_TICKVALUE will be different across pairs depending on the base & quoted currency pair combination.
  • The MarketInfo MODE_TICKVALUE IS RELIABLE for accessing the value of smallest tick movement of pairs in the deposit currency.
  • The currency pairing / synthesizing can vary to 5 possible combinations as investigated by Phillip.
  • One can confirm this by using an Independent calculation such as using the include functions that Phillip have shared.
  • MODE_TICKVALUE is calculated using Bid values. If calculated using Ask, it will have minor discrepancy compared to calling MarketInfo TV - Spread.
  • Point is the smallest possible price movement. MODE_TICKSIZE can be greater than Point.

Other findings :

  • CB : Broker have been spotted to append an apostrophe which enable Instant Execution trading.
  • Phillip : Alpari, CitiFX, CMS forex, forex.com, FXCM, FXDD, IBFX, MIG, and ODL is so far consistent with currency pairs Symbol() names. Which is important when using independent pair 'synthesizing' function.
  • LEHayes still can't find his function (just kidding LEHayes :)) I'd help if I'm not too ADD to code. I'm posting from workplace...
Someone can add should I missed anything.
 
cameofx:

[...] Someone can add should I missed anything.

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.
 
jjc:

Great summary. Two points:

  • 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.


What cameo meant by consistency of symbol names was that the convention by which symbols are named appears to be conserved...that convention being the use of appending suffixes but never prepending prefixes or intertwining symbols between the currency names themselves.

Yes: EURUSD, EURUSDm, EURUSDct, EURUSDFXF

No: EUR/USD, mEURUSD, mEUR/USDct

As such the code we explored in this thread for reducing a Symbol() to it's constituent currency components (Base and Counter) and then using that info to reconstruct the counter currency pair (and base currency pair) formed with the account's currency is considered robust with today's brokers but not robust against the possibility that tomorrow a broker could choose to break with convention and thus break this particular code.

So while not all brokers use the exact same symbol string, the convention by which they derive their symbol names appears to be consistent.
 

1005phillip:
What cameo meant by consistency of symbol names was [...]

I know. I was merely agreeing with the pair of you, and throwing in the extra point about some brokers having multiple suffixes. I should perhaps have been clearer.
 
cameofx:

Summary :

  • The MarketInfo MODE_TICKVALUE IS RELIABLE for accessing the value of smallest tick movement of pairs in the deposit currency.

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.

CB

12345678910
New comment
Reason: