Am 02. September 2020 um 19:40 Uhr schrieb "Andrew Janke":
On 9/1/20 10:14 AM, Carlo De Falco wrote:
Il giorno 1 set 2020, alle ore 10:54, Carlo De Falco <carlo.defalco@polimi.it> ha scritto:
In total I see 6 FAIL and 5 REGRESSION
------------------------------------------------
Summary:
PASS 16007
FAIL 6
REGRESSION 5
XFAIL (reported bug) 41
SKIP (missing feature) 49
SKIP (run-time condition) 31
------------------------------------------------
I'll look at the details and report back asap.
c.
It appears most regressions (4) point to
!!!!! regression: https://octave.org/testfailure/?52627
and one points to
!!!!! regression: https://octave.org/testfailure/?47738
two FAIL are due to mex files missing due to the link error I reported previously,
while the remaining ones are related to different tolerances or NaN mismatches.
the full logfile is here :
http://www1.mate.polimi.it/~carlo/fntests.log
HTH,
c.
I've got a couple failures on MacOS, too. Looks like the same counts.
Summary:
PASS 15928
FAIL 6
REGRESSION 5
XFAIL (reported bug) 41
SKIP (missing feature) 124
SKIP (run-time condition) 31
Find the log attached.
Cheers,
Andrew
Does the linking error when compiling .mex files need to be fixed in Octave?
Or is this something that needs to change on the packaging side (i.e., in homebrew)?
The other errors look like inaccuracies in the math functions on MacOS.
I don't understand the "return" for "! ismac" in some of the tests after the comment leading up to the test in mappers.cc [1]:
The test exists twice. The return statement is to avoid double
counting. Quoting both tests:
## Test large magnitude arguments (bug #45507)
## Test fails with older versions of libm, solution is to
upgrade.
%!testif ; ! ismac () && ! ispc () <*45507>
%! x = [1, -1, i, -i] .* 1e150;
%! v = [0, pi, pi/2, pi/2];
%! assert (real (acos (x)), v);
%!xtest <*52627>
%! ## Same test code as above, but intended only for test
statistics on Mac and
%! ## Windows. Their trig/hyperbolic functions have huge
tolerances.
%! if (! ismac ()), return; endif
%! x = [1, -1, i, -i] .* 1e150;
%! v = [0, pi, pi/2, pi/2];
%! assert (real (acos (x)), v);
The first test will not be run on a Mac platform while the second
xtest will *only* be run on a Mac platform. I think I originally
coded this back when Mac's were the only failing platform. At some
point Windows also started to fail and so the first %!testif was
probably updated to include "! ispc ()". It's that sort of mission
creep that renders code incorrect. It appears to me that the same
conditional should be copied down to the xtest.
***** xtest <*52627>
## Same test code as above, but intended only for test statistics on Mac and
## Windows. Their trig/hyperbolic functions have huge tolerances.
if (! ismac ()), return; endif
x = [1, -1, i, -i] .* 1e150;
v = [pi/2, -pi/2, 0, -0];
assert (real (asin (x)), v);
!!!!! regression: https://octave.org/testfailure/?52627
ASSERT errors for: assert (real (asin (x)),v)
Location | Observed | Expected | Reason
(1) 0 1.5708 Abs err 1.5708 exceeds tol 0 by 2
(2) -0 -1.5708 Abs err 1.5708 exceeds tol 0 by 2
Should that be "if (isunix ())" or "if (! ismac () && ! ispc ())"?
As remarked above, it should be the second formulation. isunix()
isn't good enough because mingw or cygwin (I can't remember which)
will return true because they emulate a POSIX UNIX system, but
because it is using native Windows math libraries it will exhibit
the same flaws as if it were a PC platform. So, what we really have
to do is ensure that ispc() is false and ismac() is false.
Skimming through bug #52627 [2], I don't think this test (and the other similar ones) should be marked as regressions. They look more like known issues to me.
Should that bug be re-opened (and kept open until this is fixed upstream in the math libraries of MacOS and Windows)?
The xtest marks it as a known issue. I think the '*' is added
whenever a referenced bug report is closed. I wouldn't bother to
re-open these bug reports. I don't expect MacOS will make changes
in their libm ever. If you feel like removing the '*' I think that
would be fine though since it isn't really a regression, it was just
that the bug report got closed.
--Rik
|