Message Boards Message Boards

GROUPS:

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: voltage wave definition
Where Vk and Vmk are complex coefficients as: complex voltage coefficients
The Gaussian window function is defined as: gaussian window function

The rectangular window function is defined as: rectangular window function

Finally, we take the Fourier transform of the windowed signal: fourier transform

The (presumably correct) answer from Versions older than 11.2 is: correct output

But the answer I'm getting now is: incorrect output

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!

5 Replies

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).

I see, that's great to know for the future. I checked it numerically and they are not equivalent.

I checked it numerically and they are not equivalent.

How did you check? I see this: enter image description here

Try this (from your notebook):

Vf1 == Vf2 // Simplify
(*  Out:  True  *)

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 yoursenter image description here

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.enter image description here

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.enter image description here

Ultimately, the resulting FFT spectrum in Version 12 is populated entirely by 0 values:enter image description here

Instead of the expected FFT spectrum from Version 9: enter image description here

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.

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 resultsenter image description here

And the equation calculated by Version 9 evaluates correctly in Version 12 as well: enter image description here

Where differences between the two are on the order of the precision being used:enter image description here

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:
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract