Re: Test Failures on Mac OS

[Rik]

On 11/14/2017 09:00 AM, address@hidden wrote:

Subject:

Re: Behold! Buildbot's waterfall display has never been so green

From:

Mike Miller <address@hidden>

Date:

11/13/2017 02:57 PM

To:

address@hidden

List-Post:

<mailto:address@hidden>

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hh7shldocxdt7wqe"

Message:

2

On Sat, Nov 11, 2017 at 10:32:02 -0500, John W. Eaton wrote:

Also, can someone please give the OS X build some love and make it green as
well?

We've looked at some of these before, here is a short summary of the
test failures on macOS.

* LLVM C++ library defect in number parsing. This results in Octave
  unable to parse a string like "4i" into a complex number with
  functions like scanf and str2double.

  This bug occurs on any operating system when Octave is built with the
  LLVM clang compiler and the LLVM C++ standard library.

  The LLVM devs are aware of this and seem to be waiting for some C++
  standards work to clarify this case before making any changes.

  LLVM bug https://bugs.llvm.org/show_bug.cgi?id=17782

  Octave bug https://savannah.gnu.org/bugs/?47413 (closed won't fix)

  This causes test failures in dlmread.cc, str2double.cc, importdata.m,
  and io.tst.

* Less accurate inverse trigonometric and hyperbolic functions in the
  macOS system math library?

Some of it may be less accurate, but some of it is philosophical.  Apple chose to re-write their libraries to get away from any "Open Source" dependence, but they also made some different decisions on gray areas of the C and C++ specification from other libraries.  See this conversation from 2010 (http://octave.1599824.n4.nabble.com/Re-Apple-atan2f-td3037234.html).  I don't want to be bothered re-hashing that.  The easiest thing to do is to widen the tolerances which allows the tests to pass on both Windows and Mac systems.  Annoying that Linux users are being punished by the Windows and Mac operating systems into changing our tests.

  I'm not sure if anyone has looked into these yet.

  This broad description is meant to capture test failures in mappers.cc
  and asech.m (functions acos, acosh, asin, asinh, and asech).

  Most or all of these may be due to system library accuracy problems,
  which I think we also may see on Windows in some of these cases.

* The default system temporary directory seems to be symlinked or
  containerized somehow on macOS. The system defines the default
  temporary directory to be "/var/tmp" (normally "/tmp" on GNU/Linux
  systems). In Octave's test for fileattrib, it tries to ensure that the
  "Name" property is the same, but "/private/var/tmp" is returned.

  This test in fileattrib.m could be dropped or modified to avoid making
  the assumption that the default temporary directory is not a symlink.

  Maybe a simple canonicalize_file_name will fix this.

We should do this anyways, and I think the approach of canonicalize_file_name is probably a good one.

* There is a test in camzoom.m that tries to assert a specific viewing
  angle, which is failing with a slight tolerance error of 2*eps. I
  assume this would be safe to fix with a tolerance argument.

Calculating values to 1 eps is important for values that will be used in further calculations, but there is no way the human eye is going to detect a 2*eps difference in angle.  I think we can widen the tolerance on this test without repercussions.

* The last two sorting tests in complex.tst are failing when the single
  precision and double precision results are compared to each other. I
  don't know if anyone has looked into this or where the underlying
  error happens.

No idea about this one, I haven't looked at it.

--Rik