[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: Patches
From: |
Martin Rubey |
Subject: |
[Axiom-developer] Re: Patches |
Date: |
Fri, 18 Jun 2004 14:09:38 +0000 |
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
- [Axiom-developer] Patches, William Sit, 2004/06/09
- [Axiom-developer] Re: Patches, m.rubey, 2004/06/09
- Re: [Axiom-developer] Re: Patches, Camm Maguire, 2004/06/11
- [Axiom-developer] Re: Patches, Manuel Bronstein, 2004/06/18
- [Axiom-developer] Re: Patches,
Martin Rubey <=
- [Axiom-developer] Re: [Gcl-devel] Re: Patches, Camm Maguire, 2004/06/21
- [Axiom-developer] Re: [Gcl-devel] Re: Patches, Martin Rubey, 2004/06/22
- [Axiom-developer] Re: [Gcl-devel] Re: Patches, Camm Maguire, 2004/06/28
- [Axiom-developer] Re: Patches, William Sit, 2004/06/18
- [Axiom-developer] Re: Patches, Manuel Bronstein, 2004/06/18
- [Axiom-developer] Re: Patches, William Sit, 2004/06/18