numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] Meta: too many numerical libraries doing the same thing?

[Rob <eu...@ho...>]

I'm currently testing the SciPy Blitz++ features with FDTD.  Should have
some comparisons soon.  Right now my statements are compiling, but not
giving the right answers :(   I think they might have it fixed soon.  
Rob.



Chris Barker wrote:
> 
> Konrad Hinsen wrote:
> > Chris Barker <chr...@ho...> writes:
> > > On another note, it looks like the blitz++ library might be a good basis
> > > for a general Numerical library (and NumPy 3)  as well. It does come
> > > with a flexible license. Any thoughts?
> 
> > I think the major question is whether we are willing to move to C++.
> > And if we want to keep up any pretentions for Numeric becoming part of
> > the Python core, this translates into whether Guido will accept C++
> > code in the Python core.
> 
> Actually, It's worse than that. Blitz++ makes heavy use of templates,
> and thus only works with compilers that support that well. The current
> Python core can compile under a very wide variety of compilers. I doubt
> that Guido would want to change that.
> 
> Personally, I'm torn. I would very much like to see NumPy arrays become
> part of the core Python, but don't want to have to compromise what it
> could be to do that. Another idea is to extend the SciPy project to
> become a complete Python distribution, that would clearly include
> Numeric. One download, and you have all you need.
> 
> > >From a more pragmatic point of view, I wonder what the implications
> > for efficiency would be. C++ used to be very different in their
> > optimization abilities, is that still the case? Even more
> > pragmatically, is blitz++ reasonably efficient with g++?
> 
> I know g++ is supported (and I think it is their primary development
> platform). From the web site:
> 
> Is there a way to soup up C++ so that we can keep the advanced language
> features but ditch the poor performance? This is the goal of the
> Blitz++ project: to develop techniques which will enable C++ to rival --
> and in some cases even exceed -- the speed of Fortran for numerical
> computing, while preserving an object-oriented interface. The Blitz++
> Numerical Library is being constructed as a testbed for these
> techniques.
> 
> Recent benchmarks show C++ encroaching steadily on Fortran's
> high-performance monopoly, and for some benchmarks, C++ is even faster
> than Fortran! These results are being obtained not through better
> optimizing compilers, preprocessors, or language extensions, but through
> the
> use of template techniques. By using templates cleverly, optimizations
> such as loop fusion, unrolling, tiling, and algorithm specialization can
> be
> performed automatically at compile time.
> 
> see: http://www.oonumerics.org/blitz/whatis.html for more info.
> 
> I havn't messed with it myself, but from the web page, it seems the
> answer is yes, C++ can produce high performance code.
> 
> --
> Christopher Barker,
> Ph.D.
> Chr...@ho...                 ---           ---           ---
> http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
>                                    ------@@@     ------@@@     ------@@@
> Oil Spill Modeling                ------   @    ------   @   ------   @
> Water Resources Engineering       -------      ---------     --------
> Coastal and Fluvial Hydrodynamics --------------------------------------
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

-- 
The Numeric Python EM Project

www.members.home.net/europax

[Numpy-discussion] Re: Numpy2 and GSL

[Jochen <jo...@jo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 26 Nov 2001 08:21:40 +0100 Martin Wiechert wrote:

Martin> Are there any plans to wrap GSL for Numpy2?
Martin> I did not actually try it (It's not Python ;-)),
Martin> but it looks clean and powerful.

There is actually a project to wrap gsl for python:
  http://pygsl.sourceforge.net/
It only provides wrapper for the special functions, but more is to
come. (Hopefully Achim will put the cvs on sf soon.)

Yes, I agree, PyGSL should be fully integrated with Numpy2, but it
should probably also remain a separate project -- as Numpy should stay
a base layer for all kind of numerical stuff and hopefully make it
into core python at some point (my personal wish, no more, AFAICT!).

I think when PyGSL will fully go to SF (or anything similar) more
people would start contributing and we should have a fine general
numerical algorithms library for python soon!

Greetings,
Jochen
- -- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: 44BCCD8E
        Sex, drugs and rock-n-roll
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt and GnuPG <http://www.gnupg.org/>

iD8DBQE8At88iJ/aUUS8zY4RAikdAJ9184yaCSH+GtkDz2mLVlrSh7mjEQCdGSqA
2uhmBKRCFBb9eeq3gmmn9/Q=
=64gm
-----END PGP SIGNATURE-----

Re: [Numpy-discussion] Meta: too many numerical libraries doing thesame thing?

[Chris B. <chr...@ho...>]

Travis Oliphant wrote:

> I believe that Eric's "compiler" module included in SciPy uses Blitz++ to
> optimize Numeric expressions.  You have others who also share your
> admiration of Blitz++

Yes, it does. That's where I heard about it. That also brings up a good
point. Paul mentioned that using something like Blitz++ would only help
performance if you could pass it an entire expression, like: x =
a+b+c+d. That is exactly what Eric's compiler module does, and it would
sure be easier if NumPy already used Blitz++! In Fact, I suppose Eric's
compiler is a start towards a tool that could comp9le en entire NumPy
function or module. I'd love to be able to just do that (with some
tweeking perhaps) rather than having to code it all by hand.

My fantasies continue...

-Chris


-- 
Christopher Barker,
Ph.D.                                                           
Chr...@ho...                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------

Re: [Numpy-discussion] Meta: too many numerical libraries doing the same thing?

[Travis O. <oli...@ee...>]

> In a sentence: the most important reason for using a C++ object oriented
> multi-dimensional array package would be easy of use, not speed.
>
> It's nice to hear Blitz++ was considered, it was proably rejected for
> good reason, but it just looked very promising to me.

I believe that Eric's "compiler" module included in SciPy uses Blitz++ to
optimize Numeric expressions.  You have others who also share your
admiration of Blitz++

-Travis

Re: [Numpy-discussion] Meta: too many numerical libraries doing the same thing?

[Chris B. <chr...@ho...>]

"Paul F. Dubois" wrote:

> We had some meetings to discuss using blitz and the truth is that as
> wrapped by Python there is not much to gain. The efficiency of blitz
> comes up when you do an array expression in C++. Then x = y + z + w + a
> + b gets compiled into one loop with no temporary objects created. But
> this trick is possible because you can bind the assignment. In python
> you cannot bind the assignment so you cannot do a lazy evaluation of the
> operations, unless you are willing to go with some sort of function call
> like x = evaluate(y + z + w). Immediate evaluations means creating
> temporaries, and performance is dead.
> 
> The only gain then would be when you passed a Python-wrapped blitz array
> back to C++ and did a bunch of operations there.

Personally, I think this could be a big gain. At the moment, if you
don't get the performance you need with NumPy, you have to write some of
your code in C, and using the Numeric and Python C API is a whole lot of
work, particularly if you want your function to work on non-contiguous
arrays and/or arrays of any type. I don't know much C++, and I have no
idea if Blitz++ fits this bill, but it seemed to me that using an object
oriented framework that could take care of reference counting, and allow
you to work with generic arrays, and index them naturally, etc, would be
a great improvement, even if the performance was the same as the current
C API. Perhaps NumPy2 has accomplished that, it sounds like it is a step
in the right direction, at least.

In a sentence: the most important reason for using a C++ object oriented
multi-dimensional array package would be easy of use, not speed.

It's nice to hear Blitz++ was considered, it was proably rejected for
good reason, but it just looked very promising to me.

-Chris








-- 
Christopher Barker,
Ph.D.                                                           
Chr...@ho...                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------

[Numpy-discussion] Re: Re-implementation of Python Numerical arrays (Numeric) available for download

[Perry G. <pe...@st...>]

> From: Chris Barker <chr...@ho...>
> To: Perry Greenfield <pe...@st...>, 
> num...@li...
> Subject: [Numpy-discussion] Re: Re-implementation of Python 
> Numerical arrays (Numeric) available
>  for  download
> 
> I used Poor wording. When I wrote "datatypes", I meant data types in a
> much higher order sense. Perhaps structures or classes would be a better
> term. What I mean is that is should be easy to use an manipulate the
> same multidimensional arrays from both Python and C/C++. In the current
> Numeric, most folks generate a contiguous array, and then just use the
> array->data pointer to get what is essentially a C array. That's fine if
> you are using it in a traditional C way, with fixed dimension, one
> datatype, etc. What I'm imagining is having an object in C or C++ that
> could be easily used as a multidimentional array. I'm thinking C++ would
> probably neccesary, and probably templates as well, which is why blitz++
> looked promising. Of course, blitz++ only compiles with a few up-to-date
> compilers, so you'd never get it into the standard library that way!
> 
Yes, that was an important issue (C++ and the Python Standard Library).
And yes, it is not terribly convenient to access multi-dimensional
arrays in C (of varying sizes). We don't solve that problem in the
way a C++ library could. But I suppose that some might say that C++
libraries may introduce their own, new problems. But coming up with
the one solution to all scientific computing appears well beyond our
grasp at the moment. If someone does see that solution, let us know!

> I agree, but from the newsgroup, it is clear that a lot of folks are
> very reluctant to use something that is not part of the standard
> library.
>
We agree that getting into the standard library is important.
 
> > > >    We estimate
> > > >    that numarray is probably another order of magnitude worse,
> > > >    i.e., that 20K element arrays are at half the asymptotic
> > > >    speed. How much should this be improved?
> > >
> > > A lot. I use arrays smaller than that most of the time!
> > >
> > What is good enough? As fast as current Numeric?
> 
> As fast as current Numeric would be "good enough" for me. It would be a
> shame to go backwards in performance!
> 
> > (IDL does much
> > better than that for example).
> 
> My personal benchmark is MATLAB, which I imagine is similar to IDL in
> performance.
> 
We'll see if we can match current performance (or at least present usable
alternative approaches that are faster).

> > 10 element arrays will never be
> > close to C speed in any array based language embedded in an
> > interpreted environment.
> 
> Well, sure, I'm not expecting that
> 
Good :-)

> > 100, maybe, but will be very hard.
> > 1000 should be possible with some work.
> 
> I suppose MATLAB has it easier, as all arrays are doubles, and, (untill
> recently anyway), all variable where arrays, and all arrays were 2-d.
> NumPy is a lot more flexible that that. Is is the type and size checking
> that takes the time?
>  
Probably, but we haven't started serious benchmarking yet so I wouldn't
put much stock in what I say now.

 
> One of the things I do a lot with are coordinates of points and
> polygons. Sets if points I can handle easily as an NX2 array, but
> polygons don't work so well, as each polgon has a different number of
> points, so I use a list of arrays, which I have to loop over. Each
> polygon can have from about 10 to thousands of points (mostly 10-20,
> however). One way I have dealt with this is to store a polygon set as a
> large array of all the points, and another array with the indexes of the
> start and end of each polygon. That way I can transform the coordinates
> of all the polygons in one operation. It works OK, but sometimes it is
> more useful to have them in a sequence. 
> 
This is a good example of an ensemble of variable sized arrays.

> > As mentioned,
> > we tend to deal with large data sets and so I don't think we have
> > a lot of such examples ourselves.
> 
> I know large datasets were one of your driving factors, but I really
> don't want to make performance on smaller datasets secondary.
> 
> -- 
> Christopher Barker,

That's why we are asking, and it seems so far that there are enough
of those that do care about small arrays to spend the effort to
significantly improve the performance.

Perry

Re: [Numpy-discussion] Meta: too many numerical libraries doing the same thing?

[Konrad H. <hi...@cn...>]

> We had some meetings to discuss using blitz and the truth is that as
> wrapped by Python there is not much to gain. The efficiency of blitz
> comes up when you do an array expression in C++. Then x = y + z + w + a
> + b gets compiled into one loop with no temporary objects created. But

That could still be of interest to extension module writers. And it
seems conceivable to write some limited Python-C compiler for
numerical expressions that generates extension modules, although this
is more than a weekend project.

Still, I agree that what most people care about is the speed of NumPy
operations. Some lazy evaluation scheme might be more promising to
eliminate the creation of intermediate objects, but that isn't exactly
trivial either...

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] Meta: too many numerical libraries doing the same thing?

[Chris B. <chr...@ho...>]

Konrad Hinsen wrote:
> Chris Barker <chr...@ho...> writes:
> > On another note, it looks like the blitz++ library might be a good basis
> > for a general Numerical library (and NumPy 3)  as well. It does come
> > with a flexible license. Any thoughts?

> I think the major question is whether we are willing to move to C++.
> And if we want to keep up any pretentions for Numeric becoming part of
> the Python core, this translates into whether Guido will accept C++
> code in the Python core.

Actually, It's worse than that. Blitz++ makes heavy use of templates,
and thus only works with compilers that support that well. The current
Python core can compile under a very wide variety of compilers. I doubt
that Guido would want to change that.

Personally, I'm torn. I would very much like to see NumPy arrays become
part of the core Python, but don't want to have to compromise what it
could be to do that. Another idea is to extend the SciPy project to
become a complete Python distribution, that would clearly include
Numeric. One download, and you have all you need.

> >From a more pragmatic point of view, I wonder what the implications
> for efficiency would be. C++ used to be very different in their
> optimization abilities, is that still the case? Even more
> pragmatically, is blitz++ reasonably efficient with g++?

I know g++ is supported (and I think it is their primary development
platform). From the web site:

Is there a way to soup up C++ so that we can keep the advanced language
features but ditch the poor performance? This is the goal of the
Blitz++ project: to develop techniques which will enable C++ to rival --
and in some cases even exceed -- the speed of Fortran for numerical
computing, while preserving an object-oriented interface. The Blitz++
Numerical Library is being constructed as a testbed for these
techniques.

Recent benchmarks show C++ encroaching steadily on Fortran's
high-performance monopoly, and for some benchmarks, C++ is even faster
than Fortran! These results are being obtained not through better
optimizing compilers, preprocessors, or language extensions, but through
the
use of template techniques. By using templates cleverly, optimizations
such as loop fusion, unrolling, tiling, and algorithm specialization can
be
performed automatically at compile time.

see: http://www.oonumerics.org/blitz/whatis.html for more info.

I havn't messed with it myself, but from the web page, it seems the
answer is yes, C++ can produce high performance code.






-- 
Christopher Barker,
Ph.D.                                                           
Chr...@ho...                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------

Re: [Numpy-discussion] Meta: too many numerical libraries doing the same thing?

[Konrad H. <hi...@cn...>]

Chris Barker <chr...@ho...> writes:

> On another note, it looks like the blitz++ library might be a good basis
> for a general Numerical library (and NumPy 3)  as well. It does come
> with a flexible license. Any thoughts?

I think the major question is whether we are willing to move to C++.
And if we want to keep up any pretentions for Numeric becoming part of
the Python core, this translates into whether Guido will accept C++
code in the Python core.

From a more pragmatic point of view, I wonder what the implications
for efficiency would be. C++ used to be very different in their
optimization abilities, is that still the case? Even more
pragmatically, is blitz++ reasonably efficient with g++?

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] Meta: too many numerical libraries doing the same thing?

[Chris B. <chr...@ho...>]

Another factor that complicates things is open source philosophy and the
licenses that go with it.

The GSL project looks very promising, and the ultimate goals of that
project appear to be to create a coherent and complete numerical
library. This kind of thing NEEDS to be open source, and the GSL folks
have chosen a license (GPL) that guarantees that it remains that way.
That is a good thing. The license also make it impossible to use the
library in closed source projects, which is a deal killer for a lot of
people, but it is also an important attribute for many folks that don't
think there should be closed source projects at all. I believe that that
will greatly stifle the potential of the project, but it fits with the
philosophy iof it's creators. Personally I think the LGPL would have
guaranteed the future openness of the source, and allowed a much greater
user (and therefor contributer) base.

BTW, IANAL either, but my reading of the GPL and Python's "GPL
compatable" license, is that GSL could be used with Python, but the
result would have to be released under the GPL. That means it could not
be imbedded in a closed source project. As a rule, Python itself and
most of the libraries I have seen for it (Numeric, wxPython, etc.) are
released under licences that allow propriatary use, so we probably don't
want to make Numeric, or SciPy GPL. too bad. 

On another note, it looks like the blitz++ library might be a good basis
for a general Numerical library (and NumPy 3)  as well. It does come
with a flexible license. Any thoughts?


-Chris







-- 
Christopher Barker,
Ph.D.                                                           
Chr...@ho...                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------

Re: [Numpy-discussion] Augmented matrix

[Konrad H. <hi...@cn...>]

Nils Wagner <nw...@me...> writes:

> How can I build an augmented matrix [A,b] in Numpy,
> where A is a m * n matrix (m>n) and b is a m*1 vector

AB = concatenate((A, b[:, NewAxis]), -1)

(assuming b is of rank 1)

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

[Numpy-discussion] Augmented matrix

[Nils W. <nw...@me...>]

Hi,

How can I build an augmented matrix [A,b] in Numpy,
where A is a m * n matrix (m>n) and b is a m*1 vector

Nils

Re: [Numpy-discussion] Sort , Complex array

[Gerard V. <gve...@la...>]

On Monday 26 November 2001 11:53, Nils Wagner wrote:
> Hi,
>
> How can I sort an array of complex eigenvalues with respect to the
> imaginary part
> (in ascending order) in Numpy ?
> All eigenvalues appear in complex cunjugate pairs.
>
> Nils
>

I have solved that like this:
>>> from Numeric import *
>>> a = array([3+3j, 1+1j, 2+2j])
>>> b = a.imag
>>> print take(a, argsort(b))
[ 1.+1.j  2.+2.j  3.+3.j]
>>>

Best regards -- Gerard

Re: [Numpy-discussion] Sort , Complex array

[Konrad H. <hi...@cn...>]

Nils Wagner <nw...@me...> writes:

> How can I sort an array of complex eigenvalues with respect to the
> imaginary part
> (in ascending order) in Numpy ?
> All eigenvalues appear in complex cunjugate pairs.

indices = argsort(eigenvalues.imag)
eigenvalues = take(eigenvalues, indices)

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

[Numpy-discussion] Sort , Complex array

[Nils W. <nw...@me...>]

Hi,

How can I sort an array of complex eigenvalues with respect to the
imaginary part
(in ascending order) in Numpy ?
All eigenvalues appear in complex cunjugate pairs.

Nils

Re: [Numpy-discussion] Re-implementation of Python Numerical arrays (Numeric) available for download

[Tim H. <tim...@ie...>]

From: "Paul Barrett" <Ba...@st...>


> Perry Greenfield wrote:
>
> >
> > An early beta version is available on sourceforge as the
> > package Numarray (http://sourceforge.net/projects/numpy/)
> >
> > Information on the goals, changes in user interface, open issues,
> > and design can be found at http://aten.stsci.edu/numarray
>
>
>   6) Should array properties be accessible as public attributes
>     instead of through accessor methods?
>
>     We don't currently allow public array attributes to make
>     the Python code simpler and faster (otherwise we will
>     be forced to use __setattr__ and such). This results in
>     incompatibilty with previous code that uses such attributes.
>
>
> I prefer the use of public attributes over accessor methods.

As do I. As of Python 2.2, __getattr__/__setattr__ should not be required
anyway: new style classes allow this to be done in a more pleasent way. (I'm
still too fuzzy on the details to describe it coherently here though).

-tim

Re: [Numpy-discussion] Meta: too many numerical libraries doing the same thing?

[Konrad H. <hi...@cn...>]

"Christos Siopis <si...@um...>" <si...@um...> writes:

> Don't take me wrong, i am not saying that Numpy, PDL, GSL & co. should be
> somehow "merged" --obviously, one needs different wrappers to call
> numerical routines from Python, Perl, C, C++ or Java. But there should be
> a way so that the actual *implementation* of the numerical algorithms is
> only done once and for all.

I agree that sounds nice in theory. But even if it were technically
feasible (which I doubt) given the language differences, it would be a
development project that is simply too big for scientists to handle as
a side job, even if they were willing (which again I doubt).

My impression is that the organizational aspects of software
development are often neglected. Some people are good programmers but
can't work well in teams. Others can work in teams, but are not good
coordinators. A big project requires at least one, if not several,
people who are good scientist and programmers, have coordinator
skills, and a job description that permits them to take up the task.
Plus a larger number of people who are good scientists and programmers
and can work in teams. Finally, all of these have to agree on
languages, design principles, etc.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

RE: [Numpy-discussion] Re: Meta: too many numerical libraries doing the same thing?

[Paul F. D. <pa...@pf...>]

There is more to this issue than meets the eye, both technically and
historically.

For numerical algorithms to be available independent of language, they
would have to be packaged as components such as COM objects. While there
is research in this field, nobody knows whether it can be done is a way
that is efficient enough.

For a given language like C, C++, Eiffel or Fortran used as the
speed-demon base for wrapping up in Python, there are some difficult
technical issues. Reusable numerical software needs context to operate
and there is no decent way to supply the context in a
non-object-oriented language. Geoff Furnish wrote a good paper about the
issue for C++ showing the way to truly reusable libraries in that
language, and recent improvements in Eiffel make it easier to do there
now. In C or Fortran you simply can't do it. (Note that Eiffel or C++
versions of some NAG routines typically have methods with one or two
arguments while the C or Fortran ones have 15 or more; a routine is not
reusable if you have to understand that many arguments to try it. There
are also important issue with regard to error handling and memory).

The second issue is the algorithmic issue: most scientists do NOT know
the right algorithms to use, and the ones they do use are often
inferior. The good algorithms are for the most part in commercial
libraries, and the numerical analysis literature, where they were
written by numerical analysts. Often the coding from both sources is
unavailable for free use, in the wrong language, and/or wretched.

The commerical libraries also exist because some companies have
requirements for fiduciary responsibility; in effect, they need a
guarantor of the software to show that they have not carelessly depended
on software of unknown quality. 

In short, computer scientists are not going to be able to write such a
library without an army of numerical analysts familiar with the
literature, and the numerical analysts aren't going to write it unless
they are OO-experienced, which almost all of them aren't, so far.

Most people when they discuss mathematical software think of leaves on
the call tree. In fact the most useful mathematical software, in the
sense that it incorporates the most expertise, is middleware such as ODE
solvers, integrators, root finders, etc. The algorithm itself will have
many controls, optional outputs, etc. This requires a library-wide
design motif.

I thus feel there are perfectly good reasons not to expect such a
library soon. The Python community could do a good OO-design using what
is available (such as LAPACK) but we haven't -- all the contributions
are functional.

[Numpy-discussion] Re: Meta: too many numerical libraries doing the same thing?

[Joe H. <jh...@oo...>]

Yes, this issue has been raised here before.  It was the main
conclusion of Paul Barrett's and my BOF session at ADASS a 5 years ago
(see our report at
http://oobleck.astro.cornell.edu/jh/ast/papers/idae96.ps).  The main
problems are that we scientists are too individualistic to get
organized around a single library, too pushed by job pressures to
commit much concentrated time to it ourselves, and too poor to pay the
architects, coders, doc writers, testers, etc. to write it for us.
Socially, we *want* to reinvent the wheel, because we want to be
riding on our own wheels.  Once we are riding reasonably well for our
own needs, our interest and commitment vanishes.  We're off to write
the next paper.

Following that conference, I took a poll on this list looking for help
to implement the library.  About half a dozen people responded that
they could put in up to 10 hours a week, which in my experience isn't
enough, once things get hard and attrition sets in.  Nonetheless, Paul
and I proposed to the NASA Astrophysics Data Analysis Program to hire
some people to write it, but we were turned down.  We proposed the
idea to the head of the High Energy Astrophysics group at NASA
Goddard, and he agreed -- as long as what we were really doing was
writing software for his group's special needs.  The frustrating thing
is how many hundreds of astronomy projects hire people to do their 10%
of this problem, and how unwilling they are to pool resources to do
the general problem.

A few of the volunteers in my query to this list have gone on to do
SciPy, to their credit, but I don't see them moving in the direction
we outlined.  Still, they have the capacity to do it right in Python
and compiled code written explicitly for Python.  They won't solve the
general problem, but they may solve the first problem, namely getting
a data analysis environment that is OSS and as good as IDL et al. in
terms of end-to-end functionality, completeness, and documentation.

I like the notion that the present list is for designing and building
the underlying language capabilities into Python, and for getting them
standardized, tested, and included in the main Python distribution.
It is also a good place for debating the merits of different
implementations of particular functionality.  That leaves the job of
building coherent end-user data analysis packages (which necessarily
have to pick one routine to be called "fft", one device-independent
graphics subsystem, etc.) to application groups like SciPy.  There can
be more than one of these, if that's necessary, but they should all
use the same underlying numerical language capability.

I hope that the application groups from several array-based OSS
languages will someday get together and collaborate on an ueberlibrary
of numerical and graphics routines (the latter being the real sticking
point) that are easily wrapped by most languages.  That seems
backwards, but I think the social reality is that that's the way it is
going to be, if it ever happens at all.

--jh--

[Numpy-discussion] Meta: too many numerical libraries doing the same thing?

[Christos S. <si...@um...>]

[ This message got longer than i had initially thought, but these thoughts 
  have been bugging me for so long that i cannot resist the temptation to 
  push the send button! Apologies in advance to those not interested...
]

On Mon, 26 Nov 2001, Martin Wiechert wrote:

> Hi!
> 
> Just an uneducated question.
> Are there any plans to wrap GSL for Numpy2?
> I did not actually try it (It's not Python ;-)),
> but it looks clean and powerful.
> 
> Regards,
> Martin.

I actually think that this question has come up before in this list,
perhaps more than once. And i think it brings up a bigger issue, which is:  
to what extent is it useful for the numerical community to have multiple
numerical libraries, and to what extent does this constitute a waste of
resources?

Numpy (Python), PDL (Perl), GSL (C), and a rather large number of other
libraries usually have to re-implement the same old numerical algorithms,
but offered under a different interface each time. However, there is such
a big body of numerical algorithms out there that it's a daunting effort
to integrate them into every language's numerical library (anyone want to
implement LAPACK's functionality in Numpy?) The compromise that is usually
made is to wrap one library around another. While this may be "better than
nothing", it is usually not a pleasant situation as it leads to
inconsistencies in the interface, inconsistencies in the error handling,
difficulties in the installation, problems with licensing,...

Since i have been a beneficiary rather than a contributor to the numerical
open-source community, i feel somewhat hesitant to file this "complaint",
but i really do think that there are relatively few people out there who
are both willing and capable of building quality open-source numerical
software, while there are too many algorithms to implement, so the
community should be vigilant to minimize waste of resources!

Don't take me wrong, i am not saying that Numpy, PDL, GSL & co. should be
somehow "merged" --obviously, one needs different wrappers to call
numerical routines from Python, Perl, C, C++ or Java. But there should be
a way so that the actual *implementation* of the numerical algorithms is
only done once and for all.

So what i envision, in some sense, is a super-library of "all"/as many as
possible numerical algorithms, which will present appropriate (but
consistent) APIs for different programming languages, so that no matter
what language i use, i can expect consistent interface, consistent
numerical behavior, consistent error handling etc. Furthermore, different
levels of access should allow the application developer to access
low-level or high-level routines as needed (and could object orientation
be efficiently built as a higher-level wrapper?)

This way, the programmer won't have to worry whether the secant root
finder that s/he is using handles exceptions well or how NaNs are treated.
Perhaps most importantly, people would feel compelled to go into the pain
of "translating" existing libraries such as LAPACK into this common
framework, because they will know that this will benefit the entire
community and won't go away when the next scripting language du jour
eclipses their current favorite. Over time, this may lead to a truly
precious resource for the numerical community.

Now, i do realize that this may sound like a "holy grail" of numerical
computing, that it is something which is very difficult, if not impossible
to accomplish. It certainly does not seem like a project that the next
ambitious programmer or lab group would want to embark into on a rainy
day. Rather, it would require a number of important requirements and
architectural decisions to be made first, and trade-offs considered. This
would perhaps be best coordinated by the numerical community at large,
perhaps under the auspices of some organization. But this would be time
well-spent, for it would form the foundations on which a truly universal
numerical library could be built. Experience gained from all the numerical
projects to this day would obviously be invaluable in such an endeavor.

I suspect that this list may not be the best place to discuss such a
topic, but i think that some of the most active people in the field lurk
here, and i would love to hear their thoughts and understand why i am
wrong :) If there is a more appropriate forum to discuss such issues, i
would be glad to be pointed to it --in which case, please disregard this
posting!

***************************************************************
/  Christos Siopis              | Tel    : 734-764-3440       \
/  Postdoctoral Research Fellow |                             \
/  Department of Astronomy      | FAX    : 734-763-6317       \
/  University of Michigan       |                             \
/  Ann Arbor, MI 48109-1090     | E-mail : si...@um...   \
/  U.S.A.  _____________________|                             \
/         / http://www.astro.lsa.umich.edu/People/siopis.html \
***************************************************************

RE: [Numpy-discussion] Numeric & changes in Python division

[Paul F. D. <pa...@pf...>]

You know what the doctor said: if it hurts when you do that, don't do
that.

Seriously, I have not the slightest idea what you're doing here. My
project won't get to 2.2 until well into the new year. Especially if
stuff like this has to be fixed. I haven't even read most of the 2.2
changes.

I understand this is also an issue with CXX. Barry Scott runs CXX now
since I am no longer in a job where I use C++. When he will get to this
I don't know. I need to demote myself on the CXX website.

You haven't seen any recent changes to Numpy, or comments from me on
numarray, because I have a release to get out at my job.


-----Original Message-----
From: num...@li...
[mailto:num...@li...] On Behalf Of
Edward C. Jones
Sent: Thursday, November 22, 2001 5:33 PM
To: num...@li...
Subject: [Numpy-discussion] Numeric & changes in Python division


# Python 2.2b1, Numeric 20.2.0

from __future__ import division
import Numeric

arr = Numeric.ones((2,2), 'f')
arr = arr/2.0

#Traceback (most recent call last):
#  File "bug.py", line 6, in ?
#arr = arr/2.0
#TypeError: unsupported operand type(s) for /



_______________________________________________
Numpy-discussion mailing list Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] Numeric & changes in Python division

[Edward C. J. <edc...@er...>]

# Python 2.2b1, Numeric 20.2.0

from __future__ import division
import Numeric

arr = Numeric.ones((2,2), 'f')
arr = arr/2.0

#Traceback (most recent call last):
#  File "bug.py", line 6, in ?
#arr = arr/2.0
#TypeError: unsupported operand type(s) for /

Re: [Numpy-discussion] Numpy2 and GSL

[Konrad H. <hi...@cn...>]

Martin Wiechert <mar...@gm...> writes:

> Are there any plans to wrap GSL for Numpy2?
> I did not actually try it (It's not Python ;-)),
> but it looks clean and powerful.

I have heard that several projects decided not to use it for legal
reasons; GSL is GPL, not LGPL. Personally I don't see the problem for
Python/NumPy, but then I am not a lawyer...  And I haven't used GSL
either, but it looks good from the description.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

[Numpy-discussion] Numpy2 and GSL

[Martin W. <mar...@gm...>]

Hi!

Just an uneducated question.
Are there any plans to wrap GSL for Numpy2?
I did not actually try it (It's not Python ;-)),
but it looks clean and powerful.

Regards,
Martin.

[Numpy-discussion] Numpy for FORTRAN users

[Nils W. <nw...@me...>]

Hi,

Currently users must be aware of the fact that multi-dimensional
arrays are stored differently in Python and Fortran.

Is there any progress that users do not need to worry about this 
rather confusing and technical detail ?

Nils