[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GLS's change to Moon's floating-point extractors proposal
- 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.