Does MATLAB code retain its accuracy when is executed in dsp kit?

Question

MATLAB code (at https://metrw-pitch.blogspot.com/ you can see improved code) executing in MATLAB online R2020b, outputs good accuracy even for low fundamental frequencies (fundFreq) but the code (originally in the answer to a question of mine) for a similar algorithm in C++ (ported in Matlab), executing in Visual Studio 2019, outputs bad accuracy in low (lower than 150 Hz) frequencies.

My question is whether MATLAB's code executing in a dsp kit retains its accuracy.
I'm homeless (in France) and get internet access only at Social Services offices and Post Offices, so it's impossible for me to run code with a dsp kit. Would you please test MATLAB's code in your dsp kits and tell me its output for fundFreq 50, 60 and 70 Hz? Be aware that when changing fundFreq, also change, if necessary, FFTfundFreq and/or GridDemiSpan so that the grid's span covers fundFreq.

I have asked a similar question on 8 Feb 2021 at 13:25, at MATLAB but nobody answered yet.

Copy of Matlab's code without comments is following.

SampFreq = 16000;
Segm = 1:1600;
FundFreq = 50;
FFTfundFreq = 41;
GridDemiSpan = 10;
FirstHarmAngles = FundFreq2pi/SampFreqSegm+1.9pi;
SinFirstHarmAngles = sin(FirstHarmAngles);
SecondHarmAngles = FundFreq22pi/SampFreqSegm+0.9pi;
SinSecondHarmAngles = sin(SecondHarmAngles);
ThirdHarmAngles = FundFreq32pi/SampFreqSegm+0.3pi;
SinThirdHarmAngles = sin(ThirdHarmAngles);
Xn = 170000SinFirstHarmAngles+220000SinSecondHarmAngles+...
150000*SinThirdHarmAngles;
Freqs = FFTfundFreq-GridDemiSpan:0.1:FFTfundFreq+GridDemiSpan;
MagnSqrd = ones(1,201);
for f = 1:201
   Angles = Freqs(f)2pi/SampFreqSegm;
   XnCos = sum(Xn.cos(Angles));
   XnSin = sum(Xn.*-sin(Angles));
   MagnSqrd(f) = XnCos.^2+XnSin.^2;
end
[maxMagnSqrd, maxMagnSqrdIndex] = max(MagnSqrd);
GRIDfundFreq = Freqs(maxMagnSqrdIndex);
disp(GRIDfundFreq);

Answer 1

Yes, C\C++ code generated from Matlab/Simulink code should behave the same as the original code.

However there are a few caveats, here are 3 problems I've experienced in real-life.

1 - Simulink\Matlab performs an implicit reset just before starting the simulation/script. Make sure you perform this reset in your C\C++ code, otherwise your results won't be the same and won't be comparable. Simulink coder generates a reset function for you. I've seen a corner case where the reset function would not reset all global variables, so be careful.

2 - Variable types. Matlab/Simulink typically use double-precision floating point variables. If your code uses doubles then great. The behaviour should be the same. However, for performance reasons, you might choose to use single-precision floating point variable aka floats. Then the behaviour could change slightly. There are ways to mitigates the effect of quantization, some algorithms are really sensitive to precision, others less so. Even if you use doubles there are some difference between platforms. So if you use doubles on an ARM µProcessor, the behaviour could be slightly different in corner cases.

3 - Integer saturation. I made the mistake in the past of using a 32-bit integer in Matlab as a free-running counter. It worked well, but after like 10 days the code would freeze. The counter would be stuck at 2^32-1 instead of wrapping back to 0. Obviously, you won't see that behaviour in simulation. So be careful, test your code thoroughly.

Answer 2

As long as your C++ implementation uses the same data types and the same algorithm structures the results should either be very close or even bit-exact, provided both platforms are compliant with "normal" standards, i.e. IEEE-754.

The link to the Matlab code doesn't work ("forbidden"). A quick look at your C++ code shows that you are using float as your main data type, which has 32-bits of precision. Matlab's default data type is double which is a 64-bit type. Unless your Matlab code specifically uses single, I would expect your Matlab code to perform much better than the C++ code.