[SciPy-user] Re: [SciPy-dev] Future directions for SciPy in light of meeting at Berkeley

[Robert Kern]

Bob Ippolito wrote:
> 
> On Mar 9, 2005, at 12:33 PM, Stephen Walton wrote:
> 
>>> 2) Installation problems -- I'm not completely clear on what the 
>>> "installation problems" really are.
>>
>>
>> scipy and matplotlib are both very easy to install.  Using ATLAS is 
>> the biggest pain, as Travis says, and one can do without it.  Now that 
>> a simple 'scipy setup.py bdist_rpm' seems to work reliably, I for one 
>> am happy.
> 
> 
> On Mac OS X, using ATLAS should be pretty trivial because the OS already 
> ships with an optimized implementation!  The patch I created for Numeric 
> was very short, and I'm pretty sure it's on the trunk (though last I 
> packaged it, I had to make a trivial fix or two, which I reported on 
> sourceforge).  I haven't delved into SciPy's source in a really long 
> time, so I'm not sure where changes would need to be made, but I think 
> someone else should be fine to look at Numeric's setup.py and do what 
> needs to be done to SciPy.

Scipy already works just fine with Accelerate. No patch is necessary. 
However, the ATLAS provided in the Accelerate framework is incomplete. 
Namely, it's missing the row-major versions of BLAS and the optimized 
LAPACK routines. Scipy does make good use of these *if* they are 
available, and the availability of these routines can be quite important 
(if you are doing heavy linear algebra, of course, if you Just Need It 
To Build, then Accelerate is the way to go).

> FYI, matplotlib, the optimized Numeric, and several other Mac OS X 
> packages are available in binary form here:
> http://pythonmac.org/packages/
> 
>> I think splitting scipy up into multiple subpackages isn't such a good 
>> idea.  Perhaps I'm in the minority, but I find CPAN counter-intuitive, 
>> hard to use, and hard to keep track of in an RPM-based environment.  
>> Any large package is going to include a lot of stuff most people don't 
>> need, but like a NY Times ad used to say, "You might not read it all, 
>> but isn't it nice to know it's all there?"
> 
> 
> I also think that a monolithic package is a pretty good idea until it 
> begins to cause problems with the release cycle.  Twisted had this 
> problem at 1.3, and went through a major refactoring between then and 
> 2.0 (which is almost out the door).  Though Twisted 2.0 is technically 
> many different packages, they still plan on maintaining a "sumo" package 
> that includes all of the Twisted components, plus zope.interface (the 
> only required dependency).  There are still several optional 
> dependencies not included, though (such as PyCrypto).
> 
> SciPy could go this route, and simply market the "sumo" package to 
> anyone who doesn't already know what they're doing.  An experienced 
> SciPy user may want to upgrade one particular component of SciPy as 
> early as possible, but leave the rest be, for example.

The Twisted re-org is something I think we should look at. There seem to 
be reference to using zpkgtools to handle the split, but I can't find 
any of the data files that are referenced in the build scripts. Does 
anyone more familiar with the Twisted re-org care to chime in?

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter