axiom-developer
[Top][All Lists]

## [Axiom-developer] RE: set function breakage

 From: Page, Bill Subject: [Axiom-developer] RE: set function breakage Date: Tue, 22 Jul 2003 19:53:37 -0400

```Tim,

On Tuesday, July 22, 2003 6:15 PM you wrote:
>
>[Bill]
> > What I am actually looking for is a simpler example of
> > an Axiom set function that actually fails. So far nothing
> > seems wrong.
>
> Why do you believe that the Set function fails?

Again, as reported by Juergen Weiss

http://mail.gnu.org/archive/html/axiom-developer/2003-06/msg00088.html

> The last command in coercels.input converts the result
> to a set. With gcl, the result contains duplicate
> elements. Problem does not occur with cmu cl.

coercels.input is "fairly" simple:

------

alternatingGroup 4
% :: List Permutation Integer
li := %
pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
p : pgr := first  li
q : pgr := first  li
basis  := [p,q,p*p,p*q, q*p,q*q, p*q*q, p*q*p, q*p*q,q*q*p,q*p*q*q,q*q*p*q]
% :: Set MonoidRing(Polynomial PrimeField 5,Permutation Integer)

------

But simpler would be better. Quite a lot of algebra has
to be loaded to execute these statements.

> The example of sets failing that I gave was actually a GCL
> common lisp example vs CCL common lisp. It was not an Axiom
> level failure. (To recall, the example was:
>
> (setq a '(a))
> (setq b '(b c))
> in GCL:
> (set-difference b a) ==> (c b)
> in CCL:
> (set-difference b a) ==> (b c)
>
> Both of these results are correct as they are both valid sets
> and the order of the result of set-difference is unspecified).
>

As you say, this is not really a failure. There is no (should
not be) any assumption of order.

> The main Axiom failure is actually in the compiler. If you do:
>
> (1) -> )co xpoly )con XPR
>
> the compile will eventually die with a stack overflow. The above
> command says to compile the domain XPR from xpoly.spad. This
> will eventually involve walking the tree of domains that XPR
> uses. Walking this tree involves finding all of the domains it
> depends on and adding them to a list to be processed (the
> DEPENDS list).

I think you said this earlier yourself: If somewhere in there
a coercion to type Set fails, perhaps "walking the tree" might
fail?

Thanks very much of the additional tutorial material on
Axiom/lisp debugging methods in your previous message.

Cheers,
Bill.

```