[PYTHON MATRIX-SIG] NumPy 1.0a3

[Paul F. Dubois]

I certainly thought we had all agreed that at least the default behavior was
that a floating point exception or math routine exception was caught
immediately.

It is impossible to debug a large code otherwise. We don't have a single
production code at LLNL which is willing to end up with the answer NaN two
days later.

----------
> From: Konrad Hinsen <hinsen@ibs.ibs.fr>
> To: matrix-sig@python.org
> Subject: [PYTHON MATRIX-SIG] NumPy 1.0a3
> Date: Monday, September 16, 1996 10:18 AM
> 
> There are a couple of issues that I think ought to be discussed
> before moving from alpha to beta status:
> 
> 1) The package system.
> ----------------------
> 
> Although a good idea, I dislike it more and more after using it for a
> while. Not only does it need the mysterious "import ni", whose meaning
> is evident neither from its name nor from the way it is used, but it
> also introduces unwelcome surprises.  For example, "from Numeric
> import *" doesn't work any more, even after "import ni", importing
> anything specific poses no problem ("from Numeric import
> array"). Sure, I can resort to "from Numeric.Core import *", but
> that's more complicated (think about interactive use) and less
> clear. How am I supposed to explain to a newbie (who just learned who
> wonderfully consistent Python is) that getting all functions from
> Numeric involves
>   import ni; from Numeric.Core import *
> although no object from "ni" is never used and "Numeric.Core" occurs
> in no other context?
> 
> So let's look at the alternatives:
> 
> a) No packages. We could then have suggestive names, e.g.
>    "Numeric_FFT" for the submodules. Of course that supposes
>    that long module names can safely be used on all systems.
> 
> b) Simulate the module behaviour in a different way. One idea I had
>    is to define a class (untested, of course ;-)
> 
>      class Submodule:
> 
>          def __init__(self, name, base):
>              self.name = name
>              self.base = base
>              self.module = None
> 
>          def __getattr__(self, name):
>              if self.module is None:
>                  module_name = self.base + self.name
>                  exec 'import ' + module_name
>                  self.module = eval(module)
>              return getattr(self.module, name)
> 
>    Then Numeric.py would contain, for example,
> 
>      FFT = Submodule('FFT', 'N_')
> 
>    and any reference to Numeric.FFF.x would import N_FFT and
>    return object x from it, which could then be assigned at
>    will or of course used directly. If performance is considered
>    a problem, one could transfer all the names from the freshly
>    loaded module into the submodule object for direct access.
>    This would give most of the package functionality, except
>    it is impossible to import a submodule directly - which in
>    our case doesn't make much sense anyway.
> 
> 
> 2) The umath module.
> --------------------
> 
> The original idea was to have two versions of this module: one, umath,
> would behave just like any decent Python program and raise exceptions
> for floating point errors, and the other, fast_umath, would for the
> sake of speed just return whatever the floating point code (or
> processor) produces. Since Jim is a speed fanatic, he has concentrated
> on fast_umath to the point that umath is not even compiled in the
> standard distribution. Still I think that there will be no disagreement
> about the need for both in an official distribution.
> 
> However, there are additional problems caused by the fact that
> routines from umath are used in Numeric (to be precise, all items from
> umath are provided by Numeric, and some are used in other functions,
> e.g. add.reduce). This raises two questions:
> 
> a) How can the user select between umath and fast_umath?
> b) Which should be the default?
> 
> Right now, "fast_umath" is hard-coded into Numeric/Core.py, which is
> probably the worst solution. The alternatives I can think of are
> 
> a) Have two separate modules, "Numeric" and "Fast_numeric". A bit
>    wasteful, even more so in the presence of packages.
> b) Selection via a variable or function in module sys.
> c) Provide just one module, umath, and add a function to it that
>    allows disabling or enabling exceptions.
> d) Remove the import from Numeric and leave it to the user. The few
>    routines actually used in Numeric/Core.py could be taken from
>    umath, since they are not speed critical.
> 
> c) would be closest to the way most C/Fortran/whatever floating-point
> libraries work. But it would also be restrictive, since one could not
> easily have exceptions for, say, square roots while disabling them for
> logarithms. b) would be little effort, but not evident and therefore
> error-prone. a) is too messy for my taste. Which leaves d) as my
> personal favourite. Note that everyone is free to define his/her
> personal module that imports everything from Numeric and
> umath/fast_umath, and to prevent name proliferation we could even
> provide two such modules with the standard distribution (coming close
> again to solution a) without its drawback of code duplication).
> 
> The default question arises only with solution b). In this case, I
> strongly favour umath as the default. According to the principle of
> least surprise, everything should work as usual in Python, and the
> decision to give up exceptions for the sake of speed should be a
> conscious decision of the user, not a default imposed by someone's
> personal preferences.
> 
> 
> And now you can all wake up, I am finished. Any comments?
> 
> Konrad.
> -- 
>
------------------------------------------------------------------------------
-
> Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
> Laboratoire de Dynamique Moleculaire   | Tel.: +33-76.88.99.28
> Institut de Biologie Structurale       | Fax:  +33-76.88.54.94
> 41, Ave. des Martyrs                   | Deutsch/Esperanto/English/
> 38027 Grenoble Cedex 1, France         | Nederlands/Francais
>
------------------------------------------------------------------------------
-
> 
> =================
> MATRIX-SIG  - SIG on Matrix Math for Python
> 
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> =================

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================