# Get the same FourierTransform results across different versions?

Posted 2 years ago
4044 Views
|
5 Replies
|
6 Total Likes
|
 My research lab has used Mathematica for many years developing models for fuel cells and simulating signals we expect from experimental measurements. Many of these files were created in version 9.0 and I have been running version 11.0.1 on my personal laptop. I updated to version 12 today and the code is giving a different output from a Fourier Transform. Specifically, it is a Fourier transform of a cosine that is multiplied by a Gaussian window function and a rectangular window function. From the revision history, it seems the FourierTransform function was last changed in version 11.2.All of this is shown in the attached file, but I will also repeat here for easy viewing. A few variables that need to be explained, ft= applied frequency, k= harmonic index, b= Gaussian window parameter, Cyc= number of signal waveforms, and nt= number of samples.The cosine is defined by: Where Vk and Vmk are complex coefficients as: The Gaussian window function is defined as: The rectangular window function is defined as: Finally, we take the Fourier transform of the windowed signal: The (presumably correct) answer from Versions older than 11.2 is: But the answer I'm getting now is: Using SameQ confirms these equations aren't equivalent. I've tinkered with the Fourier Parameters a bit, but that only seems to change the scaling coefficients. One obvious solution is reverting to pre-11.2, but I would like to avoid being stuck to a past version. Thank you in advance! Update: The apparent errors stemmed from changes in how Mathematica handles variable precisions and underflow. Using some workarounds from @Valerio in Q170416 and @halirutan in Q69912 I've updated my notebook to a working version. I would, however, appreciate if anyone knows of more elegant solutions than what I implemented. Thank you again! Attachments: Answer
5 Replies
Sort By:
Posted 2 years ago
 SameQ looks for an exact correspondence. Therefore, SameQ[x^2 - 1, (x + 1) (x - 1)] returns False, while the expressions are mathematically identical. When I am faced with situations like yours I would check by evaluating it numerically. The result should be a clear indicator of equivalence (or not). Answer
Posted 2 years ago
 I see, that's great to know for the future. I checked it numerically and they are not equivalent. Answer
Posted 2 years ago
 I checked it numerically and they are not equivalent. How did you check? I see this: Try this (from your notebook): Vf1 == Vf2 // Simplify (* Out: True *) Answer
Posted 2 years ago
 Interesting. I checked it numerically before posting the question and found they are not equivalent, but now I cannot replicate that. My outputs now agree with yours It's now seeming that these "errors" stem from Mathematica's changed handling of numerical precision in Version 11.3 or 11.2. When I check the numerical answer on a Version 9.0 notebook I get the following, where Vf is equivalent to Vf2 in the notebook I attached. As you can see, I've checked the numerical result of the first exponential coefficient in Vf2. On Version 9 this gives a small, but non-zero, result that is multiplied by large exponentials later in the equation to give the 17.64 . . . + i*17.64 . . . result. On the other hand, in Version 12 this first exponential coefficient becomes 0. Ultimately, the resulting FFT spectrum in Version 12 is populated entirely by 0 values: Instead of the expected FFT spectrum from Version 9: I'm currently following the suggestions on this thread for resolving precision issues, but am finding it only fixes Exp[x] inputs not E^x for some reason... Anyways, I suppose these issues are now outside the scope of the original question. Answer
Posted 2 years ago
 Using some workarounds from @Valerio on Q170416 and @halirutan plus @Nasser on Q69912 I've confirmed the issue arises from machine precision/ underflow checking.With those workarounds in place, the equation calculated in Version 12 gives the expected results And the equation calculated by Version 9 evaluates correctly in Version 12 as well: Where differences between the two are on the order of the precision being used: The workarounds may be somewhat clunky but at least they work. Thanks everyone for your replies, and I've attached an updated notebook with the implemented workarounds. Attachments: Answer