[sdiy] 90-degree phase displacement network calculations

David G Dixon dixon at mail.ubc.ca
Tue Jan 12 19:34:09 CET 2021


I think that the key concept here is that the pole calculation is an exact,
closed-form expression based on elliptic sine and cosine.  Also, the period
of the elliptic sine and cosine is given by the modulus.
 
The only "iterative" thing here is that mathematicians have so far failed to
give us a convenient way to calculate the elliptic functions.  However, I
have demonstrated that a simple function call in Excel is possible.
 
So, ask yourself this question:  What if there had been built-in Excel
functions for sn(u,k) and cn(u,k), and another function call for the period,
such that the functions could have been calculated by, say,
SN(3*SNPERIOD(k)/64,k)?  If such functions were available in Excel already,
would there have been any argument that this wasn't a closed-form solution
to the filter pole problem?  I would suggest that there would not.
 


  _____  

From: Liam Wall [mailto:liam.wall at gmail.com] 
Sent: Tuesday, January 12, 2021 2:40 AM
To: Guy McCusker
Cc: David G Dixon; synth-diy at synth-diy org; Bernard Arthur Hutchins, Jr;
Brian Willoughby
Subject: Re: [sdiy] 90-degree phase displacement network calculations


[CAUTION: Non-UBC Email] 
Thanks David for sharing this stuff.

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.


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.


On Tue, 12 Jan 2021 at 09:33, Guy McCusker <guy.mccusker at gmail.com> wrote:


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>
mailto: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> mailto: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>
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


_______________________________________________
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/d69933b3/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/d69933b3/attachment.png>


More information about the Synth-diy mailing list