signum() not in math?

[John Roth]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.1002968112.31501.python-list at python.org...
>
> I expect you severely underestimate the arguments there *would* be over
"the
> correct" signum function:  what to do about a 0 argument; which types it
> should accept; which type(s?) it should return; if signum(0.0) returns a
> float 0, whether the sign of 0 needs to be preserved or erased, or whether
> that's undefined; if signum(0.0) returns a 1, ditto for reflecting the
sign
> of the input; what to do about NaN arguments; and whether subclasses of
> numeric types and/or new numeric types need a way to override the base
type
> signum implementation (since you brought up the parallel, note that
numeric
> types *can* override __abs__, and that requires a whole slew of machinery
in
> the class and type implementations, and adding new slots for numeric types
> at the C level creates cross-release binary compatibility headaches too).

Come on, Tim. Most of these questions have fairly rational answers.
To try a prototype definition:

sign(x) returns a value of either 1 or -1 with the same sign and type as
the input. If the input is zero and the numeric type does not distinguish
between +0 and -1, it returns 1. It returns a NaN for a silent NaN, and
raises the appropriate exception for a signaling NaN.

sign0(x) is the same as sign(x), except that it returns a zero value for a
zero input. It is the implementors discretion as to whether to return the
same
object or a different object with the same value in this case.

Any class or type which implements numeric methods can implement
these functions by including a __sign__ or __sign0__ method.

Both functions raise a TypeError if the input is not a scalar numeric type,
or is a class instance without either __sign__ or __sign0__ defined.

The binary compatibility problem is not unique to this proposal

John Roth