[SciPy-dev] Re: [Numpy-discussion] Trying out Numeric3

[Travis Oliphant]

 >For example, if a developer uses scipyfortran package in a package, it 
immidiately reduces the number of >potential users for this package.

While I'm not in love with my suggestion and would prefer to see better 
ones put forward,  wouldn't any system that uses routines not available 
unless you have a fortran-compiled package installed be a problem?  I 
was just proposing not "hiding" this from the developer but making it 
explicit.

What do you propose to do for those situations?  I was just proposing 
putting them in a separate hierarchy so the developer is aware he is 
using something that requires fortran.    I actually think that it's 
somewhat of a non-issue myself, and feel that people who don't have 
fortran compilers will look for binaries anyway.

>
> I got an impression from earlier threads that scipy_distutils will be 
> included to scipy_base. So, I am proposing to use scipy_distutils 
> tools and our scipy experience for dealing with this issue, 
> scipy.lib.lapack
> would be a good working prototype here.
>
> Ideally, scipy_base should provide a complete interface to LAPACK 
> routines, but not immidiately, of course. Now, depending on the 
> availability of compilers and resources in a particular computer, the 
> following would happen:
> 1) No Fortran compiler, no lapack libraries in the system, only C 
> compiler is available --- f2c generated lite-lapack C sources are used 
> to build lapack extension module; wrappers to lapack routines, for 
> which there are no f2c generated sources, are disabled by f2py `only:` 
> feature.
> lite-lapack C sources come with scipy_base sources.
> 2) No Fortran compiler, system has lapack libraries (atlas or 
> Accelerate or vecLib), C compiler is available --- system lapack 
> library will be used and a complete lapack extension module can be built.
> 3) Fortran and C compiler are available, no lapack libraries in the 
> system --- Fortran lite-lapack sources are used to build lapack 
> extension module;
> lite-lapack Fortran sources come with scipy_base sources. Similar to 
> the case (1), some wrappers are disabled.
> 4-..) other combinations are possible and users can choose their 
> favorite approach.

Great, Sounds like Pearu has some good ideas here.  I nominate Pearu to 
take the lead here.

Michiel sounds like he? wants to keep the Numeric, RandomArray, 
LinearAlgebra naming conventions forever.  I want them to be more 
coordinated like scipy is doing with scipy.linalg scipy.stats and 
scipy_base ( I agree scipy.base is better).  

What are the opinions of others on this point.   Of course the names 
Numeric, RandomArray, and LinearAlgebra will still work,  but I think 
they should be deprecated in favor of a better overall design for 
numerical packages.    

What do others think?