float / double support in Python?

[jsaul]

* Brandon Van Every [2003-02-12 13:15]:
> Martijn Faassen wrote:
> > A language feature that is there will have to be considered for use.
> > Float versus double will make people wonder about what to use,
>
> I don't see what the big deal is here.  The issues are:
> - one's bigger than the other
> - one's more accurate than the other
> - one's faster for certain operations than the other, but they're the same
> for many operations
> - conversions between the two can be a performance hit
>
> These aren't terribly tricky issues.  It's not like they have radically
> different encodings or purposes.

These are entirely irrelevant issues in Python. Please take into
account that any of your above considerations (exept the one
regarding the size perhaps) depends on the assumption that the
Python overhead is negligible. Which as we (you?) all know is not
the case. Therefore, the best choice is to have *one* "general
purpose" floating point type in Python. So that you *can* perform
numerical computations in Python; that doesn't mean that these
computations can in any respect (exept accuracy) compete with the
corresponding C/C++ ones. Number crunching in pure Python is
*slow*. Nobody would seriously implement, say, a Fast Fourier
Transform in Python. That's where extension packages like Numeric
come into play (as has been mentioned many times before), which
can perform a large set of standard numerical operations in a very
efficient manner, but is implemented in C with Python becoming
more sort of a "glue" (which has no negative meaning to me).

> > and what happens on a library boundary where the library writer used
> > float throughout and I used double, is anything going to go wrong,
> > etc.
>
> I find it pretty irritating that Python, knowing full well it would be using
> C as a lower level component, chose to call the 8-byte floating point type a
> "float."  In C this is a "double."  Single precision vs. double precision
> are well defined IEEE 754 / 854 standard terms, and were so long before
> Python.  If you're worried about people getting confused, this is the most
> confusing thing the Python designers could have done.

Again, at some point it was decided to have *one* floating point
type. As explained above, accuracy was certainly a more important
consideration than space or speed of low-level operations, because
Python is *not* a low-level language.

> > Obviously Python has mechanisms (like the struct and array modules)
> > to get to basic machine types. They're just not a core part of the
> > language but are in libraries, where they belong. :)
>
> "Basic machine types belong in libraries" is not real world enough for me.

Then you are of course free to choose whatever you want.

> > Remember that Python is often used as a glue language.
>
> Pretty weak glue if it doesn't understand single-precison floats natively
> and I need to deal with an API that takes only single-precison floats.  I
> thank the makers for the busywork.

You don't get the point. If working with Python only, this is
irrelevant because problems where float vs. double becomes an
issue are not Python's domain. They are the domain of specialized
C extensions like Numeric, which deal with exactly this kind of
issues at the appropriate (i.e. low) level but quite transparent
to the user.

It is also pretty straightforward to write own C or C++
extensions; either using the Python/C API directly or through
e.g. SWIG or Pyrex.

Despite a lot of prejudice, I tried out Python only a couple
months ago, because I needed a scripting language to fill the gap
between the shell-level and C++. I found Python's numerical
capabilities (e.g. support for complex numbers) interesting for my
work (seismology, lots of number crunching) but frustratingly
slow. Particularly, binary I/O using the xdr module (pure Python)
took prohibitively long, I remember measuring factors of about
500(!) compared to the same I/O operations using my C++ library!
But fortunately I did *not* give up, but instead implemented the
same stuff first using Numeric which already made it
*substantially* (>100x) faster. Still a bit slower than what I was
used to, but after moving the whole I/O stuff to an own C
extension module, there is now practically no difference between
the I/O speed of my C extension and the C++ library I also use.

Suffices to say that now, once that work was completed, it's much
more fun to work from within Python. I do have to code a lot of
low-level stuff in C and C++, but adding a Python wrapper is
rather straightforward and worth the effort. All just a matter
of learning it once, as most other things in life.

Cheers, jsaul
-- 
Palo pa'que aprenda que aquí sí hay honor!
[Rubén Blades]