axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: algebra cycles again


From: Page, Bill
Subject: [Axiom-developer] Re: algebra cycles again
Date: Tue, 14 Oct 2003 23:57:31 -0400

Dylan,

On Tuesday, October 14, 2003 10:48 PM you wrote:

[about modifying spad files that involve a bootstrap]

> ... 
> Maybe it's worth writing some code to check that the
> generated .lisp files are the same as the cached ones?
> Or is that already written?

No, as far as I know this hasn't been written. But I
agree that it would be a good idea. However it is
apparently not trivial since the symbols in the generated
lisp code do not seem to be the same as those in the
at least the current bootstrap lisp code. Perhaps the
current bootstrap lisp code was not generated by GCL?

If re-generating the bootstrap code from the newly
compiled bootstrapped modules will stablize the names,
then a comparison (the next time around) would be
fairly trivial. Otherwise a more intellegence "equivalence"
test might be required.

In any case, if we really do need to depend on iteratively
compiling the algebra code containing cycles to a "fixed
point" solution, then such a comparison will ultimately
have to be written.

> 
> > BTW, I noticed that in the algebra/Makefile.pamphlet Tim
> > uses
> > 
> >  SETCAT -> SINT -> UFD -> GCDDOM -> COMRING -> RING ->
> >    RNG -> ABELGRP -> CABMON -> ABELMON -> ABELSG -> SETCAT
> > 
> > as an example of cycle in Axiom's type system. It occurs
> > to me that perhaps changes such as you suggested (removing
> > the Latex stuff from SETCAT) might help to eliminate *some*
> > of this sort of thing.
> 
> Well, this one would go away if the 'hash' function were
> removed from SETCAT.  It's the obvious weak link in that
> chain; the others are all very reasonable.  (Except that
> integers mod a power of 2 are not actually a UFD...)
> 
> I thought at first that the 'hash' function was better than
> 'latex', but now I see that that's not true: if the type
> doesn't support proper equality testing, it's not safe to
> use hash, and if it does, then there's always a fall-back
> (although slower) algorithm, and by having a separate
> 'Hashable' class and checking 'if T has Hashable then ...'
> you could arrange for all algorithms to run as fast in
> practice.

I tentatively agree with you about this. I think it would
be worth a test to see what impact removing the hash function
from SETCAT might have on the rest of the type system.

> 
> > I am still not sure whether cycles of this kind are a
> > good thing or a bad thing ...
> 
> There may be cases when cycles are necessary, but I don't
> think this is one.
> 

Regards,
Bill Page.





reply via email to

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