#116 Constant Optimisation: Bad division of floats

closed-invalid
None
5
2010-06-25
2010-06-25
Silky Mesmeriser
No

I am not sure if this is expected behavior but this seems odd to me, when you have the value of a constant division the optimizer rightly tries to replace it with a value, but when assigning to a float it will in some cases completely drop the decimal portion in my view this shouldn't happen. I will show the problem with direct examples as it is hard to explain otherwise:

// Take case 1
float Number = 1;

default {
state_entry() {
float Result = Number / 2;
}
}
// The compiled result is as follows, note Result gets the value of 0
default {
state_entry() {
float Result = 0;
}
}

// In case 2 it seems to work correctly where the redundant decimal point is added to the global constant declaration
float Number = 1.0;

default {
state_entry() {
float Result = Number / 2;
}
}
// Result = 0.5 which is the correct output for the calculation
default {
state_entry() {
float Result = 0.5;
}
}

It seems wrong to me and I wanted to bring it to your attention as it will produce different results in LSL Plus to the Unoptimized code and surely optimization is NOT intended to change the output of the code.

This similar happens if two variables both defined as floats are divided so doesn't seem to take into account the types of the values at all and it should as I understand it.

Discussion

    • summary: Constant Optimisation: Floats converted to Integers --> Constant Optimisation: Bad division of floats
     

  • Anonymous
    2010-06-25

    Afaict this is the way LSL works (See http://wiki.secondlife.com/wiki/Float\). So the optimization is correct in doing it like this since it is the actual behaviour in SL.

     
  • Ah, my apologies thanks for that very odd behavior indeed. Will just have to chalk that one up to LSL weirdness I guess sorry for the redundant posting here.

    Closing bug.

     
    • labels: 1165214 -->
    • status: open --> closed-invalid