Continuing the discussion from My Project at GNU Octave:
I’m making a new topic out of this comment (effectively a link to the Julia issue #18102) because I think it hides a lot.
Openlibm is maintained by the Julia project but Julia itself seems to be trying to move away from openlibm. The gist of it, if I understood correctly, is that many years ago openlibm made sense because there were many libm that behaved weird but nowadays most libm implementations are good enough that there’s no point on maintaining openlibm anymore.
If even the Julia project is trying to stop using it, should we bother on trying to make Octave use it? After today’s meeting I got the feeling that with recent glibc it’s tricky to even reproduce the issues that openlibm is meant to solve.
See also openlibm issue #193 on the status of that project.
I think this is an important topic and it would be good to answer the question not just for libm, but also libc. As Octave maintainers, how much time do we want to spend expanding Octave functionality versus getting it to work on all the different combinations of hardware and software that exist out there? At what point do we say, “This part is our problem (say we are using an API incorrectly) and we will fix it versus this part of the problem is yours (the programmer) to have a system with a reasonable combination of hardware and software libraries”.
I know we’ve had issues with libc and thus introduced wrappers and gnulib for certain functions. Some of the trigonometry functions in MinGW libm are not very accurate. We get different results from different BLAS libraries (reference BLAS vs. OpenBLAS). ARPACK has also been a library with a lot of issues for Octave. My personal feeling is that we have made a lot of accommodations in the Octave code base and this complicates things. Maybe there is no other choice, but a discussion should be had.
We can try having the discussion on a Discourse thread, but it might need to take place in real time at the next Octave Developer’s meeting.
Fwiw: Openlibm gives worse results than the default libraries on Linux for very large input to inverse trigonometric functions.
I assume you tried a small C++ program to test it. Could you post the exact code so we
would have some benchmark to test other possible candidates?
A very crude test function that I repeatedly compiled with different values:
test-acosh.c (357 Bytes)
That could definitely be implemented more comfortably. But it was good enough for me…
Edit: I used the results from Wolfram Alpha as a reference to decide which implementation was “better”. E.g.: acosh(1e150i) - Wolfram|Alpha (wolframalpha.com)
Edit 2: See also bug #49091
Edit 3: I tested extreme values (
cacosh. IIRC, not all of them were bad. But I don’t recall which were the worst ones. Sorry.
I just tried boost libs for acos/acosh/asin/asinh and it agrees with Alpha to 17th digit.
(At least on Linux)
With boost you do not need any “library” one just includes their “.hpp” files.
t_boost.c++ (548 Bytes)
p.s. For some reason I cannot download my own file back. So here is the text:
using namespace std;
cout <<"x = " << x <<endl
<< " acosh(x) = " << boost::math::acosh(x) << endl
<< " acos(x) = " << boost::math::acos(x) << endl
<< " asinh(x) = " << boost::math::asinh(x) << endl
<< " asin(x) = " << boost::math::asin(x) << endl ;
Nice. I tested for large positive and negative, pure imaginary and pure real input and with both components being the possible combinations of large positive and negative 1e150. Do they all return good results with the boost library?
I don’t know whether we would like to introduce boost as a (mandatory?) dependency of Octave. But ISTR that @jwe mentioned it at some point in the past…
Afaict, these functions are used in C++ code in Octave. So at least theoretically, it could be rather straight-forward to replace the standard functions with the boost functions (or add a configure switch for it).
Boost is not a bit one library. It is a set of small ones. In some cases it is just header
files (no binary library at all).
For this particular case we can just copy .hpp files into octave tree.
Octave does not bundle dependencies, not even for header only “libraries”.
What about gnulib and Free*.otf fonts?
2 posts were merged into an existing topic: Is gnulib still necessary for Octave?