[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Minor CLISP bug #2



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)

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

> And besides, it seems that 1.570796326... should have been printed as
> 1.5707963, not 1.5707964.

After pi/2 has been converted to a floating point value, clisp doesn't
know any more that it came from pi/2 = 1.570796326... All it has is the
internal (binary) representation, which has the value 1.570796370...
Therefore it prints 1.5707964.

                           Bruno