1

I am importing a Matlab program to Octave. I made the program work. Now everything seems working quite well a part from precision.

I found Matlab and Octave give out slightly different result for same equation. For example, 

pi = acos(-1.0); 
mu_0 = 4*pi*10^(-7);

Then, Matlab and Octave give out same result for pi. However, for mu_0, Octave gives out 1.256637061435918e-006, but MATLAB gives out 1.256637061435917e-006.

The last decimal placement is slightly different. It does affect a lot in the final results (maximum difference in the results is about 0.0001, but I need to get lower than 0.00000001), because the program has a lot of equations for calculation.

Hence, I would like to know if we can make Octave to output exactly same result with Matlab? If we can't, how can I decrease the difference between their results? Can I solve this kind of problem by writing some code or changing some figuration?

Thank you very much for your help.

PS: The point is making the Octave output the same results with MATLAB.(The edited program doesn't have any difference in calculation with original program. ) Maybe, "variable precision arithemetic" does not help much, because MATLAB also make floating point round off error.

Killed_by_Bugs
  • 79
  • 2
  • 9
  • Suggestion: don't redefine `pi`. It is a built-in function, when you assign to it you overwrite it. – Cris Luengo Jul 31 '18 at 05:50
  • If you need that level of precision, then use symbolic computations (use a CAS - Computer Algebra System). If you want to use Octave, then use the symbolic package. However, if you're only doing symbolic computations, something like [Maxima ](http://maxima.sourceforge.net/) would be more adequate. – carandraug Jul 31 '18 at 09:53

2 Answers2

3

Floating-point calculations are inherently imprecise. Changing the order of operations will often cause rounding errors to change, which you will see in the last digit (if you are lucky, if you are unlucky the differences will be much larger!). You cannot expect two different programs, or the same program running on two different computers, to generate the exact same floating-point values.

If the difference between these two numbers is a problem to your computations, you should probably find out why this difference gets amplified, and change the order of your computations so that rounding errors do not cause this much harm.

Two additional suggestions:

  • Don't redefine pi. It is a built-in function, when you assign to it you overwrite it.

  • Use 1e-7, not 10^(-7). It is more readable and easier to type.

Cris Luengo
  • 55,762
  • 10
  • 62
  • 120
  • I would bet (but not tested) that `10^(-7)` would actually trigger a calculation on the CPU where `1e7` would not. – Andy Jul 31 '18 at 07:38
  • @Andy: yes, that makes sense. But I didn’t want to mention performance because parsing the code will be expensive either way, and the JIT will likely optimize out the computations with constants. – Cris Luengo Jul 31 '18 at 12:54
  • I don't think he mentioned it because of performance. I think he mentioned it because triggering a calculation introduces additional opportunities for floating point round off error to come into play. Also, I don't believe Octave has an active JIT compiler. – Nick J Jul 31 '18 at 22:36
  • Thank you very much. I vectorised the calculation part. (I have not even changed the order of operations) I get actually identical results by using MATLAB for the original code and vectorised code. However, Octave gives out huge difference in the results to MATLAB. We are using double precision in both MATLAB and Octave. It is unexpected that the difference can be 0.001, because double precision can provide 15 significant digits. It is not like a normal rounding errors. Do you think I should variable precision arithmetic to increase the significant digits and see if the errors smaller? – Killed_by_Bugs Aug 03 '18 at 11:13
  • @Killed_by_Bugs: yes, VPA will give you more digits of precision. But you might need to think about your computations, why the imprecision in the last digits is propagating so badly. – Cris Luengo Aug 03 '18 at 13:25
  • Thanks to your help. The results of Octave are more closed to MATLAB's results after fixing some code like `10^(-7)`. However, 3 of the output difference is still huge. Then, I found MATLAB and Octave gives out different results for `log(variable)` in last digit. Do you know how to fix it? – Killed_by_Bugs Aug 09 '18 at 13:41
  • @Killed_by_Bugs: There’s nothing to fix, the last digit of a floating-point number is meaningless. Change your code so you are not dependent on the last digit. Or use VPA as Nicky suggested in the other answer. – Cris Luengo Aug 09 '18 at 15:46
  • I found that it is not only last digit's problem. Sometimes, after calculation, MATLAB gives out 14 siginificant digits for double type data, but Octave gives 16. It does affect my final results a lot, because there are hundreds of variable and about 1000 lines calculation and the errors accumulates. After making 9 variables in the Octave' program identical to MATLAB's. The round off error seems reduced. The maximum difference between MATLAB's and Octave's results decreased on 6th digit after decimal point. – Killed_by_Bugs Aug 10 '18 at 13:58
  • I have tried to use VPA. However, because of VPA, the running time increased a lot and Octave crushed many times unfortunately. So I stopped using VPA. – Killed_by_Bugs Aug 10 '18 at 14:01
  • @Killed_by_Bugs: “MATLAB gives out 14 siginificant digits for double type data, but Octave gives 16” This is what they print out. Both use 64-bit floating point representation internally, so the precision should be identical. – Cris Luengo Aug 10 '18 at 16:19
  • Oh, I thought the numbers inside "workspace"(double click the variable. Then MATLAB shows a table. Double click the cell in that table, it shows a 14 significant digits number.) were the numbers MATLAB uses internally. Thank you. Do you know how to check the internal number that MATLAB uses for computations? – Killed_by_Bugs Aug 12 '18 at 18:05
  • Also, I found Octave read the number 33.05709076 as 33.05709075999999 by using `textscan`. Do you think Octave made round off error in `textscan`? – Killed_by_Bugs Aug 12 '18 at 18:17
  • You need to read this: https://stackoverflow.com/questions/686439/why-is-24-0000-not-equal-to-24-0000-in-matlab – Cris Luengo Aug 12 '18 at 18:21
1

Use variable precision arithemetic, vpa.

mu_0 = vpa(4e-7*pi,30); %Last number is the precision

Edit: As Cris noted in the comment, this solution requires the symbolic toolbox, if this is not available to you, you can download an alternative here: https://se.mathworks.com/matlabcentral/fileexchange/36534-hpf-a-big-decimal-class

Nicky Mattsson
  • 3,052
  • 12
  • 28