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

*To*: common-lisp at SU-AI*Subject*: GLS's change to Moon's floating-point extractors proposal*From*: David A. Moon <Moon at SCRC-TENEX at MIT-MC>*Date*: Wed, 06 Oct 1982 08:19:00 -0000*In-reply-to*: The message of 4 Oct 82 23:55-EDT from Guy.Steele at CMU-10A

Date: 4 October 1982 2355-EDT (Monday) From: Guy.Steele at CMU-10A I support Moon's proposal, but would like to suggest that FLOAT-SIGN be modified to (FLOAT-SIGN x &optional (y (float 1 x))) returns z such that x and z have same sign and (= (abs y) (abs z)). In this way (FLOAT-SIGN x) returns 1.0 or -1.0 of the same format as x, and FLOAT-SIGN of two arguments is what the IEEE proposal calls COPYSIGN, a useful function indeed in numerical code. This is the SIGNUM function, which already exists on page 125 of the Colander. If my memory of the past 2 months' discussion is accurate, it was extended to the 2-argument case; the Colander only allows one argument. FLOAT-SIGN was intended to be something else, and would return 0 or 1 rather than 1.0 or -1.0. Perhaps FLOAT-SIGN is redundant given the existence of SIGNUM. There is only one problem with this, which I think I pointed out in my message: the minus zero in the proposed IEEE standard. I'm sure that SIGNUM of this has to be -0.0 rather than -1.0 (although possibly it has to be +0.0). And MINUSP of -0.0 has to be NIL. Furthermore the standard specially specifies that (= -0.0 0.0) => T. So if you're writing a portable floating point number printer, you need some way to know to print a minus sign for minus zero. If EQ worked on numbers you could use it.

- Prev by Date:
**Re: keyword pairs and OPEN** - Next by Date:
**Re: defun semantics** - Previous by thread:
**ZVONA: ~xxxxxnxxxxxxxxxxxxxxxxxxxxxx** - Next by thread:
**FLOAT-SIGN and SIGNUM** - Index(es):