Re: Minor CLISP bug #2

[Raymond Toy <toy@rtp.ericsson.se>]

>>>>> "Bruno" == Bruno Haible <haible@ilog.fr> writes:


    Bruno> M. Thomas <thommark@access.digex.net> writes:
    >> I like CLISP's facility for setting the precision of floating-point
    >> numbers.  There does appear to be a small glitch, however:
    >> 
    >> > (setf (long-float-digits) 100)
    >> 100
    >> > (/ pi 2.)
    >> 1.5707963267948966192313216916397514421L0
    >> > (asin 3.4L0)
    >> #C(1.5707964 -1.894559012672297804279889265261663451844L0)
    >> ;;; expected both realpart and imagpart to have the specified
    >> ;;; long-float precision:
    >> ;;; #C(1.5707963267948966192313216916397514421L0
    >> -1.894559012672297804279889265261663451844L0)

    Bruno> The real part here does not depend on the input, therefore - in theory -
    Bruno> it should be pi/2 with infinite precision. This is not representable, so
    Bruno> clisp chooses the format contained in the variable *default-float-format*.
    Bruno> Try (setq *default-float-format* 'long-float).

The real part certainly does depend on the input.  If the input were
less than one in magnitude, the result would not have been complex.
The choice made, though, is reasonable, except that I thought ANSI CL
says the parts of a complex number are supposed to be the same type.
Thus, the real and imaginary should have been long-floats.

Ray