* [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P
@ 2022-12-07 12:10 Jakub Jelinek
2022-12-07 15:21 ` Aldy Hernandez
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2022-12-07 12:10 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: gcc-patches
Hi!
As mentioned in PR107967, ibm-ldouble-format documents that
+- has 1ulp accuracy, * 2ulps and / 3ulps.
So, even if the result is exact, we need to widen the range a little bit.
The following patch does that. I just wonder what it means for reverse
division (the op1_range case), which we implement through multiplication,
when division has 3ulps error and multiplication just 2ulps. In any case,
this format is a mess and for non-default rounding modes can't be trusted
at all, instead of +inf or something close to it it happily computes -inf.
2022-12-07 Jakub Jelinek <jakub@redhat.com>
* range-op-float.cc (frange_arithmetic): For mode_composite,
on top of rounding in the right direction accept extra 1ulp
error for PLUS/MINUS_EXPR, extra 2ulps error for MULT_EXPR
and extra 3ulps error for RDIV_EXPR.
--- gcc/range-op-float.cc.jj 2022-12-07 12:46:01.536123757 +0100
+++ gcc/range-op-float.cc 2022-12-07 12:50:40.812085139 +0100
@@ -344,22 +344,70 @@ frange_arithmetic (enum tree_code code,
}
}
}
- if (round && (inexact || !real_identical (&result, &value)))
+ if (!inexact && !real_identical (&result, &value))
+ inexact = true;
+ if (round && (inexact || mode_composite))
{
if (mode_composite)
{
- if (real_isdenormal (&result, mode)
- || real_iszero (&result))
+ if (real_isdenormal (&result, mode) || real_iszero (&result))
{
// IBM extended denormals only have DFmode precision.
REAL_VALUE_TYPE tmp;
real_convert (&tmp, DFmode, &value);
- frange_nextafter (DFmode, tmp, inf);
+ if (inexact)
+ frange_nextafter (DFmode, tmp, inf);
+ switch (code)
+ {
+ case PLUS_EXPR:
+ case MINUS_EXPR:
+ // ibm-ldouble-format documents 1ulp for + and -.
+ frange_nextafter (DFmode, tmp, inf);
+ break;
+ case MULT_EXPR:
+ // ibm-ldouble-format documents 2ulps for *.
+ frange_nextafter (DFmode, tmp, inf);
+ frange_nextafter (DFmode, tmp, inf);
+ break;
+ case RDIV_EXPR:
+ // ibm-ldouble-format documents 3ulps for /.
+ frange_nextafter (DFmode, tmp, inf);
+ frange_nextafter (DFmode, tmp, inf);
+ frange_nextafter (DFmode, tmp, inf);
+ break;
+ default:
+ if (!inexact)
+ return;
+ break;
+ }
real_convert (&result, mode, &tmp);
return;
}
}
- frange_nextafter (mode, result, inf);
+ if (inexact)
+ frange_nextafter (mode, result, inf);
+ if (mode_composite)
+ switch (code)
+ {
+ case PLUS_EXPR:
+ case MINUS_EXPR:
+ // ibm-ldouble-format documents 1ulp for + and -.
+ frange_nextafter (mode, result, inf);
+ break;
+ case MULT_EXPR:
+ // ibm-ldouble-format documents 2ulps for *.
+ frange_nextafter (mode, result, inf);
+ frange_nextafter (mode, result, inf);
+ break;
+ case RDIV_EXPR:
+ // ibm-ldouble-format documents 3ulps for /.
+ frange_nextafter (mode, result, inf);
+ frange_nextafter (mode, result, inf);
+ frange_nextafter (mode, result, inf);
+ break;
+ default:
+ break;
+ }
}
}
Jakub
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P 2022-12-07 12:10 [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P Jakub Jelinek @ 2022-12-07 15:21 ` Aldy Hernandez 2022-12-07 15:31 ` Jakub Jelinek 0 siblings, 1 reply; 6+ messages in thread From: Aldy Hernandez @ 2022-12-07 15:21 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc-patches, Andrew MacLeod On 12/7/22 13:10, Jakub Jelinek wrote: > Hi! > > As mentioned in PR107967, ibm-ldouble-format documents that > +- has 1ulp accuracy, * 2ulps and / 3ulps. > So, even if the result is exact, we need to widen the range a little bit. > > The following patch does that. I just wonder what it means for reverse > division (the op1_range case), which we implement through multiplication, > when division has 3ulps error and multiplication just 2ulps. In any case, > this format is a mess and for non-default rounding modes can't be trusted > at all, instead of +inf or something close to it it happily computes -inf. > > 2022-12-07 Jakub Jelinek <jakub@redhat.com> > > * range-op-float.cc (frange_arithmetic): For mode_composite, > on top of rounding in the right direction accept extra 1ulp > error for PLUS/MINUS_EXPR, extra 2ulps error for MULT_EXPR > and extra 3ulps error for RDIV_EXPR. > > --- gcc/range-op-float.cc.jj 2022-12-07 12:46:01.536123757 +0100 > +++ gcc/range-op-float.cc 2022-12-07 12:50:40.812085139 +0100 > @@ -344,22 +344,70 @@ frange_arithmetic (enum tree_code code, > } > } > } > - if (round && (inexact || !real_identical (&result, &value))) > + if (!inexact && !real_identical (&result, &value)) > + inexact = true; > + if (round && (inexact || mode_composite)) > { > if (mode_composite) > { > - if (real_isdenormal (&result, mode) > - || real_iszero (&result)) > + if (real_isdenormal (&result, mode) || real_iszero (&result)) > { > // IBM extended denormals only have DFmode precision. > REAL_VALUE_TYPE tmp; > real_convert (&tmp, DFmode, &value); > - frange_nextafter (DFmode, tmp, inf); > + if (inexact) > + frange_nextafter (DFmode, tmp, inf); > + switch (code) > + { > + case PLUS_EXPR: > + case MINUS_EXPR: > + // ibm-ldouble-format documents 1ulp for + and -. > + frange_nextafter (DFmode, tmp, inf); > + break; > + case MULT_EXPR: > + // ibm-ldouble-format documents 2ulps for *. > + frange_nextafter (DFmode, tmp, inf); > + frange_nextafter (DFmode, tmp, inf); > + break; > + case RDIV_EXPR: > + // ibm-ldouble-format documents 3ulps for /. > + frange_nextafter (DFmode, tmp, inf); > + frange_nextafter (DFmode, tmp, inf); > + frange_nextafter (DFmode, tmp, inf); > + break; > + default: > + if (!inexact) > + return; > + break; It looks like this chunk... > + } > real_convert (&result, mode, &tmp); > return; > } > } > - frange_nextafter (mode, result, inf); > + if (inexact) > + frange_nextafter (mode, result, inf); > + if (mode_composite) > + switch (code) > + { > + case PLUS_EXPR: > + case MINUS_EXPR: > + // ibm-ldouble-format documents 1ulp for + and -. > + frange_nextafter (mode, result, inf); > + break; > + case MULT_EXPR: > + // ibm-ldouble-format documents 2ulps for *. > + frange_nextafter (mode, result, inf); > + frange_nextafter (mode, result, inf); > + break; > + case RDIV_EXPR: > + // ibm-ldouble-format documents 3ulps for /. > + frange_nextafter (mode, result, inf); > + frange_nextafter (mode, result, inf); > + frange_nextafter (mode, result, inf); > + break; > + default: > + break; > + } ...is the same as this chunk. Plus, all this mode composite stuff is polluting what was a rather clean function. Would it be possible to abstract this into an inline function, and then we could do: if (mode_composite) frange_composite_nextafter (...); else frange_nextafter (...); or perhaps abstract the whole nextafter in frange_arithmetic into: frange_arithmetic_nextafter () { if (mode_composite) { do ugly stuff } else frange_nextafter (...) } I'm most worried about maintainability, not correctness here, cause you obviously know what you're doing ;-). Aldy > } > } > > > Jakub > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P 2022-12-07 15:21 ` Aldy Hernandez @ 2022-12-07 15:31 ` Jakub Jelinek 2022-12-07 15:38 ` Aldy Hernandez 0 siblings, 1 reply; 6+ messages in thread From: Jakub Jelinek @ 2022-12-07 15:31 UTC (permalink / raw) To: Aldy Hernandez; +Cc: gcc-patches, Andrew MacLeod On Wed, Dec 07, 2022 at 04:21:09PM +0100, Aldy Hernandez wrote: > On 12/7/22 13:10, Jakub Jelinek wrote: > > + switch (code) > > + { > > + case PLUS_EXPR: > > + case MINUS_EXPR: > > + // ibm-ldouble-format documents 1ulp for + and -. > > + frange_nextafter (DFmode, tmp, inf); > > + break; > > + case MULT_EXPR: > > + // ibm-ldouble-format documents 2ulps for *. > > + frange_nextafter (DFmode, tmp, inf); > > + frange_nextafter (DFmode, tmp, inf); > > + break; > > + case RDIV_EXPR: > > + // ibm-ldouble-format documents 3ulps for /. > > + frange_nextafter (DFmode, tmp, inf); > > + frange_nextafter (DFmode, tmp, inf); > > + frange_nextafter (DFmode, tmp, inf); > > + break; > > + default: > > + if (!inexact) > > + return; > > + break; > > It looks like this chunk... > > > > + switch (code) > > + { > > + case PLUS_EXPR: > > + case MINUS_EXPR: > > + // ibm-ldouble-format documents 1ulp for + and -. > > + frange_nextafter (mode, result, inf); > > + break; > > + case MULT_EXPR: > > + // ibm-ldouble-format documents 2ulps for *. > > + frange_nextafter (mode, result, inf); > > + frange_nextafter (mode, result, inf); > > + break; > > + case RDIV_EXPR: > > + // ibm-ldouble-format documents 3ulps for /. > > + frange_nextafter (mode, result, inf); > > + frange_nextafter (mode, result, inf); > > + frange_nextafter (mode, result, inf); > > + break; > > + default: > > + break; > > + } > > ...is the same as this chunk. Plus, all this mode composite stuff is It is not the same, there is the DFmode, tmp vs. mode, result difference. But sure, we could either add an inline function which for (code, mode, result, inf) set of options (or (code, DFmode, tmp, inf)) do those 0, 1, 2, 3 frange_nextafter calls (and return bool if it did any - there is also the if (!inexact) return; case), or as you suggest perhaps change frange_nextafter to handle MODE_COMPOSITE_P differently and do there if (mode_composite && (real_isdenormal (&result, mode) || real_iszero (&result))) { // IBM extended denormals only have DFmode precision. REAL_VALUE_TYPE tmp; real_convert (&tmp, DFmode, &result); frange_nextafter (DFmode, tmp, inf); real_convert (&result, mode, &tmp); } else frange_nextafter (mode, result, inf); Though, that somewhat changes behavior, it will convert to DFmode and back for every nextafter rather than just once (just slower compile time), but also right now we start from value rather than result. So, perhaps a combination of that, change frange_nextafter to do the above and change frange_arithmetic for the initial inexact rounding only to do it by hand using range_nextafter and starting from value. Anyway, this patch is far less important than the previous one... Jakub ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P 2022-12-07 15:31 ` Jakub Jelinek @ 2022-12-07 15:38 ` Aldy Hernandez 2022-12-07 16:05 ` [PATCH] range-op-float, v2: " Jakub Jelinek 0 siblings, 1 reply; 6+ messages in thread From: Aldy Hernandez @ 2022-12-07 15:38 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc-patches, Andrew MacLeod On 12/7/22 16:31, Jakub Jelinek wrote: > On Wed, Dec 07, 2022 at 04:21:09PM +0100, Aldy Hernandez wrote: >> On 12/7/22 13:10, Jakub Jelinek wrote: >>> + switch (code) >>> + { >>> + case PLUS_EXPR: >>> + case MINUS_EXPR: >>> + // ibm-ldouble-format documents 1ulp for + and -. >>> + frange_nextafter (DFmode, tmp, inf); >>> + break; >>> + case MULT_EXPR: >>> + // ibm-ldouble-format documents 2ulps for *. >>> + frange_nextafter (DFmode, tmp, inf); >>> + frange_nextafter (DFmode, tmp, inf); >>> + break; >>> + case RDIV_EXPR: >>> + // ibm-ldouble-format documents 3ulps for /. >>> + frange_nextafter (DFmode, tmp, inf); >>> + frange_nextafter (DFmode, tmp, inf); >>> + frange_nextafter (DFmode, tmp, inf); >>> + break; >>> + default: >>> + if (!inexact) >>> + return; >>> + break; >> >> It looks like this chunk... >> >> >>> + switch (code) >>> + { >>> + case PLUS_EXPR: >>> + case MINUS_EXPR: >>> + // ibm-ldouble-format documents 1ulp for + and -. >>> + frange_nextafter (mode, result, inf); >>> + break; >>> + case MULT_EXPR: >>> + // ibm-ldouble-format documents 2ulps for *. >>> + frange_nextafter (mode, result, inf); >>> + frange_nextafter (mode, result, inf); >>> + break; >>> + case RDIV_EXPR: >>> + // ibm-ldouble-format documents 3ulps for /. >>> + frange_nextafter (mode, result, inf); >>> + frange_nextafter (mode, result, inf); >>> + frange_nextafter (mode, result, inf); >>> + break; >>> + default: >>> + break; >>> + } >> >> ...is the same as this chunk. Plus, all this mode composite stuff is > > It is not the same, there is the DFmode, tmp vs. mode, result difference. > But sure, we could either add an inline function which for > (code, mode, result, inf) set of options (or (code, DFmode, tmp, inf)) > do those 0, 1, 2, 3 frange_nextafter calls (and return bool if it did any > - there is also the if (!inexact) return; case), or as you suggest > perhaps change frange_nextafter to handle MODE_COMPOSITE_P differently > and do there > if (mode_composite && (real_isdenormal (&result, mode) || real_iszero (&result))) > { > // IBM extended denormals only have DFmode precision. > REAL_VALUE_TYPE tmp; > real_convert (&tmp, DFmode, &result); > frange_nextafter (DFmode, tmp, inf); > real_convert (&result, mode, &tmp); > } > else > frange_nextafter (mode, result, inf); > Though, that somewhat changes behavior, it will convert to DFmode and back > for every nextafter rather than just once (just slower compile time), > but also right now we start from value rather than result. > > So, perhaps a combination of that, change frange_nextafter to do the above > and change frange_arithmetic for the initial inexact rounding only to > do it by hand using range_nextafter and starting from value. Either way is fine. Whatever is cleaner. Aldy > > Anyway, this patch is far less important than the previous one... > > Jakub > ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] range-op-float, v2: frange_arithmetic tweaks for MODE_COMPOSITE_P 2022-12-07 15:38 ` Aldy Hernandez @ 2022-12-07 16:05 ` Jakub Jelinek 2022-12-07 17:41 ` Aldy Hernandez 0 siblings, 1 reply; 6+ messages in thread From: Jakub Jelinek @ 2022-12-07 16:05 UTC (permalink / raw) To: Aldy Hernandez; +Cc: gcc-patches, Andrew MacLeod On Wed, Dec 07, 2022 at 04:38:14PM +0100, Aldy Hernandez wrote: > > So, perhaps a combination of that, change frange_nextafter to do the above > > and change frange_arithmetic for the initial inexact rounding only to > > do it by hand using range_nextafter and starting from value. > > Either way is fine. Whatever is cleaner. Now in patch form: 2022-12-07 Jakub Jelinek <jakub@redhat.com> * range-op-float.cc (frange_nextafter): For MODE_COMPOSITE_P from denormal or zero, use real_nextafter on DFmode with conversions around it. (frange_arithmetic): For mode_composite, on top of rounding in the right direction accept extra 1ulp error for PLUS/MINUS_EXPR, extra 2ulps error for MULT_EXPR and extra 3ulps error for RDIV_EXPR. --- gcc/range-op-float.cc.jj 2022-12-07 12:46:01.536123757 +0100 +++ gcc/range-op-float.cc 2022-12-07 16:58:02.406062286 +0100 @@ -254,10 +254,21 @@ frange_nextafter (enum machine_mode mode REAL_VALUE_TYPE &value, const REAL_VALUE_TYPE &inf) { - const real_format *fmt = REAL_MODE_FORMAT (mode); - REAL_VALUE_TYPE tmp; - real_nextafter (&tmp, fmt, &value, &inf); - value = tmp; + if (MODE_COMPOSITE_P (mode) + && (real_isdenormal (&value, mode) || real_iszero (&value))) + { + // IBM extended denormals only have DFmode precision. + REAL_VALUE_TYPE tmp, tmp2; + real_convert (&tmp2, DFmode, &value); + real_nextafter (&tmp, REAL_MODE_FORMAT (DFmode), &tmp2, &inf); + real_convert (&value, mode, &tmp); + } + else + { + REAL_VALUE_TYPE tmp; + real_nextafter (&tmp, REAL_MODE_FORMAT (mode), &value, &inf); + value = tmp; + } } // Like real_arithmetic, but round the result to INF if the operation @@ -324,21 +335,40 @@ frange_arithmetic (enum tree_code code, } if (round && (inexact || !real_identical (&result, &value))) { - if (mode_composite) + if (mode_composite + && (real_isdenormal (&result, mode) || real_iszero (&result))) { - if (real_isdenormal (&result, mode) - || real_iszero (&result)) - { - // IBM extended denormals only have DFmode precision. - REAL_VALUE_TYPE tmp; - real_convert (&tmp, DFmode, &value); - frange_nextafter (DFmode, tmp, inf); - real_convert (&result, mode, &tmp); - return; - } + // IBM extended denormals only have DFmode precision. + REAL_VALUE_TYPE tmp, tmp2; + real_convert (&tmp2, DFmode, &value); + real_nextafter (&tmp, REAL_MODE_FORMAT (DFmode), &tmp2, &inf); + real_convert (&result, mode, &tmp); } - frange_nextafter (mode, result, inf); + else + frange_nextafter (mode, result, inf); } + if (mode_composite) + switch (code) + { + case PLUS_EXPR: + case MINUS_EXPR: + // ibm-ldouble-format documents 1ulp for + and -. + frange_nextafter (mode, result, inf); + break; + case MULT_EXPR: + // ibm-ldouble-format documents 2ulps for *. + frange_nextafter (mode, result, inf); + frange_nextafter (mode, result, inf); + break; + case RDIV_EXPR: + // ibm-ldouble-format documents 3ulps for /. + frange_nextafter (mode, result, inf); + frange_nextafter (mode, result, inf); + frange_nextafter (mode, result, inf); + break; + default: + break; + } } // Crop R to [-INF, MAX] where MAX is the maximum representable number Jakub ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] range-op-float, v2: frange_arithmetic tweaks for MODE_COMPOSITE_P 2022-12-07 16:05 ` [PATCH] range-op-float, v2: " Jakub Jelinek @ 2022-12-07 17:41 ` Aldy Hernandez 0 siblings, 0 replies; 6+ messages in thread From: Aldy Hernandez @ 2022-12-07 17:41 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc-patches, Andrew MacLeod OK, thanks. Aldy On 12/7/22 17:05, Jakub Jelinek wrote: > On Wed, Dec 07, 2022 at 04:38:14PM +0100, Aldy Hernandez wrote: >>> So, perhaps a combination of that, change frange_nextafter to do the above >>> and change frange_arithmetic for the initial inexact rounding only to >>> do it by hand using range_nextafter and starting from value. >> >> Either way is fine. Whatever is cleaner. > > Now in patch form: > > 2022-12-07 Jakub Jelinek <jakub@redhat.com> > > * range-op-float.cc (frange_nextafter): For MODE_COMPOSITE_P from > denormal or zero, use real_nextafter on DFmode with conversions > around it. > (frange_arithmetic): For mode_composite, on top of rounding in the > right direction accept extra 1ulp error for PLUS/MINUS_EXPR, extra > 2ulps error for MULT_EXPR and extra 3ulps error for RDIV_EXPR. > > --- gcc/range-op-float.cc.jj 2022-12-07 12:46:01.536123757 +0100 > +++ gcc/range-op-float.cc 2022-12-07 16:58:02.406062286 +0100 > @@ -254,10 +254,21 @@ frange_nextafter (enum machine_mode mode > REAL_VALUE_TYPE &value, > const REAL_VALUE_TYPE &inf) > { > - const real_format *fmt = REAL_MODE_FORMAT (mode); > - REAL_VALUE_TYPE tmp; > - real_nextafter (&tmp, fmt, &value, &inf); > - value = tmp; > + if (MODE_COMPOSITE_P (mode) > + && (real_isdenormal (&value, mode) || real_iszero (&value))) > + { > + // IBM extended denormals only have DFmode precision. > + REAL_VALUE_TYPE tmp, tmp2; > + real_convert (&tmp2, DFmode, &value); > + real_nextafter (&tmp, REAL_MODE_FORMAT (DFmode), &tmp2, &inf); > + real_convert (&value, mode, &tmp); > + } > + else > + { > + REAL_VALUE_TYPE tmp; > + real_nextafter (&tmp, REAL_MODE_FORMAT (mode), &value, &inf); > + value = tmp; > + } > } > > // Like real_arithmetic, but round the result to INF if the operation > @@ -324,21 +335,40 @@ frange_arithmetic (enum tree_code code, > } > if (round && (inexact || !real_identical (&result, &value))) > { > - if (mode_composite) > + if (mode_composite > + && (real_isdenormal (&result, mode) || real_iszero (&result))) > { > - if (real_isdenormal (&result, mode) > - || real_iszero (&result)) > - { > - // IBM extended denormals only have DFmode precision. > - REAL_VALUE_TYPE tmp; > - real_convert (&tmp, DFmode, &value); > - frange_nextafter (DFmode, tmp, inf); > - real_convert (&result, mode, &tmp); > - return; > - } > + // IBM extended denormals only have DFmode precision. > + REAL_VALUE_TYPE tmp, tmp2; > + real_convert (&tmp2, DFmode, &value); > + real_nextafter (&tmp, REAL_MODE_FORMAT (DFmode), &tmp2, &inf); > + real_convert (&result, mode, &tmp); > } > - frange_nextafter (mode, result, inf); > + else > + frange_nextafter (mode, result, inf); > } > + if (mode_composite) > + switch (code) > + { > + case PLUS_EXPR: > + case MINUS_EXPR: > + // ibm-ldouble-format documents 1ulp for + and -. > + frange_nextafter (mode, result, inf); > + break; > + case MULT_EXPR: > + // ibm-ldouble-format documents 2ulps for *. > + frange_nextafter (mode, result, inf); > + frange_nextafter (mode, result, inf); > + break; > + case RDIV_EXPR: > + // ibm-ldouble-format documents 3ulps for /. > + frange_nextafter (mode, result, inf); > + frange_nextafter (mode, result, inf); > + frange_nextafter (mode, result, inf); > + break; > + default: > + break; > + } > } > > // Crop R to [-INF, MAX] where MAX is the maximum representable number > > > Jakub > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-12-07 17:41 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-07 12:10 [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P Jakub Jelinek 2022-12-07 15:21 ` Aldy Hernandez 2022-12-07 15:31 ` Jakub Jelinek 2022-12-07 15:38 ` Aldy Hernandez 2022-12-07 16:05 ` [PATCH] range-op-float, v2: " Jakub Jelinek 2022-12-07 17:41 ` Aldy Hernandez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).