sporadic make check failure in exam_inifcns_nstdsums
Hi Stefan, A recent FTBFS for GiNaC-1.8.2 on Debian's mipsel port [1] turned up a little issue with the precision goal not being 100% reproducible. The recursive calls in GiNaC::map_trafo_H_1overx::operator() assemble symbolic functions before evalf()'ing and these are not deterministic. This makes numeric results slightly differ between calls. As a result, regression test suite exam_inifcns_nstdsums.cpp fails in about 1.6% of all cases. It only ever seems to affect H(lst{-2,1,3},numeric(245)/100) - -Li(lst{2,1,3},lst{-numeric(245)/100,-1,1}) in inifcns_test_HLi(), exam_inifcns_nstdsums.cpp:148. I tortured my computer with 1365 calls and here is a histogram of numerical differences between the H and the Li results: [0.00000...1.0e-18[ 4 okay [1.0e-18...1.0e-17[ 530 okay [2.0e-17...3.0e-17[ 503 okay [3.0e-17...4.0e-17[ 232 okay [4.0e-17...5.0e-17[ 74 okay [5.0e-17...6.0e-17[ 18 FAILURE! [6.0e-17...7.0e-17[ 2 FAILURE! [7.0e-17...8.0e-17[ 2 FAILURE!
= 8e-17 - N/A
Would it make sense to raise prec to 10*pow(10,-Digits)? If so, for which tests? Or do you have a better idea? All my best, -richard. [1] <https://buildd.debian.org/status/fetch.php?pkg=ginac&arch=mipsel&ver=1.8.2-1&stamp=1641065269> -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
Dear Richy, currently prec is set to 5 * pow(10, -Digits) in inifcns_test_HLi, but this is just some empirical value, which seemed to work fine in the last 15 years. We expect the two values for (H(lst{-2,1,3},numeric(245)/100) to differ in the last digits, the main reason being a loss of significant digits when subtracting two almost equal numbers. We are not doing interval arithmetic, so we have to live with this fact. Your explanation why this even happens on the same machine seems convincing. Clearly the testsuite should pass in 100% of the cases, not just in 98.4%. Therefore raising prec to 10 * pow(10, -Digits) or 20 * pow(10, -Digits) in inifcns_test_HLi is fine. One may discuss if one raises prec just in inifcns_test_HLi, or also in other places (like exam_inifcns_elliptic.cpp). I have a slight preference for just adjusting it in inifcns_test_HLi. If you prefer not to be bothered again in a few years with the same issue in other places, we may raise it in all places where we used similar constructions. Best wishes, Stefan On Fri, 14 Jan 2022, Richard B. Kreckel wrote:
Hi Stefan,
A recent FTBFS for GiNaC-1.8.2 on Debian's mipsel port [1] turned up a little issue with the precision goal not being 100% reproducible.
The recursive calls in GiNaC::map_trafo_H_1overx::operator() assemble symbolic functions before evalf()'ing and these are not deterministic. This makes numeric results slightly differ between calls.
As a result, regression test suite exam_inifcns_nstdsums.cpp fails in about 1.6% of all cases. It only ever seems to affect H(lst{-2,1,3},numeric(245)/100) - -Li(lst{2,1,3},lst{-numeric(245)/100,-1,1}) in inifcns_test_HLi(), exam_inifcns_nstdsums.cpp:148.
I tortured my computer with 1365 calls and here is a histogram of numerical differences between the H and the Li results: [0.00000...1.0e-18[ 4 okay [1.0e-18...1.0e-17[ 530 okay [2.0e-17...3.0e-17[ 503 okay [3.0e-17...4.0e-17[ 232 okay [4.0e-17...5.0e-17[ 74 okay [5.0e-17...6.0e-17[ 18 FAILURE! [6.0e-17...7.0e-17[ 2 FAILURE! [7.0e-17...8.0e-17[ 2 FAILURE!
= 8e-17 - N/A
Would it make sense to raise prec to 10*pow(10,-Digits)? If so, for which tests? Or do you have a better idea?
All my best, -richard.
[1] <https://buildd.debian.org/status/fetch.php?pkg=ginac&arch=mipsel&ver=1.8.2-1&stamp=1641065269> -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
Dear Stefan, On 15.01.22 00:28, Stefan Weinzierl wrote:
currently prec is set to 5 * pow(10, -Digits) in inifcns_test_HLi, but this is just some empirical value, which seemed to work fine in the last 15 years.
We expect the two values for (H(lst{-2,1,3},numeric(245)/100) to differ in the last digits, the main reason being a loss of significant digits when subtracting two almost equal numbers. We are not doing interval arithmetic, so we have to live with this fact.
Your explanation why this even happens on the same machine seems convincing.
Clearly the testsuite should pass in 100% of the cases, not just in 98.4%. Therefore raising prec to 10 * pow(10, -Digits) or 20 * pow(10, -Digits) in inifcns_test_HLi is fine.
One may discuss if one raises prec just in inifcns_test_HLi, or also in other places (like exam_inifcns_elliptic.cpp). I have a slight preference for just adjusting it in inifcns_test_HLi. If you prefer not to be bothered again in a few years with the same issue in other places, we may raise it in all places where we used similar constructions.
Given the rapid decline of larger differences between H and Li as is apparent from the histogram, I would say that setting the precision to 10*pow(10, -Digits) in inifcns_test_HLi() seems very safe. But it's entirely your decision! All my best, -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
participants (2)
-
Richard B. Kreckel
-
Stefan Weinzierl