Price Per pip - page 5

 

@Gordon

"What do u mean by 'Instant Execution'? (it's implied that it's not the same as 'Market Execution')..."

MT4 Server seems to refer (you'll see this in its manual order open pull down list) to the ability to set the stops in the order open as "Instant Execution"; and "Market Execution" when they need to be set at 0 and modified.

@SDC and 1005philip

"wouldnt it be easier just to use Symbol() in all references to the symbol then even if the brokers server has EURUSD entered as mooncheese it wont matter as long as the EA also knows EURUSD is called mooncheese"

When the symbol name is changed by the broker, this requires opening a new chart to which you will add your EA.

CB

 
cloudbreaker:

MT4 Server seems to refer (you'll see this in its manual order open pull down list) to the ability to set the stops in the order open as "Instant Execution"; and "Market Execution" when they need to be set at 0 and modified.

I'll be damned, the pull-down menu actually changes when logging to an account that only accepts stops at 0. I never noticed that. Thanks.
 
SDC:

wouldnt it be easier just to use Symbol() in all references to the symbol then even if the brokers server has EURUSD entered as mooncheese it wont matter as long as the EA also knows EURUSD is called mooncheese

Wow! the topic has grown to 42 posts & counting, it's a record...

If everyone don't mind.... picking up where I had left off...

SDC, If I'm not mistaken, Phillip was laying out his custom function to produce TickValue, independently, as opposed to simply calling the predefined MarketInfo. Of course calling MODE_TICKVALUE on Symbol() is the easiest logical thing to do. But aside from demonstrating/proving where/how the TickValue got it's value. I could be wrong but I think this has the advantage of synthesizing an/some exotic pair(s) that any particular broker may not offer. We can permutate all the base/counter that's available. I don't have an example handy. But I'm pretty sure what brokers have to offer is not a complete permutation of base/counter-s available. I'm just exploring on what Phillip had posted. May not be useful unless one need to hedge/arbitrage or something...

 

cameo I'd be happy to share more of the code I have sitting here if you'd find value in it. Honestly I assumed it was just a mundane/routine path that most folks had already traveled down in the course of their own coding adventures so I didn't want to insult anyone's intelligence by presuming it was anything new to the community. (also my code isn't exactly what I consider to be publish-worthy in the form that it sits on my harddrive, potentially doing more harm than good in the wrong hands and I really don't want to anyone losing money because of my lackluster commenting style, etc)

The benefit (I view it more as "the necessity") of being able to calculate tickvalue from the fundamentals isn't so much for hedging/arbitrage (although it certainly could be leveraged there as well) but rather it is for something far more simplistic. In my case I find it necessary for computing equity at risk, stoploss placement, etc.

(also, note: the marketinfo value for MODE_TICKVALUE is based strictly on the Bid price of currency pair, not the ask price, as such the marketinfo tickvalue is actually only technically correct for use with calculations that depend on bid price such as the takeprofit value of a long position or the stoploss of a short position...again the discrepancy is minor, and naturally it makes no difference for currency pairs in which the account currency is the counter-currency such as EURUSD and so on)

The issue with using marketinfo Tickvalue is that it is valid only for the current market prices. Tickvalue is dependent on market price for all but those currency pairs which have the account's currency as the counter currency. (tickvalue of USDJPY is different at USDJPY = 99.00 versus 98.00, etc)

The reason for the creation of "synthetic " pairs as you refer to them is that for cross-currency pairs the tickvalue is dependent on price of two currency pairs. Both the symbol being traded as well as the currency pair that is formed by the account's currency and that of the counter currency pair in the symbol being traded.

An example. Let's say your account's denomination is USD and you want to trade the EURGBP. The value of the EURGBP position once you open it is going to depend on the market price of the EURGBP as well as the market price of the GBPUSD.

You could open a long position on the EURGP at 0.8500 and it could sit there at that same price all day long and yet your trade will be underwater if the GBPUSD has been trending downward in the meantime. (this is also why you may have read a post or two from me before wherein I stated that hedging is necessary, but impractical, when trading cross-currency pairs if you aim to manage your risk)

In my case I like to programmatically determine the currency pairs that bridge between the account currency and the cross-currency pair, hence the use of "synthetic" pair formation.

 
1005phillip:

cameo I'd be happy to share more of the code I have sitting here if you'd find value in it.

Yes. That'd be great..! Please attach it or pm me if you incline to. Thanks Phillip...

The benefit (I view it more as "the necessity") of being able to calculate tickvalue from the fundamentals isn't so much for hedging/arbitrage (although it certainly could be leveraged there as well) but rather it is for something far more simplistic. In my case I find it necessary for computing equity at risk, stoploss placement, etc.

(also, note: the marketinfo value for MODE_TICKVALUE is based strictly on the Bid price of currency pair, not the ask price, as such the marketinfo tickvalue is actually only technically correct for use with calculations that depend on bid price such as the takeprofit value of a long position or the stoploss of a short position...again the discrepancy is minor, and naturally it makes no difference for currency pairs in which the account currency is the counter-currency such as EURUSD and so on)

Does this implied that the other side of the trade i.e. short (Ask price) 's market info will have discrepancy if calculated independently?

The issue with using marketinfo Tickvalue is that it is valid only for the current market prices. Tickvalue is dependent on market price for all but those currency pairs which have the account's currency as the counter currency. (tickvalue of USDJPY is different at USDJPY = 99.00 versus 98.00, etc)

The reason for the creation of "synthetic " pairs as you refer to them is that for cross-currency pairs the tickvalue is dependent on price of two currency pairs. Both the symbol being traded as well as the currency pair that is formed by the account's currency and that of the counter currency pair in the symbol being traded.

Yes. This is clearly described in the mql4 Book. I have since always look at cross-currency pairs TickValues' as 'floating'

An example. Let's say your account's denomination is USD and you want to trade the EURGBP. The value of the EURGBP position once you open it is going to depend on the market price of the EURGBP as well as the market price of the GBPUSD.

You could open a long position on the EURGP at 0.8500 and it could sit there at that same price all day long and yet your trade will be underwater if the GBPUSD has been trending downward in the meantime. (this is also why you may have read a post or two from me before wherein I stated that hedging is necessary, but impractical, when trading cross-currency pairs if you aim to manage your risk)

I've never looked at it that way! Need to ponder this s'more.... :)

In my case I like to programmatically determine the currency pairs that bridge between the account currency and the cross-currency pair, hence the use of "synthetic" pair formation.

One question (a stupid one perhaps): Have you ever encounter a pair that doesn't have USD as its base/counter but exist as a cross?


 
gordon:

Unfortunately, the naming of MODE_TICKSIZE and MODE_TICKVALUE adds a second definition to Tick (which I presume is the source of the confusion...). The definition of Tick in this context is: a Tick is the smallest possible price change for the symbol in question:

  • MODE_TICKSIZE - the size of this change in price terms (the documentation claims "Tick size in points", but that's obviously inaccurate).
  • MODE_TICKVALUE - the value of this change in the account's deposit currency (this is calculated server-side by the broker).
Comments:
  1. A 'Point' (MODE_POINT) is the smallest possible price change on the left size of the decimal point for the symbol in question. This is NOT the same as MODE_TICKSIZE. Technically: MODE_TICKSIZE>=MODE_POINT, although almost always they are equal.
  2. A 'Pip' is a convention, something we all agree on. It is not a mathematical property of the symbol or a property of the MT4 server. So for example - with a 4digit broker for EURUSD a Pip is 1 Point, but for a 5digit broker a Pip is 10 Points...
  3. There's a good discussion about how to automatically determine the size of a Pip in Points here -> https://www.mql5.com/en/forum/124692.
  4. MODE_TICKSIZE can vary, although extremely rare (Point is fixed on the other hand). CB has a method to deal with these changes here -> https://www.mql5.com/en/forum/109552/page3#195878.

If I may offer what has been my interpretation to date - adding to what Gordon had laid out very well above.

  • Point : Always ends in 1. It's a conversion factor to the ratio which we called 'price'.
  • MODE_TICKSIZE : The smallest Unit of price movement in Points.
  • MODE_TICKVALUE : Current value of counter currency in conversion to its base ratio.
 

cameofx:

Point : Always ends in 1. It's a conversion factor to the ratio which we called 'price'.
Adding a clarification to gordon's "almost always", I can't immediately think of a forex instrument where this isn't true, but it's rarely true when brokers offer metals, indices etc. For example, on Alpari's gold contract, TICKSIZE is 0.05 (and Point is 0.01). As far as I am aware, MarketInfo(Symbol(),MODE_POINT) = MathPow(10, -MarketInfo(Symbol(), MODE_DIGITS))
 
cameofx:

Yes. That'd be great..! Please attach it or pm me if you incline to. Thanks Phillip...


Included in the attached rar file. I'm sure you'll have usage questions, fire away.


cameofx:

Does this implied that the other side of the trade i.e. short (Ask price) 's market info will have discrepancy if calculated independently?



That is correct. But the percentage error is simply the spread in points divided by the ask price (~0.02%-0.05% depending on the currency pair)...it only matters if you want to account for every last penny.


cameofx:

I've never looked at it that way! Need to ponder this s'more.... :)


I included an excel file in the attached rar file in hopes of furthering you as you ponder.

cameofx:

One question (a stupid one perhaps): Have you ever encounter a pair that doesn't have USD as its base/counter but exist as a cross?



As your question is currently written the easy answer is yes - every cross without USD meets your criterion. But I think you meant to ask a different question - namely have I encountered a broker that offers a cross-currency pair and at the same time does not offer the requisite currency pair that contains the counter currency of the cross pair and the currency of account's denomination?

The answer to that question is no, and for good reason because a broker simply can't. The reason a broker can't do that is because they are bound by the same fundamental price connections of the equations detailed here...in other words they need access to the same price information in order to compute and report your cross-currency position valuations.

For example let's say your have a Euro-denominated account and you buy 1 lot of GBPUSD. The counter currency in GBPUSD is the USD. So to compute your profit/loss on your GBPUSD position your broker (and you) also need to know the price of the EURUSD. (the EUR is your account currency, the USD is the counter currency of the cross-pair you opened a position in)

If the broker did not have EURUSD as an offered pair then MT4 terminal could not compute your position's floating profit/loss on a tick-by-tick basis. Hence you will never find a broker offering you the ability to trade a cross-pair (relative to your account's denomination) without also offering the primary currency pair that contains your account currency.
 
jjc:
Adding a clarification to gordon's "almost always", I can't immediately think of a forex instrument where this isn't true, but it's rarely true when brokers offer metals, indices etc. For example, on Alpari's gold contract, TICKSIZE is 0.05 (and Point is 0.01). As far as I am aware, MarketInfo(Symbol(),MODE_POINT) = MathPow(10, -MarketInfo(Symbol(), MODE_DIGITS))
Agreed on both. I have never seen a case where MODE_POINT and MODE_DIGITS didn't confirm to this formula.
 
cameofx:
Point : Always ends in 1.
"A 'Point' (MODE_POINT) is the smallest possible price change", hence obviously it must end in a 1.
MODE_TICKSIZE : The smallest Unit of price movement in Points.

As I said before, although the documentation claims "Tick size in points", this is obviously inaccurate. It's in price terms as well.

MODE_TICKVALUE : Current value of counter currency in conversion to its base ratio.

This definition is unclear... (maybe English isn't your native language?).