Openlibm: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
mNo edit summary |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 42: | Line 42: | ||
==Report on OpenLibm== | ==Report on OpenLibm== | ||
The very idea of Linking openLibm with GNU octave was to bring consistency of maths library functions across different compilers and systems, thus achieving a good Libm implementation and countering the above bugs. The project openLibm was part of GSoC 2022, where some of the above bugs' c++ snippets were tested against openLibm to achieve the desired result. Unfortunately, the openLibm failed to provide the expected results.OpenLibm has its own limitation such as not being fully built and well-maintained Libm and hence the result. | The very idea of Linking openLibm with GNU octave was to bring consistency of maths library functions across different compilers and systems, thus achieving a good Libm implementation and countering the above bugs. The project openLibm was part of GSoC 2022, where some of the above bugs' c++ snippets were tested against openLibm to achieve the desired result. Unfortunately, the openLibm failed to provide the expected results. OpenLibm has its own limitation such as not being fully built and well-maintained Libm and hence the result. | ||
==Tests of Bugs against OpenLibm== | ==Tests of Bugs against OpenLibm== | ||
The three Bugs (bug {{bug|55538}} ,bug {{bug|62212}}, bug {{bug|62332}} ) were tested against openLibm on systems Ubuntu 20.04, Ubuntu 22.04 and macOS through the | The three Bugs (bug {{bug|55538}} ,bug {{bug|62212}}, bug {{bug|62332}} ) were tested against openLibm on systems Ubuntu 20.04, Ubuntu 22.04 and macOS through the GitHub action (code can be found at [https://github.com/shreyaswikriti/BugTesting BugTesting Repository] ). | ||
===Testing of bug {{bug|55538}}=== | ===Testing of bug {{bug|55538}}=== | ||
*;CODE SOURCE: [ | *;CODE SOURCE: | ||
<syntaxhighlight lang="C++"> | |||
#include <complex> | |||
#include <limits> | |||
#include <iostream> | |||
int | |||
main (int argc, char *argv[]) | |||
{ | |||
double x = 10.0; | |||
std::complex<double> y (std::numeric_limits<double>::infinity (), 1.0); | |||
std::complex<double> z1 = std::pow (x, y); | |||
std::complex<double> z2 = std::pow (std::complex<double> (x), y); | |||
std::complex<double> z3 = std::exp (y * std::log (x)); | |||
std::complex<double> z4 = std::exp (y * std::log (std::complex<double> (x))); | |||
std::cout << z1 << ", " | |||
<< z2 << ", " | |||
<< z3 << ", " | |||
<< z4 << std::endl; | |||
} | |||
</syntaxhighlight> | |||
*;Output Expected : | *;Output Expected : | ||
| Line 82: | Line 105: | ||
(inf,nan), (inf,nan), (-inf,inf), (inf,nan) | (inf,nan), (inf,nan), (-inf,inf), (inf,nan) | ||
*;''Observations :'' | |||
The expected output is not achieved by compiling the program with Openlibm. Also, the output is not consistent with systems and different compilers. Hence, the openlibm as a proposed solution to solve this bug has failed. | |||
=== Testing of bug {{bug|62212}} === | |||
*;CODE SOURCE: | |||
= | <syntaxhighlight lang="C++"> | ||
#include <cmath> | |||
#include <iostream> | |||
int main (void) | |||
{ | |||
double db_large_integer = std::pow (2., 64.); | |||
std::cout << "db_large_integer: " << db_large_integer << std::endl; | |||
uint64_t ui64_large_integer = db_large_integer; | |||
std::cout << "ui64_large_integer: " << ui64_large_integer << std::endl; | |||
return 0; | |||
} | |||
</syntaxhighlight> | |||
*;Output Expected : | *;Output Expected : | ||
| Line 118: | Line 159: | ||
db_large_integer: 1.84467e+19 | db_large_integer: 1.84467e+19 | ||
ui64_large_integer: 0 | ui64_large_integer: 0 | ||
*;''Observations:'' | |||
On Ubuntu, openlibm failed to link when compiling. The expected output is not achieved by compiling the program with Openlibm. Even compiling with OpenLibm is not giving any difference to the output. Hence, the openlibm as a proposed solution to solve this bug has failed. | |||
=== Testing of bug {{bug|62332}} === | |||
*;CODE SOURCE: | |||
= | <syntaxhighlight lang="C++"> | ||
*; | #include <iostream> | ||
#include <cmath> | |||
#include <complex> | |||
#define cosd(x) (cos((x) * M_PI / 180)) | |||
int main() | |||
{ | |||
for(int i=1;i<=20;i++) | |||
{ std::complex<double> x( cosd(45) , std::pow(10, -3*i) ); | |||
std::cout << real(x)<<"+"<<imag(x)<<"i"<<"-->"<<real(acos(x))<<"+"<<imag(acos(x))<<"i"<< std::endl ;} | |||
} | |||
</syntaxhighlight> | |||
*;Output Expected : | *;Output Expected : | ||
| Line 210: | Line 267: | ||
0.707107+1e-57i-->0.785398+-0i | 0.707107+1e-57i-->0.785398+-0i | ||
0.707107+1e-60i-->0.785398+-0i | 0.707107+1e-60i-->0.785398+-0i | ||
*;''Observations: '' | |||
Compiling with the Openlibm is providing the output that we want to avoid. The expected output is not achieved by compiling the program with Openlibm. Hence, the openlibm as a proposed solution to solve this bug has failed. | |||
==Conclusion== | |||
The proposed solution is to use Openlibm as a replacement of libm to deal with the inconsistency in the maths library caused when Octave is compiled with libc++ (default on macOS) and sometimes with libstdc++ has failed and the bug issues and can not be solved with openlibm. Hence, there is a need to find an alternate solution to address this issue. | |||
[[Category:Development]] | [[Category:Development]] | ||
Latest revision as of 15:13, 28 July 2022
A list of open issues that are related to the differences in math libraries among different systems:
| Bug number | Description |
|---|---|
| bug #57071 | Fix math.h and function names that block 64-bit double |
| bug #55538 | logspace BIST tests fail when Octave built with LLVM libc++ |
| bug #62212 | Wrong unsigned integer overflow with clang |
| bug #49984 | fabs missing from libm implementation. |
| bug #61812 | Math constants (e.g. M_PI) are not part of C/C++ standard |
| bug #49091 | MinGW std::acosh less accurate than Linux versions |
| bug #60784 | Inconsistent behavior for boolean matrix types with matrix functions |
| bug #45481 | rem and fmod may give very wrong results for large arguments |
| bug #61715 | Inconsistent NaN results for exponential function (0+0i)^0 with libc++ and libstdc++ |
| bug #45746 | Incorrect results of trigonometric functions gsl_sf_sin and gsl_sf_cos |
| bug #62332 | [MinGW] acos(z), asin(z) and atan(z) , ( z = x + yi ) return wrong result for imaginary part lower than 1e-12 |
Report on OpenLibm[edit]
The very idea of Linking openLibm with GNU octave was to bring consistency of maths library functions across different compilers and systems, thus achieving a good Libm implementation and countering the above bugs. The project openLibm was part of GSoC 2022, where some of the above bugs' c++ snippets were tested against openLibm to achieve the desired result. Unfortunately, the openLibm failed to provide the expected results. OpenLibm has its own limitation such as not being fully built and well-maintained Libm and hence the result.
Tests of Bugs against OpenLibm[edit]
The three Bugs (bug #55538 ,bug #62212, bug #62332 ) were tested against openLibm on systems Ubuntu 20.04, Ubuntu 22.04 and macOS through the GitHub action (code can be found at BugTesting Repository ).
Testing of bug #55538[edit]
- CODE SOURCE
#include <complex>
#include <limits>
#include <iostream>
int
main (int argc, char *argv[])
{
double x = 10.0;
std::complex<double> y (std::numeric_limits<double>::infinity (), 1.0);
std::complex<double> z1 = std::pow (x, y);
std::complex<double> z2 = std::pow (std::complex<double> (x), y);
std::complex<double> z3 = std::exp (y * std::log (x));
std::complex<double> z4 = std::exp (y * std::log (std::complex<double> (x)));
std::cout << z1 << ", "
<< z2 << ", "
<< z3 << ", "
<< z4 << std::endl;
}
- Output Expected
((-inf,inf), (inf,-nan), (-inf,inf), (inf,-nan) )
- Commands
On Ubuntu g++ -std=c++17 bug#55538.cc -o bug#55538 -lopenlibm //compiling ldd bug#55538 //to show shared libraries ./bug#55538 //output of program on macOS clang++ -stdlib=libc++ bug#55538.cc -o bug#55538 -lopenlibm otool -L bug#55538 // to show shared libraries ./bug#55538 //output of program
- Ubuntu 22.04 (with GCC compiler and Libstdc++)
linux-vdso.so.1 (0x00007ffe1cd2b000) libopenlibm.so.3 => /lib/x86_64-linux-gnu/libopenlibm.so.3 (0x00007fa21846e000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa218242000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa218222000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6(0x00007fa217ffa000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6(0x00007fa217f13000) /lib64/ld-linux-x86-64.so.2 (0x00007fa2184b0000) (-inf,inf), (-nan,-nan), (-inf,inf), (inf,-nan)
- macOS (with llvm/Clang and Libc++)
/usr/local/opt/openlibm/lib/libopenlibm.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1200.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0) (inf,nan), (inf,nan), (-inf,inf), (inf,nan)
- Observations :
The expected output is not achieved by compiling the program with Openlibm. Also, the output is not consistent with systems and different compilers. Hence, the openlibm as a proposed solution to solve this bug has failed.
Testing of bug #62212[edit]
- CODE SOURCE
#include <cmath>
#include <iostream>
int main (void)
{
double db_large_integer = std::pow (2., 64.);
std::cout << "db_large_integer: " << db_large_integer << std::endl;
uint64_t ui64_large_integer = db_large_integer;
std::cout << "ui64_large_integer: " << ui64_large_integer << std::endl;
return 0;
}
- Output Expected
db_large_integer: 1.84467e+19 ui64_large_integer: 18446744073709551615
- Commands
On Ubuntu g++ -std=c++2a bug#62212.cc -o bug#62212 -lopenlibm ldd bug#62212 ./bug#62212 on macOS clang++ -stdlib=libc++ bug#62212.cc -o bug#62212 -lopenlibm otool -L bug#62212 ./bug#62212
- Ubuntu 22.04 (with GCC compiler and Libstdc++)
linux-vdso.so.1 (0x00007ffed5d98000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd1778b4000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd17768c000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd1775a5000) /lib64/ld-linux-x86-64.so.2 (0x00007fd177af2000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd177585000) db_large_integer: 1.84467e+19 ui64_large_integer: 0
- macOS (with llvm/Clang and Libc++)
/usr/local/opt/openlibm/lib/libopenlibm.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1200.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0) db_large_integer: 1.84467e+19 ui64_large_integer: 0
- Observations:
On Ubuntu, openlibm failed to link when compiling. The expected output is not achieved by compiling the program with Openlibm. Even compiling with OpenLibm is not giving any difference to the output. Hence, the openlibm as a proposed solution to solve this bug has failed.
Testing of bug #62332[edit]
- CODE SOURCE
#include <iostream>
#include <cmath>
#include <complex>
#define cosd(x) (cos((x) * M_PI / 180))
int main()
{
for(int i=1;i<=20;i++)
{ std::complex<double> x( cosd(45) , std::pow(10, -3*i) );
std::cout << real(x)<<"+"<<imag(x)<<"i"<<"-->"<<real(acos(x))<<"+"<<imag(acos(x))<<"i"<< std::endl ;}
}
- Output Expected
7.071068e-01+1.000000e-03i -> 7.853992e-01-1.414212e-03i 7.071068e-01+1.000000e-06i -> 7.853982e-01-1.414214e-06i 7.071068e-01+1.000000e-09i -> 7.853982e-01-1.414214e-09i 7.071068e-01+1.000000e-12i -> 7.853982e-01-1.414214e-12i 7.071068e-01+1.000000e-15i -> 7.853982e-01-1.414214e-15i 7.071068e-01+1.000000e-18i -> 7.853982e-01-1.414214e-18i 7.071068e-01+1.000000e-21i -> 7.853982e-01-1.414214e-21i 7.071068e-01+1.000000e-24i -> 7.853982e-01-1.414214e-24i 7.071068e-01+1.000000e-27i -> 7.853982e-01-1.414214e-27i 7.071068e-01+1.000000e-30i -> 7.853982e-01-1.414214e-30i 7.071068e-01+1.000000e-33i -> 7.853982e-01-1.414214e-33i 7.071068e-01+1.000000e-36i -> 7.853982e-01-1.414214e-36i 7.071068e-01+1.000000e-39i -> 7.853982e-01-1.414214e-39i 7.071068e-01+1.000000e-42i -> 7.853982e-01-1.414214e-42i 7.071068e-01+1.000000e-45i -> 7.853982e-01-1.414214e-45i 7.071068e-01+1.000000e-48i -> 7.853982e-01-1.414214e-48i 7.071068e-01+1.000000e-51i -> 7.853982e-01-1.414214e-51i 7.071068e-01+1.000000e-54i -> 7.853982e-01-1.414214e-54i 7.071068e-01+1.000000e-57i -> 7.853982e-01-1.414214e-57i 7.071068e-01+1.000000e-60i -> 7.853982e-01-1.414214e-60i
- Commands
On Ubuntu g++ -std=c++17 bug#62332.cc -o bug#62332 -lopenlibm ldd bug#62332 ./bug#62332 on macOS clang++ -stdlib=libc++ bug#62332.cc -lopenlibm -o bug#62332 otool -L bug#62332 ./bug#62332
- Ubuntu 22.04 (with GCC compiler and Libstdc++)
linux-vdso.so.1 (0x00007ffef447c000) libopenlibm.so.3 => /lib/x86_64-linux-gnu/libopenlibm.so.3 (0x00007efff64c3000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007efff6297000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007efff606f000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007efff5f88000) /lib64/ld-linux-x86-64.so.2 (0x00007efff6505000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007efff5f68000) 0.707107+0.001i-->0.785399+-0.00141421i 0.707107+1e-06i-->0.785398+-1.41421e-06i 0.707107+1e-09i-->0.785398+-1.41421e-09i 0.707107+1e-12i-->0.785398+-1.4142e-12i 0.707107+1e-15i-->0.785398+-1.44329e-15i 0.707107+1e-18i-->0.785398+0i 0.707107+1e-21i-->0.785398+0i 0.707107+1e-24i-->0.785398+0i 0.707107+1e-27i-->0.785398+0i 0.707107+1e-30i-->0.785398+0i 0.707107+1e-33i-->0.785398+0i 0.707107+1e-36i-->0.785398+0i 0.707107+1e-39i-->0.785398+0i 0.707107+1e-42i-->0.785398+0i 0.707107+1e-45i-->0.785398+0i 0.707107+1e-48i-->0.785398+0i 0.707107+1e-51i-->0.785398+0i 0.707107+1e-54i-->0.785398+0i 0.707107+1e-57i-->0.785398+0i 0.707107+1e-60i-->0.785398+0i
- macOS (with llvm/Clang and Libc++)
/usr/local/opt/openlibm/lib/libopenlibm.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1200.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0) 0.707107+0.001i-->0.785399+-0.00141421i 0.707107+1e-06i-->0.785398+-1.41421e-06i 0.707107+1e-09i-->0.785398+-1.41421e-09i 0.707107+1e-12i-->0.785398+-1.4142e-12i 0.707107+1e-15i-->0.785398+-1.33227e-15i 0.707107+1e-18i-->0.785398+-0i 0.707107+1e-21i-->0.785398+-0i 0.707107+1e-24i-->0.785398+-0i 0.707107+1e-27i-->0.785398+-0i 0.707107+1e-30i-->0.785398+-0i 0.707107+1e-33i-->0.785398+-0i 0.707107+1e-36i-->0.785398+-0i 0.707107+1e-39i-->0.785398+-0i 0.707107+1e-42i-->0.785398+-0i 0.707107+1e-45i-->0.785398+-0i 0.707107+1e-48i-->0.785398+-0i 0.707107+1e-51i-->0.785398+-0i 0.707107+1e-54i-->0.785398+-0i 0.707107+1e-57i-->0.785398+-0i 0.707107+1e-60i-->0.785398+-0i
- Observations:
Compiling with the Openlibm is providing the output that we want to avoid. The expected output is not achieved by compiling the program with Openlibm. Hence, the openlibm as a proposed solution to solve this bug has failed.
Conclusion[edit]
The proposed solution is to use Openlibm as a replacement of libm to deal with the inconsistency in the maths library caused when Octave is compiled with libc++ (default on macOS) and sometimes with libstdc++ has failed and the bug issues and can not be solved with openlibm. Hence, there is a need to find an alternate solution to address this issue.