Acknowledged
over 1 year ago

Bug in Simulator 7.2.1 with Float vs Long comparisons

In the following:

    var l = 1L;
    var f = 1.0f;
    System.println(f==l); // false in 7.2.1, true in 7.2.0 and earlier
    System.println(l==f); // false in 7.2.1, true in 7.2.0 and earlier
    System.println(1.0f==1L); // false in 7.2.1 with optimization off, true with optimization on

Essentially, when the 7.2.1 simulator evaluates 1.0f==1L it returns false. All previous simulators return true.

Note that the optimizer also thinks the result is true.

I've not tried on a device yet, but from past experiments I'm pretty sure that all the watches I've used report true.

If this is something that's going to change, or that devices are inconsistent about, the type checker should issue a warning for long vs float comparisons, and the optimizer shouldn't optimize constant comparisons (especially not to the wrong value!). But my guess is that this is just a bug in the simulator.

markw65
Parents
  • 11 months ago

    >  It should obviously do the same thing for the invalid comparisons above even if the types aren't certain. ie, if one argument might be a Float, and the other might be a Long, (and the type checker is in a sufficiently strict mode) it should warn.

    I wish the behavior of Monkey C in this respect was specified. Idek what's supposed to happen here.

    In Java, the following program outputs "true":

    public class MyProgram
{
    public static void main(String[] args)
    {
        int x = 42;
        double y = 42.0;
        System.out.println(x == y);
    }
}

    This is because the int is implicitly converted to a float for the purposes of comparison. The same thing happens in C.

    Yes, I realize that it's not a good idea in general to use "==" for float comparison, but that doesn't stop Java and C from making a reasonable attempt.

Comment
  • 11 months ago

    >  It should obviously do the same thing for the invalid comparisons above even if the types aren't certain. ie, if one argument might be a Float, and the other might be a Long, (and the type checker is in a sufficiently strict mode) it should warn.

    I wish the behavior of Monkey C in this respect was specified. Idek what's supposed to happen here.

    In Java, the following program outputs "true":

    public class MyProgram
{
    public static void main(String[] args)
    {
        int x = 42;
        double y = 42.0;
        System.out.println(x == y);
    }
}

    This is because the int is implicitly converted to a float for the purposes of comparison. The same thing happens in C.

    Yes, I realize that it's not a good idea in general to use "==" for float comparison, but that doesn't stop Java and C from making a reasonable attempt.

Children
  • 11 months ago in reply to flowstate

    For MonkeyC, it appears that Number vs Float, Long, Double or Char returns true when you would expect it to, as do most of the other pairwise comparisons. Amongst those types, there are just the 4 I listed that don't, and that's only for "older" devices. With "newer" devices all the pairwise comparisons return true.

    This is unfortunate, because it seems like the ones that don't behave have always not behaved; but the simulator got it wrong. Even now the optimizer gets it wrong, which makes things even more confusing.