[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Axiom-developer] Re: libaxiom.a

From: Bill Page
Subject: RE: [Axiom-developer] Re: libaxiom.a
Date: Wed, 22 Mar 2006 10:18:18 -0500


On March 22, 2006 6:18 AM you wrote:
> On 03/21/2006 04:55 PM, Page, Bill wrote:
> [snip]
> >> A more effective path would be to load and compile your
> >> computation in lisp and then generate a standalone image to
> >> do that computation, sort of a special version of AXIOMsys.
> >> This IS standalone, machine-language code with an embedded
> >> lisp that can use all of the axiom library.
> > 
> > Yes, I agree completely. That is the right way to go.
> I don't. Suppose, I am a Fortran or C programmer and for some 
> reason I need as a subpart of all my numerical computations
> some symbolic stuff. As I understand Tim, I should consider
> my program as a subpart of a customized AXIOMsys. Do you
> think you could convince me to do that?

No. You should think of AXIOMsys as the subroutine library.

> I would certainly rather look for a library that I just
> link to my program and be happy.

Yes. In fact GCL, on which Axiom is based is licensed as
if it were a library (LGPL). This is a common situation
for Lisp environments where there is no clear separation
between compiled code and the run time environment.

> Only the minimal part of Axiom which is relevant 
> to my problem should go into my final executable.

That is the hard part. There is an enormous overhead
necessary to do even simple symbolic computation. It is
possible to eliminate unnecessary code but the resulting
executable is like to still be quite huge. It would be
interesting to take a look for example the size of Aldor
executables compared to a similar (not symbolic) program
in "C". I expect there is also a large overhead to support
the Aldor FOAM run-time environment.

> I somehow think that providing (symbolic) libraries (besides 
> the Axiom we have) is just another way to bring symbolic
> computation to a broader public. Is that such a bad idea?

That is a good idea. It should be made easier to use Axiom
in this way, i.e. via an application programmer interface
(API). Right now it is possible to do this via socket calls.
This is how Hyperdoc communicates with Axiom. A library that
makes this transparent or which eliminates the sockets and
calls GCL directly would be very nice. GCL has a foreign
function interface and I think it should be possible to use
this in reverse.

> Even Maple does now provide an interface to let external 
> programs call Maple functions. However, you need to buy
> Maple.

Yes, I have used Maple's interface. Maple runs as a separate
kernel process just like the Axiom socket interface but this
is hidden by the API.

> We could just provide appropriate libraries. Why should we
> forget about that potential?

I don't think we should forget about this potential but I
think there is more involved than "just providing appropriate

Bill Page.

reply via email to

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