CL-USER> (describe 'phase) ... Function documentation: Return the angle part of the polar representation of a complex number. For complex numbers, this is (atan (imagpart number) (realpart number)). For non-complex positive numbers, this is 0. For non-complex negative numbers this is PI. ... CL-USER> (= (phase -1) pi) NIL CL-USER> (= (phase -1) (coerce pi 'single-float)) T CL-USER> ( (type-of pi) shows that it is a double-float ). If this turns out to be a genuine bug and not e.g. something I've misunderstood about the Common Lisp specification, I've discovered that CLISP also behaves this way. GCL gets it right but it's PI seems to be wrong in the last digit. I won't enter any more bug reports though in case I'm missing something.
Further investigation (the CLHS at www.lisp.org) reveals that this incon{sistency,venience} appears to be written in to the ANSI standard. The documentation for phase could be improved but I suppose this isn't really a bug in SBCL (or CLISP). Maybe it is just GCL that's getting it wrong?
Hi Paul, I conducted the following comparison: CLISP 2.33.2 on x86 produces: [13]> (= (phase -1l0) pi) T SBCL 0.8.20 on x86: * (= (phase -1l0) pi) T GCL 2.7.0 (ie. from CVS, but from a week or so ago) on x86: >(= (phase -1l0) pi) T I think the misunderstanding is due to how PI and PHASE are defined in the CLHS. For PHASE: "phase returns the phase of number... If number is a float, the result is a float of the same type." For PI: "Constant Variable PI value: an implementation-dependent long float.". Is it possible the problem in your comparion is that PI is a long float, and phase was tested with single or double floats? If that is the case, then I don't think this is a bug.
Yes - my misunderstanding really originated with the SBCL documentation though. CLHS says "The phase of a positive real number is zero; that of a negative real number is <PI> ... If number is a rational or a complex rational, the result is a single float." The first part of that entry in CLHS seemed to confirm what I'd gathered from the SBCL documentation: that (phase -||x||) would evaluate to PI, whatever x, which is what I'd hoped it would do, but then the second part of the entry introduced the ambiguity that had me confused. So you're right: it's not a bug - just something I'll have to live with ;-) Anyway I'll close this bug now. Thanks Matthew and sorry for wasting your time.
