On Jan 21, 10:25 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Jan 21, 2009, at 3:34 PM, rjf wrote:
>
>
>
> > On Jan 21, 11:54 am, Robert Bradshaw <rober...@math.washington.edu>
... snip...
>  In our case, linear  
> algebra is done via NumPy, which in turn uses a BLAS (with Sage we  
> ship ATLAS). On the other hand, if one is doing a problem that isn't  
> easily phrased as a linear algebra/differential equations/etc.  

Sure, calling a library program from Python can be a good way to
achieve efficiency, but that is not an argument that Python is good
for scientific computing. It is an argument that it is good for
scripting, or "glue" or something along those lines.

> question for which there is already an optimized library/code, that's  
> where Cython comes in, where one can compile code that operates on C  
> doubles directly (and, because it compiles down to C, is just as  
> efficient).

This is unconvincing.   Maxima code can be translated to Lisp (by a
command called "translate").
The Lisp (if Maxima is running in GCL) can be compiled  (by a command
called "compile"), into C
and then into assembler/ binary code.  So by your argument, Maxima is
as efficient as C.
(Lisps that are not GCL compile into assembler, so maybe writing in
Lisp is as efficient as assembler??)



> It also fits in with the 90-10 philosophy, making it easy  
> to optimize only those parts one needs to (instead of writing the  
> whole thing in a more restrictive (depending on your tastes) language  
> just so your couple of inner loops can be fast enough).

I agree.  Which is why I use Lisp:
1. This 90-10 philosophy includes a need for careful profiling to find
out where the important parts are.
At least the lisp I use has superb profiling tools.
2. Optimizing code in Lisp generally can be done by increasing the
details of the (otherwise optional) declarations,
increasing the requested level of "optimizing", thereby removing error
checks, etc.
3. Changing a huge system (e.g. Maxima) to use a different version of
function F, which can be interpreted or compiled,
is accomplished by evaluating what can be a single line of code, and
done in a very short time, independent of the size
of the system.

I think Java cannot do this. I have never used Cython.

>
> Getting back to the topic of the thread, I think a reason Python is  
> nice for scientific programming is that it's easy to learn, easy to  
> read, and easy to prototype in, and has a rich set of libraries to  
> work with.

If the only comparison is with Java, who knows.  I understand that
Excel is nice, too.

> On the other hand, when you need raw number crunching  
> speed there are good tools out there to interface with or write at a  
> lower level (e.g. Cython, or all that's been wrapped by SciPy and Sage).
>
As I pointed out, this not an argument for Python being good for
scientific computing,
but for Python being good for glue.  If you wish, you can see how to
glue MPFR or
GMP  or quad-double arithmetic  to lisp, google{fateman generic.lisp}

Regards
RJF


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to