Re: Python (was: Re: [PATCH] Add min/max tests. (4/4))

[Edward Jason Riedy]

And "John W. Eaton" writes:
 - 
 - Where have they expressed this interest?

On comp.lang.python.  It's a matter of having time to do it,
and having the patience to battle the n! different fp variations.
It's my next evening project (maybe, I might try decimal 
arithmetic first, just to avoid the I/O).

 - |  * The FFI is nice, expecially from C++.
 - 
 - Sorry, I'm dense.  What is FFI?

Sorry: Foreign Function Interface.  See cxx.sourceforge.net.
Very nice.

 - Now, after some years of experience, I'm not sure that popularity is 
 - a good reason for choosing a language for the long term.  Short term 
 - it is probably OK, but favor for one language over another tends to 
 - shift.

Agreed.  Python is about half-way up the acceptance curve in
general, and some parts of the scientific community have already
accepted it.  I see it as a step towards introducing high-level
language ideas more fully in scientific computing.

 - This will probably change.  The new print>> and op= stuff seems to be
 - making Python less consistent, which usually means trouble.

Yup.  They're adding features when they should be sitting back
to find the easier pieces behind them.  A few lessons from CLOS
(meta-object protocols) and Scheme (extensible syntax) would make 
much of Python suddenly simple again.

 - Related to the problem of these new operators adding complexity is the
 - push from some people for new operators for specific numerical tasks.
 - I'm not sure that is a good idea.

Again, I agree.  I liked one idea that came up on c.l.py:  Have
an embedded language.  It's not too terribly difficult to do in
Python.  Just have statements like
  Matlabish.exec("x = A \ B;")
and do whatever you wan between quotes, just like the regular
expression support in Python.  Also means you can optimize 
temporaries out of expressions like D=A+B+C.

 - What would be nice (IMO) is to be able to easily share data between
 - languages.

MS's .NET.  Unfortunately, they've screwed up the FP support.
Went completely NaN happy...  The resources under 
  http://msdn.microsoft.com/net/
don't really go into enough detail without a big time investment.
I have StarOffice-converted PostScript files of some of the low-
level docs, but they aren't really worth reading if you're not
into compiler intermediate languages.

_Everyone_ seems to be having this idea right now.  Unfortunately,
I don't see very many folks looking at the `right' implementation.
But I'm obviously rather opinionated.

 - As it is, we still seem to be in the one-size-fits-all era of 
 - computer language design.

The pendulum swings back and forth between general purpose
languages and domain specific languages.  It always will.  Each 
learns from the other.  With C++ and Java, we're currently in the 
general purpose regime, but it's swinging back with the `scripting' 
languages and multi-language environments.

 - |  * Introspective enough that I may be able to get a distributed
 - |    version to work.  Maybe.
 - 
 - I'm not sure I understand what you mean by this.

It's pretty easy to grab the bytecode and throw it to another
node.  (The type of thing you get for free in Erlang, think 
you're supposed to get in Java, etc.)

 - | Octave's is a bit too tilted towards Matlab's way of thinking,
 - 
 - Can you be more specific?

Not off the top of my head...  ;)  

It also hurt my head when I started digging through the dMatrix -> 
MArray2<> -> Array2<> -> Array<> hierarchy with all sorts of 
non-virtual member functions that are used different ways in 
different places.  I understand why it was done...  It just 
seems convoluted to me.

 - I also don't want to start a license war, but is the GPL a problem for
 - you now?  If so, how?

Me, personally, not really.  I'm just so sick of all the lawyers
that I'd prefer a new-BSD-style license.  (The only reason I don't 
say public domain is because I'd need to check that disclaimers of
warranty still apply on PD things.)

 - If NumPy were rewritten to use parts of Octave and to avoid some of
 - the mistakes of Matlab, do you think the average Python user would
 - object to parts of it being covered by the GPL?

A few would throw a complete fit, especially with the current
not-GPL-compatible situation.  Personally, I don't mind.  I've 
been bitten by the types of situations the GPL prevents, so I 
certainly understand its worldview.

The code I'm writing has a pluggable system for the dense matrix
pieces so I can use Numpy, pdl, Matlab, Octave, Blitz++, MTL, 
whatever.  Or at least I'm trying to write it that way.  Keeps
changing under me.  sigh...

 - I think we already have some very low level libraries out there
 - (blas, lapack, etc.) and they are generally hard to use.

I consider those easy to use...  I'm also thinking lower level,
not necessarily specific to linear algebra.  Basic array 
manipulations, slicing, etc.  A large amount of Matlab software, 
like the image processing tools, just uses those operations.  
They're the types of things I need inside a sparse matrix routine.  
Well, and GEMM.  I can't really use much more.  I need tiny 
changes to GETRF, etc.

 - Maybe that is why there are not interfaces to these libraries for 
 - all the popular scripting languages.

Um, there are for many.  ;)  Many of the languages I listed have
some package that provides linear algebra, and many of those just
call the BLAS and LAPACK on appropriately packed data.  Even 
Matlab has finally switched to using them.

Jason