[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Axiom volunteer work ideas
From: |
M. Edward (Ed) Borasky |
Subject: |
Re: [Axiom-developer] Axiom volunteer work ideas |
Date: |
Sat, 27 Feb 2010 05:04:09 -0500 |
User-agent: |
Internet Messaging Program (IMP) H3 (4.1.4) |
--
M. Edward (Ed) Borasky
borasky-research.net/m-edward-ed-borasky/
"A mathematician is a device for turning coffee into theorems." ~ Paul Erd?s
Quoting Tim Daly <address@hidden>:
As to the Fortran vs C question... I'd be happy with either
but, truth be told, I'd really prefer a lisp implementation.
That said, I have seen a Fortran-to-C conversion program
somewhere although how well it would work on BLAS is unclear.
But it would be easy to embed a C version directly into GCL.
FORTRAN-C conversion is ancient technology, as are the BLAS. Allow me
to introduce you to ATLAS
http://math-atlas.sourceforge.net/
I'm not sure how current non-x86_64 versions are, but the x86_64
version gets tweaked more or less constantly. ATLAS is in C, with
assembler kernels in many places where it makes sense to have them.
The choice of python was motivated by the fact that I am
using python for a task in work. A general framework that
handled a common subset of any language would be ideal. This
would allow us to generate ruby/python/haskell/fortress/go/etc
Python's a *lot* more efficient than Ruby for number crunching.
I suppose I should journal more of these ideas to the mailing
list so others can think about them. I have partial implementations
of a lot of things, like a Cohen algebra domain that allows
explanations to be printed for each step in a solution. It is
based on Joel Cohen's Computer Algebra and Symbolic Computation books.
And I've done some more special function work but not had the
cycles to put it into the algebra yet.
Time, time, time.... sigh.
Yeah - I need to seriously pick up algorithmic composition again. It's
a lot easier than computational math, though.