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

[Donald O'Donnell]

Alex Martelli wrote:
> 
> ...
> Seems a waste of effort to compute the fractional-result when
> all I'm interested in is its integer-part; I would much rather
> have a way to ask for that integer-part *directly*, with a div
> operator or function. Often, when I want that, I also want the
> remainder, in which case existing function divmod is just
> right; but I'd like to have separate div and mod too, for
> those cases in which I _don't care_ about the other part -- as
> "explicit is better than implicit", why not let me be explicit
> about 'not caring', rather than "implicitly" expressing it by
> doing nothing further with the computed-anyway value...?
> 
Sounds like we are very much in agreement here:

If you want the integer part of a division by 2, 
(your "div" operator) use:

    a/2   =>  a truncated integer result with no time wasted 
              computing a float.

If you want a mathematically correct float use:

    a/2.0  =>  a float

If you want integer quotient and remainder use

    divmod(a,2)  =>   a 2-tuple containing 2 integers

You can get whatever you want very easily and it doesn't break
any existing code.  The rule is very simple and easy to
remember:  If an expression consists of all integers, the 
result is an integer; if it contains mixed integers and
floats, the integers are promoted to floats, the calculations 
are done using floats, and the result is a float.

If the language were changed as others have suggested, we would
have:

    a/2   =>  a float

    a/2.0  =>  a float

Seems like we've lost something here.  If we needed an integer
result under these new proposals, we would have to use:

    floor(a/2)

which would promote both a and 2 to floats, perform a floating
point division, and then truncate the fractional part of the
result and convert it to an integer.

What I think some people are loosing sight of, is that the 
underlying hardware instruction set of most computers 
contains an integer division instruction which results in a
quotient and a remainder (which, BTW Alex, implies that it 
doesn't cost any more to get both even if all you want is just
the quotient or just the remainder), which is usually at least 
an order of magnitude faster than a hardware floating point 
division; and on some computers which lack floating point 
hardware, a software generated floating point result could 
take several orders of magnitude longer to compute.  

The compiled C code underlying a Python integer division makes 
use of this fast hardware integer division instruction.  If 
Python were changed so that all integer divisions were done in
floating point, we would loose the ability to make use of this 
fast hardware divide instruction.  This could have a severe 
negative impact on some compute intensive (Numpy?) programs.

Don O'Donnell