Werner Exinger wrote:
Did you take the wrong expression or is the "1/" cut off from the screenshot?
But I doubt the result anyway - all values being 32????
Yes is cut off from the screeenshot. if k = 100 then s(k)= 64
Now its getting really funny.
I did it in Derive and the result is always k, so far. beginning from k=6 I had to use numeric approximation as Derive could not simplify the resluting expression.
Whats going on here.
I don't know how to evaluate that limit manually, but Derive's results look reasonable.
Jan Kowalski 编写:
I think you have meet the next mathcad problem, mathcad's calculation precision is 10^17 (if you have chosen the high precision pattern in the "tool" menu), that is mathcad can only display and calculate the front 17 number of a long digits number when the "float" symbolic function disabled.
Several days ago, I used to solve Project Euler by mathcad, and meet this problem when I calculate 2^1000 and 100! (the problem 16 and 20), mathcad can't solve its, even I use "float" symbolic funcion as " float,250 --->" (250 is the maximum digit that "float" can display). But I have already solve that 2 problem by using trunc() function and "float". 
Dont confuse symbolic and numeric evaluation. These are completely different sections in Mathcad.
The symbolics is not limited to 17 decimal places and does not face the upper limit of 10^307 (which in fact is 1.797..*10^308 (= 2^1024 - 1)). A limit one sometimes can overcome using logarithms (see: http://communities.ptc.com/message/195099#195099) but I don't think that this would be a solution here.
The limits for the smbolics are not known to may (display is up to 250 places, but in doung symbolics you should not use float anyway). It would be good if symbolics would work internally with integers only (as e.g. Derive does). So the limits are insatlled/usable memory and your patience only. This seems not to be the case with muPad (the symbolic engine in Mathcad).
I try to summarize here:
There is a limit consisting of a couple of summands and a root which
- for three summands is symbolically calculated correectly on some installations of Mathcad 15 M020 and is not evaluted at all on other installtions. Same version and maintainance release
- beginning from four summands, on the installations which work for three Mathcad mathcad delivers wrongs results for some/most number of summands (4, 8-15,....).
Neverteless I won't open a case at PTCs submit page as of bad experiences with that. In the past when reporting an error there where three diferent reactions possible:
- being called back (very quickly) by a (very friendly) person with obviously minor mathematical/programming knowledge which, after a second call back assured me that the error is already known and will be addresed in the next maintainance release (which it was not, but it was later in MC15).
- After submitting screenshot and worksheet for everybody to reproduce the error the person on the phone (callback again) tried to talke me insisting to participate in a kind of video chat with another person. My spoken English being less than mediocre and feeliong very uncomfortable to do so I refused. There was no reason to talk anyway as the sheet and screenshot shows clearly the error.
- No reaction at all.
Werner Exinger 编写:
Dont confuse symbolic and numeric evaluation. These are completely different sections in Mathcad.
The symbolics is not limited to 17 decimal places and does not face the upper limit of 10^307 (which in fact is 1.797..*10^308 (= 2^1024 - 1)). A limit one sometimes can overcome using logarithms (see: http://communities.ptc.com/message/195099#195099) bu I don't think that this would be a solution here.
What you say and the link is very useful for me! Thank you very very much. Yes, I do with the huge number ever used a wrong method. Sorry to disturbing you sir.
I use MuPad calculate this limit problem, the result is just the same as in mathcad, f(4)=3, f(8)=7, and f(100)=64. Seemly MC and Mupad have the same symbolic computing program.
It is almost a pity about mathcad & Mupad, maybe the better method to solve this matter (it's only a trick and really not very important to engineering work) is to run it on a more acdemic math program.
Today I have learn a lot from here, thank you again.
Another problem with Mathcad(15 and Prime 2) is unable to calculate the limit.
I'm waiting I'm waiting, and nothing.
Jan Kowalski wrote:
Another problem with Mathcad(15 and Prime 2) is unable to calculate the limit.
I'm waiting I'm waiting, and nothing.
Yes, the other way round is easier 😉
I have one friend - one mathematics teacher at my university. She has a hobby - collecting mathematical problems that she can solve but mathematical packages (Ma..., Ma..., Ma..., Ma..., Ma...) cannot solve.
She is very upset when one package together with one professional is certainly able to solve one of her problems from the collection. 
The original limit here works ok for me in M15, but doesn't in Prime 2. Prime also produces another interesting (and incorrect) result for an equivalent variant:
Alan
Well Harvey, what you say really simplify this problem, and fasten the worksheet's calculation speed.
and if I use infinity directly instead of using limitation function, the result is like Alan's
and it's very interesting that play in maple, no one is right, except use real number:
