# FLOAT issue

Binu
Junior MemberPosts:

**49**
Hi,

I am just wondering when I am doing

BUTTON_EVENT[nTPS[1],354]

{

PUSH:

{

LOCAL_VAR integer I

LOCAL_VAR float F

F = (10/4)

}

}

Now F is "2.5" But if I assign a value "10" for I

Like

BUTTON_EVENT[nTPS[1],354]

{

PUSH:

{

LOCAL_VAR integer I

LOCAL_VAR float F

I = 10

F = (I/4)

}

}

Then F is "2" I am wondering where is the ".5" gone and why??

Can some one explain?

I am just wondering when I am doing

BUTTON_EVENT[nTPS[1],354]

{

PUSH:

{

LOCAL_VAR integer I

LOCAL_VAR float F

F = (10/4)

}

}

Now F is "2.5" But if I assign a value "10" for I

Like

BUTTON_EVENT[nTPS[1],354]

{

PUSH:

{

LOCAL_VAR integer I

LOCAL_VAR float F

I = 10

F = (I/4)

}

}

Then F is "2" I am wondering where is the ".5" gone and why??

Can some one explain?

0

## Comments

1,917I think either way will force the processor to treat the values as floating, but I am not positive.

Hope this helps,

Jeff

450In this case your not forcing the CPU to do integer math, even though both numbers are integers. There was no declared variable types for either number, and it has no real way of knowing that they are integers. So it does normal division.

Here your forcing the CPU to do integer math because one of the number is of integer type. It does not care that your answer variable is a float. If you want to do float math use float for all the variables.

861if i divide two values (two integers) and i put the result in a FLOAT var, i expect the result to be a FLOAT, not an integer.

This would mean i have to declare all my values as FLOAT, instead of INTEGER, just to make sure the CPU does the correct math...

494,584I have long come to the conclusion, after many such experiences, that many of the arcane rules by which NetLinx type casts on calculations are based on an underlying philosophy of: "this is a control system, not a computer, integer math is good enough." I have found that whenever dealing with floats or doubles, to up convert everything to the highest possible variable type, do my math, then down convert the result. I use temporary variables in a function rather than making all my variable of that type. It's probably not necessary in every case, but it saves me a lot of head-scratching when I come across one of those cases where what they did doesn't make any sense to me.

450This is the best way I can explain it. It maybe strange but if you can think of all math functions in any language like C++ overloaded operator functions (Although overloaded operators are for class use, i thought it was a good way to explain). You can have multiple overloaded operator function of the same symbol. But the compiler picks the closet match, and It chooses the match based on the deceleration of the functions. The return value type of the function never comes into play when it decides which function to choose. It is always the parameters of the function.

// good overloaded operator

int operator /(int x);

float operator /(float x);

double operator /(double x);

// this would cause and error, can't overload, same function parameters.

int operator /(int x);

float operator /(int x);

861no no, it was absolutly clear. I just think it's strange the system handles math functions this way. Never had any problems with them

0I don't follow you. If you divide two integers and put the result in a float, the result will still be a float.

c is now equal to 2.0 which is a float.

2,1591,619How would you get 2.5 from integer division? That would require a cast which I don't Netlinx allows does it?

2,1591949120In the case of: F = (10/4)

10 and 4 are definitely non-floating point values, most likely set to CHAR internally by the compiler. The interpreter would do the math as integer math and cast the result to the FLOAT type.

In the case of: F = (10.0/4.0)

The constants are floating point and the result would be as you expected.

15Why would the compiler set the value to char instead of integer? Unless you put them in quotes, they should be integer values.

120Because the smallest data type that the values would fit in is an 8 bit data type, hence the CHAR. I'm going off the top of my head, but the compiler tries to fit undeclared types into the smallest one valid for the constant.