What I was trying to get at before is that testing for the difference of two expressions' being zero is a more practical general strategy than trying to simplify one form to the other with a general manipulation rule.

Nobody is going to argue -- sensibly, I suppose -- about the "simplest" form of an expression the is exactly equal to zero. So rather than wonder what is the "simplest" form of either the RHS or the LHS of your (here, trigonometric) equation, you can instead subtract them and test for zero.

acer

For fun, and to show how very many ways there are,

<Matrix(5,shape=scalar[1])>;

The extra <..> is to get a Matrix without any indexing function.

Sorry, It hasn't been clear to me whether you wanted f(i,i) or merely introduced `f` as some way to try and get the value of 1 along the diagonal.

acer

For fun, and to show how very many ways there are,

<Matrix(5,shape=scalar[1])>;

The extra <..> is to get a Matrix without any indexing function.

Sorry, It hasn't been clear to me whether you wanted f(i,i) or merely introduced `f` as some way to try and get the value of 1 along the diagonal.

acer

That is not quite right. It's not just a question of replacing the _Inert_LOCALSEQ call. The locals have to be changed from _Inert_NAME to _Inert_LOCAL and the relvant argument changed from a string to an ordinal. And subsop(2=...) doesn't serve, as that is only allowed when the number of locals remains the same, I believe.

(Perhaps see my code above, or try your code on my example procecdure f therein.)

It seems that Doug's guess was correct in any event, and that instead of blowing lexical scoping out of the water the OP merely wanted to supress the warnings due to automatic/implicit local declaration. I guess that using a term like "variable" in a Maple discussion is a bit like using the term "germ" in a conversation with an epidemiologist or microbiologist.

acer

That is not quite right. It's not just a question of replacing the _Inert_LOCALSEQ call. The locals have to be changed from _Inert_NAME to _Inert_LOCAL and the relvant argument changed from a string to an ordinal. And subsop(2=...) doesn't serve, as that is only allowed when the number of locals remains the same, I believe.

(Perhaps see my code above, or try your code on my example procecdure f therein.)

It seems that Doug's guess was correct in any event, and that instead of blowing lexical scoping out of the water the OP merely wanted to supress the warnings due to automatic/implicit local declaration. I guess that using a term like "variable" in a Maple discussion is a bit like using the term "germ" in a conversation with an epidemiologist or microbiologist.

acer

Actually, it doesn't work like that in general. Maple will automatically declare the name as local if it is assigned to. But if it is merely used, without assignment, then it gets its value at runtime via Maple's lexical scoping rules.

It is possible to rewrite a proc and turn undeclared names into declared locals. Below is a crude example of this. (It is crude in the sense that it likely needs a lot more polishing in order to handle more complicated examples properly, etc. One can very likely break it easily.)

> convloc:=proc(f)
> local oldlocs,newlocs,newf,i;
> oldlocs:=map(convert,{op(2,eval(f))},string);
> newlocs:=map(op,indets(ToInert(eval(f)),specfunc(anything,_Inert_NAME)))
>   minus {"protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))}
>   minus map(convert,{op(1,eval(f))},string)
>   minus oldlocs;
> newf := ToInert(eval(f));
> for i from 1 to nops(newlocs) do;
>   newf := subsindets(newf,specfunc(newlocs[i],_Inert_NAME),
>                      t->_Inert_LOCAL(i+nops(oldlocs)));
> end do;
> FromInert(subs(_Inert_LOCALSEQ(seq(_Inert_NAME(ZZ),ZZ in oldlocs))
>                =_Inert_LOCALSEQ(seq(_Inert_NAME(ZZ),ZZ in oldlocs),
>                                 seq(_Inert_NAME(ZZ),ZZ in newlocs)),
>                newf));
> end proc:
>
> f:=proc(x)
> local p;
> p := T; seq(i, i = 1 .. 2); NULL;
> end proc;
        f := proc(x) local p; p := T; sum(i, i = 1 .. 2); NULL end proc

>
> convloc(f);
       proc(x) local p, T, i; p := T; sum(i, i = 1 .. 2); NULL end proc

NB. BY "assigned to" I mean with the assignment statement, using := syntax. With the `assign` command, Maple will not automatically declare the name. But that's is just one of several subtleties to using `assign` inside a proc, which should usually be avoided unless one knows the system well.

> restart:
> f := proc()
> assign(a,b);
> end proc;
                       f := proc() assign(a, b) end proc

acer

Actually, it doesn't work like that in general. Maple will automatically declare the name as local if it is assigned to. But if it is merely used, without assignment, then it gets its value at runtime via Maple's lexical scoping rules.

It is possible to rewrite a proc and turn undeclared names into declared locals. Below is a crude example of this. (It is crude in the sense that it likely needs a lot more polishing in order to handle more complicated examples properly, etc. One can very likely break it easily.)

> convloc:=proc(f)
> local oldlocs,newlocs,newf,i;
> oldlocs:=map(convert,{op(2,eval(f))},string);
> newlocs:=map(op,indets(ToInert(eval(f)),specfunc(anything,_Inert_NAME)))
>   minus {"protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))}
>   minus map(convert,{op(1,eval(f))},string)
>   minus oldlocs;
> newf := ToInert(eval(f));
> for i from 1 to nops(newlocs) do;
>   newf := subsindets(newf,specfunc(newlocs[i],_Inert_NAME),
>                      t->_Inert_LOCAL(i+nops(oldlocs)));
> end do;
> FromInert(subs(_Inert_LOCALSEQ(seq(_Inert_NAME(ZZ),ZZ in oldlocs))
>                =_Inert_LOCALSEQ(seq(_Inert_NAME(ZZ),ZZ in oldlocs),
>                                 seq(_Inert_NAME(ZZ),ZZ in newlocs)),
>                newf));
> end proc:
>
> f:=proc(x)
> local p;
> p := T; seq(i, i = 1 .. 2); NULL;
> end proc;
        f := proc(x) local p; p := T; sum(i, i = 1 .. 2); NULL end proc

>
> convloc(f);
       proc(x) local p, T, i; p := T; sum(i, i = 1 .. 2); NULL end proc

NB. BY "assigned to" I mean with the assignment statement, using := syntax. With the `assign` command, Maple will not automatically declare the name. But that's is just one of several subtleties to using `assign` inside a proc, which should usually be avoided unless one knows the system well.

> restart:
> f := proc()
> assign(a,b);
> end proc;
                       f := proc() assign(a, b) end proc

acer

The purpose you now describe, of merely supressing warnings of the automatically declared names which get assigned values, is in general very different from the originally stated goal (which could otherwise have dramatic, possibly intended, effects on the scoped evaluation behaviour of the procedure).

I'm glad that you got what you were apparently really after.

acer

The purpose you now describe, of merely supressing warnings of the automatically declared names which get assigned values, is in general very different from the originally stated goal (which could otherwise have dramatic, possibly intended, effects on the scoped evaluation behaviour of the procedure).

I'm glad that you got what you were apparently really after.

acer

Joe's post, and the issue of good quality FAQs, is great.

But since the question posted here is about symbolic summation, this does not so far appear to relate to "sum vs add" in an important or very useful way. (Finite summation was not the question at hand, and while often possible to test a supposition it usually doesn't actually achieve the desired symbolic result.)

There is some modified functionality for expanding Sums in the `student` package (see `student/expand/Sum`) which is "less picky" about possibly infinite indexing end-points. The call to combine(...,exp) handles products of finitely many exp() calls, to get exp of the sum. But I don't see any similar `student/combine/xxx` extension that might, say, handle a Product of exp with symbolic end-point n (with or without assumptions that n<>infinity or n::posint ).

acer

Joe's post, and the issue of good quality FAQs, is great.

But since the question posted here is about symbolic summation, this does not so far appear to relate to "sum vs add" in an important or very useful way. (Finite summation was not the question at hand, and while often possible to test a supposition it usually doesn't actually achieve the desired symbolic result.)

There is some modified functionality for expanding Sums in the `student` package (see `student/expand/Sum`) which is "less picky" about possibly infinite indexing end-points. The call to combine(...,exp) handles products of finitely many exp() calls, to get exp of the sum. But I don't see any similar `student/combine/xxx` extension that might, say, handle a Product of exp with symbolic end-point n (with or without assumptions that n<>infinity or n::posint ).

acer

Could you let us know, which interpretation was it? Markov chains and transition matrices, or just plain old linear algebra and diagonalization?

Inquiring minds would love to find out.

acer

Could you let us know, which interpretation was it? Markov chains and transition matrices, or just plain old linear algebra and diagonalization?

Inquiring minds would love to find out.

acer

`testfloat` or verify,float might be better still than is@fnormal.

acer

`testfloat` or verify,float might be better still than is@fnormal.

acer