Scientific Libraries in Python

[Fernando Pérez]

Chris Barker wrote:

> Nice Summary of the state of the art:

Thanks.

>> Visualization:
> 
> I agree that Visulisation is key. You didn't mention it here, but the
> problem I have with most of the available stuff is that it is all
> wrappers around other external packages. To really get what I want, I
> need to be able to access the primitives form Python. That means a lot
> of the code should probalby be in Python, or at least written with this
> kind if access in mind.
> 
> I've been imagining a package built in Python that looks a lot like
> MATLAB's handle graphics (although with OO, you wouldn't need the
> handles). MATLAB's system makes it very easy to whip out a plot:
> 
> plot(x,y)
> 
> but you can also get access to all the properties of the plot, so that
> you can customise things as much as you like. I think all plots are
> created by a set of only three types of primitives, a line, a patch
> (surface), and a text object. It really works pretty well. I also
> believe that all plots are 3-d with 2-d plots being a special casse,
> where z=0 everywhere, and the view is from the top.

I was trying to keep that post tightly focused to a summary, but I agree 100% 
with you. In fact, in a previous post on the same thread, this is what I had 
said:

<quote>
3) A true visualization framework, which has both high-level plotting 
routines and access to basic primitives. Mathematica's plotting system, while 

not the most convenient to use, is a good example of this idea. You can just 
'plot' stuff, but you also have low-level access to the graphing primitives 
to program more complex stuff yourself.
</quote>


> Anyway, it's a pretty nifty system, and I think one like ot for Python
> would be great. The Graphite project (http://Graphite.sourceforge.net/)
> was a nice start to this, and I think the native SciPy one looks pretty
> promising as well.

I didn't mention graphite b/c it seems dead. I know Mayavi is active, it's 
based on a high caliber underlying toolkit (vtk) and it looks very nice. I 
think  the underlying toolkit *has* to be written in C/C++. Volume rendering 
for large datasets is just way too intensive a task to be done in an 
interpreted language. But a well designed Python interface can provide low 
enough level access to be useful for programming while offering high-level 
functions for interactive use.

> My main feeling is that we really do need something native to Python. A
> wrapper around an external package will never be flexible enough to
> really compete withe MATLAB or IDL.
> 
>> MayaVi at http://mayavi.sourceforge.net
>> -----

> 
> I agree.  framework like what I suggest above, built on top of MayaVi,
> or directly on VTK, or even more directly on OpenGL, would be great!!

I tend to think mayavi has the right approach: OpenGl is too low-level. The 
vtk people have already done a lot of *very hard* work. It would be silly to 
ignore that, IMO. And from a recent post from mayavi's author, he seems to be 
working on providing full python access to the system (while also offering 
the gui). I don't want to seem biased, I don't even know the mayavi author 
and have only superficially looked at the stuff. I just have a hunch that 
he's going in the right direction, and that (perhaps with some modifications) 
that's the best bet for the graphical part at this point.

> Another think I'd love to see is a "Scientific Python Distribution" this
> would be all of Scientific Python all packaged up with Python itself,
> all compiled and ready to go (with optimised BLAS, etc) for your
> platform of choice.
> 
> It would also support MacOS, along with *nix and MSW.

Agreed 100%

Well, let's keep it going. I don't like cross-posting and don't really know 
the Numeric and SciPy people, but if someone knows them and is willing to 
drop them a reference of this discussion it might be a good idea to hear what 
they think.

Cheers,

f