Jump to content

Talk:Window function

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Windows in actual use

[edit]

I have always thought that in actual use, and especially in the case of long signals, one applied a window function at the ends, and left most of the signal as-is. This happens naturally with the rectangular window, but the triangle would turn into a trapezoid, and other windows would also look different. One might have signals thousands, or even millions of points long. All that is needed is to remove the effects from the discontinuity due to the periodicity of the DFT, or at least get the effect low enough that one can live with it. Yet the windows, and spectra shown, don't seem to work this way. Am I missing something? Gah4 (talk) 01:49, 17 February 2016 (UTC)[reply]

For starters, it's the same question, discrete-time or continuous-time. The DFT has nothing to do with it. Given an effectively infinitely long function s(t), and a finite window w(t) (rectangular, Hann, trapezoidal, etc),
and your question is "When w(t) is relatively long, why would one choose a conventional window instead of a more trapezoidal-like window, for spectral analysis?". Throwing in the DFT adds unnecessary complexity. See Spectral_leakage#Discrete-time_functions.
--Bob K (talk) 16:11, 17 February 2016 (UTC)[reply]
And the answer is that just as a trapezoidal-like window is better than rectangular in terms of sidelobes (resolution of disparate amplitude sinusoids) and worse than rectangular in terms of main-lobe width (resolution of similar amplitudes), a conventional window (e.g. Hann or Nuttall) is better than trapezoidal-like (e.g. Tukey or Plank-taper) in terms of sidelobes and worse than trapezoidal in terms of main-lobe width.
--Bob K (talk) 16:53, 17 February 2016 (UTC)[reply]
Your example of "millions of points" implies that your trapezoidal choice would be similar to a Tukey or Plank-taper function with extremely narrow "skirts". In the limit, they become essentially rectangular. So you might as well just use the simpler rectangular window.
--Bob K (talk) 17:07, 17 February 2016 (UTC)[reply]
In Fourier terms, the sharpness of the transition determines the frequency components. Right now, I am working on smoothing the transitions at the beginning and end of audio files (CD tracks). The problem is a little different from the DFT problem, as the ear is more sensitive to high frequencies. (Most audio sources have lower amplitude at high frequencies.) A sharp edge makes a very noticeable click. I want to smooth the transition enough to avoid the click, but otherwise not change the main part of the audio track. Gah4 (talk) 09:34, 18 February 2016 (UTC)[reply]
OK, then the missing point you are looking for is that window functions can be used as lowpass filters, but it is implemented by convolution, not multiplication, in the time domain. When you apply them by multiplication, the purpose is spectral analysis.
--Bob K (talk) 10:48, 18 February 2016 (UTC)[reply]
The human aural system works in both time and frequency domain, so the signals have to be considered both ways. I want to avoid the click that comes at the beginning, so it is both time and frequency domain. Smoothing the transition at the beginning and end is a low-pass filter only for the beginning and end, with no filter in between. Gah4 (talk) 20:58, 18 February 2016 (UTC)[reply]
Looking at some Tektronix articles, it seems that spectrum analyzers tend (maybe tended) to do a series of 1024 point DFTs and display them sequentially. That is, again, both time and frequency domain. For an audio signal, such a series of transforms would have an audible effect at the transition. Gah4 (talk) 20:58, 18 February 2016 (UTC)[reply]
I don't care about any of that. You are way off the original target you wanted help with. I am not interested in your game.
--Bob K (talk) 22:16, 18 February 2016 (UTC)[reply]
It is the original target that I wanted, but I didn't explain it very well. OK, the reason for asking was that I was looking at the transform graphs and realized that they didn't apply the way I wanted to use them. Some years ago, 1024 points was a lot to compute in the time available, so things might have changed over the years. Thanks. Gah4 (talk) 09:15, 21 February 2016 (UTC)[reply]
The DFT is greatly misunderstood, by the way. It's best thought of as just a discrete-frequency sampling of the actual continuous-frequency DTFT (Discrete-time_Fourier_transform#Sampling_the_DTFT). Whatever undesirable things happened to the DTFT as a result of DSP manipulations are merely sampled, not created, by the DFT. What gets lost, when you sample the DTFT, is whether the DTFT was actually a continuous-frequency or discrete-frequency function. If it was actually a discrete-frequency function, then the original discrete-time function was periodic, and it can be unambiguously recovered by the inverse DFT. If the DTFT was actually a continuous-frequency function, the inverse DFT can only recover a periodic summation of the original discrete-time function. If the periodic summation does not cause overlap of the copies of the original discrete-time function, then one cycle of the inverse DFT is the original function. A necessary and sufficient condition for that to happen is that the original function has a finite number of non-zero samples, and the parameter N used to sample the DTFT (as follows):
Yes, but the DFT is often used on finite length regions of longer signals. Even more, sharp transitions may be added when they don't exist in the original signal. Gah4 (talk) 09:34, 18 February 2016 (UTC)[reply]
If you're still talking about lowpass filtering, we're talking about two different things.
--Bob K (talk) 10:48, 18 February 2016 (UTC)[reply]
must be large enough that the individual terms of this periodic summation do not overlap; i.e. the duration of the non-zero samples in each term is not greater than N:
--Bob K (talk) 18:16, 17 February 2016 (UTC)[reply]

Section 1.4 issue

[edit]

Reference #10 (http://www.bksv.com/doc/bv0031.pdf Technical Review 1987-3 Use of Weighting Functions in DFT/FFT Analysis (Part I); Signals and Units) asserts the following:

An application where Rectangular weighting is a "must", is in system analysis using a pseudo-random excitation signal. A pseudo-random signal is a periodic signal with its period length adjusted to the record length T of the analysis. All the components of the pseudo-random signal will therefore coincide with the centre frequencies of the filters (lines) and the analysis will be free of leakage assuming Rectangular weighting is used (optimal situation or "best case").

This assertion is false, and therefore we need to be careful about the claim "A window function is also not used when a periodic signal's period matches that of a Fourier transform".

To understand, let the filter/line center-frequencies be k/T, for integer values of k. A component rectangularly windowed to interval [0,T], will have a sinc-shaped spectral leakage pattern (Fourier transform) with zeros at every center-frequency except k/T. So computing only those lines gives the appearance of no leakage, whether the windowed function is repeated periodically or not. Periodic repetition causes the entire Fourier transform to be zero at every frequency except k/T, which is what the author interprets as no leakage.

However, a component rectangularly windowed to interval [0,T], will also have a sinc-shaped spectral leakage pattern (Fourier transform), but it will have non-zero values at every center-frequency. The peak amplitude at frequencies k/T and (k+1)/T will be distorted (reduced) by about 4 dB relative to the previous case (the component), due to scalloping loss. And the amplitude at frequency (k+10)/T (for example) will be only about 26 dB lower than that, which makes it impossible to resolve a lower-level component at that frequency using a rectangular window. In this case, periodic repetition of the windowed function does not hide the leakage. It does cause the underlying Fourier transform to be zero in-between the center-frequencies, but all the center-frequencies contain non-zero leakage, which can be redistributed (but not eliminated) by a non-rectangular window function.

--Bob K (talk) 16:06, 15 March 2016 (UTC)[reply]

The same problem appears to apply to the unreferenced shaft alignment claim. And the OFDM point is unnecessary at best, irrelevant at worst, because no OFDM algorithm description calls for windowing. The same is true when FFTs are used for fast convolution and probably many other non-spectral-analysis applications. No need to list them all here... this article is about windows, not FFTs.

--Bob K (talk) 11:59, 16 March 2016 (UTC)[reply]

Doesn't the +0.5 make the signal have a period of 2 T and therefore violate the premise of period T? Glrx (talk) 18:54, 20 March 2016 (UTC)[reply]

is the frequency (cycles per second). Therefore, the period is (seconds per cycle). The number of cycles per T sec is .
--Bob K (talk) 21:45, 21 March 2016 (UTC)[reply]

If in T seconds you have a half cycle left over, then the period is 2 T not T. That is, everything repeats over 2 T. Glrx (talk) 18:51, 24 March 2016 (UTC)[reply]

Oh, now I see what you mean. However, pseudorandom usually means it is generated randomly (in some sense) for a known duration (T), and it is repeatable. Repeating it with period T makes it periodic, regardless of its frequency content. Then the Fourier transform of the periodic signal is a line spectrum (Fourier series). A sinusoidal component with frequency will have just one line (no leakage). If one knows apriori that all the components are harmonics of , and the purpose of analysis is to determine which harmonics are present, then rectangular windowing is indeed necessary. Good point!
--Bob K (talk) 12:33, 25 March 2016 (UTC)[reply]

Belatedly pinging @Damian Yerrick:, who was the last to edit the offending section, just to make sure he is aware of the removal and subsequent discussion; I have no opinion other than that this edit seems to satisfactorily resolve the issue. --SoledadKabocha (talk) 00:11, 17 May 2016 (UTC)[reply]

Signs

[edit]

There is a recent edit, and revert, regarding the signs of the Blackman and Blackman-Harris window functions. Looking at the actual references, they are inconsistent on these signs.

Note that mathematical convention is normally to put the sign into the unknown constant, instead of into the summation, for the more general case.

But given that two reliable sources (Stanford University and National Instruments) can't agree on the sign, someone should work this out. Gah4 (talk) 18:22, 11 February 2017 (UTC)[reply]

The 10 Feb version of Blackman Window was incorrect for w[n] defined on 0 ≤ n < N. It might be correct for w0(n), defined on -N/2 ≤ n ≤ N/2. So the 11 Feb correction is the right version. Whether or not the coefficients should include negative signs is a different issue. In general, I would expect that they would, and some references surely use that convention. But in this case, we have a class of windows ("cosine sum") that all exhibit the property that their even-numbered coefficients are positive and their odd-numbered coefficients are negative. That is a distinctive feature of the class, and it is made more apparent by this formulation (where all coefficients ak ≥ 0):
--Bob K (talk) 17:11, 30 September 2017 (UTC)[reply]
I strongly believe the signs should go into the coefficients. It will make manipulation of the equations easier and less error-prone with just addition. The signs alternating is not a rule that could not be broken. Consider for example "genetic algorithm"-type optimization of window functions. Would one optimize coefficients with one sign each only? I would not as no-one has shown evidence that the signs will always alternate for useful window functions. Olli Niemitalo (talk) 04:40, 6 May 2018 (UTC)[reply]
Strongly? Well I strongly disagree with you for the reason I already mentioned, and these:
it's the cos() functions that change sign, not the coefficients.
--Bob K (talk) 18:47, 6 May 2018 (UTC)[reply]
You are right, I was wrong. I figured out the reason for the alternating sign: A "zero-centered" version of such a window has the same coefficients and only additions in the formula. In other words the value of the cosine terms, before multiplication by the coefficients, is always positive at the center of the window, and alternates at each end. The article's formulas need the alternating signs to take this into account. I made the common mistake of forgetting that the article does not have zero-centered windows functions. However, the coefficients need not be positive. Olli Niemitalo (talk) 14:58, 7 May 2018 (UTC)[reply]

Perfect windowing function!

[edit]

1. Double 'k'
2. Create a B–spline window with 'k'

rinse and repeat

This procedure reduces sidelobe levels each time it is done!

Cosine sum optimization

[edit]

cos(2 pi n) can be turned into cos(4 pi n) by (cos(2 pi n))²×2-1 so that another cosine won't have to be calculated. 2A01:119F:21D:7900:54E1:9029:DEED:43A1 (talk) 09:44, 8 August 2018 (UTC)[reply]

There's more to it. cos (6×π×n) is also (cos (2×π×n))³×4-(cos (2×π×n))×3. And cos (8×π×n) is also (cos (2×π×n))⁴×8-(cos (2×π×n))²×8+1. So we have t=cos (2×π×n), and five cosine sum terms:
  • cos (0×π×n)=1
  • cos (2×π×n)=t
  • cos (4×π×n)=2t²-1
  • cos (6×π×n)=4t³-3t
  • cos (8×π×n)=8t⁴-8t²+1
Five cosine sum terms with one cosine computation.79.185.231.241 (talk) 17:59, 2 May 2021 (UTC)[reply]

Approximate confined Gaussian window

[edit]

This section contains the statement:

The temporal width of the approximate window is asymptotically equal to Nσt for σt < 0.14.

Looking at the σt=0.1 example, the 0.1•N width occurs at an amplitude of about 0.94 (-0.5 dB). That seems like an unusually high level at which to define a window's "width".  The -3 dB width, for example, is about 0.25•N.  I'm going to assume, without proof, that we're actually talking about the temporal standard deviation, which is actually a measure of half-width.  So, multiplying by 2, the 0.2•N "width" occurs at an amplitude of about 0.8 (-2 dB), which is somewhat more intuitively pleasing. Bottom line: I'm going to change "temporal width" to "standard deviation".
--Bob K (talk) 16:27, 25 October 2018 (UTC)[reply]

How would a function like this rolloff?

[edit]

The sine window to the power of the inverse of the sine window

Hfaiovena4t (talk) 05:45, 18 September 2019 (UTC)[reply]

This forum is for discussion about improving the article. Perhaps someone at https://dspguru.com/comp.dsp/ or https://www.dsprelated.com/groups/comp.dsp/1.php will take an interest in your question.
--Bob K (talk) 12:36, 18 September 2019 (UTC)[reply]

Does "lower noise bandwidth" mean "lower-noise bandwidth" or "smaller noise bandwidth"?

[edit]

The current article version contains the text:

"But the function designed for N+1 or N+2 samples, in anticipation of deleting one or both end points, typically has a slightly narrower main lobe, slightly higher sidelobes, and a slightly lower noise bandwidth."

What is meant: "lower-noise bandwidth", "smaller noise bandwidth" , or something else? Since "high" and "low" are already in use for the height of the graphs, I suggest to use "large" and "small" for the bandwidth, to help prevent misunderstanding.Redav (talk) 14:24, 18 July 2020 (UTC)[reply]

"smaller noise bandwidth" works fine. I'll make the change if you haven't.--Bob K (talk) 15:31, 18 July 2020 (UTC)[reply]

Asymmetric

[edit]

There are these useful alternative ways to see a window function:

  1. A prototype continuous-time function that is zero-valued outside an interval. (Not applicable to all window functions.)
  2. A finite-length discrete-time sequence, possibly obtained by sampling the continuous-time function.
  3. A two-way infinite-length periodic extension of the finite-length sequence.
  4. A two-way infinite-length sequence obtained by zero-padding the finite-length sequence on both sides.

I think only those windows should be called "asymmetric" that are asymmetric in all applicable views. For examples of such window functions, see M. Schnell, M. Schmidt, M. Jander, T. Albert, R. Geiger, V. Ruoppila, P. Ekstrand, M. Lutzky, B. Grill, MPEG-4 Enhanced Low Delay AAC - a new standard for high quality communication, 125th AES Convention, San Francisco, CA, USA, preprint 7503, Oct. 2008 or Schnell, M., et al. 2007. Enhanced MPEG-4 Low Delay AAC – Low Bitrate High Quality Communication. In 122th AES Convention. Olli Niemitalo (talk) 08:13, 9 August 2020 (UTC)[reply]

Hi Olli. It's been a while. The term asymmetric is applicable to the only view defined in the article. Or to put it another way, the term is clearly defined in the article. Other articles or references may define it to suit their particular purposes. Perhaps you would like to add a section about all the views that are not covered in the article. Or perhaps just a footnote to the effect that our definition is not ubiquitous across the literature (which is not at all unusual).
Otherwise, what term are you proposing instead? DFT-even? Periodic? Those are the only ones I know of, and I don't think either of them is as descriptive as Asymmetric. And none of them are ubiquitous in the literature. To my surprise, a google search for the actual term DFT-even only turned up the original 1978 article, some amateurish chat pages, and the abstract of an article containing the statement "It can be shown [for short window lengths], that the DFT-even sampling technique as proposed by Harris is not the most suitable one."
--Bob K (talk) 15:52, 9 August 2020 (UTC)[reply]
Hi Bob! Yep I've spent much more time at DSP Stack Exchange lately. It might be best to be verbose as in "has a symmetric periodic extension", while "periodic" is also popular but not very descriptive and is also technically correct only in view 3 which is not the main view 2 of the article (the lede takes view 1 or 4). "Asymmetric", while technically correct in view 2, not in view 3 and possibly not in views 1 and 4, is only used in this article, and is not very descriptive. I think Harris means by "even" (also in "DFT-even") not even-length sequences but sequences with even symmetry, in contrast to an odd symmetry. "DFT-odd" is then a misnomer as we are not dealing with anti-symmetric windows. Olli Niemitalo (talk) 06:17, 10 August 2020 (UTC)[reply]
Good point. Upon re-reading Harris, I noticed the term DFT symmetry (bottom of p 52). So DFT-symmetric is another possibility, and less of a mouthful than "has a symmetric periodic extension" (which would be better as a footnote).
--Bob K (talk) 12:02, 10 August 2020 (UTC)[reply]
"DFT-symmetric" sounds fine to me! Olli Niemitalo (talk) 14:25, 10 August 2020 (UTC)[reply]
And thanks so much for all your help, now and before. You are amazing.
--Bob K (talk) 15:27, 10 August 2020 (UTC)[reply]
Olli, I scanned the links you provided, and my conclusion is that your problem is easily addressed by moving Section 1.5 to 1.1.5, where it will be clear that the symmetry/asymmetry discussion is about windows for DFT spectral analysis, not filter banks or filtering.
--Bob K (talk) 18:21, 9 August 2020 (UTC)[reply]

Generalized Adaptive Polynomial (GAP) window

[edit]

The figure provided looks fine, but I was not able to reproduce it using the formula provided and the coefficients published at https://www.semanticscholar.org/paper/Generalized-Adaptive-Polynomial-Window-Function-Justo-Beccaro/d8a89c11dcd8698b4ec47f5f9f2d015807d0bf75/figure/0 This is my attempt, using the plotWindow function at https://commons.wikimedia.org/wiki/File:Window_function_and_frequency_response_-_Rectangular.svg

N = 2^14;
ak = [-1.950123 1.751639 -0.965132 0.362922 -0.094316 0.014043 0.000638 -0.000907 0.000200 -0.000016];
k  = 1 : length(ak);
n  = -N/2 : N/2;
w = [ ];
for m=n
   w(end+1) = sum(  ak.*((m/N).^(2*k))  );
endfor
w = w - min(w);
w = w / max(w);
plotWindow(w, "GAP")

I also tried these (Hann) coefficients:
ak = [-0.827799 0.296717 -0.354860 0.754177 -0.972745 0.759919 -0.365929 0.106195 -0.017029 0.001159];

--Bob K (talk) 20:13, 31 October 2020 (UTC)[reply]

Probably you need an a0 term of 1, and maybe run from -N:N. But that still doesn't quite do it. Dicklyon (talk) 01:19, 1 November 2020 (UTC)[reply]
This seems to work pretty nearly. I have no idea why the 1.65 (I haven't looked at the paper).:
N = 2^10;
ak = [-1.950123 1.751639 -0.965132 0.362922 -0.094316 0.014043 0.000638 -0.000907 0.000200 -0.000016];
ak = [-0.827799 0.296717 -0.354860 0.754177 -0.972745 0.759919 -0.365929 0.106195 -0.017029 0.001159];
k  = 1 : length(ak);
n  = (-1.65*N):(1.65*N);
w = [ ];
for m=n
   w(end+1) = 1 + sum(  ak.*((m/N).^(2*k))  );
end
figure(1)
plot(w)
The article is here: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9223641
It has the same formula (#2) that I am using (n = -N/2 : N/2).
When n=-N/2:N/2, the statement w=w-min(w) causes an effective a0=0.4, which gives a better result than 1.0.
Instead of n=(-1.65*N):(1.65*N), I think you can get the same effect with w(end+1)=sum( ak.*((m/N*2*1.65).^(2*k)) ).
--Bob K (talk) 03:06, 1 November 2020 (UTC)[reply]
The article says a0 = 1. And the shape starts to look more Hann-like if you go out to 1.65*N. Obviously, something is wrong, but I don't think subtracting the min is the answer. Dicklyon (talk) 01:50, 2 November 2020 (UTC)[reply]
Turns out the authors have a matlab implementation at Mathworks File Exchange. It has different coefficients, but the big difference is that they convert the index sequence to an x sequence by dividing by standard deviation of the index sequence, rather than by N. That ratio N/std(...) is about 3.3, changing the needed N/2 to 1.65*N. The article is not self-consistent, and this approach to normalizing in the Matlab code is also not quite consistent with the letting t run to T/2. Too bad they messed up this way. Here's what they have for Hann:
   case 'hann' 
    a2 = -0.8236640350672578; a4 = 0.2396934226088473; a6 = -0.0910329438155984; 
    a8 = 0.1546641760773942; a10 = -0.2008340012917025; 
    a12 = 0.1591065890832292; a14 = -0.0777111572266440; a16 = 0.0228723527427099; 
    a18 = -0.0037192072905112; a20 = 0.0002565996927828;
Dicklyon (talk) 02:47, 2 November 2020 (UTC)[reply]

Yep, that works. Congratulations. Here is my original code, slightly modified:

% optimized Nutall
ak = [-1.9501232504232442 1.7516390954528638 -0.9651321809782892 0.3629219021312954 -0.0943163918335154 ...
0.0140434805881681 0.0006383045745587 -0.0009075461792061 0.0002000671118688 -0.0000161042445001];

N = 2^14;
k  = 1 : length(ak);
n  = -N/2 : N/2;
sigma = std(n);
w = [ ];
for m=n
   w(end+1) = sum(  ak.*((m/sigma).^(2*k))  );
endfor
w = w + 1;
w = w / max(w);
plotWindow(w, "GAP")

Note that when n=-N/2:N/2, mean(n)=0. No need to compute it and subtract it.
I also noted that w+1 is slightly better than w-min(w), even though -min(w) = 1.0002
It doesn't matter now, but when using the original normalization factor (N), the function width exceeded the window width (N), so its min value never got near -1. That is why -min(w) = 0.4 was a better choice.

Their matlab implementation, with a couple of improvements, looks like this:

% optimized Nutall
ak = [-1.9501232504232442 1.7516390954528638 -0.9651321809782892 0.3629219021312954 -0.0943163918335154 ...
0.0140434805881681 0.0006383045745587 -0.0009075461792061 0.0002000671118688 -0.0000161042445001];

N = 2^14;
n = -N/2:N/2;
x = n/std(n);
w = 1;
for k = 1 : length(ak)
   w = w + ak(k)*(x.^(2*k));
endfor

w = w/max(w);
plotWindow(w, "GAP")

--Bob K (talk) 15:51, 2 November 2020 (UTC)[reply]

You should put that code in your new figure description. File:Window function and frequency response - GAP optimized Nuttall.svg. Dicklyon (talk) 18:11, 2 November 2020 (UTC)[reply]

The source code section of that file has a link to the place where all the source code resides for all of the window functions, including this one. The link is https://commons.wikimedia.org/wiki/File:Window_function_and_frequency_response_-_Rectangular.svg

--Bob K (talk) 18:19, 2 November 2020 (UTC)[reply]

Replacement of N + 1 by L

[edit]

In this diff the formulas for the approximate confined Gaussian window and the Tukey window have been changed. It seems that should be replaced by . The formulas for the approximate confined Gaussian window seem to changed correctly. But in the formulas for the Tukey window has been used to replace instead of , which changes the window definition and the formulas for the Tukey window seem to be wrong now. If this change wasn't intended, it should be fixed. Christian Gruber (talk) 09:56, 13 January 2021 (UTC)[reply]

Good catch. Thank you. I also clarified that the convolution described there is in terms of the convolution of continuous functions. In terms of discrete convolution, each function has one sample more than the number of sample-intervals.
--Bob K (talk) 19:09, 13 January 2021 (UTC)[reply]

Discrete convention is bad idea at all for purpose of this page

[edit]

Essential purposes of window functions are not related to their discretisations within particular applications. Discretisation of window functions, where it needed, is separate problem. Lets not mix that all into common messy heap. Lets define window function as function defined on real range [-1,1] instead. Almost all windows have simplest definition in this form, and simplest method to get discrete version from it is trivial and common, but more advanced methods are also may be useful, and they may relate on rather technical application-specific details, and not related to selection of particular window function.

There are two well-known windows which can be complicated to understand in this context, Dolph-Chebyshev and ultraspheric. Here problem can arise because of specific way how they defined mathematically. They are defined by periodic functions in frequency domain, with explicit parameter N in definition, hence they intrinsically discrete in time domain. From such definition, we have natural prescription how to calculate window in discrete form only, but it is not prescription how to understand and use such calculated window, we can still understand it as discrete samples of some non-discrete function to use it same way as any other window function. — Preceding unsigned comment added by Lexey73 (talkcontribs) 12:29, 19 December 2021 (UTC)[reply]

The separate articles Hann_function and Kaiser_window are examples of what you suggest except for the parameter which you suggest should be simply 2. Both the zero-phase forms and the lagged forms are equally simple functions, but someone decided both windows deserve their own article, which is fine. And that is the approach you should take for your two examples. Let's see what you come up with, and then revisit how it affects this article, or not.
--Bob K (talk) 23:26, 19 December 2021 (UTC)[reply]

That "L" is trivial scaling factor, it only unnecessary complicates equations, and makes illusion that it is essential parameter of window function. Anyone can apply such trivial scaling where needed. Lets simply say something like "support bounds of windows here assumed to be [-1,1]" in "convention" section,

The continuous Hann function is not defined as duration 2. In these examples, it is length T :  https://www.sciencedirect.com/topics/engineering/hanning-window and http://www.vibrationdata.com/tutorials_alt/Hanning_compensation.pdf
And in this one it is TSpan :  https://www.dataphysics.com/downloads/technical/Effects-of-Windowing-on-the-Spectral-Content-of-a-Signal-by-P.-Wickramarachi.pdf
And here is one with length L (see eq.(3)): https://zenodo.org/record/1280930
It is easier for someone to set L=1 (or 2) in a general version of a formula, or a subsequent result of the formula, than to reinsert a missing parameter in all the correct places. For instance these results in Hann_function:
Not so trivial, I would say.
--Bob K (talk) 01:07, 27 December 2021 (UTC)[reply]

and remove all that annoying "N" and "L" from where they not really necessary.

That is how you do the transformation from continuous to discrete, which is your original suggestion.

I think it is bad idea to make separate page for every simple thing like Hann_function and Kaiser_window Lexey73 (talk) 10:36, 26 December 2021 (UTC)[reply]

But those articles are able to go into greater depth, if someone cares to do so. Window function is already long enough.
--Bob K (talk) 23:25, 26 December 2021 (UTC)[reply]
- it is common formula for any window to convert it from [-1,1] convention to [-L/2,L/2]  --Lexey73

The fact that it's correct does not make it common. Much more common to set T or TSpan or L to whatever specific length an application calls for. I've given you several online examples. Where are yours? --Bob K (talk) 21:14, 27 December 2021 (UTC)[reply]

for [-1,1] convention (simply replace L by 2 everywhere in formulas where [-L/2,L/2] convention was used)  --Lexey73

Yeah... it is simple... which is my point. Thank you. --Bob K (talk) 21:14, 27 December 2021 (UTC)[reply]

Note that your first formula is wrong Lexey73 (talk) 14:57, 27 December 2021 (UTC)[reply]

Here you are caught by illusion that L is essential parameter of function, because L not appeared everywhere near f, but it exactly equals to:

Lexey73 (talk) 18:56, 27 December 2021 (UTC)[reply]

Declaring a mathematical equivalence wrong is not a credible way to make your point. But I'm OK with either expression, as long as they are parametric in L.
BTW, what I like about vs is that the frequency offset between terms is more readily apparent (at least to me).
--Bob K (talk) 21:38, 27 December 2021 (UTC)[reply]

It is clear that two formulations of same function are not equivalent, and I see that second is exact, hence something wrong with first expression. Maybe it is approximation? than you will say clearly that it is approximate equation. And it is unclear reason to introduce approximate equation which is only slightly simpler than exact equation. So I suggest to simply remove that suspicious first equation from that page if you can't clarify this question in any other way. --Lexey73 (talk) 08:46, 28 December 2021 (UTC)[reply]

And yesterday you said: "it exactly equals to:
"
which I agree with. Apparently all you want is the last word, so I'm probably done with this thread.
--Bob K (talk) 15:59, 28 December 2021 (UTC)[reply]

I'm about this pair:

they are far not equivalent to each other --Lexey73 (talk) 16:56, 28 December 2021 (UTC)[reply]

Nuttal - Window - Text shortened

[edit]

For some reason, the test "Nuttal" is shortend in the image's headline. The "N" is not visible. The graphic will have to be changed, i think. 85.190.194.180 (talk) 14:36, 3 February 2022 (UTC)[reply]

Thanks. But you're only looking at a "thumb" representation of the actual figure. Thumbs are just approximations. To see the actual, click on the thumb and then click on the Original file link.
--Bob K (talk) 22:52, 3 February 2022 (UTC)[reply]

Nulls on chart are wrong

[edit]

See the WikiCommons discussion: https://commons.wikimedia.org/wiki/File_talk:Window_functions_in_the_frequency_domain.png — Preceding unsigned comment added by 92.40.200.3 (talk) 12:55, 29 April 2022 (UTC)[reply]

I replaced the figure with a better one. --Bob K (talk) 13:04, 1 May 2022 (UTC)[reply]