Re: [Axiom-developer] Axiom volunteer work ideas

[M. Edward (Ed) Borasky]

--
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.