diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2021-12-09 15:29:30 +0100 |
---|---|---|
committer | Stephan Bergmann <sbergman@redhat.com> | 2021-12-10 00:01:48 +0100 |
commit | 19559ebbee160d1625d06feec7e6566772dad231 (patch) | |
tree | d2d94c1e34ae794e903892cecc6df6415bc1c9df /sc | |
parent | 8409df4a29857acefb6e7d7d6f33e1011a65b070 (diff) |
Allow for a presumably more precise result of BESSELY(80,9)
When Clang 14 trunk changed from defaulting to -ffp-contract=off to
-ffp-contrace=on with
<https://github.com/llvm/llvm-project/commit/f04e387055e495e3e14570087d68e93593cf2918>
"Making the code compliant to the documentation about Floating Point" ("even
when optimization is off",
<https://github.com/llvm/llvm-project/commit/95edd7f53e77415ca30abefdcdc5ce723c292ebd>
"Making the code compliant to the documentation about Floating Point"), at least
a macOS ARM64 build started to fail CppunitTest_sc_addin_functions_test
CPPUNIT_TEST_NAME=AddinFunctionsTest::testAddinFormulasFODS with
> double equality assertion failed
> - Expected: 1
> - Actual : 0
> - Delta : 1e-14
because in sc/qa/unit/data/functions/addin/fods/bessely.fods, BESSELY(80,9)
evaluates to 0.0340917220777503, so comparing it against the expected
0.0340917220777493 with ROUNDSIG(...,12) fails.
The expected value stored in bessely.fods has been like that ever since
c3fc9ac6ef1be34e4683c0c5fb7f5f116da9c59e "add BESSELI,BESSELJ,BESSELK,BESSELY
test case", and presumably is what Calc happened to produce for the test author
(rather than taking the expected value from some authoritative source). And
Calc presumably has no authoritative idea about the expected value of
Bessel(80,9) anyway, beyond what the C++ source code happens to produce with a
given C++ compiler and compiler optimization settings on a given hardware
architecture.
However,
<https://functions.wolfram.com/webMathematica/FunctionEvaluation.jsp?name=BesselY&ptype=0&n=9&z=80&digits=15>
gives 0.0340917220777507, and julia-1.7.0rc3-1.fc35.x86_64 gives
0.034091722077750686 (`using Pkg; Pkg.add("SpecialFunctions"); using
SpecialFunctions; bessely(9, 80)`), which are both closer to the actual Clang 14
trunk macOS ARM64 value than to the stored expected value, making it likely that
the actual value is more correct than the expected one (in line with the
observation in the Clang documentation that with -ffp-contract=on "fused
operations are permitted to produce more precise results than performing the
same operations separately").
Change-Id: I3c3db4099c83c01d0f14e08a694fb0977cb6863c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126617
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Diffstat (limited to 'sc')
-rw-r--r-- | sc/qa/unit/data/functions/addin/fods/bessely.fods | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/sc/qa/unit/data/functions/addin/fods/bessely.fods b/sc/qa/unit/data/functions/addin/fods/bessely.fods index 1fb1ffd4f4cf..73441f07b172 100644 --- a/sc/qa/unit/data/functions/addin/fods/bessely.fods +++ b/sc/qa/unit/data/functions/addin/fods/bessely.fods @@ -5255,7 +5255,7 @@ <table:table-cell office:value-type="float" office:value="0.0340917220777493" calcext:value-type="float"> <text:p>0.034091722077749</text:p> </table:table-cell> - <table:table-cell table:style-name="ce16" table:formula="of:=ORG.LIBREOFFICE.ROUNDSIG([.A208];12)=ORG.LIBREOFFICE.ROUNDSIG([.B208];12)" office:value-type="boolean" office:boolean-value="true" calcext:value-type="boolean"> + <table:table-cell table:style-name="ce16" table:formula="of:=ORG.LIBREOFFICE.ROUNDSIG([.A208];11)=ORG.LIBREOFFICE.ROUNDSIG([.B208];11)" office:value-type="boolean" office:boolean-value="true" calcext:value-type="boolean"> <text:p>TRUE</text:p> </table:table-cell> <table:table-cell table:style-name="ce11" table:formula="of:=FORMULA([.A208])" office:value-type="string" office:string-value="=BESSELY($L4,U$1)" calcext:value-type="string"> |