Do I need to normalize this (double_type * Point)?

 

Do I need to normalize the following calculated stop loss?


double sl = 20 * Point;


The documentation states that:


The calculated StopLoss and TakeProfit values, as well as open price of pending orders must be normalized with a precision the value of which is stored in the pre-defined variable of Digits.


However, in many code examples that I've seen so far (including these from the "official" book) double values are not normalized if multiplied by "Point" as in the above example. Are these expressions normalized implicitly?


Can someone please clarify this. Thanks.


Lukasz

 
lukasz74nj:

Do I need to normalize the following calculated stop loss?


double sl = 20 * Point;


The documentation states that:



However, in many code examples that I've seen so far (including these from the "official" book) double values are not normalized if multiplied by "Point" as in the above example. Are these expressions normalized implicitly?


Can someone please clarify this. Thanks.


Lukasz



You would normalize a double which has many decimal places, i.e. 1.26787432. Normalize(1.26787432,40)=1.2678, this way you can enter a trade at this price, because you cannot enter at 1.26787432, so you have to normalize!


In your case where you have 20*Point, you do not need to normalize the data.

 

Your example is normalized by definition.


Say your Point is 0.0001, so 20 * Point = 0.0020. You will never get anything less than 1 Point.


Only when you do calculations that will end up with fractions of a Point, eg 20.015/3 * Point, or any smaller fraction than the smallest unit in question, eg 0.015 lots when the smallest lot is 0.01, that you have to Normalize.


PS: Looks like someone is quicker with an answer.

 

OK, thanks c0d3 and blogzr3 for your answers. This makes sense to me now.


A few more questions:


1) Are Bid and Ask variables normalized already?


2) How about the values returned by OrderStopLoss(), OrderTakeProfit() functions? Are these normalized as well?

 

Yes.

Yes.

 
blogzr3:

Yes.

Yes.

But then does the same apply to resulting expressions involving both values, as in the following example?


double sl = 20 * Point;


if (sl < Bid - OpenPrice()) {

}


Almost everywhere I can see similar constructs having its operands normalized, i.e.:


if (sl < NormalizeDouble(Bid - OpenPrice(), Digits)) {

}

 

There's plenty of bad/unnecessary coding out there.


If you Normalize when you don't need to, you wouldn't know the difference. If you don't Normalize when you need to, you will know the difference as the code involved will error out. It's probably easier (or is it lazyness?) to do it everywhere so you don't have to figure out where you need it and where you don't.


From a performance point of view, it will not be noticeable to overdo it, but I don't like the extra typing or the impact on the readability of the code due to its verboseness.

 
blogzr3 wrote >>

There's plenty of bad/unnecessary coding out there.

If you Normalize when you don't need to, you wouldn't know the difference. If you don't Normalize when you need to, you will know the difference as the code involved will error out. It's probably easier (or is it lazyness?) to do it everywhere so you don't have to figure out where you need it and where you don't.

From a performance point of view, it will not be noticeable to overdo it, but I don't like the extra typing or the impact on the readability of the code due to its verboseness.

yes... do everywhere not gonna be any impact on cpu!

there are too many horror stories and issues when people not normalize.

.

why not make up own function?

analogue to macro...

i did this: double norm(double dVal) {...}

save much keystrokes, less clutter and anyway... ALL workings in one function.

why ALL workings? well, for me, i got my subPipPricing Broker code in their + it allows integer actuals

wat??? well, my norm() allows type int to be actual param (in formal double val). it checks for int value and ONLY IF int does it do subPipPricing massage 'before' it does the usual normalizedouble call. is just a 'times 10' or 'times 1' issue. i got global set at init() time that decides 1 or 10 and norm() just needs to multiply without an if(..)

anyways, the global comes in handy for massaging all types stuff IF u got subPip broker.

vip stuff to do else when you multiply spread of 3 by 0.0000`1 ie, subPip broker Point u get 0.00003 (three tenths) instead of 0.0003

also, subPip broker Digits will be 3 or 5, instead of usual 2 or 4. ok, i say too much but have spent seems years thinking and making mind up how handle in a generic fashion that work on any broker... so is vip close to my heart all this stuff

maybe is interest or maybe is making u laugh but i show summry[comments removed etc] my code for norm()

.

note:i use _Point, _Digits cus i do multi symbol EA with virtual chart mapping design, so i emulate all eleven predefined datums (5scalars + 6series[]'s). why? it mean that any EA code uses emulations and therefore is free to work on any

double norm (double dVal)
{
  int intPart = dVal;
  if(intPart!=dVal)                                  //for decimal actual; only round UP to digits dp
    return(NormalizeDouble(dVal,_Digits));           //..Remem:round only uses digit's+1 pstn
  dVal *= giSubPipMultiplier;                        //IF 3,5 SubPip THEN IF SL==3 -> SL=30
  return(NormalizeDouble(dVal * _Point, _Digits));   //IF   ...      THEN 0.03`0|0.0003`0 ELSE 0.03|0.0003
}

anyway, is more code for sure, but cpu mega fast these days + how often gonna actually do the normalizedouble stuff anyway?

and when done, i still think is lightening fast simply in scheme of things, ya know? and mql5 is (4get, but think said 5X faster?) anyway is asm not interpreted, so vip faster watevr 5X or yX ;)

all of course IMHO

and for sure: FWIW

:o)

Reason: