While working on the solution of a question in another thread I stumbled upon this descrapancy which I cannot explain. It seems to have nothing to do with the fact, that a vector index of -1 would be involved, as the reaction is the same if ORIGIN is set to -1.
maybe summation and product are not intended to count down, but we are counting down in both examples, the only difference is that I replaced k-1 by -1 as k=0 is the only value k can take in the example. BTW, the expressions are supposed to be evaluated symbolical only.
If somebody is interested, the thread in question is http://communities.ptc.com/message/195245#195245
Werner Exinger wrote:
While working on the solution of a question in another thread I stumbled upon this descrapancy which I cannot explain. It seems to have nothing to do with the fact, that a vector index of -1 would be involved, as the reaction is the same if ORIGIN is set to -1.
maybe summation and product are not intended to count down, but we are counting down in both examples, the only difference is that I replaced k-1 by -1 as k=0 is the only value k can take in the example. BTW, the expressions are supposed to be evaluated symbolical only.
If somebody is interested, the thread in question is http://communities.ptc.com/message/195245#195245
Valery picked up on it recently ... http://communities.ptc.com/message/193410#193410 ... there is a difference in the way the symbolic processor handles iterating down and iterating up with the sum and product operator.
StuartBruff schrieb:
Valery picked up on it recently ... http://communities.ptc.com/message/193410#193410 ... there is a difference in the way the symbolic processor handles iterating down and iterating up with the sum and product operator.
I don't think that its the same effect. In the thread you mentioned the effects can be explained. Sums and products seem to default to iterating up. This has effect only in symbolic evaluation with unknown limits, so you cannot compare it to numerical evaluation. If you sum 1's for i=n to i=1, Mathcad assumes a summing up and therefore assumes n has to be smaller or equal to 1. So your function fn1(n) in that thread is valid only for arguments <=1. You invoked it with n=100 and naturally(?) got a wrong result. It may be a strange logic but the alternative would be that the symbolic evaluation of that sum is an "..if...otherwise" expression, which would not be that helpful in most cases. The formula n*(n+1)/2 is valid only for n>=1.
You my want to take a look at my posting in that thread http://communities.ptc.com/message/193542#193542
Maybe the whole thing has todo woth the fact, that muPad defaults to domain complex. Look at the following error and its fix:
In case of this new question the upper limit of the product is known. It is -1 in both cases, so Mathcad knows (should know) it is supposed to work downwards. If the upper limit is written as -1 it does, if its written as k-1 and k is set to 0 in the outer sum, it doesn't.
