Limit value sought

[AlfredFlaßhaar]

The attached MC14 file is looking for a limit. The result should be -pi^2/8. My attempts failed. Only with the help of good old derive did I manage it. How does this work in MC14?

[Werner_E]

Mathcad's capabilities in symbolic calculation are of course clearly inferior to those of Derive, Maple or Mathematica - at least since they switched the symbolic engine from Maple to muPad.

But I doubt that the limit of the function f(k) you defined is somewhere near the value you name:

Furthermore it does not make much sense to demand n<>m for at least two reasons:

.) Your function definition does not use any variable n

.) m is the index variable of the sum and you can't exclude single values here.

For example you can't define a function like

and hope that an evaluation like

would yield the result 3 because k=2 is excluded.

I don't think that it matters but you wrote

but its not possible to approach infinity from above/from the right.

Guess you rather meant

and not

When using infinity or minus infinity as limit its not necessary to state the direction of approaching it.

[AlfredFlaßhaar]

The calculated result is at least the absolute value of pi^2/8. This was achieved using various approaches. The problem simply requires calculating the double series of summands 1/(m^2+n^2). The necessary constraint that m is not equal to n is, of course, quite challenging. And experience has shown that the so-called Great Rearrangement Theorem (Cauchy's Double Series Theorem) must also be observed, which states that commutation of the series summands is only permitted under absolute convergence. I was just hoping that MC could do it if derive could :-(.

[Werner_E]

I really don't understand which limit you are actually looking for!

It seems to me that you used the result of your first region when defining your function f(k). But why didn't you have used this result as it is by copy and paste - why did you reTYPE it? And why didn't you simply use the symbolic result in defining f(k) like

Obviously you have this expression in mind but want to exclude the terms where m=n.

Various ways to define this function come to my mind.

Most obvious is using a program with two nested loops

But because we are using an if-statement, the symbolics chokes on it.

We could use the Kronecker delta

a Boolean expression

or simply subtract the unwanted summands

f3 is way faster when it comes to numerical evaluation and all but f0 can also be 'simplified' symbolically.

But none would simplify in a way to give a meaningful result when used in the limit expression.

Furthermore I can't see how you would get a negative result like - pi^2/8 by adding all positive values!!??
And the series seems to be continually increasing .... So the limit, if it exists, would be larger than f(10^4)=12,8...

So the main question is - the limit of which series you are really looking for?

EDIT: I also added the file in MC11 format in case that @LucMeekes  wants to give it a try using MC11 with Maple engine.

[AlfredFlaßhaar]

I accidentally made a mistake in the original problem, for which I apologize. The summand must be 1/(m^2 - n^2). The problem should now be clear.

[Werner_E]

Wouldn't the double sum always be zero with this modification? At least for finite k.

[AlfredFlaßhaar]

For a finite number of summands, the result is 0, because commutation of the summation is then permitted, and every summand also appears with the opposite sign. For an infinite number of summands, this applies, among other things, according to the aforementioned theorem only in the case of proven absolute convergence of the double series (there are even more general theorems, but they are not necessary here). Thus, for example, according to the usual index-based arrangement of the summands in a matrix with, for example, rows numbered with index m and columns numbered with index n, the series summation must be performed row-by-row and column-by-column without exchanging the summands. Then, the "inner sum" plus the "outer sum" of the double series must be processed.

[Werner_E]

Then I would be interested in screenshots (don't have Derive installed on my machine) of your success with the Derive calculation.

[AlfredFlaßhaar]

Attached are the PDFs for the problem. I found the problem while "cleaning up" and in a book. It reminded me how difficult it was back then to find a solution. It doesn't involve summing column by column or row by row. I was able to replicate this in Derive. The current reason for this problem is my interest in how software handles tasks with constraints.

[Werner_E]

I wonder about step #9 and the summand - 3/(4 m^2) which, at the end, is responsible for the non-zero result.

In my attempts I also used parfrac and ended up with an expression containing the 3/(4 m^2) as well, but because this expression also contained an infinite sign, it could not be used for further calculations

[AlfredFlaßhaar]

I've changed the text between #3 and #4. I should have copied more carefully from my pile of paper. Regarding your question #9:

"Der ursprüngliche Summand und #2 sind daher identisch mit #3. Darstellung der Summe über n als Differenz zweier harmonischer Summen, eine summiert bis N+m und die zweite summiert bis N-m.

Umformung ergibt:

sum(1/(m^2-n^2)(1 bis N) = -1/(2*m)*sum((1/(n-m)-1/(n+m))(1 bis N) = 1/(2*m)*{sum(1/k)[1 bis N+m]-sum(1/k)[1 bis N-m]}-3/(4*m^2)
Dazu Auswertung des letzten Terms durch Nebenrechnung in #21 und #22. Zu beachten ist, daß die obere Summationsgrenze durch Wahl des "neutralen" Summanden 1/k angepaßt werden muß und zu N+m bzw. N-m wird:"

[Werner_E]

OK, diese Nebenrechnung #21 & #22 fehlt also im Screenshot.

Das Problem bei Mathcad 14/15 ist, dass der Summationsoperator nicht gemäß der mathematischen Definition implementiert ist und auch Werte ungleich Null liefert, wenn der obere Summationsindex kleiner ist als der untere.

In MC14/15 agieren Numerik und Symbolik gleich, in MC11 agiert die Symbolik anders, wie @LucMeekes  gezeigt hat.+

Im vorhin geposteten Ausdruck waren Vorzeichen falsch

in  einem Rutsch geht's aber leider nicht

Dass zuerst der Grenzwert der inneren Summe ausgewertet werden muss und dann erst dessen Grenzwert entspricht mMn aber nicht den Regeln für die Grenzwertbildung.

Dadurch wird aber offenbar die nicht normgerechte Implementation der Summme neutralisiert - sonst müsste ja die erste Summe im inneren Term einen "Division durch Null" Fehler auslösen, wenn zB m=2 ist und bei der Summation von 1 bis -1 dann auch k=0 gesetzt wird.

Das Vorzeichen passt auch nicht - vermutlich hab ich schon bei der PBZ geschludert. Hab mir gestern die Terme nur auf einem nicht mehr existierenden Schmierzettel schnell zusammengebastelt. Müsste man nochmals sauberer herleiten, aber grundsätzlich funktioniert die Methode offenbar.

[LucMeekes]

OK. First check some properties of Mathcad 11:

to see that the symbolic processor handles funny summation limits differently.

With this we can write the function as:

thus omitting the case where m=n for symbolic evaluations.

Now for k=1 through 25 we get:

But as of k=26:

and the list grows as k increases. The small thin line below here contains f(333):

But notice that:

and also:

The limit for k -> infinity resulted in an error: No symbolic result.

Symbolic calculation of f(3333) crashed Mathcad.

Success!
Luc

[terryhendicott]

Hi Alfred,

Not using symbolics but number crunching by brute force gets limit ~ 0.8225

This is function 3 by Werner

A short program to work it up

Gets this after a very long wait.

Or graphically

Note if you use:

it does not converge and gives a straight line upward to the right on the log plot,

Cheers

Terry

[Werner_E]

Alfred later corrected his first post and said that is should read m^2 - n^2 instead of m^2 + n^2,

Working functions can be seen here: https://community.ptc.com/t5/Mathcad/Limit-value-sought/m-p/1007150/highlight/true#M216635

But because of symmetry the return zero as result for all finite k

[Werner_E]

OK, hier nun der etwas sauberere Anschrieb - diesmal ohne Vorzeichenfehler.

Schade nur, dass Mathcad den intuitiven direkten Ansatz für die Summen, wie zB

nicht verwenden kann und man daher auf die Substitution k=m-n zurückgreifen muss

Und dann war es auch noch nötig gerade bei dieser Summe die Summationsreihenfolge zu ändern,

damit Mathcad letztlich ein Endergebnis ausspuckt.

Da ist in Summe doch unbefriedigend viel Handarbeit und Probieren nötig gewesen 😞

Aber wenigsten hat, wie oben schon beschrieben, die nichtmathematische Implementierung des Summenoperators nicht auch noch in die Suppe gespuckt.

Hier die Herleitung, wobei durch die PBZ und das Bilden der einzelnen Summen aber die ursprünglich vorgegebene Reihenfolge der Summation verändert wurde!

Ich denke, dass die Aufgaben

und

(jeweils mit m<>n) zwei unterschiedliche sein dürften. Letztere ist ja die Frage nach dem Grenzwert der konstanten Nullfolge, den man wohl mit 0 angeben muss, oder?

[AlfredFlaßhaar]

Um Mißverständnisse zu vermeiden, nun muttersprachlich:

Ihre Lösung in MC ist im besten Sinne beeindruckend :-). Zur Frage der "konstanten Nullfolge" gilt, daß die Summe "Null" sich erst nach erlaubter Anwendung des Kommutatiosgesetzes für endliche Summen ergibt. Im Grenzfall gilt dies nicht und ein Grenzwert "Null" kann daher in diesem Fall nur durch Definition erzeugt werden. Erst mit Nachweis absoluter Konvergenz der Reihe darf vorher kommutiert werden.

Für Doppelreihen gilt (Knopp, Theorie und Anwendung der unendlichen Reihen):

Eine Doppelreihe besteht aus Summanden, die selber Reihen sind. Eine Doppelreihe besteht also aus einer inneren Summe, die die Summanden für die äußere Reihe liefern -  beide Reihen mit jeweils voneinander unabhängigem Indexverlauf (insbesondere die obere Summationsgrenze). Letzteres war für mich damals der Schlüssel zum Erfolg und bot die Möglichkeit, derive anzuwenden. Daher ist auch ganz im Sinne des Großen Umordnungssatzes (Cauchy) und den Sätzen über Reihentransformation (z. B. Markoff) bei Doppelreihen spalten- bzw. zeilenweise in der üblichen Doppelreihenmatrix vorzugehen. Für die hier behandelte Aufgabe bedeutet es, daß von Anfang an endliche Summen ohne Kommutation zu behandeln sind.

[Werner_E]

Ich bin in der Theorie nicht so beschlagen, aber was ich meinte war, dass, wenn man die Aufgabe nicht als Berechnung einer undendlichen Doppelsumme. sondern als Suche nach dem Grenzwert einer Folge auffassen wolte, der Grenzwert nicht von Null verschieden sein kann. Entweder ist er also Null oder er exisitiert nicht, Bei Definition der Folgenglieder durch die (endliche) Doppelsumme  liegen in den kleinen epsilon-Umgebungen von -p^2/8 nicht fast alle, sondern kein einziges Folgenglied. Es kann also sich nicht für jedes epsilon>0 ein N angegeben werden, sodass für n>N alle Folgenglieder in der Epsilon-Umgebung von -p^2/8 liegen. Und das wäre ja meines Wissens die Definition für den Grenzwert einer reellwertigen Folge, oder?

Deswegen meinte ich, dass die Aufgabe, den Grenzwert dieser Folge zu bestimmen sich von jener, die unendliche Doppelsumme zu bestimmen, unterscheidet.

[AlfredFlaßhaar]

Der Grenzwert aus der Folge der von den durch Kommutation der in den Folgegliedern endlich vielen Summanden erzeugten Folge aus lauter Nullen existiert zunächst nicht, ist aber nachträglich definierbar. Ihr letzter Satz zum Unterschied zwischen der Nullenfolge und dem Grenzwert der Doppelreihe ist aus meiner Sicht zutreffend - es sind verschiedene Aufgaben.