sc/qa/unit/data/functions/addin/fods/bessely.fods | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit 19559ebbee160d1625d06feec7e6566772dad231
Author: Stephan Bergmann <sberg...@redhat.com>
AuthorDate: Thu Dec 9 15:29:30 2021 +0100
Commit: Stephan Bergmann <sberg...@redhat.com>
CommitDate: Fri Dec 10 00:01:48 2021 +0100
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 <sberg...@redhat.com>
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">
