[PYTHON MATRIX-SIG] More naming/module issues

[Paul F. Dubois]

As usual, let me be different.

As elegant as it sounds, Numeric.LinearAlgebra is redundant. There is no
un-Numeric LinearAlgebra unless Python suddenly supports symbolic
computation.
LAPACK represents a certain quality assurance for me. When choosing a
routine from a module called LAPACK, I know I'm getting the right answer.
If other
stuff is mixed in, maybe I'm getting a FastButWrong amateur effort.

On the other hand, I see the virtue of having a tree-like path to find
stuff in that great big catalog of the future. Say,
LinearAlgebra.LAPACK 
LinearAlgebra.NAG
LinearAlgebra.Sparselib
FFT.FFTPACK
FFT.IMSL
FFT.NAG

I don't understand the implications of the package nesting, however. One
wouldn't want to load all of the LinearAlgebra children just because you
wanted one of them.
----------
> From: Michael McLay <mclay@eeel.nist.gov>
> To: matrix-sig@python.org
> Subject: Re: [PYTHON MATRIX-SIG] More naming/module issues
> Date: Friday, September 06, 1996 2:03 AM
> 
> Konrad Hinsen writes:
>  > > Now I'm working out the standard library.  My questions is: How many
>  > > modules should I make and what should they be called?
>  > 
>  > My preference is:
>  > 
>  > > 3) Add them to seperate modules:
>  > > 	Lapack.inverse(matrix), Fftpack.fft(waveform), Ranlib.random(100)
>  > 
>  > However, I'd prefer other names for the modules, and maybe also a
>  > somewhat wider scope. For example, I'd like to have one module for
>  > linear algebra. The standard version would contain the LAPACK
>  > interface, but conceivable someone else could write a compatible
>  > version using a special Cray library or whatever. There could also be
>  > other functions (added later) that are not part of LAPACK. Therefore
>  > the module should not be *called* LAPACK, but LinearAlgebra.
> 
> I agree that new names should be used.  I propose the following
convention 
> be followed so the library that is created makes it easy to find
> general resources, but still retain the ease of use of short hand
> notations.
> 
> The names selected for modules,classes, and functions should be
> spelled out in full for a general package called Numeric.
> 
> 	Numeric.LinearAlgebra
> 	Numeric.FourierTransform
> 	Numeric.RandomNumbers
> 
> I dropped the term Fast from FourierTransform because it seems obvious
> that you would want to do it fast and I don't recall ever hearing
> about anyone using something other than an FFT.  The nature of the
> algorithm used could be incorporated into a docstring, rather than
> encoded in the name.
> 
> Each discipline can now import the fully spelled out name and
> shorten it so it fits the conventional notation for that industry.  
> For instance ComputationalChemistry.fft module might contain the line:
> 
> 	from Numeric.FourierTransform import *
> 	fft = FourierTransform
> 	fft2d = FourierTransform2D
> 
> This notation will make it easier for new users to grasp the
> organization of the language and the library.  Using names like LAPACK
> is not intuitive to a new student.  It will become even less intuitive
> as high level language take over in the role of teaching linear
> algebra.
> 
> 
> Michael
> 
> =================
> 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
=================