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

 
 

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

Submitted by:  Avinoam Kalma <avinoam>
Submitted on:  Tue 02 Dec 2014 07:28:54 PM UTC  
 
Category: Octave FunctionSeverity: 5 - Blocker
Priority: 5 - NormalItem Group: Inaccurate Result
Status: Wont FixAssigned to: None
Originator Name: AvinoamOpen/Closed: Closed
Release: 3.8.2Operating System: Microsoft Windows

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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

I was thinking in my head that the operations were

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...

@rik:

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/101/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

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:

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:

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

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:

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:

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.

http://octave.1599824.n4.nabble.com/different-results-in-GUI-and-command-line-tt4668436.html

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
(mxe-octave)

in octave-cli version:

while in octave-gui version

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

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

Avinoam

Avinoam Kalma <avinoam>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

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

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 02 Apr 2015 05:39:01 PM UTCrik5StatusConfirmed=>Wont Fix
      Open/ClosedOpen=>Closed
    Wed 01 Apr 2015 09:18:05 PM UTCjweAttached File-=>Added foo.c, #33509
    Fri 06 Feb 2015 05:42:40 PM UTCrik5Severity3 - Normal=>5 - Blocker
    Tue 06 Jan 2015 05:27:34 PM UTCrik5StatusNone=>Confirmed
      SummaryNumerical error in mxe-octave GUI version=>different results from power operator in mxe-octave GUI/CLI
    Tue 06 Jan 2015 02:20:42 AM UTCrik5Dependencies-=>bugs #43891 is dependent
    Sat 06 Dec 2014 03:47:11 PM UTCrik5Dependencies-=>bugs #43734 is dependent

    Back to the top


    Powered by Savane 3.1-cleanup1