axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: Patches


From: m.rubey
Subject: [Axiom-developer] Re: Patches
Date: Wed, 9 Jun 2004 16:27:49 +0200 (CEST)

On Wed, 9 Jun 2004, William Sit wrote:

> 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
> 
> Note this was because before I clear all, I had defined %B and did a
> New()$SYMBOL that gives %C. 
> 
> (3) -> G1419::SYMBOL
>     G1419
> 
> (4) -> symbol(GENSYM()$Lisp)
>     G84337
> 
> All output are of type Symbol.

In fact, I was hoping that the NAG version would do this. I suspect this 
is a GCL issue. I will send Camm Maguire a message.

> I also got the product summation display correctly without error
> message, unless the upper limit is a constant. 

This is the same in the Open Source version. The problem appears only when 
*both* of the limits are constants.

> Thus I think Bronstein's use of new()$Symbol is correct, but somewhere
> in the open source version, new()$Symbol get clobbered. Of course, you
> can patch Bronstein's code to force a new symbol each time, but other
> packages that use new()$Symbol will still fail, as you recognized. I
> believe the source of the error is more subtle and probably does not
> come from new()$Symbol either.

I don't think that this is the case.

> Another reason why I think the error does not come from the source code is
> because any iteration in Axiom, the iterating variable is a dummy (and
> supposedly unique and local in scope). (Can Tim affirm this?)

If I understand correctly, dummy := new()$SE::F assigns a new symbol to 
the variable "dummy" once and for all. So, if I'm not mistaken, the policy of 
axiom which you describe is violated in COMBF, and probably in other 
packages too. It is not so unlikely that this produces errors only very 
rarely, since errors will only occur if you nest procedures from one 
package -- and not even in this case they show up unconditionally. I will 
try to produce errors in other packages that use dummy := new()$Symbol. 
BTW, line 625-6 of fspace.spad seems to refer to this problem too...

-- cannot use new()$Symbol because of possible re-instantiation
      gendiff := "%%0"::SY

.....

However, since I'm using axiom only since a few weeks, it is quite 
possible that I'm mistaken.

> Bug Report #9216:
> 
> Regarding dvdsum, I find it hard to follow Bronstein's code
> (CombinatorialFunction constructor in combfunc.spad), because I need to
> trace all the packages to figure out what opdsum does (it seems to be a
> hold to do recursion, but I am not sure and opdsum is not an exported
> function, neither is dvdsum). 

opdsum is a variable holding the operator %defsum. The line 

evaluate(opdsum, iidsum)

in COMBF instructs axiom to evaluate %defsum using the procedure iidsum. 
In other words, everywhere you see opdsum in the code, axiom will call 
iidsum upon evaluation.

> Assuming it is just a summation, mathematically speaking, then my guess
> is dvdsum does the following: it takes two arguments, a list with five
> parameters, and a symbol. Using Bronstein notation in the code (without
> regard to type, just mathematical and forget all the coercions), the
> first is [f,k,y,g,h], all belonging to some function space F, such as
> Expression Integer and the second is x. Here
> 
> f is the function to be summed with dummy variable k, 
> k is the dummy (for summation), 
> y is some symbol
> g is the lower limit of summation, presumably a function of x
> h is the upper limit of summation, presumably a function of x
> x is the symbol with respect to which differentiation is to be done

This is what I strongly believe, too.

> What the code dvdsum does, assuming odpsum is just summation, is to
> return the following: d/dx means differentiation wrt x (not the d in the
> code)
> 
> 0 if the variable y retracts to x, otherwise the formula:
> 
> d(h)/dx f(h) - d(g)/dx f(g) + summation(d(f)/dx, k = g..h)

Yes.

> I have no clue what this formula means, for example, what is the role of y?

y plays no role, since it is used *only* for display. This is the 
philosophy behind all the operators that use a dummy var. (called 
-- operators whose second argument is a dummy variable
    dummyvarop1 := [opdiff,opalg, opint, opsum, opprod]
-- operators whose second and third arguments are dummy variables
    dummyvarop2 := [opdint, opdsum, opdprod]

in op.spad)

I think that the reason for doing this is to be able to let a standard
eval (such as the eval in FS) evaluate applications of these operators, 
but I#m not at all sure about this. I think we should ask Bronstein.

> however, I hesitate to say it is wrong because Bronstein is quite
> careful, both as a mathematician and a wizard in Axiom and Aldor.  
> dvdsum occurs only three times in the source, once in the signature,
> once in the definition, and once in an obscure setProperty statement
> related to opdsum. 

the setProperty statement

setProperty(opdsum,SPECIALDIFF,dvdsum@((List F,SE)->F) pretend None)

instructs axiom to use dvdsum for differentiating %defsum. Lines 766-8 of 
fspace.spad read

    -- SPECIALDIFF contains a map (List %, Symbol) -> %
    -- it is used when the usual chain rule does not apply,
    -- for instance with implicit algebraics.

> ----------------
> Bug Report #9215:
> 
>  sum(box(i),i=a..b) 
> 
> returns the answer correctly, but the outputForm missed a pair of parenthesis
> aa-1 should be a(a-1); 
> 
>  box(sum(i),i=1..n) 
> 
> also returns correctly, because after sum is evaluated to (n^2+n)/2, an
> (invisible) box is placed around it. Note the box is useful ONLY when
> there is an operator operating on the box content. The only way this is
> easy to use is when the operator takes one argument, such as sin, cos,
> log. The argument can be a list of course.

I thought that box would simply prevent axiom from doing evaluation. I 
still don't understand.

> ---------------
> Bug Report 9218:
> 
> I believe the CombinatorialFunctions package is not meant to do what may
> be called indefinite summation, only definite summations (hence the name
> %defsum). 

I don't understand the relation of this to my bug report. Sorry.

> Note that the result from
> 
> eval(D(f(x),x),f,y+->sum(g(i,y),i=a..y))
> 
>    %defsum (g(%A,%%01),%A,i,a,x)
> 
> comes from dvdsum again and is consistent with the formula I gave above,
> except that I would not expect %%01 but rather just x.

The %%01 is the dummy variable used for differentiation (see line 625 of 
fspace.spad).

Thanks for your effort, I'm sure we'll fix all this!

Martin





reply via email to

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