Position Size Returning Negative Value - page 2

Yes, I think the string just makes the value in the double a printable version of it, but doesn't change it.  Not sure how to do it in MQL, but I know in Java you can force a type conversion from one type to another (in this case, double to int).

From the oracle docs at http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html.  This is only a small portion of the code presented.

// Casting conversion (5.4) of a float literal to
// type int. Without the cast operator, this would
// be a compile-time error, because this is a
// narrowing conversion (5.1.3):
int i = (int)12.5f;
// String conversion (5.4) of i's int value:
System.out.println("(int)12.5f==" + i);

In your case, I believe you would make it say something like

int intConvertedDouble = (int) valueYouGotItFrom;

Obviously you would need to adjust the names to fit your code better.

http://www.studytonight.com/java/type-casting-in-java also covers it there.  Since Java and MQL are both supposed to be based on C++, this might help you out.

@OP as well as reading all the MQL4 links previously posted  see Working With Doubles and PrintFormat 

@JD4 I dont see how posting Java code and referencing Java specs helps the OP. Also Java and C++ are similar but I  disagree that it's based on C++

Although you are trying to be helpful, I think many of your replies when you are not sure of answers yourself, only lead to confuse people looking for help.

In regards to your C++ thoughts, take a look at https://www.mql5.com/en/docs/basis.  Says it right there, and since they modified MQL4 to be more like MQL5 (https://docs.mql4.com/mql4changes), it applies here as well.  As far as my knowledge base, never claimed to be an expert, and I let people know that when I post if I am not sure of something, at least I try to, might miss it sometimes.  If I drive a Chevy, and I am having problems with it, I am not going to sit there and discount advice from someone who only works on Fords if it is helpful advice, even if it might not be quite right on the money.  I will also not sit there and tell them don't think you can help, if they are doing it to try to be helpful.

I think you misread my post. Mql4 OO is certainly based on c++.  I dont think there is any disputing that. I was referring to your assertion:

followed by lots of Java references. I said -

I was specifically talking about your Java references. Java is not based on c++ in my opinion. 

In any case the subject of representing decimals in floating point has been covered several times over in the threads mentioned by WHRoeder earlier.

It looks like OP wants to round to two decimal places, but without posting any output or specific examples I guess the degree of rounding error they are seeing can be ignored.

Both wrong. It rounds to the nearest integer. Irrelevant. It returns a double. 1 = 1.0 = 1.00 = 1.00000 = 1.0000000000000000000000000000000000 INFINITE  DIGITS

Learn about floating point. The == operand. - MQL4 forum

Guess WH needs to go back and re-read, I was saying what the page said the function did, not what it actually does.  And computer programming is one of the few places where (int) 1 != (double) 1.00000000 (ad infinitum) in regards to data types.

@ ydrol, I missed the direction of your intent with your statement re MQL/Java/C++.  Some reference material for you to take a look at in regards to the origin of Java as a programming language.

https://en.wikipedia.org/wiki/Java_(programming_language)

http://www.freejavaguide.com/history.html

Since they both say almost the exact same thing in regards to C++, will post from wiki.  "The language derives much of its syntax from C and C++, but it has fewer low-level facilities than either of them."

From the same age "The syntax of a language defines its surface form.". ( curly brackets etc). What is being discussed in this thread is not syntax related. My opinion is that saying 'Java is based on C++' in the same way that MQL is, is a far stronger statement which I disagree with. 

 

But as it's a qualitative statement we can both be right and wrong at the same time.   Still I don't see how Java specs helps the OP, when there are specific link already given with the issue and this was not syntax related question.

Both articles you mention , stress Java borrows from syntax - but little else. This is not a syntax related issue.

However it is related to  IEEE 754 Floating point representation used by MQL, which is also shared by the languages. (and many others that do not have c like syntax - eg Pascal, or even applications like Excel) and this is really because it is a standard supported by most CPU/FPU rather than syntactic similarities of the languages.  The issue is the floating point representation of decimal fractions  has small errors. The OP wants to round to two decimal places. The IEEE 754 format can not accurately store one tenth (0.1) nor one hundredth (0.01). In the IEEE 754 binary format these are recurring binary fractions,  (same way that 1/3 is a recurring decimal fraction 0.33333... ) - The difference between the intended number and the actual number is quite small (eg 0.00000000000001 ) but its big enough so that 

1/10  != 0.1  // probably

 And int(0.1 * 10) might round the wrong way

 But as OP hasn't  posted exactly what they are seeing the best advice was given way back in the 3rd post of this subject, go and read the MQL threads. I don't see the point in also suggesting they read Java specs too after the MQL threads are given and they likely have no familiarity with Java.

Thread summary:

• OP : Numbers are behaving funny
• WHRoeader: Here are several links with several explanations why floating points are odd. < Answer is in here somewhere ...
• OP: I get them, numbers are still behaving funny.
• JD4: MQL4 and Java are based on C++, here are some obscure Java links on typecasting and promotion, that even Java developers would find a hard read.
• ydrol: How does that help OP exactly? I dont agree that Java is based on C++ Answers were posted a while back...
• etc. etc.

I posted the Java way of type conversion for 2 reasons.  First was, admittedly, because I am more familiar with Java.  And 2, I did a search of the code, and maybe because I was tired when I did it, I did not see how to do it in MQL docs.  So, to try to be helpful, I suggested a possible solution that I was reasonably sure would work, based on presumptions that MQL and Java are close enough together given their shared comparisons to a common language, C++.

JD4: Guess WH needs to go back and re-read, I was saying what the page said the function did, not what it actually does.	Maybe you should go back and re-read what the question was. NoLimitations: Why would I still be getting answers to multiple decimal places if I'm using MathRound()? What the page says, is what it does. It rounds. Nothing to do with multiple decimal places question. Multiple decimal places is what happens when you print a double without specifying the number required.

The above was a specific response to your specific post "MathRound returns a double; infinite number of decimal places."

Once again, according to the documentation page.

"Return Value

Value rounded till to the nearest integer."

Now, a specific response to this part of your post.

"What the page says, is what it does. It rounds. Nothing to do with multiple decimal places question."

Again, re-read the quote, it says it returns "Value rounded till to the nearest integer".  An integer, by definition, is a whole number, as in no decimal places.  And again, if this is not in fact what it actually does, then the code or the description is broken, and one or the other or both needs to be fixed by MQ, or else a warning label stating that these functions do not perform as advertised.

If it actually returns the type it is given, but at the mathmatical equivalent to the nearest integer's value (as in returns 1.00000 from a 1.23456, and 1 == 1.00000) but does not return an actual integer type, then the reference page needs to specify something such as "does not change underlying data type" or some other way that is clearly stated.  I think this was a flat translation from the original Russian page, and as such, is not as clear in English as it should be.