clisp test failures in elemnum.input

[Qian Yun]

There's 2 unexpected test failures in elemnum.input with CLISP.

I wonder if this is known problem.

Debugging shows the following 2 expression are not expected:

(3) -> atan(2.0::DFLOAT * %i)

(3) - 1.5707963267948966 + 0.5493061443340549 %i
Type: Complex(DoubleFloat)

(4) -> atan(-2.0::DFLOAT * %i)

(4) 1.5707963267948966 - 0.5493061443340549 %i
Type: Complex(DoubleFloat)

The sign of real part is inverted.

The actual computation happens in atanh$DoubleFloatElementaryFunctions,
and the direct reason for the failure is that
sign(-0$DFLOAT)
is 1 for CLISP but -1 for SBCL.

This affects the line "y = 0 => sy*half_pi" where sy is sign(y).

- Qian

[Waldek Hebisch]

On Fri, Dec 08, 2023 at 11:34:01PM +0800, Qian Yun wrote:
> There's 2 unexpected test failures in elemnum.input with CLISP.
>
> I wonder if this is known problem.

Look at end of elemnum.input:

-- Since the floating point calculations depend on the underlying Common Lisp
-- engine, it may happen (and currently happens) that some tests fail only for
-- specific Lisp implementations.

So, in general sense problem is known.

> Debugging shows the following 2 expression are not expected:
>
> (3) -> atan(2.0::DFLOAT * %i)
>
> (3) - 1.5707963267948966 + 0.5493061443340549 %i
> Type: Complex(DoubleFloat)
>
> (4) -> atan(-2.0::DFLOAT * %i)
>
> (4) 1.5707963267948966 - 0.5493061443340549 %i
> Type: Complex(DoubleFloat)
>
> The sign of real part is inverted.
>
> The actual computation happens in atanh$DoubleFloatElementaryFunctions,
> and the direct reason for the failure is that
> sign(-0$DFLOAT)
> is 1 for CLISP but -1 for SBCL.

IMO this is within allowed variation between implementations.
Basically, when 0 is obtained via calculations small differnece
in exact sequence of operations may lead to different sign.
And even if we wanted there is no reasonable "fix".

One may ask if we should keep such unreliable tests? Well,
we want to test how _our_ library functions implement branches,
and current tests probably are good enough for this purpose.

--
Waldek Hebisch