Acknowledged

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.

  • I've added the test to the app: https://apps.garmin.com/apps/240150b5-7c2c-4b13-b12d-e36f89fdb6b3

    Feel free to use it and test compiler results. -o3 optimizations applied to the app.

  • As soon as I posted this, the fenix5xplus started taking charge. And as I guessed, it also gets the comparisons right. So my best guess at this point is 3.2 and later get it right.

  • tldr; the simulator thinks that anything not running CIQ5 gets the comparisons wrong. Real devices seem to start getting it right somewhere between 3.1.x and 3.3.1. So the simulator is definitely buggy.

    ---

    I finally got around to doing some real device testing, and comparing the results with the simulator.

    The devices I am able to test are fr235, fr935, fr955 and edge1030plus.

    According to the simulator, all except the fr955 return false for Float vs Long, Float vs Char, Long vs Char and Double vs Char. I've also tested fenix6x in the simulator, and it also has the "old" behavior. So I was assuming that anything other than a CIQ 5.x device (System 7 I think, but I'm not sure) had the old behavior.

    But in fact the edge1030plus (CIQ 3.3.1) gets the comparisons right. The fr935 (CIQ 3.1.8) gets it wrong, as does the fr235.

    I also have a fenix5xplus, but the battery is dead, and it doesn't seem to want to charge, so I can't confirm, but its 3.3.3, so since the edge1030plus works, I think it's likely that it would too. If I get it working again, I'll post an update.

    Meanwhile, if anyone want's to test their own devices, I've created a simple data field project at https://github.com/markw65/ComparisonTester . Build it for a device you want to test, install it in Garmin/Apps on the device, and then add it to an activity profile. Devices that get all the comparisons right will show 1023 in the data field. All the failing devices so far show 175, which means that just the 4 listed comparisons fail.

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

  • Sorry, in the previous comparison I should've said "the int is implicitly converted to a double."

    My point stands though. The same would've happened for a literal float and int comparison.