Upgraded Matlab from 2022b to 2023b and I've noticed a floating point error

I have recently upgraded my Matlab version from 2022b to 2023b and I have noticed a floating point error when running my code in windows, but not when I run it in linux. I'm sure my code hasn't changed at all so its unclear what's happened. Any ideas why this change has happened?

[Dyuman Joshi]

Please share your code and the error you get.

[Hannah]

@Dyuman Joshi It's not possible for me to share the code. I have a script that produces a .mat file. I then have a test that checks the script produces the correct .mat file by comparing it to a reference .mat file. I run the test locally in windows and it fails saying the .mat files don't match, however, pushing the changes to my gitlab pipeline (linux) the test passes. Comparing the .mat files with visdiff shows a random scattering of numbers in arrays that have a floating point error.

[madhan ravi]

You could mock your code with an example to identify the issue.

[Dyuman Joshi]

In addition to madhan ravi's comment -

How are you comparing the values? What is the test in use?

Try running the code here and see if the output matches or not, as the server here is run on Linux.

Edit - There is a time limit on running a code here, which is ~55 seconds.

[John D'Errico]

Could you have been any more vague? Well, I suppose, if you actively tried to be as vague as possible. Could there be a floating point error? Well, yes. There COULD be one. There was the infamous Pentium bug many years ago. Far more likely is you have made an error that you did not catch. That happens probably 99.9% of the time on Answers. Someone reports what they think is surely an error in MATLAB in some way, but in reality, what happened is they simply don't understand floating point arithmetic and how it works, or they have actually not used the same code on both systems, or one of many other possibilities.

So you can't or won't show us code that reproduces your "bug". And since your name is not Cleve Moler (where if he reported a bug, we would probably trust him implicitly) that means we will put you in the pool of the 99.9% of people who mistakenly found a bug that is not a bug, but a mistake they have made, due to one of an almost uncountable ways they could have gone wrong. Could we be wrong here? Of course! But I'd bet a good sum of money that I am not wrong, and you have just made some mistake. Lacking any other evidence, how could I choose differently?

Could it just be an issue of subtle differences between the systems, where a different library is employed between the different versions, and what you are seeing is normal floating point trash? Well, yes. But I would put that in the realm of just needing to understand floating point arithmetic. I might even say that is a likely possibility. But we cannot possibly know without seeing code that shows this happening.

So if you want help in this forum, you will need to show code that produces your error. Then we can execute it on different systems, and verify or disprove that you have found something.

OR, if you refuse to post code, then you need to spend the time debugging it yourself. You may be able to find someone who does know enough about MATLAB and floating point arithmetic, and who you are able to convince to help you, AND to whom you are willing to privately discose your code. (Don't send me direct mail asking for personal help. I won't invest the many hours that would surely take.)

You might be willing to send your code directly to MathwWorks (NOT here on Answers) as a techical support question. They don't divulge those things, effectively under an NDA. So if this is why you don't want to post code, that might be your only recourse.

[Hannah]

@John D'Errico Thanks for the constructive criticism

@Dyuman Joshi

I haven't added the code because its ridiculously long. To try and be more specific we are running a regression test to ensure that updates we introduce have not caused any unexpected bugs or changes to our output. The only change I made was to update the version of Matlab. I use the compare tool in the matlab IDE which shows that in a couple of the arrays, a few of the values have changed by about 1/10^12.

I will also speak to MathWorks directly.

[Hannah]

@madhan ravi

I will try and narrow the problem down and give an example

[John D'Errico]

Note that a difference of 1e-12 MAY be just floating point trash. It completely depends on the size of the other numbers involved. That is, a difference of one bit in the least sigificant bit of different size numbers may easily be as large as 1e-12. eps will tell you that.

eps(1)

ans = 2.2204e-16

eps(10000)

ans = 1.8190e-12

eps(1000000)

ans = 1.1642e-10

So a one bit difference in the least significant bits of the number 10000 is roughly 1e-12. If that is what you are seeing, if the numbers involved in your computation were of that magnitude, then you are probably just seeing floating point trash. The difference may be due to a subtly different version of the BLAS usd by the two different systems, so some numbers may have been added in a different order, getting a subtly different result.

Answer 1

[Steven Lord]

As others have said it's impossible to give a firm answer with the limited amount of information you provided. Some possibilities:

• We fixed a bug in one of the functions you were using that results in a different answer on Windows. You could check the Release Notes and/or the Bug Reports to see if any major changes affected one or more of the functions you used. [However, note that not all changes and not all bugs are reported in those two sections of the website.]
• We upgraded one of the numeric libraries (to enable new functionality, to improve accuracy, to improve performance, and/or to fix bugs) and the new library version gives an answer that is still correct but is not bit-for-bit identical to the answer in the previous release, perhaps due to a different amount of optimization performed in the library.
• We introduced a new bug in one of the functions you're using.
• The data on which you're operating could have changed.

Just because the answer is different doesn't necessarily mean it's wrong. So is the difference large enough that the answer is wrong or is it different but right? As an example, if the theoretical answer a function (let's say something like the integral function) should return using exact arithmetic was 0.5, the older version gave an answer of 0.49999999, and the newer version gives 0.50000001, is that necessarily wrong or a problem? Impossible to say without more information.

[Hannah]

Thanks for your help. Sorry its not possible for me to copy the code but I think I have narrowed it down to the line of code (quite difficult to determine exactly). The numbers aren't necessarily wrong, and don't currently cause further problems later on but before we commit changes we want to get a better understanding of what's actually happened.

X = 201x201 double

Y = 201x201 double

a 201x201 double = diff(X, [], 2)./diff(Y, [], 2)/sqrt(3)

Within this 201x201 double, a handful of the values have suddenly been calculated ever so slightly differently using the 2023b version of matlab to the 2022b version.

[Steven Lord]

Can you send a MAT-file containing those two variables and that line of code to Technical Support using this link? Please also include information about your computer (if you open the System Information app the OS Name, Version, and Processor are likely the most important pieces of information)