[Gcl-devel] Re: Patches

[Martin Rubey]

Dear Prof. Bronstein,

thanks a lot for your answer!

Manuel Bronstein writes:
 > - new()$Symbol is working properly in the NAG version, so 9298 is
 >   probably a lisp problem.

Good. I remember that somebody was building axiom on cmucl -- I think it was 
Juergen Weiss. Could he try to reproduce bug #9298 on cmucl? Camm Muguire (GCL)
already offered to track down the bug:

Camm Maguire wrote:
 > If you suspect a GCL error here, and preferably can boil it down to a simple
 > lisp example, I'd be happy to take a look.

However, I don't know how to "boil it down" :-(

Manuel Bronstein writes:

 > - The line
 >       -- cannot use new()$Symbol because of possible re-instantiation
 >       gendiff := "%%0"::SY
 >   in fspace.spad is due to a problem with the axiom runtime: when a domain
 >   falls out of the runtime cache, it gets created again next time a function
 >   from that domain is called. This means that the top-level code of the
 >   domain is re-executed, and the globals are re-assigned.  The existing
 >   objects from that domain in your session remain unchanged.  This would
 >   cause the value of the gendiff symbol to change at random times, while
 >   previous values of gendiff would be stored in live objects, and that
 >   causes havoc.  If the runtime could guarantee that top-level code is
 >   called only once, then, I would have used new()$Symbol. But this
 >   re-instantiation problem forces hardwiring a specific symbol, I used %%O
 >   hoping that it would not conflict with user variables.

This goes to the docs. Thanks a lot!


 > - The definite summation operator %defsum takes 5 arguments as follows:
 >     f  - the expression being summed, depends on a dummy summation variable
 >     v  - the dummy summation variable
 >     k  - the symbol to use for the summation variable when displaying
 >     a  - the lower bound
 >     b  - the upper bound

 >   For differentiation, it is viewed as a function of the 3 arguments f,a,b
 >   and the chain rule is used, although my interpretation of the partial
 >   derivative of the sum function with respect to the summation bounds is
 >   wrong. I have to remember the reasons for the design, but the current
 >   formula encoded in dvdsum is the following:
 > 
 >     D(sum(f(i),i=1..b)) = sum((Df)(i),i=a..b) + f(a) Da + f(b) Db
 > 
 >   for any derivation D. In the case of indefinite summation, a is an
 >   arbitrary constant, so that formula becomes
 > 
 >     D(sum(f(i),i=..n) = sum((Df)(i),i=..n) + f(n) Dn
 > 
 >   which is encoded in dvsum.  Both are clearly wrong when the bounds are not
 >   constant, I do not have the correct derivative at hand when the sum is not
 >   expressible in closed form as a function of the bounds.  If there is
 >   agreement to return an unevaluated derivative when the bounds are not
 >   constants w.r.t. D, I can probably patch dvdsum and dvsum to do this.

I'm certain that this is the best thing to do. If you could provide a patch,
that would be great!

Some more issues:

- is there any (written) documentation on the design of the EXPR domain
  (including FS, ES, COMBFS, FS2 ...) ?

- I have a problem with sum: once sum is turned into an operator (for example
  via summation or idsum), it stays such an operator. It would be great if sum
  could be re-evaluated. In fact, I believe that sum$FS2 should be called
  automatically in certain circumstances. However, I do not yet have a clear
  picture how this should be done. (Also considering the fact that there should
  be more summation algorithms in the near future. Maybe the RISC people will
  help, I don't know...)

- is the Algebra library from Aldor Open Source? Where could I get it? Looking
  at the Basic Categories in its documentation it seems that there is quite a
  bit of overlap with the corresponding Axiom Domains. It would be nice if we
  could make the two things converge *somehow*. (It seems to me that the Aldor
  stuff is more up to date, but I don't know.)

Thanks again for joining,

Martin