matplotlib-devel Mailing List for matplotlib

On Sunday 20 November 2005 5:47 pm, Robert Kern wrote:
> Darren Dale wrote:
> > The last couple of days, I have been thinking about scipy_core's atlas
> > dependency, which might be a big barrier for some. There is this issue
> > with getting the full lapack instead of the truncated version, for
> > example. I don't know how difficult it is to compile atlas, having been
> > screened from the process by gentoo's package manager. The mpl devs have
> > put a lot of effort into making mpl easily accessible to the newbies
> > (remember the backend issues circa 0.50?) so I am concerned about
> > erecting new barriers now. Will scipy_core ever include something like
> > Numeric's lapack_lite?
>
> scipy_core does not depend on ATLAS. It already has lapack_lite.
>
> [svk-projects]$ ls scipy_core/scipy/corelib/lapack_lite
> blas_lite.c dlapack_lite.c f2c_lite.c zlapack_lite.c
> dlamch.c f2c.h lapack_litemodule.c
Interesting. A couple days ago I removed atlas, blas and lapack, removed my 
site.cfg, and was unable to install scipy_core. I'll try again, maybe I did 
something wrong.

>>>>> "Vineet" == Vineet Jain <vi...@al...> writes:
 Vineet> Hi, Do you know where I can get the 0.85 package for
 Vineet> ubuntu. I installed the one in:
 Vineet> http://peds-pc311.bsd.uchicago.edu binary/
 Vineet> but that is an older version.
I just updated the repository -- try updating and then reinstalling.
JDH

Darren Dale wrote:
> The last couple of days, I have been thinking about scipy_core's atlas 
> dependency, which might be a big barrier for some. There is this issue with 
> getting the full lapack instead of the truncated version, for example. I 
> don't know how difficult it is to compile atlas, having been screened from 
> the process by gentoo's package manager. The mpl devs have put a lot of 
> effort into making mpl easily accessible to the newbies (remember the backend 
> issues circa 0.50?) so I am concerned about erecting new barriers now. Will 
> scipy_core ever include something like Numeric's lapack_lite?
scipy_core does not depend on ATLAS. It already has lapack_lite.
[svk-projects]$ ls scipy_core/scipy/corelib/lapack_lite
blas_lite.c dlapack_lite.c f2c_lite.c zlapack_lite.c
dlamch.c f2c.h lapack_litemodule.c
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

On Sunday 20 November 2005 1:55 am, Travis Oliphant wrote:
> John Hunter wrote:
> >Travis, Perry, Todd and I have been
> >discussing the benefits of changing matplotlib to work *only* with the
> >new scipy, which include faster build times, smaller binaries, less
> >complexity and pushing the community to a single array object. Since
> >the new array interface works with Numeric 24, recent numarray or the
> >new scipy, *any* of these array packages would work with a matplotlib
> >compiled just for scipy. We decided to hold off on doing this until
> >scipy installations issues were sorted out even on semi-obscure
> >platforms -- Travis, what's your sense of this?
>
> My sense is that scipy_core installation is working on as many platforms
> as Numeric did. I'd personally love to see matplotlib move to a single
> scipy core build as soon as possible. This would encourage even more
> installation and testing of the new scipy core and help us iron out any
> remaining issues even faster.
>
> However, as long as matplotlib users have a sense that this is the
> direction matplotlib is headed, I see nothing wrong with making a
> release with the 3-supported arrays (especially since somebody has done
> all of the work already :-) ), and then making a release after that
> build only with new scipy core.
>
> Just having the ability to build against new scipy will still encourage
> some to make the transition (and that will help with continued testing).
The last couple of days, I have been thinking about scipy_core's atlas 
dependency, which might be a big barrier for some. There is this issue with 
getting the full lapack instead of the truncated version, for example. I 
don't know how difficult it is to compile atlas, having been screened from 
the process by gentoo's package manager. The mpl devs have put a lot of 
effort into making mpl easily accessible to the newbies (remember the backend 
issues circa 0.50?) so I am concerned about erecting new barriers now. Will 
scipy_core ever include something like Numeric's lapack_lite?
As a staff scientist at a national lab, I will be creating tools to aid our 
users in data visualization and analysis. Some of our projects involve 
extensive outreach efforts, involving gradeschool, highschool, and colleges 
around the country. My collaborators don't care if they are using matlab, 
python or whatever, as long as it is easy to use and they can get their 
analysis done.
I suggest that mpl not commit to requiring scipy *instead* of numeric or 
numarray until scipy_core can be built without external math libraries (like 
numarray and Numeric), and has proved to be a piece of cake to install 
on the major os's/distributions known to be used in this community. For 
example, scipy/distutils is still missing a site.cfg.example. I've been around 
long enough to know about site.cfg from scipy-0.3.2, but even so, when I 
build on Gentoo, I still have to edit system_info.py for new scipy to find 
the blas libraries.
I'm impressed with scipy, and hope the numeric/numarray community will adopt 
it quickly. But I don't want to advocate using MPL as a vehicle to force such 
an adoption prematurely.
Respectfully,
Darren

Hi,
 
Do you know where I can get the 0.85 package for ubuntu. I installed the one
in:
 
http://peds-pc311.bsd.uchicago.edu binary/
 
but that is an older version.
 
Thanks,
 
VJ
 

John Hunter wrote:
.....
> So my inclination is to include your patch now, during a transition
> period, and then move over to a new scipy only build, retaining the
> numerix layer so Numeric, numarray and (new) scipy users can continue
> to use mpl transparently. In particular we need to make sure that
> basemap which uses numarray.ndimage continues to work.
> 
John:
Basemap no longer uses nd_image, I've recoded the interp function in 
pure python, so it should work with scipy_core.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

John Hunter wrote:
>I read over the patch and it looks like you did a very thorough job.
>Thanks! In the near term, this means that mpl would compile three
>shared object files for each of the three array objects for each
>extension module, which of course will increase compile times and
>binary distribution sizes. Travis, Perry, Todd and I have been
>discussing the benefits of changing matplotlib to work *only* with the
>new scipy, which include faster build times, smaller binaries, less
>complexity and pushing the community to a single array object. Since
>the new array interface works with Numeric 24, recent numarray or the
>new scipy, *any* of these array packages would work with a matplotlib
>compiled just for scipy. We decided to hold off on doing this until
>scipy installations issues were sorted out even on semi-obscure
>platforms -- Travis, what's your sense of this?
> 
>
My sense is that scipy_core installation is working on as many platforms 
as Numeric did. I'd personally love to see matplotlib move to a single 
scipy core build as soon as possible. This would encourage even more 
installation and testing of the new scipy core and help us iron out any 
remaining issues even faster. 
However, as long as matplotlib users have a sense that this is the 
direction matplotlib is headed, I see nothing wrong with making a 
release with the 3-supported arrays (especially since somebody has done 
all of the work already :-) ), and then making a release after that 
build only with new scipy core. 
Just having the ability to build against new scipy will still encourage 
some to make the transition (and that will help with continued testing). 
>So my inclination is to include your patch now, during a transition
>period, and then move over to a new scipy only build, retaining the
>numerix layer so Numeric, numarray and (new) scipy users can continue
>to use mpl transparently. In particular we need to make sure that
>basemap which uses numarray.ndimage continues to work.
> 
>
With the patch already submitted, I think this makes a lot of sense. 
I'd still like to encourage people to help us test scipy core, though. 
While you may still find occasional problems (which are typically fixed 
quickly), the system is working quite well. The sooner we can merge to 
one array object, the more we will be able to help each other make it a 
better object, and the sooner we will be able to ease the burden of 
third-party packages that use arrays, and eliminate the need for heroic 
efforts like the numerix layer.
Best regards,
-Travis

I just submitted a patch to add a new non-interactive backend that
produces enhanced metafiles, an OpenOffice and Microsoft Windows
scalable graphics format that can also be embedded in .rtf files.
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1361839&group_=
id=3D80706&atid=3D560722
The backend is based on my pyemf package that I finally released with
its first public beta:
http://pyemf.sourceforge.net
The API should be stable -- I'm only planning on adding to it and not
changing any existing method signatures in the version 2.0.* series.
Oh, and I didn't say so in the patch itself, but I'm happy to donate
the patch to matplotlib under the default matplotlib license.
Rob