Price Per pip - page 3

New comment
 

Hehe another happy customer :)- while we're at it, LEHayes mind giving me help on calculating money management in percentage Without rounding the pips up. Here's what i currently use when I want to bet 1% of my account equity:

double Profit_F=0.00001,Lots=0.1;
Lots=NormalizeDouble((AccountEquity()*Profit_F),1);
if (Lots < 0.1) Lots=0.1;
if (Lots > 1.0) Lots=1.0;

This works fine for my stoploss of 100 when I have a $10,000 for example. As $10,000 X 0.00001 = 0.1 Lot. But when I have $15,000 the lot size now equals 0.15, but it rounds to 2.0 maybe because my broker does not allow macro lots. How can I force it to stay at 0.1 until equity hit $20,000? I've been up for a long time, after reading your thread, I'm too tired for searching and studying. If you have another equation for calculating mm please provide instead.

 
LEHayes:

This is driving me nuts, I have been looking for months now for an existing algorythem that does nothing more than calculate the Price Per Pip, regardless of the pair it is on. I have found 2 really good money management strategies that are both dependent upon this value as a way to precalculate trade sizes and money risk management, but I cannot find a single example of a calculation that handles Price Per Pip.

I am willing to offer my money management system to you in exchange for this in a function. I will provide you with both of the techniques suggested by the mentors I have been working with.


First we have to recognize there are five basic symbol types. This matters when it comes to matters such as calculating tick_value, leverage, and so on.

There is no formal definition of symbol type but for a USD-denominated account here is how I enumerate the symbol types: (these are specific examples, not all inclusive)
            SymbolType 1:  Symbol() = USDJPY
                           
                           Base = USD
                           Counter = JPY
            
            SymbolType 2:  Symbol() = EURUSD
                           
                           Base = EUR
                           Counter = USD

            SymbolType 3:  Symbol() = CHFJPY
                           
                           Base = CHF
                           Counter = JPY
                           
                           USD is base to the base currency pair - USDCHF
                           
                           USD is base to the counter currency pair - USDJPY
            
            SymbolType 4:  Symbol() = AUDCAD
                           
                           Base = AUD
                           Counter = CAD
                           
                           USD is counter to the base currency pair - AUDUSD
                           
                           USD is base to the counter currency pair - USDCAD
            
            SymbolType 5:  Symbol() = EURGBP
                           
                           Base = EUR
                           Counter = GBP
                           
                           USD is counter to the base currency pair - EURUSD
                           
                           USD is counter to the counter currency pair - GBPUSD

The relevance is how the account's denominated is related to the base currency and counter currency of the financial instrument of interest. It is the same for CFD's as well as currency pairs.

Once you have the symbol type you can then calculate the leverage per financial instrument - for example here is the code necessary to compute the leverage for AUDCAD:

CalculatedLeverage=NormalizeDouble(MarketInfo(Symbol(),MODE_LOTSIZE)*(MarketInfo(CalculatedBasePairForCross,MODE_BID)+MarketInfo(CalculatedBasePairForCross,MODE_ASK))/(2*MarketInfo(Symbol(),MODE_MARGINREQUIRED)),2)
In this example I the call function I coded would have already determined that for AUDCAD the CalculatedBasePairForCross is AUDUSD:
CalculatedBasePairForCross=StringConcatenate(SymbolBase,AccountCurrency(),postfix);
And the SymbolBase (that is the base currency of the financial instrument Symbol()) is:
SymbolBase=StringSubstr(Symbol(),0,3);
And so on.

For calculating tick value you need to account for symbol type as this matters when the valuation changes in both the financial instrument of interest - Symbol() - as well as the connecting currency pair that leads back to the account's denomination. Continuing the above example where we are discussing Symbol type of 4 - AUDCAD when account is USD denominated - the Tick value is explicitly defined as:

CalculatedTickValue=MarketInfo(Symbol(),MODE_POINT)*MarketInfo(Symbol(),MODE_LOTSIZE)/MarketInfo(CalculatedCounterPairForCross,MODE_BID)
Where the variable CalculatedCounterPairForCross for AUDCAD was previously determined to be USDCAD:
CalculatedCounterPairForCross=StringConcatenate(AccountCurrency(),SymbolCounter,postfix);
And SymbolCounter was determined by:
SymbolCounter=StringSubstr(Symbol(),3,3);

By programming the computation of these values explicitly in this fashion you can make broker agnostic market info determinations.

Keep in mind the code here is only useful for symboltype = 4 in which the account's denomination currency is the counter currency when paired with Symbol()'s base currency and likewise the account's denomination currency is the base currency when paired with the counter currency that forms the Symbol() pair.

(AUDCAD -> AUDUSD & USDCAD)

It turns out that while there are five universal symbol types you only need to categorize four of them for computing leverage, margin, and tickvalue. And the math only becomes a specific sticking point when dealing with cross-currency pairs relative to the account's denomination.

I worked out the specific relations between all the base and counter combinations because my money management approach is to explicitly define the value at risk of loss for every trade and that requires knowing exactly the price value at which the trade needs to be exited such that the loss complies with the previously defined budget for losses. For cross pairs it naturally turns out that the value at risk is based on the price of two currency pairs at any given instant in time (unless you hedge against one or the other).

Does this info help at all?

 
cloudbreaker:

TICKVALUE, when used on its own, can be unreliable.

It would be interesting to know which broker(s) this applies to, or whether there are other considerations such as being around market open/close. I've never been able to replicate these findings of yours.

 
Ha ha. I realize that jjc. But it doesn't hurt to use the ratio. Most often we'll be dividing by 1. Safe rather than sorry eh? CB
 
1005phillip:

Does this info help at all?

I have never noticed the distinction u made between symbol type 3-5 (or maybe I just haven't thought about it in this context). Anyway, good food for thought... Kudos for an excellent summary!
 

wow i never realised there was so much to calculating the value of a pip, in my EA i did it by letting the ea calculate it using the first open order if it is a buy, current bid price - order open price /order profit = pip value in current base currency, or if it is a sell, currentask+openprice/orderprofit=pip value, is this not going to work correctly ?

Edit: I realise i wrote that backwards i meant orderprofit/(currentbid-openprice)=pip value

 
SDC:

wow i never realised there was so much to calculating the value of a pip, in my EA i did it by letting the ea calculate it using the first open order if it is a buy, current bid price - order open price /order profit = pip value in current base currency, or if it is a sell, currentask+openprice/orderprofit=pip value, is this not going to work correctly ?


That calculation is valid in the limit that every pip has the same valuation regardless of the current bid or ask price.

This is rigorously true for currency pairs that are symbol type = 2 as I defined them above, i.e. EURUSD, etc. (any currency pair in which the account's denomination is the counter-currency in the pair).

For most folks the differences aren't likely to matter, the resultant errors are small. In my case I wanted to robustly compute the values with correct analytical expressions.

For example if I budget $200 for max possible loss on an upcoming trade and my stops are set to 200 points then I want to know the lotsize for my order such that I my losses can't exceed $200...to be robust about this I must calculate pip valuation correctly at the point of the stoploss price. Winging it was not an acceptable option for me or my clients ;)
 

I'm glad LEHayes sorted it all out. And Phillip, you have completely demistified TickValue & layout pairs-synthesizing very well for all to benefit. Awsome!

I just like to add : the synthesizing operations ...

CalculatedCounterPairForCross=StringConcatenate(AccountCurrency(),SymbolCounter,postfix);

SymbolCounter=StringSubstr(Symbol(),3,3);

... need to watch out for the extra append-age like USDJPYm in some mini-lot brokers. Don't know if a broker might/ever alter the first six letter of the symbols by putting or append a letter in front or in between base & counter, if you're looking for robustness, IMO reading from a .set file or .sel file is a safer bet.

 
cameofx:

I'm glad LEHayes sorted it all out. And Phillip, you have completely demistified TickValue & layout pairs-synthesizing very well for all to benefit. Awsome!

I just like to add : the synthesizing operations ...

CalculatedCounterPairForCross=StringConcatenate(AccountCurrency(),SymbolCounter,postfix);

SymbolCounter=StringSubstr(Symbol(),3,3);

... need to watch out for the extra append-age like USDJPYm in some mini-lot brokers. Don't know if a broker might/ever alter the first six letter of the symbols by putting or append a letter in front or in between base & counter, if you're looking for robustness, IMO reading from a .set file or .sel file is a safer bet.


Good point! however I'm not looking for that kind of robustness when I talk about robust calculations.

Brokers can name their currency pairs whatever they want, one would hope I'd have the presence of mind to notice such and amend my codes accordingly before attempting live trade with a new broker using currency symbol lovelyUSDmoonCADcheese! :P

This code simply deals with 100% of the cases I have come across so far (Alpari, CitiFX, CMS forex, forex.com, FXCM, FXDD, IBFX, MIG, and ODL)...I'm not worried about making it future proof, merely present proof. Now if you had something in mind to make it futureproof...well now's a good time to speak your mind :)

 

lovelyUSDmoonCADcheese! ...

Lol! I have seen broker mistyped the Symbol description in the property of symbol (not the Symbol() parameter but they have to type this one at some point too!). Who knows! :))

I can't tell if it would ever be 100% foolproof (what is?). But I'm thinking something like this :

  • create a list/inventory of possible 3 letters uppercase base/counter name.
  • Read the pair string from .set or .sel.
  • Scan for a possible match shifting one letter at a time. Ignoring accepting possible upper/lowercase combinations (the ASCII value would differ by x integer, need to check) we can use a loop to turn all letters to uppercase for instance.
  • If a match is found, save it as the 'broker'/'alias' name as opposed to the 'inventory' name we have. Continue looking for the second part of the pair & do the same.
  • we need to check also if a base / counter name is consistent throught al Symbol(). And save its 'aliases' as well.
  • use the aliases to synthesize the pair.
  • if a new base/counter name is altered or added. Add it to the aliases.

Gordon some time ago offers his view to me on what merits would an automatic foolproof check has in an EA. Having this in mind (& respecting that) I still figure this may be something worthwhile, even just for the hell of it! :)

12345678910
New comment
Reason: