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

[Alex Martelli]

"Huaiyu Zhu" <hzhu at users.sourceforge.net> wrote in message
news:slrn8vgst8.oo.hzhu at rocket.knowledgetrack.com...
> On Thu, 26 Oct 2000 07:16:06 GMT, Donald O'Donnell <donod at home.com> wrote:
> >
> >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

Haven't seen Donald's post, so I take advantage of Huaiyu's
reply to answer this: _maybe_ it's just as cheap for, certain
numeric values, on a given hardware/software platform, to
compute both quotient and remainder as to compute only one
of them -- *and maybe it isn't*.  It depends on many factors.

For example, for longs, there are algorithms to compute
only one of them that can be much faster than general ones
to compute both, although I don't think Python makes any
real attempt at heavy optimization in this field, _right
now_.  In any case, allocating the space for two numbers
when only one is of interest is sure to be a sheer waste
in this case.

When I program in a very high level language, *I do not care
and do not want to care* about such issues -- this is WHY
I'm using a VHLL, remember?  If a specific programming
problem was all about working close to the machine, a VHLL
would not be the most appropriate choice.

If a CPU comes onto the market tomorrow, for which the
instruction to compute just-the-quotient is half the cost
of the one for computing quotient-and-remainder, do you
want to be using a language that has forced you to throw
away that possible speedup forevermore...?!

What I want of a high-level language is, first of all, a
way to express my intentions exactly, clearly, explicitly.
If I only want the quotient, and don't care about the
remainder, I want a way to ask for the quotient.  It's
fine (except, possibly, for performance issues) if, in
some cases (or even all) the language internally computes
the remainder too, and throws it away; this is a language
implementation issue, and potential optimizations in this
very specific area will have to be weighted against other
opportunities.  But the _language_ itself must let me
state my intentions directly -- this makes my code more
readable *and* yields easy optimization opportunities to
future processors for that language -- it's a win/win.


> >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.

But if Py3000 changed so that _both_ truncating-division
and non-truncating-division operators existed, one could make
use of the appropriate one according to one's needs, and
live happily ever after.  And THAT is what I want: / for
non-truncating division, div (ideally) for truncating
division quotient, mod (ideally) for truncating division
remainder (currently existing but spelled %), divmod (the
only currently existing one) for quotient AND remainder.
(I, personally, feel no need for a polymorphic operator
or function to mean "don't truncate, unless both args are
integral, in which case do truncate" -- but I have no
objection to the existence of such an obscure peculiarity
to ease the porting of Python source to Py3000:-).

I could stand other spellings for the truncating and non
truncating division operators (or functions) -- syntax
sugar is not the key issue to me -- but I think the syntax
should be optimized towards those for which it's most likely
to be a biggie (i.e., beginners), and that those people
would likely expect / to be non-truncating, etc.  If one
holds compatibility with the past as the highest target
(which is not supposed to be the case for Py3000), then
I guess / will have to keep meaning the current peculiar
polymorphic operator, and all we need are operators for
truncating and non-truncating divisions (simulating them
today as functions is easy for div -- just divmod and a
[0] at the end:-) -- not so easy for non-truncating-division
except by introducing a non-built-in "rationals" module:-).


> A little test result.  Doing a+a one million times takes 2.05sec for
a==2.2,
> and 1.82sec for a==22.  That's about 9/8 ratio.
>
> For a/a the time ratio becomes 2.180/ 2.040, or about 16/15.
>
> Doesn't look like an order of magnitude to me.

The negligible difference between addition and division is also
interesting.  Python-internals-overhead dominating...?-)


Alex