Re: [Axiom-developer] Software Archaeology/Patches

[m.rubey]

Concerning Software Archaeology, I agree. However, much of the code -- 
especially COMBF -- is very easy to understand. Therefore I suppose the 
best thing is to write documentation, both on new and old code, as bugs 
are discovered and fixed. In this spirit I volunteer to document those 
functions in COMBF and FS that I understand now. Before I do so, I only 
ask for a "go ahead" by some key developer, because I don't want to waste 
my time.

Unfortunately, I also have to say that I'm a little bit disappointed: I
submitted a patch which fixes a problem that turned up in Wester's
test-suite -- no reaction. I posted some questions -- no reaction. A
simple (private) "sorry, I don't know - interesting question" or "sorry, I
don't know, - but it's a stupid question anyway" would help a lot. At the
moment, there aren't that many developers around so that it would result
in flooding my email account.

On the other hand, I'm very happy that I received this email now...

> I'll write separately on Rubey's reported bug (but for now, the problem
> is not Bronstein's, in Axiom 2.3, each new()$Symbol generates a new
> variable name and Bronstein used dummy:=new()$Symbol to define the
> iterating variable in product and summation. The problem is from the
> upper limit of the summation being numerical rather than a symbol.)

I believe this is not quite correct: His line 145 of
combfunc.spad.pamphlet reads

  dummy := new()$SE :: F

Therefore (I believe), when COMBF is first read, "dummy" is assigned 
("immediately") a new symbol, once and for all. Thus, everywhere where 
"dummy" is used, the *same* symbol is inserted. In particular, all sums 
and all products use the same iteration variable. Clearly, when sums and 
products are nested and evaluation takes place, problems occur.

Meanwhile I tested my patch and it works quite well, so I'll submit it 
now. As I said, the only problem remains when you use the symbol 
which will be generated next somewhere in the sum (or product). I don't 
know how to fix this, but this is a problem which should be fixed in 
new()$Symbol. By the way, there are references to this problem in 
fspace.spad...

The reason I did not submit the patch earlier was, that I just changed 
job, so I had no time to test it. I don't want to submit untested patches.

The problem in dvdsum is unrelated, easier to understand but more
difficult to fix, as I wrote in my bug report

http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9216

The problem is that I don't know how to return 

D(sum(f(i),i=1..x),x)

unevaluated. Some trials resulted in ugly and partially wrong results, see 
reports

http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9215

and

http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9218

Therefore, no patch.

I'll write about the other things a little later

All the best,

Martin Rubey

> 
> William
> -- 
> William Sit
> Department of Mathematics..............Email: address@hidden
> City College of New York..........................Tel: 212-650-5179
> Convent Ave at West 138th Street..................Fax: 212-862-0004
> New York, NY 10031............Axiom, A Scientific Computation Sytem
> USA..........................http://www.nongnu.org/axiom/index.html
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
>