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.
|
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.
|
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?
|
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.
|
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.
|
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?
|
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.
|
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:
|
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)
|
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.
|
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.
|
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).
|
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.
|
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?
|
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
|
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.
|
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.
|
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
|