Ticket Created
over 3 years ago

CIQQA-1396

Bug: Print doubles with full precision to prevent weird behaviour by test messages.

    (:test)
    function garminDouble(logger) {
      var mile = 0.6213711922d;
      var km = 21.0975;

      var hm = mile * km;

      Test.assertEqualMessage(hm, 13.109379d,
        Lang.format("half marathon in miles $1$ equals to $2$",
          [ hm, 13.109379d ]));
    }

The following code fails with: Exception: ASSERTION FAILED: half marathon in miles 13.109379 equals to 13.109379

Please make sure that the printed version equals what the actual test uses for the precision of the double. As soon as you toString() the values, it becomes the same value. Which is unclear and very confusing.

waterkip
Parents
  • over 3 years ago

    "Can you try comparing with hm.equals(13....)?"

    , as discussed in the other thread, that's not the problem. The perceived problem is that only 6 digits are printed out but the true value has many more significant decimal places.

    Once again, "==" works fine to compare doubles (and longs).

    *However*, even in C, using printf("%g") on "21.0975d * 0.6213711922d" only prints out 4 places, and using "%f" on the same value prints out 6 places.

    The real question is what should be expected when a double is printed out "directly", using Lang.format or System.println.

    If you use alert or console.log in javascript, you get full precision. Same with print() in python. Same with C# and Java. So it looks like precedent is not on the side of Monkey C.

    e.g. python:

    >>> x = 21.0975 * 0.6213711922
    >>> print (x)
    13.1093787274395
    >>> print (x == 13.1093787274395)
    True

    In this case, the workaround is to force more decimals to be printed out.

    e.g.

    Test.assertEqualMessage(hm, 13.109379d,
            Lang.format("half marathon in miles $1$ equals to $2$",
              [ hm,format("%.17g"), 13.109379d.format("%.17g") ]));

    (See: https://stackoverflow.com/a/21162120)

    This should produce output that makes more sense. e.g.

    ASSERTION FAILED: half marathon in miles 13.109378632625781 equals to 13.109379000000001

Comment
  • over 3 years ago

    "Can you try comparing with hm.equals(13....)?"

    , as discussed in the other thread, that's not the problem. The perceived problem is that only 6 digits are printed out but the true value has many more significant decimal places.

    Once again, "==" works fine to compare doubles (and longs).

    *However*, even in C, using printf("%g") on "21.0975d * 0.6213711922d" only prints out 4 places, and using "%f" on the same value prints out 6 places.

    The real question is what should be expected when a double is printed out "directly", using Lang.format or System.println.

    If you use alert or console.log in javascript, you get full precision. Same with print() in python. Same with C# and Java. So it looks like precedent is not on the side of Monkey C.

    e.g. python:

    >>> x = 21.0975 * 0.6213711922
    >>> print (x)
    13.1093787274395
    >>> print (x == 13.1093787274395)
    True

    In this case, the workaround is to force more decimals to be printed out.

    e.g.

    Test.assertEqualMessage(hm, 13.109379d,
            Lang.format("half marathon in miles $1$ equals to $2$",
              [ hm,format("%.17g"), 13.109379d.format("%.17g") ]));

    (See: https://stackoverflow.com/a/21162120)

    This should produce output that makes more sense. e.g.

    ASSERTION FAILED: half marathon in miles 13.109378632625781 equals to 13.109379000000001

Children
No Data