<div dir="ltr"><div>Thanks David for sharing this stuff.</div><div><br></div><div>Agree with what Guy has said below, and would add to that all the same applies to standard sine, exp, ln, and sqrt --- these are functions that we can't compute exactly for all input values, but we know how to compute sufficiently good approximations in a known (short) time. All considered "closed form". As far as I can tell "closed form" isn't really a precisely defined mathematical term. In fact, quoting the opening line of the Wikipedia page "The set of operations and functions admitted in a closed-form expression may vary with author and context". So are sn and K in or out? It's pretty much arbitrary.<br></div><div><br></div><div>I've no idea how much accuracy Excel can manage. I think floating point doubles are 64 bits in most languages? In the interests of science I calculated the k'(i) series starting with k'(0)=0.0001 using 2048 bit floating point values (the most I have handy). Excel gave David k'(6)=1.0; all the extra bits gave k'(6)=0.9999999999990897, and k'(7) == 1.0.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 12 Jan 2021 at 09:33, Guy McCusker <<a href="mailto:guy.mccusker@gmail.com">guy.mccusker@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">While I agree with David that it is essentially fruitless to argue over whether something is "iterative" or "recursive", trying to figure out how I would describe this algorithm gave me the impetus I needed to study it a bit, so it helped me at least. <div><br></div><div>From a computational perspective, iteration and recursion are equivalent, and they both describe processes that may in principle be non-terminating. But there is a difference in the spirit of how things are expressed. Iteration somehow means "do these steps again and again" while recursion means "compute this function in terms of other invocations of itself". (The computational equivalence means you can always hack one to look like the other so the distinction is not at all sharp really.) A very common use of "iteration" is "do these steps again and again until some calculated error is small enough." With that in mind I looked at the theory and practice of what David is doing here. </div><div><br></div><div>The expressions for the poles in terms of elliptic functions are exact. However they rely on the elliptic integral which requires some work to compute. David uses the Landen transformation to do this. Again, the Landen transformation is exact. No approximations are in play... yet.</div><div><br></div><div>The equations David wrote for computing sn via the Landen transformation are recursive in spirit: the equations show how to calculate sn( , ) using an expression ** which also contains calls to sn( , ) **. That is what gives it a recursive nature in my eyes. The equations also show when this recursion can terminate: when the "k" term is zero, sn reduces to sin, which presumably we know how to compute, so we do not need to perform further recursive calls.</div><div><br></div><div>However, if computing *exactly*, the recursion will never terminate, as Ian Fritz pointed out -- the k term in the recursive calls will never become exactly zero. </div><div><br></div><div>For practical purposes we don't need it to be exactly zero: it just needs to be close enough that sin is a good enough approximation to sn. What David's code does is to compute the sequence of k values until they get close enough to zero. This computation feels like an iterative approximation, though I could live with it being called recursive</div><div><br></div><div>David has determined that 8 steps are enough to get close enough for his purposes, which may simply mean close enough that Excel thinks the answer is 0. Once that is accepted, we have a fixed way to calculate good approximations to the values we are looking for. </div><div><br></div><div>Well, that's my take on all this anyway. I'm finding this interesting from both a mathematical and a practical point of view. This list is great!</div><div><br></div><div>Guy.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 11, 2021 at 11:57 PM David G Dixon <<a href="mailto:dixon@mail.ubc.ca" target="_blank">dixon@mail.ubc.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p><font size="2" face="Courier New">Well, Michael, we're basically arguing about
the meaning of the words "iteration" and "recursion" at this point, and I find
this argument to be utterly fruitless.<br><br>To me, iteration is something that
is required when approximate solutions are sought and the criterion is
convergence. The solution to the phase displacement problem is
exact. The poles are given by the following closed-form
equation:<br><br><img alt="" src="cid:176f5da9b6d204896f31" hspace="0" border="0" align="bottom"></font></p>
<p><font size="2" face="Courier New">The only recursive part of this whole problem
is that 2K is a function of k' which must be determined by a recursive process
(as far as I know). This is a feature of elliptic sines and has nothing to
do with the filter pole calculation, which is completely closed form.
Elliptic functions differ from circular functions in that the latter have fixed
periods (2*pi), but the former have periods which are functions of their modulus
k. However, the period is a unique function of the modulus. Hence,
when you specify the modulus you are also specifying the period. However,
to actually calculate the value of the period from the modulus, you need to
engage in a recursive calculation. THIS IS NOT ITERATION. We are not
approximating or approaching some idealized solution by iterating to the correct
period. The period is determined by the modulus -- there is nothing
approximate about it. The solution to this problem is exact.</font></p>
<p><font size="2" face="Courier New">How's that for an analytical and
thought-provoking response?</font></p>
<p><br><br><br><br><font size="2" face="Courier New">-----Original
Message-----<br>From: Michael E Caloroso [</font><a href="mailto:mec.forumreader@gmail.com" target="_blank"><font size="2" face="Courier New">mailto:mec.forumreader@gmail.com</font></a><font size="2" face="Courier New">]<br>Sent: Monday, January 11, 2021 3:29 PM<br>To: David G
Dixon<br>Cc: Ian Fritz; Bernard Arthur Hutchins, Jr; <a href="mailto:synth-diy@synth-diy.org" target="_blank">synth-diy@synth-diy.org</a>;
Brian Willoughby<br>Subject: Re: [sdiy] 90-degree phase displacement network
calculations<br><br>[CAUTION: Non-UBC Email]<br><br>Well that was a highly
analytical and thought provoking conclusion<br><br>MC<br><br>On 1/11/21, David G
Dixon <<a href="mailto:dixon@mail.ubc.ca" target="_blank">dixon@mail.ubc.ca</a>> wrote:<br>> Hello Ian,<br>><br>> Well,
I'm getting a bit tired about arguing about this, so my official<br>> answer
is... whatever.<br>><br>> Cheers<br>> Dave<br>><br>>
-----Original Message-----<br>> From: Ian Fritz [</font><a href="mailto:ijfritz@comcast.net" target="_blank"><font size="2" face="Courier New">mailto:ijfritz@comcast.net</font></a><font size="2" face="Courier New">]<br>> Sent: Monday, January 11, 2021 6:44 AM<br>> To:
David G Dixon; 'Bernard Arthur Hutchins, Jr';<br>>
<a href="mailto:synth-diy@synth-diy.org" target="_blank">synth-diy@synth-diy.org</a><br>> Cc: 'Brian Willoughby'<br>> Subject: Re:
[sdiy] 90-degree phase displacement network calculations<br>><br>>
[CAUTION: Non-UBC Email]<br>><br>> That looks not to be true. The
difference between two successive k'(i)<br>> values clearly can not be zero.
The process is a (rapidly) converging<br>> iterative one.<br>><br>> In
case you can't see this, the proof is trivial:<br>> Suppose k'(i) =
k'(i-1)<br>> Then from the second equation, k(i) = k(i-1) Now the first
equation<br>> yields 0 = k(i)-k(i-1) = [1-k'(i-1)]/[1+k'(i-1)]
-<br>> [1-k'(i-2)]/[1+k'(i-2)]<br>> This can be generally true
only if k'(i-2) = k'(i-1) So by induction,<br>> all the k'(i) values are the
same.<br>><br>> A sequence either iterates or it doesn't -- it can't just
drop dead in<br>> the middle of the street.<br>><br>> Ian<br>> (math
minor, including some pretty tough analysis courses)<br>><br>><br>> On
1/11/2021 2:23 AM, David G Dixon wrote:<br>><br>>> ........ There
are no "approximate" answers, and this problem is not<br>>> one where one
gets closer and closer to the true solution with each<br>>> step.
That would be an iterative solution, and as I've said ad<br>>> nauseum,
this is not that problem.<br>><br>><br>><br>>
_______________________________________________<br>> Synth-diy mailing
list<br>> <a href="mailto:Synth-diy@synth-diy.org" target="_blank">Synth-diy@synth-diy.org</a><br>> </font><a href="http://synth-diy.org/mailman/listinfo/synth-diy" target="_blank"><font size="2" face="Courier New">http://synth-diy.org/mailman/listinfo/synth-diy</font></a><br><font size="2" face="Courier New">> Selling or trading? Use
<a href="mailto:marketplace@synth-diy.org" target="_blank">marketplace@synth-diy.org</a><br>><br></font></p></div>
_______________________________________________<br>
Synth-diy mailing list<br>
<a href="mailto:Synth-diy@synth-diy.org" target="_blank">Synth-diy@synth-diy.org</a><br>
<a href="http://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" target="_blank">http://synth-diy.org/mailman/listinfo/synth-diy</a><br>
Selling or trading? Use <a href="mailto:marketplace@synth-diy.org" target="_blank">marketplace@synth-diy.org</a><br>
</blockquote></div>
_______________________________________________<br>
Synth-diy mailing list<br>
<a href="mailto:Synth-diy@synth-diy.org" target="_blank">Synth-diy@synth-diy.org</a><br>
<a href="http://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" target="_blank">http://synth-diy.org/mailman/listinfo/synth-diy</a><br>
Selling or trading? Use <a href="mailto:marketplace@synth-diy.org" target="_blank">marketplace@synth-diy.org</a><br>
</blockquote></div>