Hi Folks -- I implemented an improved Fourier transform routine, called imfourier(...) It is sorta like the pre-existing fourier(...) routine, except: ++ On the input, it can accept complex numbers represented as strings, in a single column. ++ It can also accept complex numbers represented by separate real and imaginary parts, in two columns. ++ The inverse transform is normalized to be the actual /inverse/ of the forward transform. ++ Input slots are never skipped. ++ As a related point, anything that can be coerced will be coerced to a number. ++ There is also a zeropad(...) function, which makes it easy for folks to pad their data so that the number of rows is a power of 2. This lays a foundation for the future. We should not be training users to expect that our FFT will always require powers of 2.
To say the same thing the other way: -- The pre-existing fourier(...) does not accept complex inputs under any conditions. -- Not coincidentally, it is not invertible. -- Not coincidentally, this makes it unusable for a wide range of important applications. -- In many situations, the failure manifests itself as a non- obvious numerically-incorrect answer, rather than a warning or error message. -- The limitations were undocumented. Compatibility: With one exception, anybody using the old fourier(...) routine can get the same /or better/ results using imfourier(...). The one thing the latter does not do is _skipping invalid data_. I don't even know what that's supposed to mean when there are separated real and imaginary parts, and one part is valid when the other part is not. Also, the whole idea of skipping points in time-series data seems kinda sketchy. If anybody can describe a relevant use-case it would help us figure out what (if anything) to do about this issue. The patch can be found at http://www.av8n.com/computer/imfourier.patch There is also a spreadsheet at http://www.av8n.com/computer/imfourier.gnumeric containing examples of the upgraded transforms in action ... including transform/inverse_transform pairs. This is "alpha" code. Constructive suggestions are welcome. The patch applies to the current 1.12.1 tarball. In case anybody is wondering about the importance of this: It's true that not very many people using the Gnumeric Fourier transform feature at the moment ... but please imagine how many more people would use it if it were actually usable! Spreadsheets are great for rapid prototyping, for figuring stuff out. I know a lot of people who will benefit from this, as soon as an upgraded version is released. Comments, anyone? Questions? Suggestions? _______________________________________________ gnumeric-list mailing list gnumeric-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnumeric-list
