Martin Rubey | 6 May 2008 17:43
Picon
Picon
Favicon

Re: [open-axiom-devel] [Axiom-developer] Am I posing this solve problem wrong?

"Bill Page" <bill.page@...> writes:

> I have been thinking specifically about the algorithms that the Axiom
> interpreter uses to do type inference and function selection. Some part of
> the behaviour is "hard coded" into the interpreter and not easy to change,
> but a large part of it depends on interaction with the design of the Axiom
> library, i.e. the coercions and other operations that are exported by exposed
> domains. It seems to me that in many cases not enough attention has been paid
> to "tuning" the Axiom library so that the Axiom interpreter produces fewer
> surprises for the new user.

Some time ago I posted a question in exactly this direction (something like
"why doesn't HOAGG R export coerce: % -> List R and coerce: List R -> %).

I can only guess that one answer (which I didn't get, but I give myself) is
optimization: coercion done by the library *might* be relatively slow.

However, I'm quite sure it would make a lot of sense to replace the contents of
i-coerce by appropriate definitions in the algebra.

Exploration here is very very welcome -- and in FriCAS also relatively
painless, one only has to keep in mind that changes at this level usually make
complete recompilation of the algebra necessary.

Of course, the insights will be valuable for all three projects.

Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
(Continue reading)

Bill Page | 6 May 2008 18:08
Gravatar

Re: [open-axiom-devel] Re: [Axiom-developer] Am I posing this solve problem wrong?

On Tue, May 6, 2008 at 11:43 AM, Martin Rubey wrote:
>
> "Bill Page" <bill.page@...> writes:
>
>> I have been thinking specifically about the algorithms that the Axiom
>> interpreter uses to do type inference and function selection. Some part of
>> the behavior is "hard coded" into the interpreter and not easy to change,
>> but a large part of it depends on interaction with the design of the Axiom
>> library, i.e. the coercions and other operations that are exported by exposed
>> domains. It seems to me that in many cases not enough attention has been
>> paid to "tuning" the Axiom library so that the Axiom interpreter produces
>> fewer surprises for the new user.
>
> Some time ago I posted a question in exactly this direction (something
> like "why doesn't HOAGG R export
> coerce: % -> List R and coerce: List R -> %).
>
> I can only guess that one answer (which I didn't get, but I give myself)
> is optimization: coercion done by the library *might* be relatively slow.
>

As I said in the previous thread, I think your idea is a good one.

I think you are probably being too generous to the developers. I doubt
that any such consideration of optimization was ever applied. I expect
that the detailed coding in the Axiom interpreter and the coercions
supplied (or not) by the Axiom library are merely artifacts of the
constraints to the original Axiom development process.

> However, I'm quite sure it would make a lot of sense to replace the contents
(Continue reading)

Gabriel Dos Reis | 7 May 2008 05:19
Picon
Favicon

Re: [open-axiom-devel] Am I posing this solve problem wrong?

"Bill Page" <bill.page@...> writes:

[...]

| I think you are probably being too generous to the developers.

I tend to give the original Axiom developers lot of credits :-)

[ That is probably because I've tried many radical ideas, only to
discover that there were reasons why they did certain things the way
they did, even if I don't like it. ]

| that any such consideration of optimization was ever applied. I expect
| that the detailed coding in the Axiom interpreter and the coercions
| supplied (or not) by the Axiom library are merely artifacts of the
| constraints to the original Axiom development process.

OpenAxiom already moved many of syntactic transformations and
coercions to library.  More reamin to do done; but that would rely on good,
clear, abstract, object models of computations.

-- Gaby

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Bill Page | 7 May 2008 06:57
Gravatar

Re: [open-axiom-devel] Am I posing this solve problem wrong?

Gaby,

On Tue, May 6, 2008 at 11:19 PM, you wrote:
> ...
> OpenAxiom already moved many of syntactic transformations and
> coercions to library.  More remains to do done; but that would rely
> on good, clear, abstract, object models of computations.
>

Could you please give an example of a coercion that has been moved to
the library? Does this include any of the coercions that are "hard
coded" into the Axiom interpreter?

Regards,
Bill Page.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Gabriel Dos Reis | 7 May 2008 16:05
Picon
Favicon

Re: [open-axiom-devel] Am I posing this solve problem wrong?

"Bill Page" <bill.page@...> writes:

| Gaby,
| 
| On Tue, May 6, 2008 at 11:19 PM, you wrote:
| > ...
| > OpenAxiom already moved many of syntactic transformations and
| > coercions to library.  More remains to do done; but that would rely
| > on good, clear, abstract, object models of computations.
| >
| 
| Could you please give an example of a coercion that has been moved to
| the library? Does this include any of the coercions that are "hard
| coded" into the Axiom interpreter?

See an example I gave on the wiki

   a := 'x :: OutputForm
   b := 'y :: OutputForm
   a and b

-- Gaby

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Martin Rubey | 7 May 2008 16:32
Picon
Picon
Favicon

Re: [open-axiom-devel] Am I posing this solve problem wrong?

Gabriel Dos Reis <gdr@...> writes:

> "Bill Page" <bill.page@...> writes:
> 
> | Gaby,
> | 
> | On Tue, May 6, 2008 at 11:19 PM, you wrote:
> | > ...
> | > OpenAxiom already moved many of syntactic transformations and
> | > coercions to library.  More remains to do done; but that would rely
> | > on good, clear, abstract, object models of computations.
> | >
> | 
> | Could you please give an example of a coercion that has been moved to
> | the library? Does this include any of the coercions that are "hard
> | coded" into the Axiom interpreter?
> 
> See an example I gave on the wiki
> 
>    a := 'x :: OutputForm
>    b := 'y :: OutputForm
>    a and b
> 
Gaby,

could you please elaborate?  I found this on the wiki:

(1) -> a := 'x :: OutputForm

   (1)  x
(Continue reading)

Bill Page | 7 May 2008 16:33
Gravatar

Re: [open-axiom-devel] Am I posing this solve problem wrong?

On Wed, May 7, 2008 at 10:05 AM, Gabriel Dos Reis wrote:
> ...
> Bill Page writes:
> |
> | Could you please give an example of a coercion that has been moved
> | to | the library? Does this include any of the coercions that are "hard
> | coded" into the Axiom interpreter?
>
> See an example I gave on the wiki
>
>   a := 'x :: OutputForm
>   b := 'y :: OutputForm
>   a and b
>

Ok, I see. Compare the output of:

http://axiom-wiki.newsynthesis.org/SandBoxOpenAxiom#bottom

(which is executed using OpenAxiom) to:

http://axiom-wiki.newsynthesis.org/SandBoxAxiom#bottom

(which is executed by default using FriCAS).

Thanks!

Regards,
Bill Page.

(Continue reading)

Martin Rubey | 7 May 2008 16:36
Picon
Picon
Favicon

Re: [open-axiom-devel] Am I posing this solve problem wrong?

Martin Rubey <martin.rubey@...> writes:

> Gaby,
> 
> could you please elaborate?  I found this on the wiki:

Oh, Bill answered already!

Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Martin Rubey | 10 May 2008 09:33
Picon
Picon
Favicon

Re: [open-axiom-devel] Re: BINGO! Re: [fricas-devel] Re: FriCAS, Aldor, sbcl and gcl

Dear all,

here are the changes necessary to make aldor (precisely, src_aldor2.tgz) work
with sbcl-based FriCAS.  I guess that they should also work for OpenAxiom.

Abstract:

*) the right way to get oneself into the underlying lisp from within the
   FriCAS/OpenAxiom interpreter is )fin, I believe

*) possibly gcl *needs* the call 

    <at> echo "(si::use-fast-links nil)" >> $(MID)/tmp/mkax_$*.lsp

   If so, this needs to conditionalized.

*) ANSI Common Lisp does not understand old CLTL style in-package with options,
   as produced by Aldor. The (lisp) package within which the PanAxiom
   interpreter operates (and, in particular, loads and compiles aldor generated
   files) is "BOOT".  Therefore, we shadow in-package in "BOOT".  Since depsys
   operates in "COMMON-LISP-USER", we need to switch to "BOOT" first.

   The shadowing in src/interp/sys-pkg.lisp needs to be condionalized on ANSI
   CL.

   The right fix, however, would be to modify the Aldor compiler to output ANSI
   Common Lisp code.

*) There are some other ANSI Common Lisp changes in interp/foam_l.lisp.  Most
   annoyingly, Aldor assumes that fixnums can be of size 2^31, which is not the
(Continue reading)

Martin Rubey | 10 May 2008 18:09
Picon
Picon
Favicon

Re: [open-axiom-devel] Re: BINGO! Re: [fricas-devel] Re: FriCAS, Aldor, sbcl and gcl

Dear Waldek, Peter,

Waldek Hebisch <hebisch@...> writes:

> I belive that the change to Makefile.in and changes to 'foam_l.lisp' can go
> in.  [...]

I just wanted to commit the change to Makefile.in, and wanted to write a line
of explication.  Then I found that Makefile.pamphlet exists, and looked up the
meaning of DEP, which explained a bit:

    The {\bf DEP} variable contains the list of files that
    will be loaded into {\bf DEPSYS}. Notice that these files
    are loaded in interpreted form. We are not concerned about
    the compile time performance so we can use interpreted code.
    We do, however, care about the macros as these will be
    expanded in later compiles. All macros are assumed to be
    in this list of files.

    <<environment>>=
    DEP=	vmlisp.lisp	ggreater.lisp	\
    	hash.lisp	bootfuns.lisp	\
    	union.lisp	nlib.lisp	\
    	macros.lisp	comp.lisp	\
    	spaderror.lisp	debug.lisp	\
    	spad.lisp	bits.lisp	\
    	setq.lisp	property.lisp	\
    	foam_l.lisp      \
    	axext_l.lisp

(Continue reading)


Gmane