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

Hi Axel, How about this,

fname := "D:\\temp\\minttemp.txt";

ps. Axel, I still "owe" you a promised post on the Compiler and C function-pointer stuff.

acer

A useful suggestion, djc.

I wonder why `expand/Sum` and `student/expand/Sum` differ in this way. (Are students less likely to handle infinite bounds?!)

interface(verboseproc=3):
eval(`expand/Sum`);
eval(`student/expand/Sum`);

acer

A useful suggestion, djc.

I wonder why `expand/Sum` and `student/expand/Sum` differ in this way. (Are students less likely to handle infinite bounds?!)

interface(verboseproc=3):
eval(`expand/Sum`);
eval(`student/expand/Sum`);

acer

Yes, I already pointed out that the wording of the error message was not good.

I mentioned that I didn't have Maple in front of me at the time, to check which symbolic quantity would act differently. As usual when I go by memory, I get the idea right but the detail wrong.

> Pi(17);
                                    Pi(17)
 
> Pi(17.0);
                                   Pi(17.0)
 
> evalf(Pi(17));
                                    Pi(17)
 
> evalf(Pi(17.0));
                                   Pi(17.0)

There are lots of expressions in Maple which evaluate to numeric under evalf, but which would not do so if first applied to an argument (as if they were operators).

Brushing off the expression/operator distinctions, even if only for (complex) numeric values, if a bad habit, and is asking for future trouble.

acer

Yes, I already pointed out that the wording of the error message was not good.

I mentioned that I didn't have Maple in front of me at the time, to check which symbolic quantity would act differently. As usual when I go by memory, I get the idea right but the detail wrong.

> Pi(17);
                                    Pi(17)
 
> Pi(17.0);
                                   Pi(17.0)
 
> evalf(Pi(17));
                                    Pi(17)
 
> evalf(Pi(17.0));
                                   Pi(17.0)

There are lots of expressions in Maple which evaluate to numeric under evalf, but which would not do so if first applied to an argument (as if they were operators).

Brushing off the expression/operator distinctions, even if only for (complex) numeric values, if a bad habit, and is asking for future trouble.

acer

If I recall, that error can occur when expressions and procedures are mixed. It's not a very clear wording. I don't have Maple right now, but you might try,

fsolve( tt->zerovalue(tt)-8, 195..200);

fsolve( 'zerovalue'(tt)-8, tt=195..200);

While Maple can treat 8 as an operator -- 8(17) gives 8, etc -- it's not true of general symbolic or exact radical numeric quantities. So it seems more consistent to disallow 8 to be used alongside zerovalue, than to have a more confusing behavioural discrepency between 8 and sqrt(2) say.If I recall, not everyone agrees on this.

acer

If I recall, that error can occur when expressions and procedures are mixed. It's not a very clear wording. I don't have Maple right now, but you might try,

fsolve( tt->zerovalue(tt)-8, 195..200);

fsolve( 'zerovalue'(tt)-8, tt=195..200);

While Maple can treat 8 as an operator -- 8(17) gives 8, etc -- it's not true of general symbolic or exact radical numeric quantities. So it seems more consistent to disallow 8 to be used alongside zerovalue, than to have a more confusing behavioural discrepency between 8 and sqrt(2) say.If I recall, not everyone agrees on this.

acer