signum() not in math?

[Paul Rubin]

"Tim Peters" <tim.one at home.com> writes:
> I've used a lot of languages over the endlessly tiring <wink> years, but
> have never seen another language community so keen to avoid writing two-line
> functions themselves.  When a function you want is indeed trivial to code in
> Python, that's a strong argument against bloating the core C code with it.

This is partly because of the enormous speed difference between the
interpreter and C functions, and partly from a desire of not having to
clutter up one's application code with functions that it's reasonable
to make available everywhere.  The second can be solved by putting
some functions in the loadable Python modules.  Anyway, the math
module (at least in Python 2.1.1 for Linux) is dynamically loaded, not
part of the what I think of as the Python core (i.e. it's not
statically linked and present in every running Python image).
> 
> 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).

This is an argument FOR putting signum into the math module.  It says
it's much more than a trivial two-line Python function.  It's better
for the language to settle on a definition and implementation, than
to have N users all doing the same thing differently.

>     It provides access to the mathematical functions defined by
>     the C standard.
> 
> That was Guido's practical way of letting some other committee argue for
> years (literally) about which functions are of most use, and exactly what
> they should do.  Trust me when I tell you there's nothing easy about math
> library definition, design, or implementation, and especially not
> floating-point math libraries.

Does IEEE 754 not define how to do signum (I'm not sure)?  How about
Common Lisp?  Common Lisp is pretty careful about these things and is
a good example to follow.  The C standard doesn't say anything about
complex arithmetic, but there's a cmath module, after all.

> I won't find it embarrassing, no; it's more embarrassing that we haven't
> invented a % format code to convert integers to Roman numerals, which is a
> more frequent topic on the newsgroup, and wrt support for which Python
> severely lags behind Common Lisp <wink>.

I find the whole machinery of % formats to be a case of excessive
cuteness in Python and would prefer that formatted output be done by a
normal library function, but that's a side issue.  As for roman
numerals, sure, there could be some loadable Python module that prints
them and it might as well be included in the library.  (As the CL docs
say, IIRC, roman numerals are useful for printing tables of contents
and stuff like that).  I remember that Maclisp can also READ roman
numerals but don't rememnber if CL can.  Now THAT seems useless. :)

There are different philosophies one can choose about whether to
include miscellaneous functions like signum and roman numerals in a
library.  A minimalist philosophy says leave them out.  A "batteries
included" philosophy says put them in.  Scheme is minimalist, CL is
"batteries included" (both are good languages).  According to its
documentation, Python is also "batteries included", a choice its
authors didn't have to make, but they did, and they put it in the
"advertising", as a result Python attracted the type of users who like
that choice.  So its maintainers shouldn't agonize too much about
whether to include something, especially in a loadable module.  If
there's a reasonable case for putting it in, the advertised philosophy
says to put it in.