[10305] in Athena Bugs
that Maple error
daemon@ATHENA.MIT.EDU (zeno@Athena.MIT.EDU)
Mon Feb 22 21:16:27 1993
From: zeno@Athena.MIT.EDU
Date: Mon, 22 Feb 93 21:16:22 -0500
To: bugs@Athena.MIT.EDU
Cc: cohn@Athena.MIT.EDU
cohn@athena says:
>
> What were you trying to do?
> I asked Maple to do the following sum:
> sum(1/n^n,n=1..infinity);
>
> What's wrong:
> It replied as follows: Zeta(n)
>
> This doesn't even make sense, since n is just a dummy variable.
True, it doesn't make sense. But somehow Maple has treated the exponent n
as a constant, separate from the sum variable n, as if you had asked for
sum(1/k^n, k=1..infinity) . This is, of course, precisely the definition
of zeta(n) and there's no general closed-form expression for it. So this
wouldn't have been an unreasonable answer on Maple's part if it weren't for
the confusion about the variable(s). (Don't know if this will help in
tracking down the Maple bug, but I thought I'd mention it at least).
As a tangential issue, at least w.r.t. bugs, there's also no closed-form
expression for the sum that was actually requested. Anyway, since 60^{-60}
is less than 10^{-99}, so that dc thinks it's 0 when using 99 decimals (the
maximum), the following gives the desired sum to that limit of accuracy,
more or less:
echo '99k 60 [dddd+-^lt+st1-d0<x]sx lxx ltp' | dc
--> 1.291285997062663540407282590595600541498619368274522317310002445136944\
538765234455558817041129429687
