#837 FFT windows are incorrectly scaled

[geraldfournier]

8aa20cfc9 2024-01-24 fft window functions back to correct scaling - no need need for post scaling step

This commit incorrectly changed the scaling for an unknown reason.

I am performing comparisons against Xyce, and am getting incompatible results.
Reverting this change gives good agreement.

Please revert 8aa20cfc9

[geraldfournier]

it looks as if 8aa20cfc9 was trying to normalize the peak of the windows to a value of 1, which is incorrect.

[geraldfournier]

Although this change would produce agreement with Xyce, It seems like Xyce has a different convention. That's why they might agree with window=rect, after recent fixes, but perhaps should not agree when a window is applied.

The ngspice 45 manual says:

All window functions have a rms value of 1. That means: 
No amplitude correction for the result is needed after 
applying the functions to the time domain input signal.

And I don't think Xyce makes the same choice.

So i'm putting this issue on hold until I have a better understanding.

[geraldfournier]

On second thought, the current behavior is consistent with the convention adopted by ngspice, which is to normalize results to match the signal amplitude. This means applying an ACF (Amplitude correction factors) in conjunction with windows which renormalizes the peak values to match signal amplitude.

I've identified two other small bugs/issues wrt FFT windowing in ngspice, but they are somewhat subtle and have only a minor effect on numerical results. Since attempts to fix bugs here have been SO dispiriting, I won't pursue these further.

As of 1c0bc1d5c in pre-master-46 (2026-03-06), I consider the FFT in ngspice to be largely usable, with some minor bugs/issues remaining around windowing, memory safety, usability, efficiency, and code clarity.

See also: 829(ZOMG),833,834,835,836.