Apache OpenOffice (AOO) Bugzilla – Issue 121561
Use of boost instead of RTL hyperbolic/power functions
Last modified: 2013-05-07 19:00:25 UTC
Created attachment 80082 [details] Use basic hyperbolic and power functions from boost in Sc Some functions are known to have poor implementations in most OS's libc. The results can be poor math but also we end up with functions that are highly dependent on the operating system. Boost, OTOH, has excellent implementations of some special functions. I made a proof of concept patch to use Boost implementations of asinh, acosh, and atanh. This may serve as a proof-of-concept to do something similar with other functions and to determine testing procedures for such cases.
Created attachment 80083 [details] A basic spreadsheet to see that things work I tried doing some very basic tests to see if these functions produce consistent results. The results are inconclusive from a precision POV, I basically only got different results in the last digit in a result in atanh, and a small error with small numbers in in acosh, but it seems pretty similar to the system libraries. More testing with small values of acosh are desirable.
Created attachment 80085 [details] Testcases for PMT Hi Pedro. Find attached the test cases for PMT, which I had used when fixing function PMT in bug 91870. The blue values are calculated with a CAS. While the rate goes zero the payment should converge monotonically to 7.
Comment on attachment 80085 [details] Testcases for PMT Whoa ... very interesting !!! The values seem OK, but Boost just failed the tests! Looking at the "negative 1" and "negative 0" spreadsheets Calc crashes: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<_STL::overflow_error> >' I will have to look at the Policy stuff.
Created attachment 80086 [details] Use hyperbolic and power function from boost in Sc I adjusted the Boost policy so that it behaves like the original functions. With this adjustments Regina's PMT test won't crash and Calc passes the test.
Created attachment 80090 [details] Exercise a bit the Hyperbolic functions
Hi Pedro, bug 97605 contains my study of the accuracy problem and contains documents with test cases, one for acosh and one for asinh. Please have a look at them with your boost using version.
(In reply to comment #6) > Hi Pedro, bug 97605 contains my study of the accuracy problem and contains > documents with test cases, one for acosh and one for asinh. Please have a > look at them with your boost using version. Excellent tests Regina! We are now better than Gnumeric and very near MuPad. FWIW, I was already detecting similar issues in my tests in Symphony. It seems the Symphony guys forgot to update RTL and still carry the defects you detected. I think this is ready for wider testing, so I will commit it.
"pfg" committed SVN revision 1427988 into trunk: i121561 - Use of boost instead of RTL hyperbolic/power functions.
Thanks for working on this important task! The win buildbot complains in http://ci.apache.org/builders/aoo-win7/builds/451 about some problems caused by the changes though: main/solver/350/wntmsci12.pro/inc\boost/math/special_functions/atanh.hpp(78) : error C2784: '_Tp _STL::abs(const _STL::complex<_Tp> &)' : could not deduce template argument for 'const _STL::complex<_Tp> &' from 'const value_type' E:/slave14/aoo-win7/build/main/solver/350/wntmsci12.pro/inc/stl\stl/_complex.h(768) : see declaration of '_STL::abs'
Created attachment 80094 [details] log of failed sc compile on win buildbot run #450
(In reply to comment #10) > Created attachment 80094 [details] > log of failed sc compile on win buildbot run #450 Thank you so much for the report.. and patience! It looks like the MSVC doesn't like the default policy. There is a MSVC specific hint in the Boost documentation: http://www.boost.org/doc/libs/1_48_0/libs/math/doc/sf_and_dist/html/math_toolkit/policy/pol_tutorial/changing_policy_defaults.html I committed a change and MSVC should be less strict about assertions now but it may happen that this needs to be fixed in the Windows specific build or reverted :(.
Just wondering why the robot didn't catch r1428523
"pfg" committed SVN revision 1428523 into trunk: i121561 - Attempt to fix windows build issue
(In reply to comment #12) > Just wondering why the robot didn't catch r1428523 The robot caught the change, tried to update the issue, could not connect and so queued the update until the robot was woken up by another commit. Maybe it should retry after 1min, 2min, 4min, ... instead
"pfg" committed SVN revision 1428922 into trunk: i121561 - Better attempt to fix the Windows build.
"hdu" committed SVN revision 1428926 into trunk: #i121561# workaround windows build problem with the new boost functions
Created attachment 80102 [details] Use boost tgamma and lgamma This is yet untested but uses "true" gamma and log gamma from Boost. The original code was based on the Boost implementation so this replacement makes sense plus we get the advantages of type promotion. While here, I replaced the author field in the log to "bst", to denote that we are using Boost. No idea yet what secondary effects (if any) this may have.
(In reply to comment #17) > Created attachment 80102 [details] > Use boost tgamma and lgamma > > This is yet untested but uses "true" gamma and log gamma from Boost. > The patch won't compile due to a bug in boost 1.48 :( https://svn.boost.org/trac/boost/ticket/6400
Just a status report: I made some fixes to our internal boost to fix a compilation bug. Running a comparison between boost gamma and our native gamma I get the exact same results. Running a comparison between the boost Normal function and our native normal function I get the exact same results. In general the results with Boost are good and the code looks a lot cleaner but it is not exactly urgent to change the implementation if the results are the same. Boost also causes many warnings.
Created attachment 80270 [details] patch for the scaddin error functions This is a proof of concept patch to replace the erf functions with the ones in boost. This includes some unrelated fixes for the complex stuff.
Created attachment 80271 [details] Basic tests the error functions These currently return the same values as the native implementations, so I only include them for reference.
Created attachment 80272 [details] Additional use of erf functions in sc (proof of concept) This is was a test that seemed to work however, uses of erf in sc are unnecessary as we can call directly the boost versions.
Created attachment 80273 [details] WIP: Use boost functions for Bessel. This currently doesn't build, but it shows the cleanups that result of using the boost functions instead.
I lost interest and I won't be working on this anymore. I leave some patches in case someone else wants to work on it.
Some of this was done but in general there is a lack of interest.
Please refer to the process for marking issues WONTFIX: http://wiki.openoffice.org/wiki/Issue_lifecycle In particular, they should be discussed on the mailing list first. Thanks! -Rob