POSSIBLE BUG with if-statement comparison operators when used with negative numbers?

  • I'm having a problem performing comparisons when the arguments are negative numbers. A simple example:

    This code will show that the (-270 LT -180) evaluates as false for release 1.0.8 beta 9 (build 2010-02-21). I was definitely seeing problems with the previous release as well. By the way, this particular set of numbers also produces the incorrect result for LE, GT and GE.

    Not all negative number combinations produce errors however, (-300 LT -30) is wrong but (-300 LT -60) is correct. (-60 LT -90) is incorrect but (-60 LT -120) is right. One thing that is consistent, is that whenever the error occurs , both numbers will be negative.

    Here is some code to test the operator across a range of numbers. It sweeps each operand from -360 to 360 in increments of 30:

    This produces the following result. Note that not all comparisons produce erroneous results:

    This appears to be a bug. Am I missing something?

    steve

    Edited once, last by pinsane (February 26, 2010 at 1:59 AM).

  • Quote

    it's a bug, the negative values were interpreted as "Strings",


    Interesting. In the spirit of better understanding, could you elaborate as to how the if statement resolves it's predicate? I find it a little mysterious especially because I'm trying to write a robust isnull action. It's odd that only certain combinations of negative values seem to cause this to fail. It seems that the workaround is to subtract the values first and then compare with zero, but I must admit that automating such a check still relies on using the LT operator so I couldn't be sure if my test was completely valid.

    Code
    I have fixed that now for the next release,


    Thanks!

    Quote

    btw - your "while" action is great!

    Thanks. That's high praise indeed coming from you! I had considered making a post to share these looping actions (I've written actions for while, do, for, and foreach) but I've noticed that for big loops the recursion seems to be able to "get ahead" of the interpreter and abort due to an action overflow error. You'll note in the nested while loops in the above example, I put a wait(0) statement. If you remove this statement you'll see an overflow error for release 1.0.8 beta 9 (build 2010-02-21). The wait(0) seems to get around the problem, for reasons that are completely opaque to me (command queueing? garbage collection?), but I'd be interested if there is a more elegant, faster, and robust workaround. Also, I'll point out that I'm using push and pop so that the loops can be nested, but that means that if someone were to execute push/pop functions asymmetrically (# of pushes != # of pops) from within the loop then strange behavior would occur indeed. Personally, I think the best outcome would be to support looping directly from within the language *wink* because recursion is not the easiest thing for a neophyte programmer to implement.

    Thanks for such a great program Klaus!

    steve

  • Hi,

    Interesting. In the spirit of better understanding, could you elaborate as to how the if statement resolves it's predicate? I find it a little mysterious especially because I'm trying to write a robust isnull action. It's odd that only certain combinations of negative values seem to cause this to fail. It seems that the workaround is to subtract the values first and then compare with zero, but I must admit that automating such a check still relies on using the LT operator so I couldn't be sure if my test was completely valid.

    first - the krpano scripting is still a very simple one, please don't compare it with real scripting languages


    the if action looks if there are variables with the give names:
    if yes it takes the value of the variable for comparison,
    if not it assumes the given variable is a string,

    there is only one exception - when using the new '===' and '!==' if operators,
    then 'null' will be used when a variable wasn't found,

    then when the content of the variable or the given text itself is a string (note - all not predefined values are strings),
    then the first character was checked if it was a numeric character, and if yes, it will be parsed and converted to a number,

    btw. - there is a new version out where the negative values compare is fixed (now it checks also for a + or - sign before the number)

    Thanks. That's high praise indeed coming from you! I had considered making a post to share these looping actions (I've written actions for while, do, for, and foreach) but I've noticed that for big loops the recursion seems to be able to "get ahead" of the interpreter and abort due to an action overflow error. You'll note in the nested while loops in the above example, I put a wait(0) statement. If you remove this statement you'll see an overflow error for release 1.0.8 beta 9 (build 2010-02-21). The wait(0) seems to get around the problem, for reasons that are completely opaque to me (command queueing? garbage collection?), but I'd be interested if there is a more elegant, faster, and robust workaround. Also, I'll point out that I'm using push and pop so that the loops can be nested, but that means that if someone were to execute push/pop functions asymmetrically (# of pushes != # of pops) from within the loop then strange behavior would occur indeed. Personally, I think the best outcome would be to support looping directly from within the language *wink* because recursion is not the easiest thing for a neophyte programmer to implement.

    I have limited the number of single actions to be executed at once to 2000 at the moment,
    it is still a simple interpreter and the flashplayer is not that fast in this case and so too much
    actions will slow down the viewer too much,

    and I have made this limit also to catch up user coding faults when writing "endless loops"
    (the flashplayer could run and block the system up to 15 seconds when in an endloss loop!)

    the wait(0) will work because it stops and current action queue, wait '0' () seconds and continue
    later (on the next flashplayer timer/frame interval) again - btw. a great solution , maybe I should
    do that automatically when reaching the limit of given actions (but then I had still the problem of
    how to catch endless loops)

    best regards,
    Klaus

  • Quote

    btw. - there is a new version out where the negative values compare is fixed (now it checks also for a + or - sign before the number)

    Yes!!!!! The new version works great! *thumbsup*

    Quote

    ...there is only one exception - when using the new '===' and '!==' if operators,
    then 'null' will be used when a variable wasn't found,

    Yessss again!!!!! I don't know how long these strict comparison operators have existed, but it seems that the considerable time I've spent refining an isnull action has been wasted. and that's a good thing!!!! *thumbup*

    There is one area that still seems to be a problem with the strict operators. It's not obvious to me how to set a variable to null. Consider this example:

    Note that the second if statement fails. I'm assuming that it is because using set to assign null to the variable is turning it into a string, but then what is the proper way to set a variable to null?

    And while we're talking about obscure corner cases, I ran into this one when creating this example. If you spell "it's" properly in the above example it fails, even though the single quote is between two double quotes. I'm at a loss to explain what's going on with this:


    For this I assumed that the single quote being between the double quotes wouldn't be a problem, but the second if statement never even executes...weird! *confused*

    Quote

    have limited the number of single actions to be executed at once to 2000 at the moment,
    it is still a simple interpreter and the flashplayer is not that fast in this case and so too much
    actions will slow down the viewer too much,

    and I have made this limit also to catch up user coding faults when writing "endless loops"
    (the flashplayer could run and block the system up to 15 seconds when in an endloss loop!)

    I guess I can understand this limitation, you don't want to make it easy to deploy a pano with an infinite loop in it. I must admit that the only time I ran into the action overflow problem was when writing debugging and test routines.

    Thanks again for a superb tool Klaus! those strict comparison operators have made my week!

    steve

  • Hi Steve,

    Quote

    what is the proper way to set a variable to null?

    I have tried set(foo); but it has no effect...
    I have tried set(foo,); but it is like set(foo,""); (a string with nothing)....
    It seems there is no way to set a variable to null ...
    The only case I found to be possible is for variables set inside a plugin or an hotspot... removing the plugin or hotspot makes the variables to be null ...

    SAlut.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!