[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Minor CLISP bug #2
- To: email@example.com
- Subject: Re: Minor CLISP bug #2
- From: Raymond Toy <firstname.lastname@example.org>
- Date: Tue, 07 Jan 1997 16:42:31 -0500
- In-reply-to: (Your message of Tue, 07 Jan 1997 18:54:51 +0100.) <9701071739.AA11524@>
- References: <9701071739.AA11524@>
>>>>> "Bruno" == Bruno Haible <email@example.com> writes:
Bruno> M. Thomas <firstname.lastname@example.org> 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)
>> > (/ pi 2.)
>> > (asin 3.4L0)
>> #C(1.5707964 -1.894559012672297804279889265261663451844L0)
>> ;;; expected both realpart and imagpart to have the specified
>> ;;; long-float precision:
>> ;;; #C(1.5707963267948966192313216916397514421L0
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.