Position Size Returning Negative Value - page 3

MetaQuotes documentation is weak at best.

However, that being said, MathRound() returns a double by definition:

 

 

If the returned value read: "Value divided by 2" it would still be a double.

The same way that "Value rounded till to the nearest integer" is still a double.

 

Hope that helps 

To me, "Value rounded till to the nearest integer" is not clear that it returns anything other than an integer because of the definition of integer.  I get that it is actually how it works, but that stressed my point that the code and/or the official page wording is broken and needs to be fixed.  Either the code needs to be adjusted so that it does return a type int, or the page wording needs to be changed.  We as users have no way to do that.  The value you are getting the number to be rounded doesn't change, unless you assign it back to that variable.  Like if you are rounding y with a value of 1.3, and placing it in x, using the wording above, after the function is done, you would expect y to still contain 1.3, and x to contain 1, not 1.0.  In my mind, and how I am reading it, rounding means you round to the nearest item you are trying to round to, not a value equivalent to that item.  Maybe the phrase "something is lost in translation" is very appropriate here.

I'm not a fan of the documentation, but I have to say that I think they have been consistent in this regard. All the documentation lists the returned data type (int, double, bool etc) at the top of the page, the returned value section later on never repeats this data type. Plus in this case they are returning exactly the same data type that gets put in.

In any event, if you are using the #property strict compiler directive you should be getting a warning:

 

I have started a thread on MQL5.com forum at https://www.mql5.com/en/forum/61394 that will hopefully ultimately help this documentation issue.  Maybe if we get enough people behind the idea, MQ will let us all help to fix what until now has been a problem to many people.  I hope MQ will get on board with the idea, because we as users cannot change anything.

@ knave & WH - I wholeheartedly agree with your examples, but I am still seeing an issue here, that I either am not explaining clearly, or else I am one of few people who are seeing this as a problem.  To me, your examples are proving my side of this topic more than you think they are proving your side.

knave, your example will return an error because it is not returning the data type it is supposed to be returning, an int.  The fact that you are casting your variable as an int just makes it easier to see the problem with the function not working properly.

WH, you point out that line (from the doc page) and it is saying the basically the same thing as the line I am highlighting.  The example only uses a double as what value is being sent to the function.  None of your posts show that state 100% definitively clearly that the data type returned from the function is a double, only that the example is sending a double.

Rounding is generally accepted to change the value of a specific number to a lower precision.  I think on this we can all agree.

In this case, it is no different.  The page specifies "rounded to the nearest integer of the specified numeric value".  It reads that it will round to a lesser precision (int) from another value.  In the example used, a double is sent.  That is all that is 100% clear.

I'm sorry JD4, you've totally lost me... 

That is exactly what I've marked up with an arrow. It returns a double (big red arrow) and the passed parameter is also a double (under my arrow). Take a look at any function. OrderSend() returns an int... OrderClose() returns a bool.... and MathRound() returns a double

 

 

 

 

 

The function is working exactly as advertised.

If you think it is an int (wrong), you get this:

 

 

 

If you typecast it as an int, you acknowledge you are using the wrong data type:

 

 

 

If you treat it as a double (which it is), you have no warnings:

 

The example is typecasting to return a double.  In your code example of int RoundedNumber, you are type casting to return an int as the return type.  This should not be necessary as it is supposed to return an int, based on what the page tells you.  The line at the top and the one in return value says it rounds to an integer of the specified value.  An integer, no matter how many times we say differently, does not have any decimal places, fractions, or any other way of representing numbers in between whole numbers, zero, and negative whole numbers.  As the example I posted above, based on the given docs, sending the MathRound function "1.3" should return "1", not "1.0", as "1.0" is not an integer, but "1" is. (quotes for clarification only)

Typecasting it as an int shows an error because the underlying function operates counter to what the page says it does, not because it is supposed to return other than an int.  If you treat it as a double (which it may be but is not supposed to be), then that is just letting the incorrect function continue to operate counter to what it is documented to do, return an integer which was rounded from the value sent to it, which is a double.

Sending a double to be rounded (the way the code is documented now) to an integer and then casting or storing the returned value to a double type will not generate errors because it is supposed to be returning an int, and if you store an int to a double, you are not losing any precision in the conversion.  The errors are there to notify the programmer about potential loss of precision in the calculations.  If you store a double into an int, you will expect an error like the one you are showing because you are forcing it into another form with less precision than it had before.

If the MathRound function is not supposed to return an int, then the wording on the page needs to be changed so that it doesn't say it is supposed to return an int.  My issue has never been with the function doing any different than what it does, other than it is counter to what the page says it is supposed to do.  They need to fix either the code for the function so that it returns an int as the doc page says it is, or edit the doc page to reflect that it does not necessarily return an int.  "Rounded off to the nearest integer" is exactly that, an integer.

Edit:  I did further research both through C++ and Java references, as MQL is somewhat based on C++, and is syntactically similar to Java and C++.  C++ shows on one part of the doc (http://www.cplusplus.com/reference/cmath/round/) "Round to nearest Returns the integral value that is nearest to x, with halfway cases rounded away from zero."  But later on the page it says "Return Value The value of x rounded to the nearest integral (as a floating-point value)."  You might say this supports your view on this, when in fact it doesn't, because the C++ specifies it returns a float.  Java documentation at http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html shows the following on the 2 methods named round.  Both (Java and C++) are functionally equivalent within their languages to the MathRound and/or round functions in MQL.

static long	round(double a) Returns the closest long to the argument, with ties rounding up.
static int	round(float a) Returns the closest int to the argument, with ties rounding up.

MQL MathRound returns an integer value in a float datatype. Surely What C++, or Java rounding functions does is irrelevant. It's trivial to write your own 'int round(double a)' function in  MQL if you want one.

 (32bit)floats can hold (16 bit)integers just fine without loss of precision. The problem is OP wants value rounded to two decimal places and expects it to be exact. It wont be.

I got off topic with my posts specifically being about the function operating a certain way, and I am done posting that off-thread topic discussion.  If this function discussion ends up moving somewhere else, I am fine with that.

Edit: I started a thread for continued discussion of this conflicting doc page at https://www.mql5.com/en/forum/156174.  Gum, I have responded to your below post here on that thread.

JD4, you seem to be the only person that is confused by this

HonestKnave has pointed out that the documentation clearly shows that the function returns a double. An integer represented as a double.

"rounded off to the nearest integer " doesn't mean that it is converted to an integer

If I tell you to cut a piece of wood to the same length as a piece of string. The wood still remains wood, it doesn't suddenly change into a piece of string.

Well, I'm not sure what will convince you JD4. The documentation clearly, 100% states that the function returns a double. You are reading something else into the description of the returned value - it never states that it returns an integer. 

When you look at OrderSend() it says "Returned value: Returns number of the ticket assigned to the order by the trade server or -1 if it fails. To get additional error information, one has to call the GetLastError() function."

So what does it mean by number? That's kind of vague, don't you think? Do they mean double? float? char? short? int? long? The answer lies at the top of the page, like that big arrow I posted earlier. That is their standard format for where you look to see the returned data type. (note I didn't say returned data value). I really can't think of a single example in the documentation where the "returned value" section ever mentions the data type.