Okay anytime I divide anything like 4/6 or 5/8 i get 0. Does MQL4 automatically round fractions down to 0? This is a real pain because I need to base my buy orders on a number between 0 and 1. Basically I'm assigning each indicator a weighting, adding up the weightings for buy/sell signals and then dividing it by the total weightings.. like this:
//SellSignal is the sum of all indicator weightings showing overbought conditions, TotalWeight is the fixed maximum value SellSignal can take ie the sum of all the signal weightings
But it consistently returns SellTrigger = 0 even thou SellSignal is showing some integer
This is one of the badly thought-out features of MQL4. It is one of the very few (if any) programming languages that does this.
When you divide two integers, the result is an integer. It does not matter if you assign it to a double or not, the result is an integer.
doublevar = intvar1/intvar2; // result integer, ie rounded down.
doublevar = (intvar1+0.0)/intvar2; // result double
There is an article somewhere that explain all these number things.
Disclaimer: However, overall, I am still quite pleased with MQL4 and it's built in functions. :)
DxdCn is soooo on-the-ball...
You have explicitly asked the code to do integer division. The result of that operation (an integer) is then promoted to the double type followed by storing in memory location addressed by doublevar.
truncation occurred during integer division because that is exactly what the code was asked to do...
The above is standard practice and what DxdCn has so succinctly said ;)
The MQL team is knowing about this stuff - as they should! - is not peculiar to MQL language.
blogzr3 in effect has used a cast to type double on intvar1.
Now of course, you have: double / int; and the promotion to double [which is deFacto standard practice] can take place thus keeping the remainder.
Again, the cast is explicit instruction - not needing compiler subjectivity as to the coders intentions...
You can equate MQL4 as a sub-set of what C is. But MQL4 is very powerful and what 'it' may lack - the coder can totally make up for. Just takes some imagination at times :)
fwiw, have a looksee at part text below and full text is here and K&R is seen by many, the final word when it comes to a bit of Computer Science
[This section corresponds to the second half of K&R Sec. 2.7]
Most of the time,
C performs conversions between related types automatically.
for the complete story.)
When you assign an int value to a float variable
or vice versa,
or perform calculations involving mixtures of arithmetic types,
the types are converted automatically, as necessary.
C even performs some pointer conversions automatically:
malloc returns type void *
but a void * is automatically converted
to whatever pointer type you assign
malloc's return value to.
Occasionally, you need to request a type conversion explicitly.
Consider the code
int i = 1, j = 2; float f; f = i / j;
Recall that the division operator /
results in an integer division,
discarding the remainder,
when both operands are integral.
It performs a floating-point division,
yielding a possibly fractional result,
when one or both operands have floating-point types.
What happens here?
Both operands are int,
but the result of the division is assigned to a float,
which would be able to hold a fractional result.
Is the compiler smart enough to notice,
and perform a floating-point division?
No, it is not.
The rule is, ``if both operands are integral,
division is integer division and discards any remainder'',
and this is the rule the compiler follows.
In this case, then,
we must manually and explicitly force one of the operands
to be of floating-point type.
Explicit type conversions are requested in C
using a cast operator .
(The name of the operator comes from the term typecast ;
``typecasting'' is another term for explicit type conversion,
and some languages have ``typecast operators.''
Yet another term for type conversion is coercion .)
A cast operator consists of a type name, in parentheses.
One way to fix the example above would be to rewrite it as
f = (float)i / j;.....
This is a good quote.
Is the compiler smart enough to notice,
and perform a floating-point division?
oh sure... smart enough to generate instructions which the code explicitly states NOT to do??? cmon..
The compilers smartness is in NOT doing what it was not asked to do - all translators behave similarly.
1. is the compiler supposed to make decision based on premise that coder not fully understand syntax and therefore when sees an int/int that in actual fact it is to generate machine code for a float division?
I say 'sorry' because I was once guilty of such non-thinking. Not now... I have learned HOWTO use and abuse MQL to suit me. I can programmatically get it to jump through hoops if I so choose.
In a nutshell... I accept it for what it is and proceed to totally employ it's functionality to my own requirements.
This one explicitly says to truncate the result:
int = int1/int2;
This one doesn't:
double = int1/int2;
All? Wrong. Many don't.
According to your own quote, the compiler is not smart enough. That's the word they used. Live with it.
PS: In case anyone is wondering, I think overall MQL4 is great. Just not this bit.
noooo, it is explicitly saying to truncate, that's the whole thrust of this topic. That is not how code generation works. That is why the article and me, use the term interim.
int/int is only one step in a multistep process which leads eventually to the storing of a value in memory associated with the double.
That is what the article is saying. 4/6 -> 0. That is integer division and it cannot be anything else.
That value of 0 is result of executing an interim set of instructions ie, the int/int set of instructions.
Only then is the next step done, which is to 'promote'/'cast' to the next higher width, which in this case is of type double.
Another step can now take place to move this 'promoted' binary pattern to the double's memory location.
Is not magic or anything - is how a complex set of instructions is broken down into small steps that map to the computer chips instruction set.
It is not smart for very good and time tested practical reasons. Smartness is in the eyes of the beholder. Is massively obvious [and... I easily accept} that: double = int/int; "if looking at it top level" seems as if the remainder would be in the result. However, I invite you to look underneath the 'hood' and see why that top level expectation is never going to happen. I have above described in outline exactly the series of hardware/assembler steps that are used to negate that top level expectation.
I live with what physically happens inside a cpu and it's hardware components - I cannot change that, so yes... I happily live with it.
Please be so kind to show or point me in direction of those that do not do as you say: Many don't.
Learning is never over is it?
However, I invite you to look underneath the 'hood' and see why that top level expectation is never going to happen. I have above described in outline exactly the series of hardware/assembler steps that are used to negate that top level expectation.
That is where you are missing the point.
MQL4 is a high level language (at least 4-GL) which allows you to concentrate on RSI, MACD, AccountEquity(), MarketInfo(), OrderOpenPrice(), Point, Pips, etc, etc, and not about type-casting, pointers, compilers, code generation, interim instructions and other things under the hood.
ya... ok - look, that's the way it is. I really do appreciate where you come from but MQL4 is C like yes? and that maps very closely to hardware/assembler instructions.
A spreadsheet is what some may call HLL, not from where I am standing (for me it is way to High Level) - but again is all from one's perspective that these posts continue, yes?
With MQL4 syntax comes great power. The coder is firmly in the drivers seat. That power is almost board level. I'd hazard a guess that Excel is not the same and no one would expect it to be (so ok. one can I believe use umm, VB etc, but for the general user consumption not used I'd bet). Spreadsheets for sure are there for manipulating large amounts of data and 'playing around' with What If's (i believe Excel does this anyway) and having to mess with 'cast' concepts etc. would be total nightmare. Different all together...
So each has power but of different types.
My looking under the hood, is total second nature and not consciously considered yet it [generally ;] guides me around such obstacles that this thread has illuminated. I am completely free to deep immerse self in my concept/system. Should I 'come up against' a funny - well, I dust off the Print()'s and figure out the issue. Is my way, many come onto a forum - I'd rather dig and find out/learn by rolling up my sleeves. Of course I sometimes get it wrong or not simply 'get it' and then... that is when having a forum to use is fantastic, yes? I am not being at all elitist here but my questions do not generally get responses. Maybe they are to abstract in the formation of a post content, maybe no one considers my questions have any merit, maybe ... whatever! So, I generally dig myself - that way I at least know I'll get a reply, even if it's saying the wrong thing - LOL
Again... we all come from varied start positions and what seems an issue for one is not for another.
So, I do indeed take in all that you have kindly informed me of, has been interesting dialog - thank you.
I'm off now - somehow have to end it, yes?
Best Regards and... a steady wind to push you towards Financial Freedom Through Forex Trading