Sun 03 Sep 2017 02:03:26 AM UTC, comment #15:
Marking as fixed and closing report.
|
Sun 27 Aug 2017 05:57:48 PM UTC, comment #14:
Avinoam, thank you for testing. I pushed the patch here: http://hg.savannah.gnu.org/hgweb/octave/rev/5570b0f12112
|
Sun 27 Aug 2017 05:45:45 PM UTC, comment #13:
The attached patch fixes the failure.
|
Sat 26 Aug 2017 08:13:11 AM UTC, comment #12:
The failing BIST is due to a bug in std::pow that we use from mingw-w64 [1].
The code in graphics.cc uses that function to calculate the axis limits for logarithmic axes. The attached patch "fixes" the BIST by performing the same operation in the test (powers of 10). So both are affected by the upstream bug.
Since the aim of this test is to check whether the auto axis limits are calculated as expected, I think that is the right thing to do here.
The change can be reverted, once the bug should be fixed in mingw-w64.
[1]: https://sourceforge.net/p/mingw-w64/bugs/466/
(file #41665)
|
Sun 09 Apr 2017 04:52:36 AM UTC, comment #11:
In the discussion of bug #49470 I commented that in 64 bit version,
Note also that
while in 32 bit both are zero.
There is a comment of Dmitri A. Sergatskov in that discussion:
"The difference could be due to sse (default on 64-bit)
vs fp87 (on 32-bit) floating point path"
I also noticed with __octave_config_info that MXE octave is compiled in 32 bit version with
FFLAGS = -g -O2 -mieee-fp
while in 64 bit, with
FFLAGS = -g -O2
is this related to this bug?
|
Sun 26 Feb 2017 04:15:45 PM UTC, comment #10:
I can confirm this test still fails on Octave 4.2.1 64bit on Windows 10.
Please, let me know if any further tests can help narrowing down the issue.
|
Thu 17 Nov 2016 04:07:50 AM UTC, comment #9:
Can someone please run the test suite with the 4.2.0 official releases to confirm that this bug is still relevant?
|
Wed 02 Nov 2016 09:52:20 PM UTC, comment #8:
32 bit version has been fixed, but 4.2.0-rc3 64 bit version from alpha.gnu.org still suffers from this bug.
Using octave_config_info I noticed that 64 bit version was not compiled with fp-ieee. Is it related to this bug?
|
Thu 07 Jul 2016 09:56:36 PM UTC, comment #7:
In the 32-bit executable environment on Windows, setting the right value of the control word, or calling a Java function, makes these same tests pass, see bug #48418.
So we have one solution that works there, Avinoam will be testing a patch to see if setting the control word at startup makes all tests pass.
The same tests are failing with the same exact kinds of tolerance errors for you in the 64-bit executable environment, but this setting does not change anything.
|
Thu 07 Jul 2016 09:49:30 PM UTC, comment #6:
Just FTR I tried "test axis"before and after calling a Java function:
so am I right to surmise that the FPU control word seems to make little difference?
|
Thu 07 Jul 2016 09:44:22 PM UTC, comment #5:
Sure:
I didn't have OF packages loaded.
Note that ov-java.cc is included in the test suite when running __run_test_suite__ ; I suppose ov-java-cc.tst can be (temporarily moved out of share/.../etc/tests
|
Thu 07 Jul 2016 09:06:12 PM UTC, comment #4:
Attached this time.
(file #37762)
|
Thu 07 Jul 2016 09:05:42 PM UTC, comment #3:
Philip, can you build and run the attached .oct function in your 64-bit build of Octave, like the following:
What value is shown on your system? Does loading or running Java functions change the value? Do you happen to have the io package installed and configured to load on startup (thus always loading Java before any tests you run)?
|
Wed 06 Jul 2016 04:02:03 AM UTC, comment #2:
Test axis also fails on Windows 32 bit versions, for the same resons. We do not see this when running __run_test_suite__ because of bug #48418
|
Fri 01 Jul 2016 04:37:53 PM UTC, comment #1:
I think it might be worth looking into where these differences are coming from, since every other system passes, while on Windows you see a difference of 3*eps(1e-5).
|
Fri 01 Jul 2016 01:31:22 PM UTC, original submission:
This FAIL has been there for along time, yet axis has always worked fine.
Is the fix simply a matter of specifying eps as tolerance rather than 0?
|