| Re: bug in IDL's hanning() window-generating function [message #25975] |
Thu, 02 August 2001 19:32  |
Kenneth P. Bowman
Messages: 585
Registered: May 2000
|
Senior Member |
|
|
Without making any comment on your problems with RSI, I can say that at
least the 5.3 and 5.4 releases (and possibly earlier?) have included
all the IDL documentation in PDF format, which in my experience is
vastly superior to either the paper manuals or the old help system.
Also, you can always download the latest version of IDL (including the
documentation) from the RSI web site. We have always found it easy to
install updates.
Ken Bowman
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #25976 is a reply to message #25975] |
Thu, 02 August 2001 18:42  |
bennetsc
Messages: 18
Registered: January 1998
|
Junior Member |
|
|
In article <3B69C65C.74C8539D@noaa.gov>,
Pavel A. Romashkin <pavel.romashkin@noaa.gov> wrote:
> bennetsc@NOSPAMucs.orst.edu wrote:
>>
>> I didn't contact them. I'm disgusted with them after seeing how
>> they cheated my faculty advisor and, when I asked them to rectify
>> their errors, they refused to do so.
>
> Wow. Are you sure it was not a misunderstanding? I have never had a
> problem on a consumer level with RSI. Of course, I am not trying to
> sparkle an outpour of complains by writing this.
My advisor got a couple of IDL licenses back at IDL 5.0, one for
his Mac and one for a Sun, which is the one I use. After 5.1 came
out, the only way we found out about it was when we heard and read
that other sites had gotten their updates and were using them. Later,
we got 5.2, which came as a CDROM and a small book titled _What's_
New_in_IDL_5.2?_. However, that book only covered changes between 5.1
and 5.2, so I didn't have what I needed to start using 5.2 if it were
installed. Eventually, we heard that other people had gotten their
5.3 updates, but we never got one of those either. Other people in
our college also have IDL licenses, so I was able to get the college's
computer/networking support folks to install 5.3 and we did get a
license string from RSI for it. However, without up-to-date
documentation, especially on changes all the way from 5.0 to 5.3,
it was not practical to proceed from 5.0.
I don't recall whether I had contacted RSI before this time
about missing releases and lack of documentation, but at this point
I certainly did. My first attempt was ignored. After waiting more
than adequate time for response from corporate staff that might be
backlogged, I tried again and got a response from a "Technical Support
Engineer," who claimed to have forwarded my message to our "maintenance
rep" and also claimed there would be a charge if we wanted the manuals
we were already supposed to have gotten. (She didn't mention the
CDROMs.) No word was ever received from the "maintenance rep." What
I needed most by this time was an up-to-date version of the _Using_IDL_
book, but probably would have managed fine with a complete sequence
of the _What's_New..._ books. She suggested using the on-line "help"
facility and otherwise gave me the brush-off.
I was and still am quite busy with my work and dealing with
unresponsive software companies isn't really supposed to be taking
up my time, so I did nothing to bring more frustration upon myself
from RSI for some time after that. Eventually, we got a CDROM for
5.4 and a book titled _What's_New_in_IDL_5.4_, which, again, was
insufficient for my needs. So I tried contacting RSI again. This
time a different person responded and, naturally, knew nothing about
the situation, so I started all over. She told me that they stopped
shipping new manuals to educational licensees when they started giving
a greatly increased educational discount. (I don't know when that
was supposed to have happened.) If we wanted new manuals, they would
cost us. So I told her to just ship us the update packages that they
had failed to send us and I would use the _What's_New..._ books to
get up to date. She said all she had for 5.1 and 5.3 were the CDROMs,
not the books that were shipped with them. I said they should make
good on the service contract by providing us an adequate substitute
free of charge for what they had failed to ship us in the first place.
She said they would not do that, but said they keep a pile of used
manuals that customers return for some reason (abandonment of package?)
and that she would look for some old ones to send us.
That was the last I heard from her until today. Apparently,
she saw or was given a copy of the complaint I posted last night.
She pretended in today's note not to know what my complaint was
about, nor the name of the licensee (i.e. my advisor.) So to answer
Pavel's question, it does not seem to me to be conceivable that
there was any misunderstanding. They simply cheated my advisor and
refused to make good when confronted with the facts.
Scott Bennett, Comm. ASMELG, CFIAG
College of Oceanic and Atmospheric
Sciences
Oregon State University
Corvallis, Oregon 97331
************************************************************ **********
* Internet: sbennett at oce.orst.edu *
*----------------------------------------------------------- ---------*
* "Lay then the axe to the root, and teach governments humanity. *
* It is their sanguinary punishments which corrupt mankind." *
* -- _The_Rights_of_Man_ by Tom Paine (1791.) *
************************************************************ **********
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #25977 is a reply to message #25976] |
Thu, 02 August 2001 18:00 |
bennetsc
Messages: 18
Registered: January 1998
|
Junior Member |
|
|
In article <3B6974E4.CBCC8A96@noaa.gov>,
Paul van Delst <paul.vandelst@noaa.gov> wrote:
> bennetsc@NOSPAMucs.orst.edu wrote:
>>
>> In article <MPG.15d1a1e0a012bdcd989e44@news.frii.com>,
>> David Fanning <david@dfanning.com> wrote:
>>> Scott Bennett writes after a long analysis of the Hanning function:
>>>
>>>> In any case, I think the point Harris made is that a discrete
>>>> sampling of a window function should not taper to the same value at
>>>> the end that it has at the beginning because to do so would include
>>>> the first sample of the *next* period (windowed segment.) So IDL's
>>>> hanning() gets it wrong for both even- and odd-length windows. :-(
>>>
>>> Uh, huh. And how did RSI respond when you contacted them
>>> about it?
>>>
>> I didn't contact them. I'm disgusted with them after seeing how
>> they cheated my faculty advisor and, when I asked them to rectify
>> their errors, they refused to do so. I recommended to my advisor that
>> he turn the whole matter over to the university's legal counsel. He
>> told me that he was not going to renew the service contract any more,
>> so I doubt he will bother with having the legal counsel deal with it,
>> but either way it will be his decision and it's now out of my hands.
>> Given their denial of service while we had a service contract, I doubt
>> they would do any better now that we no longer have a service
> contract.
>
> Oi vey. another future matlab user.... ? :o)
>
Who knows? It will depend upon which package, if any, my next
employer wants me to use. I don't even know what my chances are
of ever being involved in time series data analysis work again after
I finish this degree program. (I suppose, if I can find a suitable
disk drive to replace the one that died on my ancient NeXT, I could
mess around with Mathematica 3.02 at home... :-)
Scott Bennett, Comm. ASMELG, CFIAG
College of Oceanic and Atmospheric
Sciences
Oregon State University
Corvallis, Oregon 97331
************************************************************ **********
* Internet: sbennett at oce.orst.edu *
*----------------------------------------------------------- ---------*
* "Lay then the axe to the root, and teach governments humanity. *
* It is their sanguinary punishments which corrupt mankind." *
* -- _The_Rights_of_Man_ by Tom Paine (1791.) *
************************************************************ **********
|
|
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #25989 is a reply to message #25982] |
Thu, 02 August 2001 10:53 |
Clay Kirkendall
Messages: 5
Registered: August 2001
|
Junior Member |
|
|
FYI: the hanning() routine that I have from matlab (ver 1.4, 1994) is in
worse shape than the one provided with IDL. It is symmetric (not
fft-symmetric) and it does not even taper to zero.
Clay
Paul van Delst wrote:
> bennetsc@NOSPAMucs.orst.edu wrote:
>>
>> In article <MPG.15d1a1e0a012bdcd989e44@news.frii.com>,
>> David Fanning <david@dfanning.com> wrote:
>>> Scott Bennett writes after a long analysis of the Hanning function:
>>>
>>>> In any case, I think the point Harris made is that a discrete
>>>> sampling of a window function should not taper to the same value at
>>>> the end that it has at the beginning because to do so would include
>>>> the first sample of the *next* period (windowed segment.) So IDL's
>>>> hanning() gets it wrong for both even- and odd-length windows. :-(
>>>
>>> Uh, huh. And how did RSI respond when you contacted them
>>> about it?
>>>
>> I didn't contact them. I'm disgusted with them after seeing how
>> they cheated my faculty advisor and, when I asked them to rectify
>> their errors, they refused to do so. I recommended to my advisor that
>> he turn the whole matter over to the university's legal counsel. He
>> told me that he was not going to renew the service contract any more,
>> so I doubt he will bother with having the legal counsel deal with it,
>> but either way it will be his decision and it's now out of my hands.
>> Given their denial of service while we had a service contract, I doubt
>> they would do any better now that we no longer have a service contract.
>
> Oi vey. another future matlab user.... ? :o)
>
> --
> Paul van Delst A little learning is a dangerous thing;
> CIMSS @ NOAA/NCEP Drink deep, or taste not the Pierian spring;
> Ph: (301)763-8000 x7274 There shallow draughts intoxicate the brain,
> Fax:(301)763-8545 And drinking largely sobers us again.
> Alexander Pope.
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #25994 is a reply to message #25989] |
Thu, 02 August 2001 08:42 |
Paul van Delst
Messages: 364
Registered: March 1997
|
Senior Member |
|
|
bennetsc@NOSPAMucs.orst.edu wrote:
>
> In article <MPG.15d1a1e0a012bdcd989e44@news.frii.com>,
> David Fanning <david@dfanning.com> wrote:
>> Scott Bennett writes after a long analysis of the Hanning function:
>>
>>> In any case, I think the point Harris made is that a discrete
>>> sampling of a window function should not taper to the same value at
>>> the end that it has at the beginning because to do so would include
>>> the first sample of the *next* period (windowed segment.) So IDL's
>>> hanning() gets it wrong for both even- and odd-length windows. :-(
>>
>> Uh, huh. And how did RSI respond when you contacted them
>> about it?
>>
> I didn't contact them. I'm disgusted with them after seeing how
> they cheated my faculty advisor and, when I asked them to rectify
> their errors, they refused to do so. I recommended to my advisor that
> he turn the whole matter over to the university's legal counsel. He
> told me that he was not going to renew the service contract any more,
> so I doubt he will bother with having the legal counsel deal with it,
> but either way it will be his decision and it's now out of my hands.
> Given their denial of service while we had a service contract, I doubt
> they would do any better now that we no longer have a service contract.
Oi vey. another future matlab user.... ? :o)
--
Paul van Delst A little learning is a dangerous thing;
CIMSS @ NOAA/NCEP Drink deep, or taste not the Pierian spring;
Ph: (301)763-8000 x7274 There shallow draughts intoxicate the brain,
Fax:(301)763-8545 And drinking largely sobers us again.
Alexander Pope.
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #25997 is a reply to message #25994] |
Thu, 02 August 2001 06:35 |
Clay Kirkendall
Messages: 5
Registered: August 2001
|
Junior Member |
|
|
There is no doubt that the IDL supplied hanning window is symmetric but not
"fft-symmetric" as it should be for fft processing. I would guess that for
most applications this difference will not significantly impact the results,
but for situations where there is a large signal to noise ratio ( > 80 dB)
with a sinusoidal signal exactly centered in an fft bin there can be major
differences between the two windows. Most real world problems (at least that
I have come across) dont meet this situation and the observed differences
are minor. Of course there is no reason to use the wrong window when the
correct one is easily generated.
Clay
bennetsc@NOSPAMucs.orst.edu wrote:
> In article <3B681285.B12C4939@fz-juelich.de>,
> Jaco van Gorkom <j.c.van.gorkom@fz-juelich.de> wrote:
>> David Fanning wrote:
>>> Scott Bennett writes after a long analysis of the Hanning function:
>>>
>>>> In any case, I think the point Harris made is that a discrete
>>>> sampling of a window function should not taper to the same value at
>>>> the end that it has at the beginning because to do so would include
>>>> the first sample of the *next* period (windowed segment.) So IDL's
>>>> hanning() gets it wrong for both even- and odd-length windows. :-(
>>>
>>> Uh, huh. And how did RSI respond when you contacted them
>>> about it?
>>
>> I suspect they would suggest the following workaround:
>>
>> function Harris, n, _EXTRA=extra
>> return, (hanning(n+1, _EXTRA=extra))[0:n-1]
>> end
>>
> That looks like it should work for Hann, Hamming, and other
> raised cosine windows. I am not prepared to vouch for that method
> for all windows.
>
>> Scott, I've read your post, but I'm not sure I'm getting the point.
>> Tapering from zero to zero seems like good idea to me, the symmetry
>> sort of "feels good". Besides, it is convenient to have the weight of
>> the window at its centre. What exactly is so wrong with it?
>>
> First, remember that a continuous, finite Fourier transform
> operates over a time (or space, but I'm just going to refer to time)
> domain of finite length T. The lowest frequency that can be resolved
> is the one whose period 1/f = T; i.e. one full period takes exactly
> the length of the time over which the integral operates.
> So now consider a periodic function at that frequency. Take,
> for example, a sine function like y = cos(2 pi t/T), where 0 le t lt T.
> Note that the function begins at cos(0)=1. The assumption underlying
> the Fourier transform is that the basis functions are all periodic.
> So the finite Fourier transform is based upon the same assumption, but
> also that the function value over the time period from 0 to T exactly
> repeats ad infinitum. Therefore the time period is closed at the
> starting point and open at the ending. The open end is the point at
> which the cycle is assumed to begin its repetition of the starting
> point; i.e. it's the starting point of the next cycle or period, if
> another cycle were to exist.
> The discrete, finite Fourier transform operates upon a sampling
> of the continuous function taken at N regular intervals of length
> delta t, so the samples are at n * delta t, where n = 0, 1, 2, ..., N-1.
> Note that a sample taken at t = N * delta t represents the point at
> which the cycle would repeat if more samples existed because the
> samples are taken at the start of each time interval, not at the end
> of each time interval. (A data window is supposed to have the same
> period as the data being windowed, so the data window's period likewise
> is closed at the left (starting) end and open-ended at the right.)
> To see what happens when the discrete transform is applied to one
> too many samples, try the following. (Set color1 and color2 to vividly
> contrasting colors in your preferred color table.)
>
> samples = cos(2. * !pi * findgen(9)/ 8.)
>
> That gives us a sampled cosine function for one period of eight
> samples, plus an extra for our experiment. Next, get the discrete
> transforms and look at them.
>
> gooddft = fft(samples[0:7])
> baddft = fft(samples)
> plot, float(gooddft), /nodata, yrange=[-.4, .6]
> oplot, float(gooddft), psym=1, color=color1
> oplot, imaginary(gooddft), psym=7, color=color2
>
> The above should yield a graph with a color1 (real component) spike of
> .5 above the points for 1 and 7, corresponding to frequencies of 1/T
> and -1/T, and zeros everywhere else (within the limits of precision,
> etc.,) and color2 (imaginary component) values of zero everywhere.
> Then try:
>
> plot, float(baddft), /nodata, yrange=[-.4, .6]
> oplot, float(baddft), psym=1, color=color1
> oplot, imaginary(baddft), psym=7, color=color2
>
> This should give a graph showing a non-zero real (color1) mean value
> over the zero frequency, real (color1) peaks over the points 1 and 8,
> corresponding to frequencies of 1/T and -1/T, but a little higher than
> a value of .5 and imaginary (color2) points just less than .2 and just
> greater than -.2 over the same horizontal positions. Note that real
> and imaginary components of other frequencies are also non-zero. We
> know this cannot be correct because we specified the generating
> function to have only one frequency, which the transform splits in
> half over the symmetric frequencies of 1/T and -1/T, and we know that
> the mean of a cosine function over one complete period is zero. The
> amplitudes (both real and imaginary) of all other frequencies should
> be zero.
> So a Hann window, and other windows I've seen so far, should not
> include a repetition of its first coefficient as the last coefficient.
>
> Scott Bennett, Comm. ASMELG, CFIAG
> College of Oceanic and Atmospheric
> Sciences
> Oregon State University
> Corvallis, Oregon 97331
> ************************************************************ **********
> * Internet: sbennett at oce.orst.edu *
> *----------------------------------------------------------- ---------*
> * "Lay then the axe to the root, and teach governments humanity. *
> * It is their sanguinary punishments which corrupt mankind." *
> * -- _The_Rights_of_Man_ by Tom Paine (1791.) *
> ************************************************************ **********
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #26000 is a reply to message #25997] |
Thu, 02 August 2001 00:16 |
bennetsc
Messages: 18
Registered: January 1998
|
Junior Member |
|
|
In article <3B681285.B12C4939@fz-juelich.de>,
Jaco van Gorkom <j.c.van.gorkom@fz-juelich.de> wrote:
> David Fanning wrote:
>> Scott Bennett writes after a long analysis of the Hanning function:
>>
>>> In any case, I think the point Harris made is that a discrete
>>> sampling of a window function should not taper to the same value at
>>> the end that it has at the beginning because to do so would include
>>> the first sample of the *next* period (windowed segment.) So IDL's
>>> hanning() gets it wrong for both even- and odd-length windows. :-(
>>
>> Uh, huh. And how did RSI respond when you contacted them
>> about it?
>
> I suspect they would suggest the following workaround:
>
> function Harris, n, _EXTRA=extra
> return, (hanning(n+1, _EXTRA=extra))[0:n-1]
> end
>
That looks like it should work for Hann, Hamming, and other
raised cosine windows. I am not prepared to vouch for that method
for all windows.
> Scott, I've read your post, but I'm not sure I'm getting the point.
> Tapering from zero to zero seems like good idea to me, the symmetry
> sort of "feels good". Besides, it is convenient to have the weight of
> the window at its centre. What exactly is so wrong with it?
>
First, remember that a continuous, finite Fourier transform
operates over a time (or space, but I'm just going to refer to time)
domain of finite length T. The lowest frequency that can be resolved
is the one whose period 1/f = T; i.e. one full period takes exactly
the length of the time over which the integral operates.
So now consider a periodic function at that frequency. Take,
for example, a sine function like y = cos(2 pi t/T), where 0 le t lt T.
Note that the function begins at cos(0)=1. The assumption underlying
the Fourier transform is that the basis functions are all periodic.
So the finite Fourier transform is based upon the same assumption, but
also that the function value over the time period from 0 to T exactly
repeats ad infinitum. Therefore the time period is closed at the
starting point and open at the ending. The open end is the point at
which the cycle is assumed to begin its repetition of the starting
point; i.e. it's the starting point of the next cycle or period, if
another cycle were to exist.
The discrete, finite Fourier transform operates upon a sampling
of the continuous function taken at N regular intervals of length
delta t, so the samples are at n * delta t, where n = 0, 1, 2, ..., N-1.
Note that a sample taken at t = N * delta t represents the point at
which the cycle would repeat if more samples existed because the
samples are taken at the start of each time interval, not at the end
of each time interval. (A data window is supposed to have the same
period as the data being windowed, so the data window's period likewise
is closed at the left (starting) end and open-ended at the right.)
To see what happens when the discrete transform is applied to one
too many samples, try the following. (Set color1 and color2 to vividly
contrasting colors in your preferred color table.)
samples = cos(2. * !pi * findgen(9)/ 8.)
That gives us a sampled cosine function for one period of eight
samples, plus an extra for our experiment. Next, get the discrete
transforms and look at them.
gooddft = fft(samples[0:7])
baddft = fft(samples)
plot, float(gooddft), /nodata, yrange=[-.4, .6]
oplot, float(gooddft), psym=1, color=color1
oplot, imaginary(gooddft), psym=7, color=color2
The above should yield a graph with a color1 (real component) spike of
.5 above the points for 1 and 7, corresponding to frequencies of 1/T
and -1/T, and zeros everywhere else (within the limits of precision,
etc.,) and color2 (imaginary component) values of zero everywhere.
Then try:
plot, float(baddft), /nodata, yrange=[-.4, .6]
oplot, float(baddft), psym=1, color=color1
oplot, imaginary(baddft), psym=7, color=color2
This should give a graph showing a non-zero real (color1) mean value
over the zero frequency, real (color1) peaks over the points 1 and 8,
corresponding to frequencies of 1/T and -1/T, but a little higher than
a value of .5 and imaginary (color2) points just less than .2 and just
greater than -.2 over the same horizontal positions. Note that real
and imaginary components of other frequencies are also non-zero. We
know this cannot be correct because we specified the generating
function to have only one frequency, which the transform splits in
half over the symmetric frequencies of 1/T and -1/T, and we know that
the mean of a cosine function over one complete period is zero. The
amplitudes (both real and imaginary) of all other frequencies should
be zero.
So a Hann window, and other windows I've seen so far, should not
include a repetition of its first coefficient as the last coefficient.
Scott Bennett, Comm. ASMELG, CFIAG
College of Oceanic and Atmospheric
Sciences
Oregon State University
Corvallis, Oregon 97331
************************************************************ **********
* Internet: sbennett at oce.orst.edu *
*----------------------------------------------------------- ---------*
* "Lay then the axe to the root, and teach governments humanity. *
* It is their sanguinary punishments which corrupt mankind." *
* -- _The_Rights_of_Man_ by Tom Paine (1791.) *
************************************************************ **********
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #26002 is a reply to message #26000] |
Thu, 02 August 2001 00:21 |
bennetsc
Messages: 18
Registered: January 1998
|
Junior Member |
|
|
In article <3B681285.B12C4939@fz-juelich.de>,
Jaco van Gorkom <j.c.van.gorkom@fz-juelich.de> wrote:
> David Fanning wrote:
>> Scott Bennett writes after a long analysis of the Hanning function:
>>
>>> In any case, I think the point Harris made is that a discrete
>>> sampling of a window function should not taper to the same value at
>>> the end that it has at the beginning because to do so would include
>>> the first sample of the *next* period (windowed segment.) So IDL's
>>> hanning() gets it wrong for both even- and odd-length windows. :-(
>>
>> Uh, huh. And how did RSI respond when you contacted them
>> about it?
>
> I suspect they would suggest the following workaround:
>
> function Harris, n, _EXTRA=extra
> return, (hanning(n+1, _EXTRA=extra))[0:n-1]
> end
>
That looks like it should work for Hann, Hamming, and other
raised cosine windows. I am not prepared to vouch for that method
for all windows.
> Scott, I've read your post, but I'm not sure I'm getting the point.
> Tapering from zero to zero seems like good idea to me, the symmetry
> sort of "feels good". Besides, it is convenient to have the weight of
> the window at its centre. What exactly is so wrong with it?
>
First, remember that a continuous, finite Fourier transform
operates over a time (or space, but I'm just going to refer to time)
domain of finite length T. The lowest frequency that can be resolved
is the one whose period 1/f = T; i.e. one full period takes exactly
the length of the time over which the integral operates.
So now consider a periodic function at that frequency. Take,
for example, a sine function like y = cos(2 pi t/T), where 0 le t lt T.
Note that the function begins at cos(0)=1. The assumption underlying
the Fourier transform is that the basis functions are all periodic.
So the finite Fourier transform is based upon the same assumption, but
also that the function value over the time period from 0 to T exactly
repeats ad infinitum. Therefore the time period is closed at the
starting point and open at the ending. The open end is the point at
which the cycle is assumed to begin its repetition of the starting
point; i.e. it's the starting point of the next cycle or period, if
another cycle were to exist.
The discrete, finite Fourier transform operates upon a sampling
of the continuous function taken at N regular intervals of length
delta t, so the samples are at n * delta t, where n = 0, 1, 2, ..., N-1.
Note that a sample taken at t = N * delta t represents the point at
which the cycle would repeat if more samples existed because the
samples are taken at the start of each time interval, not at the end
of each time interval. (A data window is supposed to have the same
period as the data being windowed, so the data window's period likewise
is closed at the left (starting) end and open-ended at the right.)
To see what happens when the discrete transform is applied to one
too many samples, try the following. (Set color1 and color2 to vividly
contrasting colors in your preferred color table.)
samples = cos(2. * !pi * findgen(9)/ 8.)
That gives us a sampled cosine function for one period of eight
samples, plus an extra for our experiment. Next, get the discrete
transforms and look at them.
gooddft = fft(samples[0:7])
baddft = fft(samples)
plot, float(gooddft), /nodata, yrange=[-.4, .6]
oplot, float(gooddft), psym=1, color=color1
oplot, imaginary(gooddft), psym=7, color=color2
The above should yield a graph with a color1 (real component) spike of
.5 above the points for 1 and 7, corresponding to frequencies of 1/T
and -1/T, and zeros everywhere else (within the limits of precision,
etc.,) and color2 (imaginary component) values of zero everywhere.
Then try:
plot, float(baddft), /nodata, yrange=[-.4, .6]
oplot, float(baddft), psym=1, color=color1
oplot, imaginary(baddft), psym=7, color=color2
This should give a graph showing a non-zero real (color1) mean value
over the zero frequency, real (color1) peaks over the points 1 and 8,
corresponding to frequencies of 1/T and -1/T, but a little higher than
a value of .5 and imaginary (color2) points just less than .2 and just
greater than -.2 over the same horizontal positions. Note that real
and imaginary components of other frequencies are also non-zero. We
know this cannot be correct because we specified the generating
function to have only one frequency, which the transform splits in
half over the symmetric frequencies of 1/T and -1/T, and we know that
the mean of a cosine function over one complete period is zero. The
amplitudes (both real and imaginary) of all other frequencies should
be zero.
So a Hann window, and other windows I've seen so far, should not
include a repetition of its first coefficient as the last coefficient.
Scott Bennett, Comm. ASMELG, CFIAG
College of Oceanic and Atmospheric
Sciences
Oregon State University
Corvallis, Oregon 97331
************************************************************ **********
* Internet: sbennett at oce.orst.edu *
*----------------------------------------------------------- ---------*
* "Lay then the axe to the root, and teach governments humanity. *
* It is their sanguinary punishments which corrupt mankind." *
* -- _The_Rights_of_Man_ by Tom Paine (1791.) *
************************************************************ **********
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #26003 is a reply to message #26000] |
Wed, 01 August 2001 22:56 |
bennetsc
Messages: 18
Registered: January 1998
|
Junior Member |
|
|
In article <MPG.15d1a1e0a012bdcd989e44@news.frii.com>,
David Fanning <david@dfanning.com> wrote:
> Scott Bennett writes after a long analysis of the Hanning function:
>
>> In any case, I think the point Harris made is that a discrete
>> sampling of a window function should not taper to the same value at
>> the end that it has at the beginning because to do so would include
>> the first sample of the *next* period (windowed segment.) So IDL's
>> hanning() gets it wrong for both even- and odd-length windows. :-(
>
> Uh, huh. And how did RSI respond when you contacted them
> about it?
>
I didn't contact them. I'm disgusted with them after seeing how
they cheated my faculty advisor and, when I asked them to rectify
their errors, they refused to do so. I recommended to my advisor that
he turn the whole matter over to the university's legal counsel. He
told me that he was not going to renew the service contract any more,
so I doubt he will bother with having the legal counsel deal with it,
but either way it will be his decision and it's now out of my hands.
Given their denial of service while we had a service contract, I doubt
they would do any better now that we no longer have a service contract.
Scott Bennett, Comm. ASMELG, CFIAG
College of Oceanic and Atmospheric
Sciences
Oregon State University
Corvallis, Oregon 97331
************************************************************ **********
* Internet: sbennett at oce.orst.edu *
*----------------------------------------------------------- ---------*
* "Lay then the axe to the root, and teach governments humanity. *
* It is their sanguinary punishments which corrupt mankind." *
* -- _The_Rights_of_Man_ by Tom Paine (1791.) *
************************************************************ **********
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #26017 is a reply to message #26003] |
Wed, 01 August 2001 10:51 |
Brian Jackel
Messages: 34
Registered: January 1998
|
Member |
|
|
Hi Scott
A friend and I noticed this several years ago. My
recollection is that he reported this to RSI, but
they weren't convinced of the problem. Of course,
it *is* a (minor) problem.
At the time I was playing around with windows (or
apodizing functions, or tapers) and wrote some IDL
code. It's included below. The "Slepian" window
is commented out because it requires something clever
with eigenvalues, and the details have escaped me.
To see what Scott is talking about, try typing the
following two commands:
test= FFT_TAPER(512,'hanning',/PLOT) ;correct way
test= FFT_TAPER(512,'badhanning',/PLOT) ;IDL way
Although this is old code, I would appreciate any
comments or bug reports. Have fun.
Brian Jackel
;=========================================================== ======
;distribute freely,
;use at own risk,
;send all bug reports to bjackel@phys.ucalgary.ca
;+
; NAME: FFT_TAPER
;
; PURPOSE: This function provides a selection of "tapers" (also known
; as "windows" or "apodizing functions") to reduce sidelobe
; leakage when calculating FFT's.
;
; CATEGORY: Time Series Analysis, Signal Processing
;
; CALLING SEQUENCE: Result=
FFT_TAPER(Nelements,Windowname,[Parameter])
;
; INPUTS:
; Nelements the number of elements in the window ie. # of
; elements in the time series to be windowed.
; Must be a positive integer (floats will be rounded).
;
; Windowname a string containing the name of the windowing function
; to use. Not case sensitive, whitespace will be
ignored.
;
; OPTIONAL INPUTS:
; Parameter some tapers can be tuned with a parameter value. See
; specific descriptions for details.
;
; KEYWORD PARAMETERS:
;
; PLOT_EXAMPLE if set, the window and amplitude spectrum will
; be plotted
; RETURN_WINDOWLIST if set, Result will be a string array of all
; valid Windownames
;
;
;
;
;
;
; Kaiser-Bessel This taper can be tuned. Set the parameter to
; (Nuttall p89) the desired location (in scaled Lf/pi units) of
; the first null. ie. 2, 3, or 4
;
; van der Maas This taper can be tuned. Set the parameter to
; (Nuttall p90) the ratio of the log of the peak to sidelobe level
; ie. 2 (factor of 100 or 20dB) or 3 (30dB)
;
;
; MODIFICATION HISTORY:
; Written by: Brian Jackel 1995
;-
Function FFT_TAPER,Length,Windowtype,Parameter, $
RETURN_WINDOWLIST=return_windowlist,PLOT_EXAMPLE=plot_exampl e
;
;Make a list of all the legal window names, and put them in an array.
If the
;keyword RETURN_WINDOWLIST is set, then just return the array of
strings. This
;is useful for letting the user know what options are available.
;
windowlist=['Hanning', 'Hamming', 'Blackman', 'Exact Blackman',
'Blackman-Harris']
windowlist= [windowlist, 'Dolph-Chebyshev', 'Kaiser-Bessel', 'van der
Maas', 'Slepian']
IF KEYWORD_SET(RETURN_WINDOWLIST) THEN return,windowlist
;First, test Length:
; If not set, use 16.
; If it's a scalar, that's the window length.
; If it's a 1D array, then use the # of elements as the window length.
; Otherwise, return with an error message.
;
IF (N_PARAMS() LT 1) THEN length= 16
siz= SIZE(length)
CASE siz(0) OF
0: L= length
1: L= N_ELEMENTS(length)
ELSE: MESSAGE,'Length must be a scalar or a 1D array'
ENDCASE
;Check the Windowtype.
; If none given, use Hanning
; Remove spaces, convert to uppercase
;
IF (N_PARAMS() LT 2) THEN BEGIN
MESSAGE,'No Windowtype given, using default: Hanning',/INFORMATIONAL
Windowtype= 'Hanning'
ENDIF
Windowtype= STRUPCASE(STRCOMPRESS(Windowtype,/REMOVE_ALL))
print,windowtype
;If no additional parameter is provided, set it to 1
;
IF (N_PARAMS() LT 3) THEN parameter=1.0
result= 1.0
nn= 2.0*!pi*FINDGEN(L)/L
t= 2.0*FINDGEN(L)/L - 1.0 ;-1 to almost 1
CASE (windowtype) OF
;----------------------------------------------------------- ---------------------
;The Hanning window is widely used, due to the advantages of a simple
; representation in the time domain and an analytic expression for the
; transform. Unfortunately, it has neither a particularly narrow main
; lobe nor low sidelobes.
;
'HANNING': wind= 1.0 + cos(!pi*t)
;----------------------------------------------------------- --------------------
;Although the analytic expression of a taper is (usually) symmetric,
the
; FFT form shouldn't be, as the last point is the same as the first,
and
; shouldn't be explicitly included. Here's what the Hanning window
looks
; like if done incorrectly. Not a big difference, but worth getting
right.
;
'BADHANNING': BEGIN
t= 2.0*FINDGEN(L)/(L-1.0) - 1.0
wind= 1.0 + cos(!pi*t)
END
;----------------------------------------------------------- --------------------
;The Hamming window has a time domain representation similar to the
Hanning.
;It has a comparable mainlobe width, but a lower first sidelobe.
;
;
'HAMMING': wind= 1.0 + 0.46/0.54*cos(!pi*t)
;----------------------------------------------------------- --------------------
;The Blackmann window has a moderately wide main lobe, and low
sidelobes
;
'BLACKMAN':wind= 1.0 + 0.50/0.42*cos(!pi*t) + 0.08/0.42*cos(2.0*!pi*t)
;----------------------------------------------------------- --------------------
;
;
"EXACTBLACKMAN": wind= 1.0 + 1.16402*cos(!pi*t) +
0.180146*cos(2.0*!pi*t)
'DOLPH-CHEBYSHEV':BEGIN
order= L
x= 10.0^parameter
z0 = COSH( ALOG(x + SQRT(x^2-1.0) ) / order )
;Harris calls this 'beta'
arg= z0 * COS(nn/2.0)
temp= (-1)^FINDGEN(L) * TCHEBYSHEV(arg,order) / x
; stop
wind= FLOAT(FFT(temp,1))
END
'KAISER-BESSEL':BEGIN
b= parameter*!pi
arg= SQRT( (1.0-t^2) > 0.0) ;avoid
problems at arg^2 = 1
wind= BESELI(b*arg,0) / (SINH(b)/b)
; stop
END
'NORTON-BEER':BEGIN
n= FIX(parameter)
CASE n OF ;four possible
window types (0,1,2,3)
0: c= [1.0, 0.0, 0.0, 0.0, 0.0]
1: c= [0.384093, -0.087577, 0.703484, 0.0, 0.0]
2: c= [0.152442, -0.136176, 0.983734, 0.0, 0.0]
3: c= [0.045335, 0.0, 0.554883, 0.0, 0.399782 ]
ELSE:MESSAGE,'For Norton-Beer, parameter should be an
integer from 0 (no apodization) to 3 (strong apodization)'
ENDCASE
u= 2.0 * FINDGEN(l) / l - 1.0
arg= 1.0 - u^2
wind= c(0)
FOR i=1,4 DO BEGIN
IF ( c(i) NE 0.0 ) THEN wind= wind + c(i)*arg^i
ENDFOR
END
'VANDERMAAS':BEGIN
r= 10.0^parameter ;peak to sidelobe ratio
b= ALOG(r + SQRT(r^2-1) ) ;scale factor
arg= SQRT( (1.0-t^2) > 1.0E-12)
wind= b* BESELI(b*arg,1) / arg
wind(0)= (b^2)/2.0 ;ensure that the limit is good for
small arguments
wind(0)= wind(0) + L ;then tack on a bit (delta
function)
wind= wind / COSH(b) ;normalize for unit peak in
spectrum
END
;----------------------------------------------------------- ------------
;
;
;
;'SLEPIAN':BEGIN
; IF (N_ELEMENTS(parameter) GT 1) THEN order=parameter(1)
ELSE order=0
; n= l+1 ;get 1 more point than necessary
; w= FLOAT(parameter(0))/n ;frequency width (sort of)
; indx= INDGEN(n) ;useful index array
; diag= ((n-1.0d0-2.0d0*indx)/2.0d0)^2 * COS(2.0*!dpi*w)
;diagonal elements
; offdiag= indx*(n-indx)/2.0d0 ;off-diagonal
elements;
;
; lo= 0.0d0
; hi= 0.45d0*n^2
; ; evalue=
TRI_EIGENVALUE(diag,offdiag,evector,RANGE=[lo,hi],ORDER=orde r)
; wind= evector(0:n-2)
; END
ELSE:BEGIN
MESSAGE,'Invalid WINDOWTYPE '+windowtype,/INFORMATIONAL
MESSAGE,'Should be one of: '+windowlist
END
ENDCASE
IF (siz(0) EQ 1) THEN BEGIN
result= length*wind
result= SHIFT(result,L/2)
ENDIF ELSE result= wind
IF KEYWORD_SET(PLOT_EXAMPLE) THEN BEGIN
!p.multi=[0,1,2]
spec= 4.0*ABS(FFT([result,REPLICATE(0.0,l*3)],-1))
spec= 10.0*ALOG10(spec)
xspec= 2.0*FINDGEN(l*4.0)/(4.0*l)
every4= FINDGEN(l)*4
PLOT,t,result,TITLE=windowtype + ' Window',PSYM=-4,SYMSIZE=0.5
XYOUTS,0.7,!y.crange(1)*0.85,STRING(l,FORMAT='("N=",I3)')
IF (parameter(0) NE 1) THEN BEGIN
pstring= STRCOMPRESS( STRING(parameter(0),FORMAT='("p=",F6.1)'))
XYOUTS,0.7,!y.crange(1)*0.75,pstring
ENDIF
!p.multi=[2,2,2]
PLOT,xspec,spec,TITLE='Amplitude
Spectrum',YRANGE=[-100,0],XRANGE=[0,0.5],XSTYLE=1,YTITLE='dB ',XTITLE='f
/ fN',XTICKS=2
PLOT,xspec*l,spec,TITLE='Amplitude
Spectrum',YRANGE=[-50,0],PSYM=-4,SYMSIZE=0.3,XRANGE=[0,12],X STYLE=1,XTICKS=2,XTITLE='Delta
f'
OPLOT,xspec(every4)*l,spec(every4),PSYM=4,SYMSIZE=0.7
ENDIF
RETURN,result
END
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #26029 is a reply to message #26017] |
Wed, 01 August 2001 08:10 |
Paul van Delst
Messages: 364
Registered: March 1997
|
Senior Member |
|
|
Jaco van Gorkom wrote:
>
> David Fanning wrote:
>> Scott Bennett writes after a long analysis of the Hanning function:
>>
>>> In any case, I think the point Harris made is that a discrete
>>> sampling of a window function should not taper to the same value at
>>> the end that it has at the beginning because to do so would include
>>> the first sample of the *next* period (windowed segment.) So IDL's
>>> hanning() gets it wrong for both even- and odd-length windows. :-(
>>
>> Uh, huh. And how did RSI respond when you contacted them
>> about it?
>
> I suspect they would suggest the following workaround:
>
> function Harris, n, _EXTRA=extra
> return, (hanning(n+1, _EXTRA=extra))[0:n-1]
> end
>
> Scott, I've read your post, but I'm not sure I'm getting the point.
> Tapering from zero to zero seems like good idea to me, the symmetry
> sort of "feels good". Besides, it is convenient to have the weight of
> the window at its centre. What exactly is so wrong with it?
Hello,
I think Scott's post underscores the fact that any sort of Fourier analysis is not to be
undertaken lightly without fully understanding how any code used works (or is supposed to
work) and knowing, in some fashion, what the result should look like in advance. The
difference of a point (or a window being a little bit wider etc) can make a *huge*
difference in how one interprets or subsequently uses the results in FFT applications.
While I'm not dismissing your comments about the good vibrations one typically gets from
symmetry (I try to achieve that as much as possible too) I'm going to file Scott's message
under the "READ_THESE_FIRST!!!" sub-directory in my FFT code/work directory. :o)
paulv
--
Paul van Delst A little learning is a dangerous thing;
CIMSS @ NOAA/NCEP Drink deep, or taste not the Pierian spring;
Ph: (301)763-8000 x7274 There shallow draughts intoxicate the brain,
Fax:(301)763-8545 And drinking largely sobers us again.
Alexander Pope.
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #26031 is a reply to message #26029] |
Wed, 01 August 2001 07:30 |
Jaco van Gorkom
Messages: 97
Registered: November 2000
|
Member |
|
|
David Fanning wrote:
> Scott Bennett writes after a long analysis of the Hanning function:
>
>> In any case, I think the point Harris made is that a discrete
>> sampling of a window function should not taper to the same value at
>> the end that it has at the beginning because to do so would include
>> the first sample of the *next* period (windowed segment.) So IDL's
>> hanning() gets it wrong for both even- and odd-length windows. :-(
>
> Uh, huh. And how did RSI respond when you contacted them
> about it?
I suspect they would suggest the following workaround:
function Harris, n, _EXTRA=extra
return, (hanning(n+1, _EXTRA=extra))[0:n-1]
end
Scott, I've read your post, but I'm not sure I'm getting the point.
Tapering from zero to zero seems like good idea to me, the symmetry
sort of "feels good". Besides, it is convenient to have the weight of
the window at its centre. What exactly is so wrong with it?
Jaco
PS: I would look it up myself, but I seem to have misplaced
IEEE vol. 66 somehow...
----------------
Jaco van Gorkom
FOM-Instituut voor Plasmafysica "Rijnhuizen", The Netherlands
e-mail: gorkom@rijnh.nl
|
|
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #26082 is a reply to message #25975] |
Fri, 03 August 2001 22:26 |
bennetsc
Messages: 18
Registered: January 1998
|
Junior Member |
|
|
In article <020820012132307408%kbowman@null.net>,
Kenneth P. Bowman <kbowman@null.net> wrote:
>
> Without making any comment on your problems with RSI, I can say that at
> least the 5.3 and 5.4 releases (and possibly earlier?) have included
> all the IDL documentation in PDF format, which in my experience is
> vastly superior to either the paper manuals or the old help system.
I looked at the 5.3 stuff in PDF format, but my recollection is
that it was broken up into lots of very small files, very inconvenient
and expensive to print hardcopy manuals, which then would have had to
be punched and put into binders in order to be usable. Since we were
supposed to have received the update information anyway, it's not a
grad student's place to squander resources on it.
The IDL 5.0 help system is nearly worthless. Perhaps the later
versions' help systems are better, but they would still be a grossly
inefficient and frustrating way of finding out what had changed from
version to version.
>
> Also, you can always download the latest version of IDL (including the
> documentation) from the RSI web site. We have always found it easy to
> install updates.
>
I'm a grad student here. Installation of large software packages
with licensing schemes is reserved to the college's computer support
staff.
FWIW, I would like someday, preferably in the very near future,
to finish this degree. It's a bit late in the process for me to
devote much effort to switching releases at this point.
Scott Bennett, Comm. ASMELG, CFIAG
College of Oceanic and Atmospheric
Sciences
Oregon State University
Corvallis, Oregon 97331
************************************************************ **********
* Internet: sbennett at oce.orst.edu *
*----------------------------------------------------------- ---------*
* "Lay then the axe to the root, and teach governments humanity. *
* It is their sanguinary punishments which corrupt mankind." *
* -- _The_Rights_of_Man_ by Tom Paine (1791.) *
************************************************************ **********
|
|
|
|
|
|
| Re: bug in IDL's hanning() window-generating function [message #26179 is a reply to message #26002] |
Fri, 10 August 2001 09:16 |
Jaco van Gorkom
Messages: 97
Registered: November 2000
|
Member |
|
|
bennetsc@NOSPAMucs.orst.edu wrote:
> Jaco van Gorkom <j.c.van.gorkom@fz-juelich.de> wrote:
>> function Harris, n, _EXTRA=extra
>> return, (hanning(n+1, _EXTRA=extra))[0:n-1]
>> end
>>
> That looks like it should work for Hann, Hamming, and other
> raised cosine windows. I am not prepared to vouch for that method
> for all windows.
Well, I inherited *some* of the functionality from the built-in
HANNING() function. Therefore this is not very likely to produce other
types of windows, symmetric or not.
> So a Hann window, and other windows I've seen so far, should not
> include a repetition of its first coefficient as the last coefficient.
Thanks to all for the explanations and examples. I am now definitely a
convert to 5.5-style hanning windows. Even though I will certainly never
encounter an 80 dB signal-to-noise ratio...
Jaco
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
