0

I found some error in multiplication while using Octave. For instance look below.

Edit: It is not the same as 24.0000 = 24.0000. That is towards understanding why it happens. I am looking for a command or syntax to fix the number of digits in all varibales. Sort of a Global round off. I am facing issues with equality checks in my analysis because of this. And I did not face such issues in MATLAB. In matlab may be it is an issue with number representation. In octave it feels like it affects the solution.

Octave window:

>> b=3*19.05
b =  57.15000000000001
>> a=57.15
a =  57.15000000000000
>> a==b
ans = 0

Firstly why does this happen? I tried rounding off the variable using a code. However, many variables had such error. Now I really wonder how many such calculations went wrong. Or am I missing something here? I want to fix the number of digits of precision to say 6 or 10 or something. How do I do that for all variables. Something like a command in the beginning?

Bruce Lee Jun Fan
  • 13
  • 1
  • 6
  • `help format` E.g. set `format short`, then `19.05 * 3` will output `57.150`. – HansHirse Sep 09 '20 at 06:37
  • 2
    This has nothing to do with octave. It is a property of floating point arithmetic. See the classic [what every computer scientist should know about floating point arithmetic](http://cr.yp.to/2005-590/goldberg.pdf) paper (often cited on stackoverflow). – Tasos Papastylianou Sep 09 '20 at 07:44
  • E.g., see also: https://stackoverflow.com/q/54261566/4183191, and https://stackoverflow.com/q/62735901/4183191 – Tasos Papastylianou Sep 09 '20 at 07:48
  • @TasosPapastylianou I understand machine precision and the extra hidden digits stored for accurate computations. I have not faced this in matlab. I am looking for a general global command/sytax so that all variables have an accuracy of 10 digit or so. – Bruce Lee Jun Fan Sep 10 '20 at 10:39
  • @HansHirse Isn't that only for display purpose? Further I need atleast 6 digits precision. – Bruce Lee Jun Fan Sep 10 '20 at 10:40
  • @CrimeFighterCE Without a proper [mre] and some more detailed explanations, what your actual problems are, it's quite difficult to provide more help. Show the code, that worked with MATLAB, but does not in Octave. Are you sure, that it's not a simple display issue? – HansHirse Sep 10 '20 at 10:46
  • "I have not faced this in Matlab". I can confirm that `fprintf('%.30f\n', 19.05 * 3)` prints `57.150000000000005684341886080801` on both matlab and octave. Perhaps matlab's default formatting uses less significant digits when printing. When you say "an accuracy of 10 digits or so", you need to be explicit whether you are referring to 'representation', or _actual_ accuracy in terms of variable precision arithmetic. If what you're after is the latter, you need a library for vpa operations specifically. E.g. see https://octave.sourceforge.io/symbolic/function/vpa.html from the symbolic pkg. – Tasos Papastylianou Sep 10 '20 at 15:17
  • Having said that, 10 digits is nowhere close to floating point accuracy (let alone machine precision, i.e. `eps`, typically of the order 2^-52 for doubles). I doubt you need to involve such libraries. Your problem is probably more of a representational nature. E.g. using `num2str( a, 10)` to inspect `a` at 10 digit precision. – Tasos Papastylianou Sep 10 '20 at 15:22
  • Sorry, I need to correct myself. The examples on Wikipedia seems to contradict me on the above. https://en.wikipedia.org/wiki/Floating-point_arithmetic#Representable_numbers,_conversion_and_rounding. (good to learn something new). at 10 significant digits you may well start running into problems. Still, good to think whether you really need that much accuracy though, or whether it is more of a representational issue. – Tasos Papastylianou Sep 10 '20 at 15:33
  • @TasosPapastylianou Thanks for pointing out the issue in matlab aswell. However, I think in matlab it is only a representation issue. Where as in Octave, I am having issues with equality checks (although I understand equality checks are not really suggested) – Bruce Lee Jun Fan Sep 11 '20 at 11:22
  • @TasosPapastylianou `>> b=3*19.05 b = 57.15000000000001 >> a=57.15 a = 57.15000000000000 >> a==b ans = 0 >>` – Bruce Lee Jun Fan Sep 11 '20 at 11:22
  • @CrimeFighterCE There is no command to do what you ask. The accepted answer in the marked duplicate shows you how to get around this problem. I am extremely dubious that you would not see this exact same behavior in MATLAB since this is a problem with IEEE-754 floating point representation and binary arithmetic, not just Octave's implementation. – beaker Sep 11 '20 at 14:51
  • 1
    Type this in your octave terminal: `fprintf('%.40f\n%.40f\n', 19.05 * 3, 57.15 )`. You will see `57.1500000000000056843418860808014869689941` and `57.1499999999999985789145284797996282577515`. So octave is telling you the truth; these are not the same. However, at the specified tolerance (i.e. `1e-10`), they are: `assert( 19.05*3, 57.15, 1e-10 )`. This is why [you should never simply compare floats for equality](https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/). Either use inequality, or check the absolute difference is below some desired tolerance. – Tasos Papastylianou Sep 12 '20 at 08:46
  • The ONLY time it makes sense to compare two floats for equality directly, is if you're trying to find out _if they have been initialised in exactly the same way_. E.g. `a = 57.15, b = 57.15, a == b` will succeed, because here a and b are guaranteed to have the exact same floating point representation due to identical initialisation. – Tasos Papastylianou Sep 12 '20 at 08:48
  • In fact, I would go as far as suggesting that, if in matlab `19.05*3 == 57.15` succeeds, then this is a serious bug and it should be reported. No sane language should allow that. UPDATE: This is false on matlab as well. All is well with the world again. :) – Tasos Papastylianou Sep 12 '20 at 08:52
  • ```>> find(node(:,1)==b && node(:,2)==ro) ans = [](0x0) >> find(node(:,1)==b & node(:,2)==ro) ans = 6 >>``` – Bruce Lee Jun Fan Sep 15 '20 at 07:31

0 Answers0