make ut-js failure with (expt 1.0 +nan.0)

[gambiteer]

No idea what's going on here:

LD_LIBRARY_PATH=../lib:../gsi:../gsc:/usr/local/libimobiledevice/lib:/usr/local/Gambit/current/lib:/usr/local/chibi/lib:/usr/local/chicken-5.3.0/lib ../gsi/gsi -:tl,~~bin=../bin,~~lib=../lib,~~include=../include -f ./run-unit-tests.scm -js -gsc
[118|  0]  38% ██████▏          133.6s 03-number/expt.scm
*** FAILED 03-number/expt.scm WITH EXIT CODE HI=1 LO=0
"unit-tests/03-number/expt.scm"@137.1-137.35: FAILED (check-eqv? (expt 1. +nan.0) 1.) GOT +nan.0

yet when I build gsi-js with

gsc -target js -o gsi-js -exe -prelude '(include"../lib/header.scm")' gsi/_gsi.scm

I see

heine:~/programs/gambit/gambit> ./gsi-js 
Gambit v4.9.7-7-g65714d67

> (expt 1.0 +nan.0)
1.
> (eqv? (expt 1.0 +nan.0) 1.0)
#t
>        

[feeley]

The expansion of the failing test is this:

(let (($actual-result$
       (if (and ('#<procedure #2 ##eq?> expt '#<procedure #64 expt>)
                (or ('#<procedure #7 ##not>
                     ('#<procedure #27 ##iflnegative?> 1.))
                    ('#<procedure #65 ##iflinteger?> +nan.0)))
           ('#<procedure #66 ##iflexpt> 1. +nan.0)
           (expt 1. +nan.0))))
  (if (##eqv? $actual-result$ 1.)
      #f
      (##failed-check
       "\"unit-tests/03-number/expt.scm\"@137.1-137.35: FAILED (check-eqv? (expt 1. +nan.0) 1.)"
       $actual-result$)))

This logic will end up executing (##iflexpt 1. +nan.0). With the C backend the inlined ##iflexpt calls the C pow function which returns 1.0, the test's expected result. With the js backend the inlined ##iflexpt calls the JavaScript Math.pow function where:

$ node
Welcome to Node.js v23.11.0.
Type ".help" for more information.
> Math.pow(1., 1e400-1e400)
NaN
> 1.0 ** (1e400-1e400)
NaN

So either the expansion of expt has to change to account for the new special cases, or the js backend implementation of ##iflexpt has to account for the new special cases, or the spec of the JavaScript Math.pow function should be changed to make it consistent with C (the designers of the JS spec should wonder why it is not the same as C).

Python and Ruby seem to agree with C:

>>> import math
>>> math.pow(1.0, 1e400-1e400)
1.0
>>> 1.0 ** (1e400-1e400)
1.0

irb(main):001:0> 1.0 ** (1e400-1e400)
=> 1.0

[feeley]

In commit 8018d16 I have added the option -expansion to help debug failing unit tests like this one. For example:

$ cd tests
$ ./run-unit-tests.scm -js -gsc -expansion unit-tests/03-number/expt.scm
...
(let (($actual-result$
       (if (and ('#<procedure #2 ##eq?> expt '#<procedure #64 expt>)
                (or ('#<procedure #7 ##not>
                     ('#<procedure #27 ##iflnegative?> 1.))
                    ('#<procedure #65 ##iflinteger?> +nan.0)))
           ('#<procedure #66 ##iflexpt> 1. +nan.0)
           (expt 1. +nan.0))))
  (if (##eqv? $actual-result$ 1.)
      #f
      (##failed-check
       "\"unit-tests/03-number/expt.scm\"@137.1-137.35: FAILED (check-eqv? (expt 1. +nan.0) 1.)"
       $actual-result$)))
...

[gambiteer]

OK, then I say we leave things as they are on the Gambit side, maybe simplify the code in lib/_num.scm to match the expansion, and I'll see whether I can influence the Javascript people (if there are such things as javascript people) to fix it at their end.

I'll leave this open for a while just to remind me.

[feeley]

Best of luck with changing JS! It may require superhuman powers! But maybe they can be convinced if you explain that having Math.pow agree with C's pow may simplify compilers from C to JavaScript and/or Wasm, which is a more relevant use case for them.

The new -expansion option has helped me notice that the constant folding of the calls to ##ifl... primitives broke when I introduced these primitives (which used to be calls to ##fl... primitives which were correctly constant folded). I fixed this in commit 59e4432. So now I get:

$ ./run-unit-tests.scm -js -gsc -expansion unit-tests/03-number/expt.scm
...
(let (($actual-result$
       (if ('#<procedure #2 ##eq?> expt '#<procedure #64 expt>)
           1.  ;; <================== result of constant folding (##iflexpt 1. +nan.0) by gsc (built with the C backend)
           (expt 1. +nan.0))))
  (if (##eqv? $actual-result$ 1.)
      #f
      (##failed-check
       "\"unit-tests/03-number/expt.scm\"@137.1-137.35: FAILED (check-eqv? (expt 1. +nan.0) 1.)"
       $actual-result$)))
...

Because this constant folding bypasses the call to Math.pow in the JS version of the Gambit runtime library the test now passes! So be aware of this if you can't reproduce the issue and wonder why.

[feeley]

You could reproduce the problem more directly like this:

$ ./gsi-js 
Gambit v4.9.7-7-g65714d67

> (expt 1. +nan.0)
1.
> (##flexpt 1. +nan.0)
+nan.0

Because ##flexpt does not check the special cases that are checked by expt (actually ##expt).

[gambiteer]

There should be a way to run the unit tests with the Javascript backend per se with gsi-js, not compiling the code first.

That's what I want when I make a change to the runtime.

Edit: I see how to do it now, without changing the makefile, just build ../gsi/gsi-j and then do a make ut-js, interrupt the job, and run the command line without the -gsc argument.

Right now, all the make ut-js, ut-python, etc., targets invoke the compiler; do you want similar targets that just run in the interpreter?

If so, what do you want to call these targets?

[gambiteer]

The V8 interpreter, built into Node.js, follows the Javascript spec, which doesn't follow the C/C++ spec:

https://tc39.es/ecma262/#sec-numeric-types-number-exponentiate

So we need to work around it somehow.

[feeley]

Currently _num.scm has this logic when both x and y are flonums:

      (cond ((##flzero? y)
             (macro-inexact-+1))
            ((##fl= x (macro-inexact-+1))
             (macro-inexact-+1))
            ((##flnan? x)
             x)
            ((##flnan? y)
             y)
            ((or (##flpositive? x)
                 (macro-flonum-int? y))
             (##flexpt x y))
            (else
             (complex-expt x y)))

I propose that you remove the tests for y=0 and x=1 and move those into the implementation of ##flexpt. On the C backend the implementation of ##flexpt as a call to the C pow function will do the right thing (it probably includes a test for these special values). For the JS backend those tests will have to be done by ##flexpt before calling Math.pow.

[gambiteer]

So you're proposing to add the Javascript equivalent of this specific test

(if (##fl= x (macro-inexact-+1)
    (macro-inexact-+1)
    (Math.pow x y))

to the Javascript case of the definition of univ-emit-float-expt in gsc/_t-univ-3.scm, and then we can remove something from the flonum-flonum case of ##expt?

Actually we would do better to come up with a single clause with a condition where we call complex-expt, and otherwise just call flexpt. Because after we fix univ-emit-float-expt, the flonum-flonum case becomes

      (cond ((or (##flzero? y)
                 (##fl= x (macro-inexact-+1))
                 (##flnan? x)
                 (##flnan? y)
                 (##flpositive? x)
                 (macro-flonum-int? y))
             (##flexpt x y))
            (else
             (complex-expt x y)))