axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: [Gcl-devel] Re: Patches


From: Camm Maguire
Subject: [Axiom-developer] Re: [Gcl-devel] Re: Patches
Date: 21 Jun 2004 13:11:33 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Martin Rubey <address@hidden> writes:

> 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" :-(
> 

OK, I'm afraid I've lost the thread.  If you could please give me the
commands you are using in axiom, what the result is, and what you
think it should be, in of course as simple an example as you can, I'll
be happy to take a look.

Take care,

> 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
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

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