[COMMITTED] arm: update libm test ulps

[COMMITTED] arm: update libm test ulps

[Szabolcs Nagy]

Updated after commits 9acda61d94acc5348c2330f2519a14d1a4a37e73
and 43576de04afc6a0896a3ecc094e1581069a0652a.
---
 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
 
 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
-- 
2.17.1

Re: [COMMITTED] arm: update libm test ulps

[Vineet Gupta]

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]

Re: [COMMITTED] arm: update libm test ulps

[Szabolcs Nagy]

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.

Re: [COMMITTED] arm: update libm test ulps

[Adhemerval Zanella]

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.

Re: [COMMITTED] arm: update libm test ulps

[Joseph Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com