NormaliseDouble, Digits ommitting the last digit when price ends with a zero

 

Quick question: Why, despite telling it display the price in accordance to the appropriate number of decimal places of the chart, does it constantly fail to include the "0" when the price ends with a zero.

I have the following: 

double CurrentBarOpenPrice =  NormalizeDouble(Open[0],Digits);

then:

string(CurrentBarOpenPrice)

Whenever the prices ends with a "0", MQL4 fails to display the "0", much mike a typical calculator. 

Thank you.

 
TheHonestPrussian:

Quick question: Why, despite telling it display the price in accordance to the appropriate number of decimal places of the chart, does it constantly fail to include the "0" when the price ends with a zero.

I have the following: 

then:

Whenever the prices ends with a "0", MQL4 fails to display the "0", much mike a typical calculator. 

Thank you.

because you are casting it to a string, so that is default behaviour.

If you want to control what goes in the string use DoubleToString

if you simply want to format the output use PrintFormat

 
Paul Anscombe #:

because you are casting it to a string, so that is default behaviour.

If you want to control what goes in the string use DoubleToString

if you simply want to format the output use PrintFormat

Awesome, thank you 

 
Paul Anscombe #:

because you are casting it to a string, so that is default behaviour.

If you want to control what goes in the string use DoubleToString

if you simply want to format the output use PrintFormat

Just a further quick question, the following documentation when it comes to floating values makes no sense:

https://docs.mql4.com/convert/stringformat

How on earth do you apply String Format to format the output of a price depending on the brokers price specificity?

I would preferably like to pre-format the output variable of the prices without having to write `DoubleToString` everytime. 

Thanks

StringFormat - Conversion Functions - MQL4 Reference
StringFormat - Conversion Functions - MQL4 Reference
  • docs.mql4.com
StringFormat - Conversion Functions - MQL4 Reference
 

You used NormalizeDouble, It's use is usually wrong, as it is in your case.

  1. Floating point has an infinite number of decimals, it's you were not understanding floating point and that some numbers can't be represented exactly. (like 1/10.)
              Double-precision floating-point format - Wikipedia, the free encyclopedia

    See also The == operand. - MQL4 programming forum (2013)

  2. Print out your values to the precision you want with DoubleToString - Conversion Functions - MQL4 Reference.

  3. SL/TP (stops) need to be normalized to tick size (not Point) — code fails on non-currencies.
              On 5Digit Broker Stops are only allowed to be placed on full pip values. How to find out in mql? - MQL4 programming forum #10 (2011)

    And abide by the limits Requirements and Limitations in Making Trades - Appendixes - MQL4 Tutorial and that requires understanding floating point equality Can price != price ? - MQL4 programming forum (2012)

  4. Open price for pending orders need to be adjusted. On Currencies, Point == TickSize, so you will get the same answer, but it won't work on non-currencies. So do it right.
              Trailing Bar Entry EA - MQL4 programming forum (2013)
              Bid/Ask: (No Need) to use NormalizeDouble in OrderSend - MQL4 programming forum (2012)

  5. Lot size must also be adjusted to a multiple of LotStep and check against min and max. If that is not a power of 1/10 then NormalizeDouble is wrong. Do it right.
              (MT4 2013)) (MT5 2022))

  6. MathRound() and NormalizeDouble() are rounding in a different way. Make it explicit.
              MT4:NormalizeDouble - MQL5 programming forum (2017)
              How to Normalize - Expert Advisors and Automated Trading - MQL5 programming forum (2017)

  7. Prices you get from the terminal are already correct (normalized).

  8. PIP, Point, or Tick are all different in general.
              What is a TICK? - MQL4 programming forum (2014)

 
William Roeder #:

You used NormalizeDouble, It's use is usually wrong, as it is in your case.

  1. Floating point has an infinite number of decimals, it's you were not understanding floating point and that some numbers can't be represented exactly. (like 1/10.)
              Double-precision floating-point format - Wikipedia, the free encyclopedia

    See also The == operand. - MQL4 programming forum (2013)

  2. Print out your values to the precision you want with DoubleToString - Conversion Functions - MQL4 Reference.

  3. SL/TP (stops) need to be normalized to tick size (not Point) — code fails on non-currencies.
              On 5Digit Broker Stops are only allowed to be placed on full pip values. How to find out in mql? - MQL4 programming forum #10 (2011)

    And abide by the limits Requirements and Limitations in Making Trades - Appendixes - MQL4 Tutorial and that requires understanding floating point equality Can price != price ? - MQL4 programming forum (2012)

  4. Open price for pending orders need to be adjusted. On Currencies, Point == TickSize, so you will get the same answer, but it won't work on non-currencies. So do it right.
              Trailing Bar Entry EA - MQL4 programming forum (2013)
              Bid/Ask: (No Need) to use NormalizeDouble in OrderSend - MQL4 programming forum (2012)

  5. Lot size must also be adjusted to a multiple of LotStep and check against min and max. If that is not a power of 1/10 then NormalizeDouble is wrong. Do it right.
              (MT4 2013)) (MT5 2022))

  6. MathRound() and NormalizeDouble() are rounding in a different way. Make it explicit.
              MT4:NormalizeDouble - MQL5 programming forum (2017)
              How to Normalize - Expert Advisors and Automated Trading - MQL5 programming forum (2017)

  7. Prices you get from the terminal are already correct (normalized).

  8. PIP, Point, or Tick are all different in general.
              What is a TICK? - MQL4 programming forum (2014)

Thanks


I realised I used the NormalizeDouble, however, I wanted to explore the possibility of just formatting the output using StringFormat as opposed to NormalizeDouble as an alternative. Whilst NormalizeDouble is OK, using it every time I want to format the output can be a tad cumbersome. 

The documentation around StringFormat when it comes to float values is as clear as mud.

 
TheHonestPrussian #:
How on earth do you apply String Format to format the output of a price depending on the brokers price specificity?
#property strict

void OnStart()
  {
   double a = 1.11111111;
   double b = 7.77777777;
   PrintFormat("a %s, b %s", DoubleToString(a, Digits()), DoubleToString(b, Digits())); // a 1.11111, b 7.77778
  }

or

#property strict
#define _prcToStr(a_val) DoubleToString(a_val, Digits())

void OnStart()
  {
   double a = 1.11111111;
   double b = 7.77777777;
   PrintFormat("a %s, b %s", _prcToStr(a), _prcToStr(b)); // a 1.11111, b 7.77778
  }

or

Print("a ", _prcToStr(a), ", b ", _prcToStr(b));
 
Vladislav Boyko #:
or

or

#property strict

void OnStart()
  {
   string formatStr = calculFormatStr(Digits()); // in OnInit()
   double a = 1.11111111;
   double b = 7.77777777;
   PrintFormat(formatStr, a, b);
  }

#define _formatPrc(a_digits) "%." + (string)a_digits + "f"
string calculFormatStr(int digits) { return("a " + _formatPrc(digits) + " b " + _formatPrc(digits)); }
#undef _formatPrc

This is a joke code. Perhaps such code will even work a couple of nanoseconds faster than DoubleToString, but this is very inconvenient. I would use DoubleToString

Reason: