[Axiom-developer] Re: Quick question on the symbol issue:

[Martin Rubey]

Hi Camm!

Camm Maguire writes:
 > OK, the issue does not appear to be with the underlying lisp as far as I can
 > tell. Please correct me if I am in error (with verifiable details if
 > possible).

This is very strange: in
http://lists.gnu.org/archive/html/axiom-developer/2004-06/msg00081.html William
Sit reports that the problem does not occur in the NAG version. He writes:

> I have started verifying your bug on the NAG Axiom 2.3 version, which
> presumably have the same algebra sources. There are some places where I cannot
> duplicate your error messages. (I am also handicapped as far as Linux goes and
> so my Axiom set up is on a separate computer (in fact a virtual computer) that
> makes it clumsy to transfer text. I am using the NAG version because it helps
> to identify whether the bug is from the algebra or the open source "meddling"
> :-)
> 
> On my system, which is not the open source one, I have this (transcribing ;-(
> nonessential things omitted)
> 
> )clear all
> (1) -> %A:SYMBOL
>     %A
> 
> (2) -> new()$SYMBOL
>     %D

On the other hand, your explanations make a lot of sense.

 > Rather the new() functions in SYMBOL.spad do not check that the user might
 > have referred previously to a symbol with the 'special' % prefix.

Yes, that was my first thought too.

 > Alternatively, perhaps it was intended that % act somewhat like the #: lisp
 > reader macro in designating a symbol that is to be uninterned.  If this is
 > the case, please point me to the code that is intended to establish this
 > behavior and I'll look at it.

No idea. However, I'd be interested whether the bug *really* does not occur in
the NAG version. It could well be the case that new()$Symbol always starts with
%D in NAG. Could you check, William?

 > (sid)address@hidden:/fix/g/camm/axiom/axiom-0.20040831/src/algebra$ diff -u 
 > symbol.spad.pamphlet.ori symbol.spad.pamphlet
 > --- symbol.spad.pamphlet.ori 2004-05-24 22:53:45.000000000 +0000
 > +++ symbol.spad.pamphlet     2004-09-24 16:51:41.000000000 +0000
 > @@ -252,27 +252,32 @@
 >          if zero?(n) then return ns
 >        
 >      new() ==
 > -      sym := anyRadix(count()::Integer,ALPHAS)
 > -      count() := count() + 1
 > -      concat("%",sym)::%
 > +      repeat
 > +        sym := anyRadix(count()::Integer,ALPHAS)
 > +        count() := count() + 1
 > +        ns := concat("%",sym)
 > +        if not FIND_-SYMBOL(ns)$Lisp then return ns::%
 >  
 >      new x ==
 > -      n:Integer :=
 > -        (u := search(x, xcount)) case "failed" => 0
 > -        inc(u::Integer)
 > -      xcount(x) := n
 > -      xx := 
 > -        not scripted? x => string x
 > -        string name x
 > -      xx := concat("%",xx)
 > -      xx :=
 > -        (position(xx.maxIndex(xx),nums)>=minIndex(nums)) => 
 > -          concat(xx, anyRadix(n,alphas))
 > -        concat(xx, anyRadix(n,nums))
 > -      not scripted? x => xx::%
 > -      script(xx::%,scripts x)
 > +      repeat
 > +        n:Integer :=
 > +          (u := search(x, xcount)) case "failed" => 0
 > +          inc(u::Integer)
 > +        xcount(x) := n
 > +        xx := 
 > +          not scripted? x => string x
 > +          string name x
 > +        xx := concat("%",xx)
 > +        xx :=
 > +          (position(xx.maxIndex(xx),nums)>=minIndex(nums)) => 
 > +            concat(xx, anyRadix(n,alphas))
 > +          concat(xx, anyRadix(n,nums))
 > +    if not FIND_-SYMBOL(xx)$Lisp then
 > +          if not scripted? x then return xx::%
 > +          return script(xx::%,scripts x)

great. Even better: it would have been impossible for me to fix that! (don't
know find-symbol...)

 >  
 >      resetNew() ==
 > +--    Do we want to unintern the symbols previously interned here?
 >        count() := 0
 >        for k in keys xcount repeat remove_!(k, xcount)
 >        void
 
 > As noted in the comment, regardless of resetNew(), subsequent invocations of
 > new() will start where the counter left off, unless one adds code to
 > unintern the specified symbols, which in this case might wipe out a symbol
 > explicitly specified by the user.  Don't know what is best here, though I
 > suspect the latter.

I don't understand what you explain here. What symbols do you mean with
"specified symbols"?

-----------------------------------------------------------------------------

 > As for gensym, it returns a fresh *uninterned* symbol at all times.  (eq
 > '#:g '#:g) ==> nil.  Axiom is printing the symbol without this special
 > syntax which might alert one to what is going on.  In short, G1419::Symbol
 > *is in fact distinct* from the return value of symbol(GENSYM()$Lisp) even
 > when the print value is the same.

Well observed! I had to try it out :-) :

(1) -> a:=G1418::Symbol

   (1)  G1418
                                                                 Type: Symbol
(2) -> b:=symbol(GENSYM()$Lisp)
   (2)  G1418
                                                                 Type: Symbol
(4) -> (a=b)::Boolean

   (4)  false
                                                                Type: Boolean
(5) -> a:=%A::Symbol

   (5)  %A
                                                                 Type: Symbol
(6) -> b:=new()$Symbol

   (6)  %A
                                                                 Type: Symbol
(8) -> (a=b)::Boolean

   (8)  true

Shame on me...

 > And yes, in answer to your previous question, though not a mathematician, I
 > have a Ph.D. in theoretical physics, and so could work on math bugs in axiom
 > providing they are not too specialized.  

Great!

 > As time is short, I'd really prefer not working on things which are not
 > *important*, which I'm defining here as increasing the utility of as many
 > people as possible by as much as possible.

Yes. BTW, it seems that Bill Page made progress on integrating pamphlets into
MathAction. Very good week! 

If you can spare time I suggest that you look at 

http://page.axiom-developer.org/zope/mathaction/WishList

The TodoList currently seems a bit outdated to me. I will update it when I get
to it. However, I'm not that good at rating what's important and what's not
that urgent. I find that there are not that many severe unfixed bugs known at
the moment (on the other hand: a (mathematical) bug is one bug too many), so
maybe a windows port and more functionality (mathswise) has higher priority.

Maybe you could also add to the WishList what would be a real goody for a
physicist?

Thanks again,

Martin