Home› AMX User Forum› AMX Technical Discussion

FLOAT issue

BinuBinu Posts: 49
in AMX Technical Discussion
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?

Comments

  • Spire_JeffSpire_Jeff Posts: 1,917
    I believe the processor is treating both values as integers and as such is dropping the remainder. Try the following:
    BUTTON_EVENT[nTPS[1],354]
{
PUSH:
{
LOCAL_VAR integer I
LOCAL_VAR float F
LOCAL_VAR float F_Divisor
I = 10
F_Divisor = 4
F = (I/F_Divisor)
}
}

OR...

BUTTON_EVENT[nTPS[1],354]
{
PUSH:
{
LOCAL_VAR integer I
LOCAL_VAR float F
I = 10
F = (I/4.0)
}
}

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

    Hope this helps,
    Jeff
  • AMXJeffAMXJeff Posts: 450
    Binu wrote: »

    F = (10/4)

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

    In 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.
    Binu wrote: »

    LOCAL_VAR integer I
    LOCAL_VAR float F
    I = 10
    F = (I/4.0)
    }

    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.
  • yuriyuri Posts: 861
    thats a bit strange...

    if 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...
  • BinuBinu Posts: 49
    The way Mr. Spire_Jeff explained is working fine. Thanks
  • DHawthorneDHawthorne Posts: 4,584
    yuri wrote: »
    thats a bit strange...

    if 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...

    I 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.
  • AMXJeffAMXJeff Posts: 450
    yuri wrote: »
    thats a bit strange...

    if 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...

    This 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);
  • yuriyuri Posts: 861
    AMXJeff wrote: »
    This 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);

    no no, it was absolutly clear. I just think it's strange the system handles math functions this way. Never had any problems with them :/
  • [Deleted User][Deleted User] Posts: 0
    yuri wrote: »
    thats a bit strange...

    if 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...


    I don't follow you. If you divide two integers and put the result in a float, the result will still be a float.
    int a = 10
int b = 4
float c = a/b

    c is now equal to 2.0 which is a float.
  • Joe HebertJoe Hebert Posts: 2,159
    a_riot wrote: »
    I don't follow you. If you divide two integers and put the result in a float, the result will still be a float.
    int a = 10
int b = 4
float c = a/b

    c is now equal to 2.0 which is a float.
    c is now equal to 2, it?s supposed to be 2.5
  • a_riot42a_riot42 Posts: 1,624
    Joe Hebert wrote: »
    c is now equal to 2, it?s supposed to be 2.5

    How would you get 2.5 from integer division? That would require a cast which I don't Netlinx allows does it?
  • Joe HebertJoe Hebert Posts: 2,159
    a_riot42 wrote: »
    How would you get 2.5 from integer division? That would require a cast which I don't Netlinx allows does it?
    Why do I feel like I?m in some sort of Abbot and Costello Who?s on First routine? :)
  • ProjectsProjects Posts: 1
    Thanks AMXJeff. You saved me destroying monitor with skull. Cheers
  • mpullinmpullin Posts: 949
    a_riot wrote: »
    I don't follow you. If you divide two integers and put the result in a float, the result will still be a float.
    int a = 10
int b = 4
float c = a/b

    c is now equal to 2.0 which is a float.
    I think this would be the case for any language, when the calculation a/b is performed both sides are ints, the processor isn't able to look one move ahead and see what type of container you're going to put it in. 10/4 in integer addition is 2. Converting 2 to a float yields 2.0.
  • cwpartridgecwpartridge Posts: 120
    If one or both of the constant numbers were floats, the compiler would have handled it as you expected.

    In 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.
  • gusgizmogusgizmo Posts: 15
    cwpartridge wrote: »
    If one or both of the constant numbers were floats, the compiler would have handled it as you expected.

    In 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.

    Why would the compiler set the value to char instead of integer? Unless you put them in quotes, they should be integer values.
  • cwpartridgecwpartridge Posts: 120
    gusgizmo wrote: »
    Why would the compiler set the value to char instead of integer? Unless you put them in quotes, they should be integer values.

    Because 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.
Sign In or Register to comment.