Price Per pip - page 6

New comment
 
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))

jjc, Thanks for your reply :

I think it's because we use decimal as our mathematical convention in calculation & perceiving numbers. If instead we use Hexadecimal for instance we wouldn't have the convenient of Point ended in one. An example would be converting how many meter is 5cm we would simply multiply it with the conversion factor of a hundredth. ( 5 cm * 0.01 --> 0.05 m ) -- traversing a full count of 10[units of cm] -- ten times. But if we use a Hexadecimal. We would have need to traverse a full count of 6 - 16 times with a modulus of 4.

So a Point is a decimal conversion factor. If market convention would suggest that for example the current price ratio of GBPUSD is 1.3535 it's only because we/they deemed the 5th place decimal conversion value of buying 1 GBP with 1.3535 USD is insignificant to the trade economy. But should the trade be larger (in yards value perhaps) and frequent. Then we/they would chase it to the least significant penny the price ratio should be. Such as 1.3535665, for example.

So I agree that Point will always be = MathPow(10, -MarketInfo(Symbol(), MODE_DIGITS)) as you equate it.

EDIT : Sorry guys, the first draft got through. Was & still too ADD to post. I hope this is better...

 
1005phillip:

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

Phillip, I can't thank you enough! This is too awesome! I need some time to figure this out. But on first look the comments are all clear & I have no trouble understanding the excel file too. This a valuable addition to my arsenal. It's very generous of you to share this piece of work to the community Phillip. Thanks again!

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.

That's very interesting!

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.

Yes your latter interpretation of my question is the correct one. Bad wording on my part. This will add some more enlightenment to the characteristic of currency pairs. Thank you...

cameo

 
gordon:
"A 'Point' (MODE_POINT) is the smallest possible price change", hence obviously it must end in a 1.

Yes, It's kinda silly an explanation. But I was only trying to underline that Point will characteristically be different with TICK_SIZE since TICK_SIZE will not always end in 1. Broker will resize it to which they see it's value fit the fluctuation's / economic value.

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

I don't understand the part in bold Gordon... If you care to explain...

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

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

Yes, It's my second language. Though that hasn't prove to be a hindrance when it comes to producing strings of nonsensical babbling in the past or future for that matter :))))

I'll try explaining it in next post. Apologies since I'm short in time. Many thanks as always Gordon!
 
cameofx:
"As I said before, although the documentation claims "Tick size in points", this is obviously inaccurate. It's in price terms as well."

I don't understand the part in bold Gordon... If you care to explain...

Let's say Point = 0.00001. If MODE_TICKSIZE were in points, then for example we would have MarketInfo(Symbol(),MODE_TICKSIZE) return 1, which would be interpreted as 1*Point=1*0.00001=0.00001. But that's not what MarketInfo(Symbol(),MODE_TICKSIZE) returns, it returns (for example) 0.00001, so it returns a value that represents price and not Points. The documentation claims "Tick size in points", this is obviously inaccurate (probably a mistake in the translation from Russian).
 
SDC:

i read that thread before its full of condradictory information.

BarrowBoy - a change in bid and/or ask

Rosh - a "new price" event

kminler - each tick represents a closed trade

puncher - a tick is a pip

After reading other threads and discussions about ticks I had come to the conclusion that a tick has no specific value as all it contains is a new bid and a new ask, which could be 1 pip different to the last tick, no pips different or several pips difference so in itself the tick carries no price difference, only a new price.

But now i have been investigating how to calculate the value of a pip i come across MarketInfo MODE_TICKVALUE which appears to be a static set value, this in itself contradicts what most people seem to say about a tick, that it simply conveys a change in price, no specific amount, so how can there be such a thing as MODE_TICKVALUE it doesnt make any sense unless most people are wrong and 1 tick does in fact have a specific value equal to 1 pip, my problem is the lack of proper documentation how is one supposed to find out what is right and what is wrong, forum threads contain some information, much of it based on opinion or assumtion rather than fact which in most circumstances does not matter but when one is trying to write a program based on such sketchy and contradictory information it makes life very difficult


Yes, this is my concern as well.

Just getting back in here to follow up on my research, I will have to read this again tomorrow. I am already having reading trouble due to too little sleep and too much time in front of pc.

 

Wow, I just caught up on all the reading here. I am really exhausted and still not sure how to address the problem.

So, I will simply say, now that we seem to be understanding my concerns, the offer still stands that I would like a method to accurately calculate the value of price movement from 1 of the smallest values to the next (aka from x.0001 to x.0002) according to what ever symbol the EA may be on, it should calculate the leverage involved as well. (ie if on contract of 100,000 and leverage of 400:1, I might expect EURUSD to cost 10 or what have you.


In return, I have 2 manual trading gurus Money Management formula I can apply using your function to get the pip value and create 2 sets of money management functions. I am researching other methods as well. The idea that I have in mind is to create a money manager package containing choices based on various gurus and the user can choose the one that works for them.

So I would be really grateful if someone could come up with a function that can get me the pip value. Honestly, I am surprised that it is not already a standard function in the MT4.

If point is the value of say 1.1234 - 1.1233 and you can come up with the money value of that result, then this is what I am looking for. To me the term point here is just as good as the term pip.

I would like to be able to change the leverage value so this should be a parameter.

Ok, I have now been up for about 53 hours now, so I need to get some rest. We have been busy hammering out for our new releases and I am totally washed out.

 
LEHayes:

So, I will simply say, now that we seem to be understanding my concerns, the offer still stands that I would like a method to accurately calculate the value of price movement from 1 of the smallest values to the next (aka from x.0001 to x.0002) according to what ever symbol the EA may be on

Well, partly summarising what's been said over 6 pages, the smallest possible movement in price is given by MODE_TICKSIZE, and its cash value per whole lot is given by MODE_TICKVALUE. With three caveats:

  • MODE_TICKSIZE and MODE_TICKVALUE can vary between brokers depending on the number of decimal places used. For example, Alpari (5DP) report TS as 0.00001 and TV as 1.00 on EURUSD. FXDD report TS as 0.0001, and TV correspondingly as 10.00. Attempts to standardise MODE_TICKSIZE across brokers are a separate issue, e.g. as discussed in https://www.mql5.com/en/forum/124692
  • MODE_TICKVALUE varies over time if the quote currency of the symbol is different to your deposit currency (e.g. on a USD account EURUSD has a fixed TICKVALUE but USDJPY is floating).
  • Cloudbreaker has logged instances of TICKSIZE varying (e.g. TICKSIZE being reported as 0.0002 and 0.0001 on successive calls, with corresponding variation in TICKVALUE). I've never personally seen this, across 15 different brokers.
 
gordon:
Let's say Point = 0.00001. If MODE_TICKSIZE is in points, then for example we can have MarketInfo(Symbol(),MODE_TICKSIZE) return 1, which would be interpreted as 1*Point=1*0.00001=0.00001. But that's not what MarketInfo(Symbol(),MODE_TICKSIZE) returns, it returns (for example) 0.00001, so it returns a value that represents price and not Points,. This is obviously a mistake in the documentation (probably a mistake in the translation from Russian).
I beg to differ Gordon, MODE_TICKSIZE is in points -- Point(s) to be precise. MODE_TICKSIZE will always be an X multiple of Point. Be it 1, 2, 5, 35 etc. Point IMHO is a type double converting-factor to take us to the last significant decimal place of price ratio. If a broker see fit to offer the 6th decimal place as a bargain to be offered to customer then they will make Point as 0.000001 and Digits = 6.
Digits in this matter will represent Point in integer.
 
LEHayes:

So, I will simply say, now that we seem to be understanding my concerns, the offer still stands that I would like a method to accurately calculate the value of price movement from 1 of the smallest values to the next (aka from x.0001 to x.0002) according to what ever symbol the EA may be on, it should calculate the leverage involved as well. (ie if on contract of 100,000 and leverage of 400:1, I might expect EURUSD to cost 10 or what have you.

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

int CalculatedSymbolType=SymbolType();

2. call the CounterPairForCross() function

string CalculatedCounterPairForCross=CounterPairForCross();


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

   switch(CalculatedSymbolType) // Determine the tickvalue for the financial instrument based on the instrument's SymbolType (major, cross, etc)
      {
      case 1   :  Print("Calculated TICKVALUE = ",DoubleToStr(MarketInfo(Symbol(),MODE_POINT)*MarketInfo(Symbol(),MODE_LOTSIZE)/MarketInfo(Symbol(),MODE_BID),6)," (Tick value in the deposit currency - base)"); break;
      case 2   :  Print("Calculated TICKVALUE = ",DoubleToStr(MarketInfo(Symbol(),MODE_POINT)*MarketInfo(Symbol(),MODE_LOTSIZE),6)," (Tick value in the deposit currency - counter)"); break;
      case 3   :  Print("Calculated TICKVALUE = ",DoubleToStr(MarketInfo(Symbol(),MODE_POINT)*MarketInfo(Symbol(),MODE_LOTSIZE)/MarketInfo(CalculatedCounterPairForCross,MODE_BID),6)," (Tick value in the deposit currency - ",AccountCurrency()," is Base to Counter)"); break;
      case 4   :  Print("Calculated TICKVALUE = ",DoubleToStr(MarketInfo(Symbol(),MODE_POINT)*MarketInfo(Symbol(),MODE_LOTSIZE)/MarketInfo(CalculatedCounterPairForCross,MODE_BID),6)," (Tick value in the deposit currency - ",AccountCurrency()," is Base to Counter)"); break;
      case 5   :  Print("Calculated TICKVALUE = ",DoubleToStr(MarketInfo(CalculatedCounterPairForCross,MODE_BID)*MarketInfo(Symbol(),MODE_POINT)*MarketInfo(Symbol(),MODE_LOTSIZE),6)," (Tick value in the deposit currency - ",AccountCurrency()," is Counter to Counter)"); break;
      default  :  Print("Error encountered in the SWITCH routine for calculating tickvalue of financial instrument ",Symbol()); // The expression did not generate a case value
      }


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

1. call the int SymbolType() function
int CalculatedSymbolType=SymbolType();

2. call the BasePairForCross() function

string CalculatedBasePairForCross=BasePairForCross();


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

int   CalculatedLeverage=SymbolLeverage();   // Leverage for USDJPY is set to 100:1
Print("Leverage for ",Symbol()," is set at ",CalculatedLeverage,":1");
 
cameofx:
I beg to differ Gordon, MODE_TICKSIZE is in points -- Point(s) to be precise. MODE_TICKSIZE will always be an X multiple of Point. Be it 1, 2, 5, 35 etc. [...]
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. 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.
12345678910
New comment