bugGNU Octave - Bugs: bug #43741, different results from power...


bug #43741: different results from power operator in mxe-octave GUI/CLI

Submitter:  Avinoam Kalma <avinoam>
Submitted:  Tue 02 Dec 2014 07:28:54 PM UTC
Category:  Octave Function Severity:  5 - Blocker
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Wont Fix Assigned to:  None
Originator Name:  Avinoam Open/Closed:  * Closed
Release:  * 3.8.2 Operating System:  * Microsoft Windows
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Thu 02 Apr 2015 05:39:01 PM UTC, comment #17: 

Closing report with reason "Wont't Fix" as there isn't anything to be done here.

Rik <rik5>
Project Administrator
Thu 02 Apr 2015 04:53:12 PM UTC, comment #16: 

I don't really see anything that we can do here.  Finite precision floating point arithmetic is not exact.

John W. Eaton <jwe>
Project Administrator
Thu 02 Apr 2015 03:58:44 PM UTC, comment #15: 

My mistake.  This definitely shows how ingrained the tendency is to think of Octave as performing pure math calculations equivalent to pencil and paper.  When I wrote

1/10 * 1/10 - 1/100

I was thinking in my head that the operations were

(1/10) * (1/10) - (1/100)

the way you might do them on paper.

So, is there anything to do for this report or do we just close it?

Rik <rik5>
Project Administrator
Thu 02 Apr 2015 12:28:16 PM UTC, comment #14: 

Oops, I should have used verbatim...



is evaluated as


or, equivalently,


That's not the same as


Try it with format bit.

John W. Eaton <jwe>
Project Administrator
Thu 02 Apr 2015 12:25:00 PM UTC, comment #13: 

@rik:  1/10*1/10 is evaluated as ((1/10)*1)/10.  That's not the same as (1/10)*(1/10).  Try it with format bit.

Also, any intermediate expressions in Octave are stored in octave_value objects, even if they aren't assigned to symbols.  They won't be using extended precision registers.

John W. Eaton <jwe>
Project Administrator
Wed 01 Apr 2015 10:15:23 PM UTC, comment #12: 

@jwe: Maybe the reason we see it with the Qt libraries linked in is that there is more register pressure on the compiler?

Here is another test case

octave:1> x = 1/10;
octave:2> x*x - 1/100
ans =    1.7347e-18
octave:3> 1/10 * 1/10 - 1/100
ans = 0

If I understand this correctly, storing 1/10 in a double loses some precision so that 1/10 * 1/10 is no longer equal to 1/100.  On the other hand, executing the calculation directly on the command line doesn't involve a register truncation as the result is just calculated serially in an extended floating point register.  Is that right?

Rik <rik5>
Project Administrator
Wed 01 Apr 2015 10:03:32 PM UTC, comment #11: 

@Avinoam: At least the GUI and CLI are consistent :)

This is because we are not really using the CLI anymore.  The launcher (octave.vbs) was changed to always run the octave-gui.exe file (the one linked with Qt libraries).  It just launches it with the '--no-gui' option if you want a command line, but with Qt available.

Rik <rik5>
Project Administrator
Wed 01 Apr 2015 09:18:24 PM UTC, comment #10: 

Just a comment: now the results of GUI and CLI are the same
(both are wrong...), since CLI now is
C:\Octave\Octave-4.0.0-rc2\octave.vbs --no-gui
and GUI is
C:\Octave\Octave-4.0.0-rc2\octave.vbs --force-gui
for both of them:

>>  10^(-2) - 1./10^2
ans =   1.7347e-018

Avinoam Kalma <avinoam>
Project Member
Wed 01 Apr 2015 09:18:05 PM UTC, comment #9: 

I'm attaching a short program that you can experiment with.  I see different results for (1/10)*(1/10) vs 1/100 regardless of the compiler options I tried.  So I don't think it's likely that you should expect to get the results of these two expressions to always agree.

(file #33509)

John W. Eaton <jwe>
Project Administrator
Wed 01 Apr 2015 08:38:26 PM UTC, comment #8: 

So is the answer just to accept that machine calculations are only good to within eps of the true result?  Certainly for long matrix calculations I accept this.  It's just a little disheartening when you have a simple expression that doesn't yield the expected simple result.

Reading the man page for gcc, using -ffloat-store sounds like it could have negative repercussions on performance if one can't park intermediate calculations in the dedicated floating point registers.  Maybe it's miniscule these days with SSE instructions.  That, at least, could be verified.

Rik <rik5>
Project Administrator
Wed 01 Apr 2015 07:35:50 PM UTC, comment #7: 

This is almost certainly a float-store problem, but I'm not sure why there is a difference with the cli and gui versions.  Is it possible to set the storage mode dynamically?

I don't fully understand what's happening, but using gdb I found that in both cases the 10^(-2) operation is ultimately calling powi from the mingw math library.  This function computes x = 1/10 and then x *= x to generate the result.

Here is a simplified function that demonstrates the same problem:

#include <octave/oct.h>
DEFUN (foo, args, , "")
  double x = args(0).scalar_value ();
  x = 1 / x;
  x *= x;
  return octave_value (x);

Using "format bit", you can see the difference:

format bit
x = 1/10; [foo(10); x*x]
ans =


Declaring X volatile in Ffoo makes the results be the same, as does compiling foo.cc with -ffloat-store.

I agree that it's bad to have the CLI and GUI versions produce different results and we should probably try to figure out why that's happening.  But I also see that the following expressions produce different results on my Debian system:

x = 1/10; [x*x; 1/100]
ans =


I don't see what can be done about that, though I expect the result will be surprising to some users.  In this case, I don't think the intermediate result (x = 1/10) is stored in an extended precision register because it is stored in a scalar octave_value object.

John W. Eaton <jwe>
Project Administrator
Fri 06 Feb 2015 05:42:40 PM UTC, comment #6: 

Upgraded to Blocker here and on the Release 4.0 Bug Fix list (http://wiki.octave.org/Bug_Fix_List_-_4.0_Release).

Rik <rik5>
Project Administrator
Fri 06 Feb 2015 05:28:06 PM UTC, comment #5: 

There may be more than one problem in this sequence of
reports. But, Rik is right: it needs to be fixed. ALL
implementations should get the sane (correct) answers.
So, blocking for 4.0 seems right.

Michael Godfrey <godfrey>
Project Member
Fri 06 Feb 2015 04:59:07 PM UTC, comment #4: 

This isn't good at all.  It's like running 2+2 and getting answers of 4 or 5 depending on the operating system.  What I particularly don't like is that we don't understand the mechanism, and therefore don't understand what percentage of Octave's calculations are affected.  Should this be raised in priority and made a blocker for the 4.0 release?

Rik <rik5>
Project Administrator
Thu 05 Feb 2015 05:09:42 AM UTC, comment #3: 

Another example from the mailing list that might be related, showing floating point differences when Octave is run with and without Qt libs:

format long
N=1e4; s=0; for i=1:N s+=(mean(ones(i,1)*.9)-.9); endfor; s

In console mode with --no-gui-libs, the answer is  -4.48086012738713e-013, in the GUI the answer is  -3.15685588780923e-010.

For comparison, on Linux only the larger of these two is returned in Octave with or without Qt.


Mike Miller <mtmiller>
Project Administrator
Tue 06 Jan 2015 05:44:41 PM UTC, comment #2: 

I can confirm this with a recent build of octave-4.1.0+ with MXE on a Windows XP virtual machine.  The --enable-float-truncate option was also definitely on for me.

Rik <rik5>
Project Administrator
Sat 06 Dec 2014 03:57:09 PM UTC, comment #1: 

This suggests that potentially a different power routine (^ operator) is getting linked to when the Qt libs are present.  That or somehow the '--enable-float-truncate' configure option is not being used for the GUI build.  Or maybe there is yet another place in the code where we need to truncate intermediate floating point results on Windows systems.

This isn't going to be easy to debug unfortunately.

Rik <rik5>
Project Administrator
Tue 02 Dec 2014 07:28:54 PM UTC, original submission:  

In GNU Octave Version 3.8.2, using windows unofficial version

in octave-cli version:

octave:4> 10^(-2) - 1./10^2
ans = 0

while in octave-gui version

>> 10^(-2) - 1./10^2
ans =   1.7347e-018

This affects some routines, for example chop (bug 43734).

This numerical error does not appear in my linux version (Ubuntu).


Avinoam Kalma <avinoam>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #33509:  foo.c added by jwe (909B - text/x-csrc)


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by avinoam (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-02 rik5 StatusConfirmed Wont Fix
        Open/ClosedOpen Closed
    2015-04-01 jwe Attached File- Added foo.c, #33509
    2015-02-06 rik5 Severity3 - Normal 5 - Blocker
    2015-01-06 rik5 StatusNone Confirmed
        SummaryNumerical error in mxe-octave GUI version different results from power operator in mxe-octave GUI/CLI
    2015-01-06 rik5 Dependencies- bugs #43891 is dependent
    2014-12-06 rik5 Dependencies- bugs #43734 is dependent

    Back to the top

    Powered by Savane 3.9