FPGA Central

In another thread, I asked why my plots did not *RESEMBLE* Rick Lyons'
'textbook' examples. I received many informative responses. Some pointed
out "gotchas" that newbies such as myself often miss. Other responses
addressed issues which can trip up gurus. I wish to address some issues
in the 2nd category although I'll complicate issue by being a newbie

I wish to investigate/evaluate/? windowing functions.
I make an underlying assumption that knowing/understanding the FFT of a
time domain windowing function is crucial.

I started with a rectangular window.
{ It's crude but easily reproduced }

Based on some 'a priori' assumptions/presumptions, I chose 90% as a
appropriate duty cycle.

I plotted 2 cases and got widely different results.
[ see http://users.erols.com/jyavins/Owlett.htm ]

the scilab code for first is
a(1:899)=1;
a(900:1000)=0;
plot2d( [1:1000], abs(fft(a,-1)), logflag="nl")

the scilab code for second is
a(1:89)=1;
a(90:100)=0;
plot2d( [1:100], abs(fft(a,-1)), logflag="nl")

Making them more general

a(1:AA)=1;
a((AA+1):BB)=0;
plot2d( [1:BB], abs(fft(a,-1)), logflag="nl")

I suspect that for a "clean" plot AA and BB should be relatively prime.
I suspect AA and BB should *EACH* be prime.

Am I on the right track?

Richard Owlett wrote:

> In another thread, I asked why my plots did not *RESEMBLE* Rick Lyons'
> 'textbook' examples. I received many informative responses. Some pointed
> out "gotchas" that newbies such as myself often miss. Other responses
> addressed issues which can trip up gurus. I wish to address some issues
> in the 2nd category although I'll complicate issue by being a newbie
>
> I wish to investigate/evaluate/? windowing functions.
> I make an underlying assumption that knowing/understanding the FFT of a
> time domain windowing function is crucial.
>
> I started with a rectangular window.
> { It's crude but easily reproduced }
>
> Based on some 'a priori' assumptions/presumptions, I chose 90% as a
> appropriate duty cycle.
>
> I plotted 2 cases and got widely different results.
> [ see http://users.erols.com/jyavins/Owlett.htm ]
>
> the scilab code for first is
> a(1:899)=1;
> a(900:1000)=0;
> plot2d( [1:1000], abs(fft(a,-1)), logflag="nl")
>
> the scilab code for second is
> a(1:89)=1;
> a(90:100)=0;
> plot2d( [1:100], abs(fft(a,-1)), logflag="nl")
>
> Making them more general
>
> a(1:AA)=1;
> a((AA+1):BB)=0;
> plot2d( [1:BB], abs(fft(a,-1)), logflag="nl")
>
> I suspect that for a "clean" plot AA and BB should be relatively prime.
> I suspect AA and BB should *EACH* be prime.
>
> Am I on the right track?

It depends what you mean by "clean". If you can't get useful results
with whatever AA and BB apply to your problem, you need to better
understand the tools.

Much of your initial difficulty arose from using log plots. While zero
is not a reliably obtainable result with quantized floating-point math,
"as small as makes never-no-mind" (AKA smaller than a pixel) is. Since
log plots spread small values apart, no quantity is as small as a pixel
on a log plot. The upshot is that on log plots of calculations that
could theoretically go to zero, the moiré between the pixel distance and
the location of plotted points will be almost inevitably obvious. The
effect appears in linear plots too, but it is usually less pronounced.

Making those spacings relatively prime won't help. Carefully matching
the calculation steps to the pixel distance might.

Jerry

P.S. http://users.erols.com/jyavins/Owlett.htm is updated to show your code.
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry Avins wrote:
>
> Much of your initial difficulty arose from using log plots.

Hmm, you've said that before.
Rick mentioned it
Others observed

It just sunk in ;{
( BTW there is clinical evidence that my skull is denser than average
( now we wait for bad bone head puns )