[Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison

[Alex Martelli]

"Greg Ewing" <see at my.signature> wrote in message
news:39FCE175.B5E3BA13 at my.signature...
> Alex Martelli wrote:
> >
> > Although you could make the same point for
> > numeric addition versus sequence concatenation.
>
> Not quite, because addition only makes sense
> for numbers,

Addition also makes sense for "groupings" of
numbers, actually.  I'm deliberately being vague
in indicating what a "grouping" is.  But surely
you recall the vast debates this summer about
element-wise versus matrix-wise arithmetic and
the need for alternate-arithmetic operators.

The natural interpretation of "this grouping
of numbers X, plus this number Y here" may
well be "the new grouping obtained by adding
Y to each of X's items".  For example, if
current VAT rates were [0.04, 0.13, 0.19]
(depending on what good or service is being
taxed), and I read a headline "All VAT rates
to increase by one percent", I would take it
as meaning the new VAT rates are going to be
[0.05, 0.14, 0.20].  I.e., in Python syntax,
    rates = [rate+0.01 for rate in rates]
rather than
    rates = rates + [0.01]

But the overloading of '+' in these contexts
to mean such different things is really not
as natural as all that.

> whereas concatenation only makes
> sense for sequences.

_Concatenation_, yes, by definition.  Other
senses of '+', surely no less natural than
'concatenation' (e.g., set-union), may appeal
for certain non-sequences.  If an object has
both a natural mapping to "a sequence", and
an appealing alternative interpretation for
'+', the situation is, however, slightly
awkward -- no less than that which the overload
of / to mean both truncating and non-truncating
division produces.  E.g., for a set, it seems
natural to treat '+' as meaning set-union, but
also provides a sequence-view, so that iterating
over the set's elements with a for statement
works as expected.  One might decide to finesse
that by forcing the iteration to use another
object ("for element in myset.elements()" or
thereabouts, for example, rather than the handier
"for element in myset"), but that sort of thing
_is_ a slight hassle.  The root cause of the
hassle is the overload of '+'.

Overloading an operator to mean totally diverse
things is never hassle-free -- not even, say,
Python's overloading of '%' to mean either
"modulo/remainder of truncating division" or
"formatting using a format-string" (or C++'s
overloading of '<<' to mean either "bit shift
to the left" or "formatted output to stream",
which is much in the same spirit:-).

It may be worth it, I guess, but I have my
doubts about that.  Where I see polymorphism
playing a useful role is not in such usages
of overloading, where one will sensibly never
want to use the substitution-possibilities it
affords; but, rather, exactly for those cases
where the operations _are_ similar enough that
"getting the right operation depending on
operand types" IS potentially useful.  Whether
that applies to truncating vs non-truncating
division -- well -- I can't think of any
non-contrived example, though I guess that with
some ingenuity one might be built up.

> Python has no built-in
> type which is both a number and a sequence,

It cannot have a type to which both addition
(in the numeric sense) and concatenation (in
the sequence sense) usefully apply, of course --
not without some more or less severe hassles;
by the overload it has chosen to define on '+',
it has painted itself in a corner that way.

But let's not confuse "a type which is a
number" with "a type to which numeric addition
can usefully apply" (e.g., a container of
numbers).  There are, of course, such types --
that they're not currently built-in to Python
is hardly a "plus".

I don't know about you, but me, I have quite
a few scripts that start with
    from Numeric import *
and treat those 100+ identifiers "as if" they
were basically builtin.  Hey, if I ask Python,
after even an 'import Numeric', it tells me:
>>> type(Numeric.array)
<type 'builtin_function_or_method'>
so it seems to THINK it's builtin -- it says
so:-)  [Bad terminology in the output of
'type', of course -- it says 'builtin' when
it really means something more akin to
'natively coded in C';-)].

So, I have objects around that *are* both
sequences (I can loop over them with for)
AND 'natural subjects for numeric addition'.

Numeric gives me the second meaning for '+',
the one intended for numbers, NOT the one
intended for sequences (and right is it --
in a Numeric context, I have arithmetic in
mind more often than concatenation!-).

Still, this does mean I have to use the
'verb' "concatenate" when I do want to do
that; and, more serious, I cannot pass such
an array 'natively' to a function that will
polymorphically concatenate any sort of
sequence as a part of its job.  If different
operators were used for the different roles
of numeric-addition and sequence-catenation,
no such problem would arise.

Yeah, yeah, I know the workarounds, such
as using the .tolist() method of array
objects, or wrapping my own concatenation
function around both array's concatenate
and other sequence's '+' (actually, the
'concatenate' itself will do that, if I
write my polymorphic function _knowing_
it must not use '+' to join sequences --
that makes it _dependent_ on Numeric, which
is not always what one wants, particularly
as 'concatenate' will always return an
array...).

In other words, I'm not speaking of grave
and perilous defects, but of _serious
inconveniences_ deriving from the apparently
'convenient' use of '+' to mean two really
distinct things.

The parallel to '/' meaning two really
distinct kinds of 'division' is, I think,
rather applicable.

> and no automatic coercions between numbers
> and sequences, so there's no confusion.

See above.  Numeric in a sense 'converts' a
number to an array of numbers in appropriate
contexts (arithmetic, not structural ones).

That Numeric cannot fit seamlessly in Python
because of the '+' overload hardly looks to
me as an _advantage_ of that overload:-).


Alex