[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

"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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]