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

[Alex Martelli]

"Greg Ewing" <see at my.signature> wrote in message
news:39F9076E.5C7253E7 at my.signature...
> Charles Boncelet wrote:
> >
> > the
> > right question to ask is "what do serious programmers want?"
>
> As a serious programmer, what I want is a straightforward
> and efficient way to specify the operation I want performed.

I agree, but would add "readable" and "concise" to the
desiderata (to make them properly "slightly self
contradictory": there are often such slight self
contradictions).


> Truncating and non-truncating division are very different
> operations, used for very different purposes. Which one
> I want depends on the algorithm I'm implementing. Whenever
> I write a division in my code, I know which one I want.
> But the only way I can tell Python which one to use
> is indirectly, by manipulating the types of operands
> I feed to the / operator.

Good point.  Although you could make the same point for
numeric addition versus sequence concatenation.  When
polymorphism is applied to operations which are not
really the same, such issues do arise.  A further
problem here is that there is a fairly natural mapping
of either operation to the same types of arguments,
as they are both numbers (and number-type objects are
sometimes implicitly coerced...).  Being able to
easily obtain the remainder of a floating point
division (just a % b) but not as easily the
corresponding ("truncated-to-integer") quotient is
a rarer, but pretty irking problem too.  If I want
both quotient and remainder, divmod is great.  If
I only want the remainder, % works.  If I only want
the quotient... no close equivalent (not even just
a typecast on an operand).

Having div and mod operators (or functions, but
ideally with the ability to use them in infix syntax)
would restore symmetry.  And we could abandon the
peculiar overload of the % operator to mean totally
different things (formatting OR remainder...?!).
(Of course, the total incompatibility with current
Python means this is a proposal for Python3000).


> To me, this is so obviously wrong that I can't understand
> how any serious programmer could think it was right.

If one never needs or wants floating-point, I guess
it's easy to convince oneself that nobody else should
ever want or need it either (particularly since it does
give problems unless used carefully and craftily).


Alex