You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: magnitude_spectrum returns negative magnitudes for negative-sum windows #32054
This is a regression introduced by PR #25122. The change replaces absolute window sums with signed sums. For the all-negative window above, the magnitude spectrum is divided by -8, changing the magnitude at frequency 2 from 0.5 to -0.5.
The example uses the public mlab.magnitude_spectrum API with a numeric window array, which is a legal input. Although removing abs() was the stated implementation strategy for correcting signed-window scaling, the resulting negative magnitude is an unintended behavioral regression.
I'd consider that a malformed window so garbage in garbage out. What are you trying to achieve that you would provide a negative sum window but don't want the resulting spectrum to also be negative?
We can always reopen. One could argue that a magnitude spectrum should always produce non negative values, but given that negative values indicate a broken window, I think it's ok to leave this be
All this aside from the fact that we should remove mlab
Regarding the bot concern: the paper linked (arXiv:2603.03121) describes a GUI testing tool for desktop applications, which is a different project. This regression was identified through manual analysis of the behavioral change introduced by PR #25122.
My understanding is that this is not simply a change in behavior. magnitude_spectrum computes |FFT(x)|, whose output should be nonnegative by definition, regardless of the window used. While PR #25122 addressed #24821, it appears that removing np.abs() also introduced this side effect.
The numerator, np.abs(result), is always nonnegative. From the PR discussion, it seems the motivation was to correct the normalization for psd mode (particularly for flattop windows, whose sums are positive). This edge case for magnitude mode with a fully negative window does not appear to have been considered during the review.
Since magnitude_spectrum computes |FFT(x)|, the output is expected to be nonnegative regardless of the window values. With the current implementation, a negative-sum window produces negative magnitudes solely because of the normalization denominator.
One possible way to preserve the intent of #24821 while keeping the magnitude output nonnegative would be:
Activity
jklymak commentedon Jul 17, 2026
I'd consider that a malformed window so garbage in garbage out. What are you trying to achieve that you would provide a negative sum window but don't want the resulting spectrum to also be negative?
rcomer commentedon Jul 17, 2026
Apparently OP is a bot, so there isn’t a genuine use case behind the report.
https://arxiv.org/pdf/2603.03121
Suggest closing if the example doesn’t make sense. I can’t make that call myself as I don’t know anything about
magnitude_spectrum.jklymak commentedon Jul 17, 2026
We can always reopen. One could argue that a magnitude spectrum should always produce non negative values, but given that negative values indicate a broken window, I think it's ok to leave this be
All this aside from the fact that we should remove mlab
RippleTester commentedon Jul 20, 2026
Thanks for the responses.
Regarding the bot concern: the paper linked (arXiv:2603.03121) describes a GUI testing tool for desktop applications, which is a different project. This regression was identified through manual analysis of the behavioral change introduced by PR #25122.
To clarify the behavioral change:
magnitude_spectrumnormalized usingnp.abs(window.sum()). Even with a negative-sum window, the resulting magnitudes were nonnegative (e.g.,0.5).np.abs()was removed, so the same input now produces negative magnitudes (e.g.,-0.5).My understanding is that this is not simply a change in behavior.
magnitude_spectrumcomputes|FFT(x)|, whose output should be nonnegative by definition, regardless of the window used. While PR #25122 addressed #24821, it appears that removingnp.abs()also introduced this side effect.RippleTester commentedon Jul 20, 2026
As a follow-up, I looked at the actual diff in PR #25122. For
mode == "magnitude", the relevant change was:The numerator,
np.abs(result), is always nonnegative. From the PR discussion, it seems the motivation was to correct the normalization forpsdmode (particularly for flattop windows, whose sums are positive). This edge case formagnitudemode with a fully negative window does not appear to have been considered during the review.Since
magnitude_spectrumcomputes|FFT(x)|, the output is expected to be nonnegative regardless of the window values. With the current implementation, a negative-sum window produces negative magnitudes solely because of the normalization denominator.One possible way to preserve the intent of #24821 while keeping the magnitude output nonnegative would be:
jklymak commentedon Jul 20, 2026
What does scipy.signal do with a window that sums to a negative value?