Thu 15 Sep 2016 09:05:28 PM UTC, comment #9:
I don't think it matters too much. As long as they are linked so that they get closed at the same time.
|
Thu 15 Sep 2016 06:45:55 PM UTC, comment #8:
I suppose the acos FAILs mentioned in bug #48312 are the same.
Should this bug be listed there as dependency or the other way round?
|
Thu 15 Sep 2016 06:16:49 PM UTC, comment #7:
I marked the failing acosh BIST tests with this bug number (http://hg.savannah.gnu.org/hgweb/octave/rev/4d9c371d2cca). I also added a FIXME note saying that we are waiting for upstream to improve their library. I've changed the bug title and marked it as postponed.
I'm also re-building with MXE to test that the failures are now reported correctly as known failures, but that will take a few hours.
|
Thu 15 Sep 2016 05:03:45 PM UTC, comment #6:
I like your third option. I don't feel we should have to dumb down Octave's tests for a single failing library on a single platform. And I also don't like disabling a std:: library when there is a good possibility that it will be fixed upstream at some point.
|
Thu 15 Sep 2016 04:35:11 PM UTC, comment #5:
A third option is to add this bug number to the tests, which reports them as XFAIL and this bug can remain open or be closed. Someone might want to report this to the MinGW project, if it's something that can be handled there.
I already marked some tests with bug #45507, which is about a similar failure on systems with an older gcc and/or libm system library. We are continuing to use the std::acosh function on these older GNU systems even though the results fail some tolerance tests.
|
Thu 15 Sep 2016 04:06:22 PM UTC, comment #4:
The results I am seeing in fntests.log are
When using doubles, it is failing by 31 eps. When using floats it is failing by60 eps ("single"). Those are pretty big tolerances. Do we want to add those in or disable the library on Windows?
|
Thu 15 Sep 2016 12:26:11 AM UTC, comment #3:
I checked and _have_feature_ reports that I am using the std library version. So, that kind of sucks. The std library is less accurate than direct computation on Windows machines.
Do we want to change the library or the test? We could certainly add to the #ifdef.
The second option is to increase the tolerance of the test.
|
Wed 14 Sep 2016 10:23:48 PM UTC, comment #2:
The mxe-octave binary distribution should include config.log in the share/octave/4.2.0-rc1/etc directory, that should tell you whether std::acosh was found by configure. Also running
in the interpreter should tell the same thing.
|
Wed 14 Sep 2016 10:17:54 PM UTC, comment #1:
I guess the question is why acosh (10i) is different from acosh (-10i). On Linux they are the same. But on Windows, I get
In liboctave/libnumeric/lo-specfun.cc the acosh function is defined as
If I execute the #else path in Octave I get the right answer.
I don't know how MXE Octave was build, but this suggests that the std library might be at fault on Windows.
|
Wed 14 Sep 2016 07:50:58 PM UTC, original submission:
Using a tolerance of 7e-15 instead of zero will solve this.
|