I have the following function of sum of sines and cosines in both C++ and MATLAB and I am using this function for testing purposes. However, for some reason the output text file of both codes isn't matching. I double checked my parenthesis and floating point precision but with no difference.
> The output is a 2D array written in a text file but somehow not all the lines match.
Depends on what you mean by "not matching".
If you're talking about random +/-1 in the least significant digit of the results, then there's nothing to worry about, and probably little you can do about it.
what do you think that memset does?
memset is a byte dump function. it says set every BYTE to a value. Not every double. A double is 8 bytes, and you set all 8 of them to an identical value. If that value is not zero, and you are doing doing something extremely weird, its likely those statements are wrong.
@jonnin
Memset has always been a confusing function to me. Here I am initializing my XX and YY to zeros with a specific size so that I can later use them in functions. This has been the only "initializing" way that worked for me with fftw_malloc
@salem c
The type of difference b/w results I am talking about is like this:
As you can see, things start okay but suddenly change...
Obviously it's hard to compare by just looking or simply posting this here, since these are large text files. So, instead I found I loaded these files on MATLAB and found the difference between the two, and there's a significant difference.
you can clear doubles to zero with memset, but just use 0, not 42. You set each individual byte of the doubles to 42. If that somehow makes zero, I do not understand it.
as far as the two result streams drifting apart, the easy way is to check each term on both sets of code for the first 10 or something terms. see which term(s) are not correct, and we can look at that closer.
8 consecutive bytes holding 42 is not the double 0.0. According to Ganado it's 1.42603e-105. OP was already told not to use 42 with memset() back in April.
hmm... its pretty darn close to zero, though. Interesting trick, if mostly useless. I suddenly feel compelled to learn all 255 of the possible doubles to see if any ARE useful...
you may find it to be an order of operations issue, as well. its aggravating but if you keep comparing the inputs and terms you will find it going wrong somewhere. That is more than roundoff error in your output.
It seems the issue was a huge "round off" error. I didn't think to match the number of significant figures of MATLAB's output to the C++. When I set both to 16 sig figs that seemed to solve the issue. I clearly missed that somehow although it was almost obvious. Thanks!