diff mbox series

[COMMITTED] arm: update libm test ulps

Message ID 20210408085827.5369-1-szabolcs.nagy@arm.com
State Committed
Commit 2d690bbb17f0eed223af74966d7ff012a713dd29
Headers
Series [COMMITTED] arm: update libm test ulps |

Commit Message

Szabolcs Nagy April 8, 2021, 8:58 a.m. UTC 
  Updated after commits 9acda61d94acc5348c2330f2519a14d1a4a37e73
and 43576de04afc6a0896a3ecc094e1581069a0652a.
---
 sysdeps/arm/libm-test-ulps | 50 +++++++++++++++++++-------------------
 1 file changed, 25 insertions(+), 25 deletions(-)

Comments

Vineet Gupta April 11, 2021, 6:04 p.m. UTC | #1 
On 4/8/21 1:58 AM, Szabolcs Nagy via Libc-alpha wrote:
> Updated after commits 9acda61d94acc5348c2330f2519a14d1a4a37e73
> and 43576de04afc6a0896a3ecc094e1581069a0652a.

Is there a better way for this to be done at the time of original change 
other than running the tests on all affected architectures. arches 
always seem to be chasing these kind of changes ...

> ---
>   sysdeps/arm/libm-test-ulps | 50 +++++++++++++++++++-------------------
>   1 file changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/sysdeps/arm/libm-test-ulps b/sysdeps/arm/libm-test-ulps
> index cdb635ee3d..f7e6046da4 100644
> --- a/sysdeps/arm/libm-test-ulps
> +++ b/sysdeps/arm/libm-test-ulps
> @@ -851,35 +851,35 @@ double: 1
>   
>   Function: "j0":
>   double: 2
> -float: 8
> +float: 9
>   
>   Function: "j0_downward":
> -double: 2
> -float: 4
> +double: 5
> +float: 9

[snip]
Szabolcs Nagy April 13, 2021, 9:52 a.m. UTC | #2 
The 04/11/2021 18:04, Vineet Gupta wrote:
> On 4/8/21 1:58 AM, Szabolcs Nagy via Libc-alpha wrote:
> > Updated after commits 9acda61d94acc5348c2330f2519a14d1a4a37e73
> > and 43576de04afc6a0896a3ecc094e1581069a0652a.
> 
> Is there a better way for this to be done at the time of original change 
> other than running the tests on all affected architectures. arches 
> always seem to be chasing these kind of changes ...

i think there are only small variations between targets for
float and double, so the ulp error limits for those could be
shared (unless a target has its own implementation with
different quality requirement for some reason).

long double is more target specific. i think the tests could
be organised such that each sysdeps/ieee754/* directory has
its own ulp limits file and the target picks up the right one.

and libmvec needs target specific ulp limits.

i don't know how hard it would be to implement this.
Adhemerval Zanella Netto April 13, 2021, 3:01 p.m. UTC | #3 
On 13/04/2021 06:52, Szabolcs Nagy wrote:
> The 04/11/2021 18:04, Vineet Gupta wrote:
>> On 4/8/21 1:58 AM, Szabolcs Nagy via Libc-alpha wrote:
>>> Updated after commits 9acda61d94acc5348c2330f2519a14d1a4a37e73
>>> and 43576de04afc6a0896a3ecc094e1581069a0652a.
>>
>> Is there a better way for this to be done at the time of original change 
>> other than running the tests on all affected architectures. arches 
>> always seem to be chasing these kind of changes ...
> 
> i think there are only small variations between targets for
> float and double, so the ulp error limits for those could be
> shared (unless a target has its own implementation with
> different quality requirement for some reason).
> 
> long double is more target specific. i think the tests could
> be organised such that each sysdeps/ieee754/* directory has
> its own ulp limits file and the target picks up the right one.
> 
> and libmvec needs target specific ulp limits.
> 
> i don't know how hard it would be to implement this.
> 

The math/libm-test-support.c imposes maximum ulp limits depending of 
the underling type:

 228   if (testing_ibm128)
 229     /* The documented accuracy of IBM long double division is 3ulp
 230        (see libgcc/config/rs6000/ibm-ldouble-format), so do not
 231        require better accuracy for libm functions that are exactly
 232        defined for other formats.  */
 233     max_valid_error = exact ? 3 : 16;
 234   else
 235     max_valid_error = exact ? 0 : 9;

And if I recall correctly there was a suggestion to consolidate and/or
remove the ulps file altogether and use the maximum valid error as the
threshold to report regressions.  The only drawback I see of moving
towards it is each architecture won't see if some change has degraded
the function precision.

But I tend to agree that using per-architecture ulp files do not add
much, since arch maintainer tend todig into the precision issues only
when it is higher the the tests threshold.
Joseph Myers April 13, 2021, 6:02 p.m. UTC | #4 
On Tue, 13 Apr 2021, Adhemerval Zanella via Libc-alpha wrote:

> The math/libm-test-support.c imposes maximum ulp limits depending of 
> the underling type:
> 
>  228   if (testing_ibm128)
>  229     /* The documented accuracy of IBM long double division is 3ulp
>  230        (see libgcc/config/rs6000/ibm-ldouble-format), so do not
>  231        require better accuracy for libm functions that are exactly
>  232        defined for other formats.  */
>  233     max_valid_error = exact ? 3 : 16;
>  234   else
>  235     max_valid_error = exact ? 0 : 9;
> 
> And if I recall correctly there was a suggestion to consolidate and/or
> remove the ulps file altogether and use the maximum valid error as the
> threshold to report regressions.  The only drawback I see of moving
> towards it is each architecture won't see if some change has degraded
> the function precision.

And for some of the higher ulps values it might be good to improve the 
precision, which suggests having at least per-format if not 
per-architecture empirical bounds for each function.
diff mbox series

Patch

diff --git a/sysdeps/arm/libm-test-ulps b/sysdeps/arm/libm-test-ulps
index cdb635ee3d..f7e6046da4 100644
--- a/sysdeps/arm/libm-test-ulps
+++ b/sysdeps/arm/libm-test-ulps
@@ -851,35 +851,35 @@  double: 1
 
 Function: "j0":
 double: 2
-float: 8
+float: 9
 
 Function: "j0_downward":
-double: 2
-float: 4
+double: 5
+float: 9
 
 Function: "j0_towardzero":
-double: 4
-float: 5
+double: 6
+float: 9
 
 Function: "j0_upward":
-double: 4
-float: 5
+double: 9
+float: 9
 
 Function: "j1":
-double: 2
+double: 4
 float: 9
 
 Function: "j1_downward":
-double: 3
-float: 5
+double: 5
+float: 8
 
 Function: "j1_towardzero":
-double: 3
-float: 2
+double: 4
+float: 8
 
 Function: "j1_upward":
-double: 3
-float: 5
+double: 9
+float: 9
 
 Function: "jn":
 double: 4
@@ -1074,7 +1074,7 @@  double: 9
 float: 8
 
 Function: "tgamma_downward":
-double: 8
+double: 9
 float: 7
 
 Function: "tgamma_towardzero":
@@ -1087,35 +1087,35 @@  float: 8
 
 Function: "y0":
 double: 3
-float: 8
+float: 9
 
 Function: "y0_downward":
 double: 3
-float: 6
+float: 9
 
 Function: "y0_towardzero":
-double: 3
-float: 3
+double: 4
+float: 9
 
 Function: "y0_upward":
 double: 3
-float: 6
+float: 9
 
 Function: "y1":
 double: 3
-float: 2
+float: 9
 
 Function: "y1_downward":
-double: 3
-float: 2
+double: 6
+float: 9
 
 Function: "y1_towardzero":
 double: 3
-float: 2
+float: 9
 
 Function: "y1_upward":
 double: 7
-float: 2
+float: 9
 
 Function: "yn":
 double: 3