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 commented on 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 commented on 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 commented on 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 commented on 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:
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.
RippleTester commented on 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 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:
jklymak commented on Jul 20, 2026
What does scipy.signal do with a window that sums to a negative value?