[sdiy] 90-degree phase displacement network calculations

Tue Jan 12 10:31:10 CET 2021

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.

>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.

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.

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.

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.

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

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.

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!

Guy.

On Mon, Jan 11, 2021 at 11:57 PM David G Dixon <dixon at mail.ubc.ca> wrote:

> 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.
>
> 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:
>
> 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.
>
> How's that for an analytical and thought-provoking response?
>
>
>
>
>
> -----Original Message-----
> From: Michael E Caloroso [mailto:mec.forumreader at gmail.com
> <mec.forumreader at gmail.com>]
> Sent: Monday, January 11, 2021 3:29 PM
> To: David G Dixon
> Cc: Ian Fritz; Bernard Arthur Hutchins, Jr; synth-diy at synth-diy.org;
> Brian Willoughby
> Subject: Re: [sdiy] 90-degree phase displacement network calculations
>
> [CAUTION: Non-UBC Email]
>
> Well that was a highly analytical and thought provoking conclusion
>
> MC
>
> On 1/11/21, David G Dixon <dixon at mail.ubc.ca> wrote:
> > Hello Ian,
> >
> > Well, I'm getting a bit tired about arguing about this, so my official
> > answer is... whatever.
> >
> > Cheers
> > Dave
> >
> > -----Original Message-----
> > From: Ian Fritz [mailto:ijfritz at comcast.net <ijfritz at comcast.net>]
> > Sent: Monday, January 11, 2021 6:44 AM
> > To: David G Dixon; 'Bernard Arthur Hutchins, Jr';
> > synth-diy at synth-diy.org
> > Cc: 'Brian Willoughby'
> > Subject: Re: [sdiy] 90-degree phase displacement network calculations
> >
> > [CAUTION: Non-UBC Email]
> >
> > That looks not to be true. The difference between two successive k'(i)
> > values clearly can not be zero. The process is a (rapidly) converging
> > iterative one.
> >
> > In case you can't see this, the proof is trivial:
> > Suppose k'(i) = k'(i-1)
> > Then from the second equation, k(i) = k(i-1) Now the first equation
> > yields 0 = k(i)-k(i-1) = [1-k'(i-1)]/[1+k'(i-1)] -
> >   [1-k'(i-2)]/[1+k'(i-2)]
> > This can be generally true only if k'(i-2) = k'(i-1) So by induction,
> > all the k'(i) values are the same.
> >
> > A sequence either iterates or it doesn't -- it can't just drop dead in
> > the middle of the street.
> >
> > Ian
> > (math minor, including some pretty tough analysis courses)
> >
> >
> > On 1/11/2021 2:23 AM, David G Dixon wrote:
> >
> >> ........  There are no "approximate" answers, and this problem is not
> >> one where one gets closer and closer to the true solution with each
> >> step.  That would be an iterative solution, and as I've said ad
> >> nauseum, this is not that problem.
> >
> >
> >
> > _______________________________________________
> > Synth-diy mailing list
> > Synth-diy at synth-diy.org
> > http://synth-diy.org/mailman/listinfo/synth-diy
> > Selling or trading? Use marketplace at synth-diy.org
> >
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20210112/e6aa6f63/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pole.png
Type: image/png
Size: 14884 bytes
Desc: not available
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20210112/e6aa6f63/attachment.png>