Sine Lookup Table with Linear Interpolation

I'm lurking in this thread, and it's great (a better s/n than I
expected for such a long thread), until I got to this URL:
On Mon, 18 Mar 2013 17:47:41 -0400, rickman <gnuarm@gmail.com> wrote:

>...
>It is a lot of document for just two pages.  Try this link to see the 
>short version...
>
>arius.com/foobar/1972_National_MOS_Integrated_Circuits_Pages_273-274.pdf

   PLEASE put the http:// thing at the start of any URL - it triggers
most software (such as this Free Agent) to make the URL clickable:

http://arius.com/foobar/1972_National_MOS_Integrated_Circuits_Pages_273-274.pdf

On Sat, 23 Mar 2013 18:02:29 -0400, rickman <gnuarm@gmail.com> wrote:

>On 3/23/2013 2:42 PM, josephkk wrote:
>> On Thu, 21 Mar 2013 17:51:42 -0400, rickman<gnuarm@gmail.com>  wrote:
>>
>>>
>>>>>>>> if you assume an approximate quadratic behavior over that short segment,
>>>>>>>> you can compute the straight line where the error in the middle is equal
>>>>>>>> in magnitude (and opposite in sign) to the error at the end points.
>>>>>>>> that's a closed form solution, i think.
>>>>>>>
>>>>>>> Yes, it is a little tricky because at this point we are working with
>>>>>>> integer math (or technically fixed point I suppose).
>>>>>>
>>>>
>>>> Hmm.  I would like to take a crack at simpson's rule interpolation for
>>>> this to measure error budget.  I may not be timely but this is
>>>> interesting.  joseph underscore barrett at sbcglobal daht cahm
>>>
>>> Oh, I thought you were talking about using Simpsom's rule as part of the
>>> interpolation.  You are talking about using it to estimate the integral
>>> of the error.  Great idea!  I'll shoot you an email.
>>
>> I was talking about using it for interpolation.
>
>The email bounced.

Hmmm.  Not sure just what happened.  Can you see the headers of this news
post?

Plus after getting into my books again i think i can explain just how to
do it without fussing with a spreadsheet.

It is a matter of weighting the coefficients (and using more cardinal
points).

For a section of table spanning 5 (or just 3) cardinal points; we take the
sub-interval centered on the 'nearest' cardinal point. (semi open segment,
-2^n to +2^n-1; where 2*2^n-1 is the number of interpolated points.)  For
5 cardinal points this point gets maximum weight call it 1/2.  The two
points to either side get weighted 1/4 each, and the two outermost
cardinal points get weighted 1/8 each.  For three cardinal points just
eliminate the outer two.  Then the rest of your interpolator tool should
do the rest.

?-)

On 3/26/2013 9:11 PM, josephkk wrote:
> On Sat, 23 Mar 2013 18:02:29 -0400, rickman<gnuarm@gmail.com>  wrote:
>>
>> The email bounced.
>
> Hmmm.  Not sure just what happened.  Can you see the headers of this news
> post?

Yes, and the email address is exactly what I used.  Here it is with the 
address slightly munged.

<joseph_barrett at sbcglobal.com>:
Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too long.


> Plus after getting into my books again i think i can explain just how to
> do it without fussing with a spreadsheet.

The spread sheet isn't important, but I don't have an image of what you 
are talking about below.


> It is a matter of weighting the coefficients (and using more cardinal
> points).
>
> For a section of table spanning 5 (or just 3) cardinal points; we take the
> sub-interval centered on the 'nearest' cardinal point. (semi open segment,
> -2^n to +2^n-1; where 2*2^n-1 is the number of interpolated points.)  For
> 5 cardinal points this point gets maximum weight call it 1/2.  The two
> points to either side get weighted 1/4 each, and the two outermost
> cardinal points get weighted 1/8 each.  For three cardinal points just
> eliminate the outer two.  Then the rest of your interpolator tool should
> do the rest.

One of the things I have realized is that with the table size I am 
using, the curve segments that I am interpolating become very good 
matches to a straight line to within 18 bits.  I have a 512 entry table 
and interestingly enough, there is this give and take between the range 
of the interpolation and the non-linearity of the curve at that point.

The part of the quarter sine table that has the highest step size is at 
zero where the linearity is near dead on.  The part of the table that 
has the worst approximation to linear is at 90 degrees where the step 
size is near zero.  I think in an 18 bit table the step is just one 
count!  So there is not much improvement to be had over simple linear 
interpolation.  In fact, I can't say there is much of an improvement by 
offsetting any of the end point.

If the word width increases from 18 bits, then perhaps there might be 
some advantage to other methods.  But even an 18 bit table gives a 19 
bit result when the sine bit is added.  That is way down there in the 
noise really.  I am looking at a software version and to keep from going 
to double precision I might just drop the extra bit and limit the signed 
result to 18 bits.  This is in a custom processor in an FPGA.  18 bits 
comes from the memory size in the block RAMs.  We'll see.  The 
difference is only near the end of the code section and *something* has 
to be sent out to the CODEC even if the extra bits are just noise in the 
DAC, 24 bits, 90 dB SINAD.  Why so many bits you have to wonder...

-- 

Rick