* Re: Man page issues: logb, significand, cbrt, log2, log10, exp10 [not found] ` <CANv4PNmMpiwfv5acr7U6VEVe7PE_AMTzkkpNoNN9jrtVzk_93Q@mail.gmail.com> @ 2024-03-02 21:54 ` Alejandro Colomar 2024-03-03 2:02 ` Morten Welinder 0 siblings, 1 reply; 32+ messages in thread From: Alejandro Colomar @ 2024-03-02 21:54 UTC (permalink / raw) To: Morten Welinder; +Cc: linux-man, libc-alpha, jsm-csl, newbie-02 [-- Attachment #1: Type: text/plain, Size: 2354 bytes --] [CC += glibc, and those involved in the glibc bug report] Hi Morten, On Sat, Mar 02, 2024 at 04:17:36PM -0500, Morten Welinder wrote: > I think what happens is that the compiler (not glibc) computes that > exp10 for you and that the compiler happens to be more accurate. > Here's what I get for the loop: > > for (int i = 1; i < 20; i++) { > printf ("%.20g\n", exp10 (i)); > } > > welinder@CarbonX1:~$ ./a.out > 10 > 100 > 1000.0000000000001137 > 10000.000000000001819 > 100000 > 1000000 > 9999999.9999999981374 > 99999999.999999985099 > 999999999.99999988079 > 10000000000 > 100000000000 > 1000000000000 > 10000000000000 > 100000000000000 > 1000000000000000 > 10000000000000000 > 99999999999999984 > 1000000000000000000 > 10000000000000000000 > > Here's the bug report to go with this: > https://sourceware.org/bugzilla/show_bug.cgi?id=28472 > Note comment 6. It is clearly not a high-priority item for glibc. Thanks for that link. I agree with glibc that the standard specifies that these functions need not be precise. That lost precission probably results in better performance. Most programs won't care that these functions are inaccurate. If you need a correctly-rounded version of these functions, which is perfectly reasonable, the right thing to ask is that libc implements the cr_ version of these functions. I also understand that adding functions to glibc isn't straightforward, so glibc maintainers have reasons to not do it at the moment. In fact, lately I've been leaning towards thinking that libc is a huge monster to which nothing more should be added, at all. How about writing a new library --maybe call it libm-cr, maybe libm-cr-pow, maybe libm-cr-exp10, depending on how extensive you want it-- and add cr_exp10(3) to that library? You could do that, and just support the systems you need to support. The effort would be certainly smaller than adding the function to glibc. Regarding the manual pages, I don't remember from the top of my head if there's any page documenting that libm functions are imprecise. I would prefer documenting it in one place, rather than adding caveats to every libm page. > > M. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/> Looking for a remote C programming job at the moment. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Man page issues: logb, significand, cbrt, log2, log10, exp10 2024-03-02 21:54 ` Man page issues: logb, significand, cbrt, log2, log10, exp10 Alejandro Colomar @ 2024-03-03 2:02 ` Morten Welinder 2024-03-03 2:21 ` Alejandro Colomar 2024-03-04 12:17 ` Adhemerval Zanella Netto 0 siblings, 2 replies; 32+ messages in thread From: Morten Welinder @ 2024-03-03 2:02 UTC (permalink / raw) To: Alejandro Colomar; +Cc: linux-man, libc-alpha, jsm-csl, newbie-02 Thanks. There is (was?) already crlibm out there. https://core-math.gitlabpages.inria.fr/ No particular need for wheel reinvention here. FWIW, it appears that the author of the glibc exp10 implementation agrees with me that the implementation is sub-standard: https://codebrowser.dev/glibc/glibc/math/e_exp10.c.html /* This is a very stupid and inprecise implementation. It'll get replaced sometime (soon?). */ return __ieee754_exp (M_LN10 * arg); Compare with musl: https://github.com/rofl0r/musl/blob/master/src/math/exp10.c ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Man page issues: logb, significand, cbrt, log2, log10, exp10 2024-03-03 2:02 ` Morten Welinder @ 2024-03-03 2:21 ` Alejandro Colomar 2024-03-03 11:46 ` Vincent Lefevre 2024-03-04 12:17 ` Adhemerval Zanella Netto 1 sibling, 1 reply; 32+ messages in thread From: Alejandro Colomar @ 2024-03-03 2:21 UTC (permalink / raw) To: Morten Welinder; +Cc: linux-man, libc-alpha, jsm-csl, newbie-02 [-- Attachment #1: Type: text/plain, Size: 985 bytes --] Hi Morten, On Sat, Mar 02, 2024 at 09:02:24PM -0500, Morten Welinder wrote: > Thanks. > > There is (was?) already crlibm out there. > https://core-math.gitlabpages.inria.fr/ No particular need for wheel > reinvention here. crlibm doesn't seem to exist anymore. Maybe just add some headers to core-math, and package it as a standalone library. > FWIW, it appears that the author of the glibc exp10 implementation > agrees with me that the implementation is sub-standard: > > https://codebrowser.dev/glibc/glibc/math/e_exp10.c.html > > /* This is a very stupid and inprecise implementation. It'll get > replaced sometime (soon?). */ > return __ieee754_exp (M_LN10 * arg); Hmmm. Still, it's simple. If pow(10, x) is strictly better, maybe one can prove it and send a patch. Or for something better, it'll take more work. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/> Looking for a remote C programming job at the moment. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Man page issues: logb, significand, cbrt, log2, log10, exp10 2024-03-03 2:21 ` Alejandro Colomar @ 2024-03-03 11:46 ` Vincent Lefevre 2024-03-03 12:21 ` Alejandro Colomar 0 siblings, 1 reply; 32+ messages in thread From: Vincent Lefevre @ 2024-03-03 11:46 UTC (permalink / raw) To: Alejandro Colomar Cc: Morten Welinder, linux-man, libc-alpha, jsm-csl, newbie-02 On 2024-03-03 03:21:26 +0100, Alejandro Colomar wrote: > Hi Morten, > > On Sat, Mar 02, 2024 at 09:02:24PM -0500, Morten Welinder wrote: > > Thanks. > > > > There is (was?) already crlibm out there. > > https://core-math.gitlabpages.inria.fr/ No particular need for wheel > > reinvention here. > > crlibm doesn't seem to exist anymore. The sources are still available at more non-official mirror, but it is no longer maintained. > Maybe just add some headers to core-math, and package it as a > standalone library. The issue is that it is not portable yet. > > FWIW, it appears that the author of the glibc exp10 implementation > > agrees with me that the implementation is sub-standard: > > > > https://codebrowser.dev/glibc/glibc/math/e_exp10.c.html > > > > /* This is a very stupid and inprecise implementation. It'll get > > replaced sometime (soon?). */ > > return __ieee754_exp (M_LN10 * arg); > > Hmmm. Still, it's simple. If pow(10, x) is strictly better, maybe one > can prove it and send a patch. Or for something better, it'll take more > work. If by "strictly better", you mean that for each input, it returns a result that is at least as accurate as the one returned by the above expression, then, probably no. The reason is that the rounding errors in the above expression may partly compensate on a random basis. So, for some proportion of inputs, you'll actually get an accurate result. And unless pow is designed to be almost correctly rounded, it will probably be sometimes worse. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Man page issues: logb, significand, cbrt, log2, log10, exp10 2024-03-03 11:46 ` Vincent Lefevre @ 2024-03-03 12:21 ` Alejandro Colomar 2024-03-03 22:26 ` Morten Welinder 0 siblings, 1 reply; 32+ messages in thread From: Alejandro Colomar @ 2024-03-03 12:21 UTC (permalink / raw) To: Vincent Lefevre, Morten Welinder, linux-man, libc-alpha, jsm-csl, newbie-02 [-- Attachment #1: Type: text/plain, Size: 1977 bytes --] Hi Vincent, On Sun, Mar 03, 2024 at 12:46:00PM +0100, Vincent Lefevre wrote: > On 2024-03-03 03:21:26 +0100, Alejandro Colomar wrote: > > Maybe just add some headers to core-math, and package it as a > > standalone library. > > The issue is that it is not portable yet. Well, one could package it just to the systems to which it is portable, if that's useful. That's why a standalone library has more chances of being available soon than glibc. You'd need to make it portable (and other things) to put it in glibc; but if you say "here's libcore-math, avaiable only in XXX systems", you could get distros to distribute it already. And then provide headers that don't clash with glibc, such as <core-math/*.h> or whatever. > > > > FWIW, it appears that the author of the glibc exp10 implementation > > > agrees with me that the implementation is sub-standard: > > > > > > https://codebrowser.dev/glibc/glibc/math/e_exp10.c.html > > > > > > /* This is a very stupid and inprecise implementation. It'll get > > > replaced sometime (soon?). */ > > > return __ieee754_exp (M_LN10 * arg); > > > > Hmmm. Still, it's simple. If pow(10, x) is strictly better, maybe one > > can prove it and send a patch. Or for something better, it'll take more > > work. > > If by "strictly better", you mean that for each input, it returns a > result that is at least as accurate as the one returned by the above > expression, then, probably no. The reason is that the rounding errors > in the above expression may partly compensate on a random basis. So, > for some proportion of inputs, you'll actually get an accurate result. > And unless pow is designed to be almost correctly rounded, it will > probably be sometimes worse. Then glibc's current code is good, I guess. It's simple, and works for most programs. Have a lovely day! Alex -- <https://www.alejandro-colomar.es/> Looking for a remote C programming job at the moment. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Man page issues: logb, significand, cbrt, log2, log10, exp10 2024-03-03 12:21 ` Alejandro Colomar @ 2024-03-03 22:26 ` Morten Welinder 0 siblings, 0 replies; 32+ messages in thread From: Morten Welinder @ 2024-03-03 22:26 UTC (permalink / raw) To: Alejandro Colomar Cc: Vincent Lefevre, linux-man, libc-alpha, jsm-csl, newbie-02 Sorry to be a bit of a pain. Some testing says that the average error from exp10 is 300-500 times bigger than the average error from pow(10,.). This is consistent across a large range of arguments. The maximum error from pow(10,.) in the samples is 1ulp (relative to a reference rounded value, so the true error is likely less). The maximum error from exp10 in the samples is 2ulp. This is not surprising given that exp10 starts out by introducing a rounding error due to the multiplication before the call to exp. I didn't bother looking, but it is almost certainly true that there are arguments for which exp10 is better than pow(10,.). However, the numbers below imply that such arguments are very rare compared to the other way around. -------------------------- average ----- max Binade -7 exp10: 0.3378 1 Binade -7 pow(10,.): 0.0007 1 Binade -6 exp10: 0.3429 2 Binade -6 pow(10,.): 0.0007 1 Binade -5 exp10: 0.3532 2 Binade -5 pow(10,.): 0.0008 1 Binade -4 exp10: 0.3774 2 Binade -4 pow(10,.): 0.0008 1 Binade -3 exp10: 0.4402 2 Binade -3 pow(10,.): 0.0010 1 Binade -2 exp10: 0.4118 2 Binade -2 pow(10,.): 0.0009 1 Binade -1 exp10: 0.4228 2 Binade -1 pow(10,.): 0.0009 1 Binade 0 exp10: 0.4204 2 Binade 0 pow(10,.): 0.0009 1 Binade 1 exp10: 0.4221 2 Binade 1 pow(10,.): 0.0009 1 Binade 2 exp10: 0.4204 2 Binade 2 pow(10,.): 0.0009 1 Binade 3 exp10: 0.4222 2 Binade 3 pow(10,.): 0.0009 1 Binade 4 exp10: 0.4209 2 Binade 4 pow(10,.): 0.0009 1 Binade 5 exp10: 0.4200 2 Binade 5 pow(10,.): 0.0009 1 Binade 6 exp10: 0.4210 2 Binade 6 pow(10,.): 0.0009 1 Binade 7 exp10: 0.4210 2 Binade 7 pow(10,.): 0.0009 1 Notes: 1. Only positive arguments tested. 2. powl (long double version of pow) is used as a reference. I double-checked with a double-double version of pow (good to about 100ish bits) that this does not matter. #define _GNU_SOURCE 1 #include <stdio.h> #include <math.h> #include <stdint.h> static uint64_t murmur64 (uint64_t h) { h ^= h >> 33; h *= 0xff51afd7ed558ccdll; h ^= h >> 33; h *= 0xc4ceb9fe1a85ec53ll; h ^= h >> 33; return h; } static double exp10ref (double x) { volatile double y = (double)(powl (10.0l, x)); return y; } static double exp10viapow (double x) { return pow (10, x); } static void test_binade (int b, double (*f) (double), const char *funcname) { uint64_t h = 0x0123456701234567ll; double ulps = 0; double mulp = 0; int N = 1000000; for (int i = 0; i < N; i++) { h = murmur64 (h); double x = ldexp ((h & 0xfffffffffffffll) | 0x10000000000000ll, b - 52); double y = f (x); double yref = exp10ref (x); double dy = fabs (y - yref); double ulp = dy / (nextafter (yref, INFINITY) - yref); ulps += ulp; if (ulp > mulp) mulp = ulp; } printf ("Binade %2d %10s: %6.4f %10.0f\n", b, funcname, ulps / N, mulp); } int main () { for (int b = -7; b <= 7; b++) { test_binade (b, exp10, "exp10"); test_binade (b, exp10viapow, "pow(10,.)"); } return 0; } ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Man page issues: logb, significand, cbrt, log2, log10, exp10 2024-03-03 2:02 ` Morten Welinder 2024-03-03 2:21 ` Alejandro Colomar @ 2024-03-04 12:17 ` Adhemerval Zanella Netto 1 sibling, 0 replies; 32+ messages in thread From: Adhemerval Zanella Netto @ 2024-03-04 12:17 UTC (permalink / raw) To: Morten Welinder, Alejandro Colomar Cc: linux-man, libc-alpha, jsm-csl, newbie-02 On 02/03/24 23:02, Morten Welinder wrote: > Thanks. > > There is (was?) already crlibm out there. > https://core-math.gitlabpages.inria.fr/ No particular need for wheel > reinvention here. > > FWIW, it appears that the author of the glibc exp10 implementation > agrees with me that the implementation is sub-standard: > > https://codebrowser.dev/glibc/glibc/math/e_exp10.c.html This code was not used by any port and we recently removed to avoid this very issue [1]. The exp10 implementation used by all ports is at sysdeps/ieee754/dbl-64/e_exp10.c (i386/m68k are exceptions and my plan to eventually remove this implementation in favor the generic one [2]). And the exp10 implementation was recently improved [3], with the author suggesting the worst-case error in round-to- should be nearest to 0.513 ULP (I am not sure if he did some empirical testing to verify this value, at least with libm-test-ulps the resuts are bounded to 2 ulp max). > > /* This is a very stupid and inprecise implementation. It'll get > replaced sometime (soon?). */ > return __ieee754_exp (M_LN10 * arg); > > > Compare with musl: > > https://github.com/rofl0r/musl/blob/master/src/math/exp10.c > [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=9c61303ebbdc6e727c89591bff3229c9fbfa438b [2] https://sourceware.org/pipermail/libc-alpha/2024-January/154107.html [3] https://sourceware.org/git/?p=glibc.git;a=commit;h=63d0a35d5f223a3f4b68190567b7d4d44545bce5 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 0/3] manual/math.texi: logb(3) and cbrt(3) fixes [not found] <CANv4PNkVv_0eLgiSP3L_KfC-eZJaVLZ5AP1AGfD0GNrR5M4Hrg@mail.gmail.com> [not found] ` <ZeEnJB96mMC5bfBz@debian> @ 2024-03-05 16:12 ` Alejandro Colomar 2024-03-05 16:12 ` [PATCH v2 1/3] manual: logb(x) is floor(log2(fabs(x))) Alejandro Colomar ` (3 more replies) 1 sibling, 4 replies; 32+ messages in thread From: Alejandro Colomar @ 2024-03-05 16:12 UTC (permalink / raw) To: libc-alpha Cc: Alejandro Colomar, Morten Welinder, Vincent Lefevre, Adhemerval Zanella Netto [-- Attachment #1: Type: text/plain, Size: 517 bytes --] Hi, I've merged these patches into a single patch set. v2: - Remove spurious parenthesis. [Vincent] - Add patch 2/3, saying logb(x) isn't exactly the same as floor(log2(fabs(x))). [Vincent] Have a lovely day! Alex Alejandro Colomar (3): manual: logb(x) is floor(log2(fabs(x))) manual: floor(log2(fabs(x))) has rounding errors manual: Cube roots are rarely representable manual/math.texi | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) -- 2.43.0 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 1/3] manual: logb(x) is floor(log2(fabs(x))) 2024-03-05 16:12 ` [PATCH v2 0/3] manual/math.texi: logb(3) and cbrt(3) fixes Alejandro Colomar @ 2024-03-05 16:12 ` Alejandro Colomar 2024-03-29 22:08 ` DJ Delorie 2024-03-05 16:12 ` [PATCH v2 2/3] manual: floor(log2(fabs(x))) has rounding errors Alejandro Colomar ` (2 subsequent siblings) 3 siblings, 1 reply; 32+ messages in thread From: Alejandro Colomar @ 2024-03-05 16:12 UTC (permalink / raw) To: libc-alpha Cc: Alejandro Colomar, Morten Welinder, Vincent Lefevre, Adhemerval Zanella Netto [-- Attachment #1: Type: text/plain, Size: 1131 bytes --] log2(3) doesn't accept negative input, but it seems logb(3) does accept it. Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#u> Reported-by: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Vincent Lefevre <vincent@vinc17.net> Signed-off-by: Alejandro Colomar <alx@kernel.org> --- manual/math.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/math.texi b/manual/math.texi index 2f6ee253b9..c54eaebb65 100644 --- a/manual/math.texi +++ b/manual/math.texi @@ -561,7 +561,7 @@ These functions return the base-2 logarithm of @var{x}. @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} These functions extract the exponent of @var{x} and return it as a floating-point value. If @code{FLT_RADIX} is two, @code{logb} is equal -to @code{floor (log2 (x))}, except it's probably faster. +to @code{floor (log2 (fabs (x)))}, except it's probably faster. If @var{x} is de-normalized, @code{logb} returns the exponent @var{x} would have if it were normalized. If @var{x} is infinity (positive or -- 2.43.0 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 1/3] manual: logb(x) is floor(log2(fabs(x))) 2024-03-05 16:12 ` [PATCH v2 1/3] manual: logb(x) is floor(log2(fabs(x))) Alejandro Colomar @ 2024-03-29 22:08 ` DJ Delorie 2024-03-29 23:00 ` Alejandro Colomar 0 siblings, 1 reply; 32+ messages in thread From: DJ Delorie @ 2024-03-29 22:08 UTC (permalink / raw) To: Alejandro Colomar; +Cc: libc-alpha Alejandro Colomar <alx@kernel.org> writes: > -to @code{floor (log2 ( x ))}, except it's probably faster. > +to @code{floor (log2 (fabs (x)))}, except it's probably faster. Confirmed that the only change here is the addition of fabs() Confirmed that logb() accepts negative numbers LGTM Reviewed-by: DJ Delorie <dj@redhat.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 1/3] manual: logb(x) is floor(log2(fabs(x))) 2024-03-29 22:08 ` DJ Delorie @ 2024-03-29 23:00 ` Alejandro Colomar 0 siblings, 0 replies; 32+ messages in thread From: Alejandro Colomar @ 2024-03-29 23:00 UTC (permalink / raw) To: DJ Delorie; +Cc: libc-alpha [-- Attachment #1: Type: text/plain, Size: 520 bytes --] Hi DJ, On Fri, Mar 29, 2024 at 06:08:19PM -0400, DJ Delorie wrote: > Alejandro Colomar <alx@kernel.org> writes: > > -to @code{floor (log2 ( x ))}, except it's probably faster. > > +to @code{floor (log2 (fabs (x)))}, except it's probably faster. > > Confirmed that the only change here is the addition of fabs() > > Confirmed that logb() accepts negative numbers > > LGTM > Reviewed-by: DJ Delorie <dj@redhat.com> Thanks! Have a lovely night! Alex -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 2/3] manual: floor(log2(fabs(x))) has rounding errors 2024-03-05 16:12 ` [PATCH v2 0/3] manual/math.texi: logb(3) and cbrt(3) fixes Alejandro Colomar 2024-03-05 16:12 ` [PATCH v2 1/3] manual: logb(x) is floor(log2(fabs(x))) Alejandro Colomar @ 2024-03-05 16:12 ` Alejandro Colomar 2024-03-30 0:24 ` DJ Delorie 2024-03-05 16:12 ` [PATCH v2 3/3] manual: Cube roots are rarely representable Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 0/4] manual: arith.texi and math.texi fixes Alejandro Colomar 3 siblings, 1 reply; 32+ messages in thread From: Alejandro Colomar @ 2024-03-05 16:12 UTC (permalink / raw) To: libc-alpha Cc: Alejandro Colomar, Morten Welinder, Vincent Lefevre, Adhemerval Zanella Netto [-- Attachment #1: Type: text/plain, Size: 1364 bytes --] Link: <https://inbox.sourceware.org/libc-alpha/20240305150131.GD3653@qaa.vinc17.org/T/#m3ceecda630012995339bcc5448fee451cf277a8b> Reported-by: Vincent Lefevre <vincent@vinc17.net> Suggested-by: Vincent Lefevre <vincent@vinc17.net> Cc: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> --- manual/math.texi | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/manual/math.texi b/manual/math.texi index c54eaebb65..79bf3a1401 100644 --- a/manual/math.texi +++ b/manual/math.texi @@ -560,8 +560,11 @@ These functions return the base-2 logarithm of @var{x}. @standardsx{logbfNx, TS 18661-3:2015, math.h} @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} These functions extract the exponent of @var{x} and return it as a -floating-point value. If @code{FLT_RADIX} is two, @code{logb} is equal -to @code{floor (log2 (fabs (x)))}, except it's probably faster. +floating-point value. +If @code{FLT_RADIX} is two, +@code{logb (x)} is similar to @code{floor (log2 (fabs (x)))}, +except that the latter may give an incorrect integer +due to intermediate rounding. If @var{x} is de-normalized, @code{logb} returns the exponent @var{x} would have if it were normalized. If @var{x} is infinity (positive or -- 2.43.0 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 2/3] manual: floor(log2(fabs(x))) has rounding errors 2024-03-05 16:12 ` [PATCH v2 2/3] manual: floor(log2(fabs(x))) has rounding errors Alejandro Colomar @ 2024-03-30 0:24 ` DJ Delorie 2024-03-30 9:27 ` Alejandro Colomar 2024-03-30 9:47 ` Andreas Schwab 0 siblings, 2 replies; 32+ messages in thread From: DJ Delorie @ 2024-03-30 0:24 UTC (permalink / raw) To: Alejandro Colomar; +Cc: libc-alpha Alejandro Colomar <alx@kernel.org> writes: > -floating-point value. If @code{FLT_RADIX} is two, @code{logb} is equal > -to @code{floor (log2 (fabs (x)))}, except > -it's probably faster. > +floating-point value. If @code{FLT_RADIX} is two, @code{logb (x)} is similar > +to @code{floor (log2 (fabs (x)))}, except > +that the latter may give an incorrect integer due to intermediate rounding. So we're replacing "is equal to" with "is similar to", and replacing "it's probably faster" (understatement ;) with a note about correctness. I can't think of a different description that is both more correct and more succinct, nor do I think it's worth the effort to try to come up with such. LGTM. Reviewed-by: DJ Delorie <dj@redhat.com> Also, if you could avoid unnecessary reformating, that would help with reviews. Thanks! ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 2/3] manual: floor(log2(fabs(x))) has rounding errors 2024-03-30 0:24 ` DJ Delorie @ 2024-03-30 9:27 ` Alejandro Colomar 2024-03-30 9:30 ` Alejandro Colomar 2024-03-30 9:47 ` Andreas Schwab 1 sibling, 1 reply; 32+ messages in thread From: Alejandro Colomar @ 2024-03-30 9:27 UTC (permalink / raw) To: DJ Delorie; +Cc: Alejandro Colomar, libc-alpha [-- Attachment #1: Type: text/plain, Size: 6475 bytes --] Hi DJ, On Fri, Mar 29, 2024 at 08:24:48PM -0400, DJ Delorie wrote: > > Alejandro Colomar <alx@kernel.org> writes: > > > -floating-point value. If @code{FLT_RADIX} is two, @code{logb} is equal > > -to @code{floor (log2 (fabs (x)))}, except > > -it's probably faster. > > > +floating-point value. If @code{FLT_RADIX} is two, @code{logb (x)} is similar > > +to @code{floor (log2 (fabs (x)))}, except > > +that the latter may give an incorrect integer due to intermediate rounding. > > So we're replacing "is equal to" with "is similar to", and replacing > "it's probably faster" (understatement ;) with a note about correctness. > > I can't think of a different description that is both more correct and > more succinct, nor do I think it's worth the effort to try to come up > with such. > > LGTM. > Reviewed-by: DJ Delorie <dj@redhat.com> Thanks! > Also, if you could avoid unnecessary reformating, that would help with > reviews. Thanks! Actually, I believe it's the other way around. I did that because the patch was already horrible without reformatting, since breaking lines at the 80-col right margin makes for pretty much unreadable patches. I transformed the sentence to use semantic newlines, which will make subsequent editions of the sentence much easier to diff. Here's the original diff before I started breaking the lines at sensible points: diff --git a/manual/math.texi b/manual/math.texi index c54eaebb65..ecb77af94d 100644 --- a/manual/math.texi +++ b/manual/math.texi @@ -560,8 +560,9 @@ These functions return the base-2 logarithm of @var{x}. @standardsx{logbfNx, TS 18661-3:2015, math.h} @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} These functions extract the exponent of @var{x} and return it as a -floating-point value. If @code{FLT_RADIX} is two, @code{logb} is equal -to @code{floor (log2 (fabs (x)))}, except it's probably faster. +floating-point value. If @code{FLT_RADIX} is two, @code{logb (x)} is +similar to @code{floor (log2 (fabs (x)))}, except that the latter may +give an incorrect integer due to intermediate rounding. If @var{x} is de-normalized, @code{logb} returns the exponent @var{x} would have if it were normalized. If @var{x} is infinity (positive or To me, it doesn't look any better, since it also reflows the text, but at random points, instead of breaking at sensible points as I did. Here's a small description about semantic newlines that we provide in man-pages(7): $ MANWIDTH=64 man man-pages \ | sed -n '/Use semantic newlines/,/^$/p'; Use semantic newlines In the source of a manual page, new sentences should be started on new lines, long sentences should be split into lines at clause breaks (commas, semicolons, colons, and so on), and long clauses should be split at phrase bound‐ aries. This convention, sometimes known as "semantic newlines", makes it easier to see the effect of patches, which often operate at the level of individual sentences, clauses, or phrases. For more details, you may also find interesting the commit message of a recent-ish commit that I applied to that text, which contains a quote from Brian W. Kernighan, who also recommended that practice: commit 6ff6f43d68164f99a8c3fb66f4525d145571310c Author: Alejandro Colomar <alx.manpages@gmail.com> Date: Fri Nov 12 22:38:11 2021 +0100 man-pages.7: Add phrasal semantic newlines advise Brian W. Kernighan, 1974 [UNIX For Beginners]: [ Hints for Preparing Documents Most documents go through several versions (always more than you expected) before they are finally finished. Accordingly, you should do whatever possible to make the job of changing them easy. First, when you do the purely mechanical operations of typing, type so subsequent editing will be easy. Start each sentence on a new line. Make lines short, and break lines at natural places, such as after commas and semicolons, rather than randomly. Since most people change documents by rewriting phrases and adding, deleting and rearranging sentences, these precautions simplify any editing you have to do later. ] He mentioned phrases, and they are indeed commonly the operands of patches (see this patch's changes (the second part) as an example), so they make for a much better breaking point than random within a clause that is too long to fit a line. The downside is that they are more difficult to automatically spot than clause breaks (which tend to have associated punctuation). But we are humans writing patches, not machines, and therefore we should be able to decide and detect them better. Link: <https://rhodesmill.org/brandon/2012/one-sentence-per-line/> Cc: G. Branden Robinson <g.branden.robinson@gmail.com> Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com> diff --git a/man7/man-pages.7 b/man7/man-pages.7 index 23015b00a..b52a2260a 100644 --- a/man7/man-pages.7 +++ b/man7/man-pages.7 @@ -640,11 +640,13 @@ .SS Formatting conventions for manual pages describing functions .SS Use semantic newlines In the source of a manual page, new sentences should be started on new lines, -and long sentences should be split into lines at clause breaks -(commas, semicolons, colons, and so on). +long sentences should be split into lines at clause breaks +(commas, semicolons, colons, and so on), +and long clauses should be split at phrase boundaries. This convention, sometimes known as "semantic newlines", makes it easier to see the effect of patches, -which often operate at the level of individual sentences or sentence clauses. +which often operate at the level of +individual sentences, sentence clauses, or phrases. .\" .SS Formatting conventions (general) Paragraphs should be separated by suitable markers (usually either I would recommend using that practice in glibc, at least for new paragraphs (that is, I'm not saying you should reflow every line of current documentation), and also when existing paragraphs would need to be reflowed anyway due to a patch. Have a lovely day! Alex -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 2/3] manual: floor(log2(fabs(x))) has rounding errors 2024-03-30 9:27 ` Alejandro Colomar @ 2024-03-30 9:30 ` Alejandro Colomar 0 siblings, 0 replies; 32+ messages in thread From: Alejandro Colomar @ 2024-03-30 9:30 UTC (permalink / raw) To: DJ Delorie, libc-alpha [-- Attachment #1: Type: text/plain, Size: 6982 bytes --] Whoops; I replied from a wrong address. Please reply to <@kernel.org>. On Sat, Mar 30, 2024 at 10:27:19AM +0100, Alejandro Colomar wrote: > Hi DJ, > > On Fri, Mar 29, 2024 at 08:24:48PM -0400, DJ Delorie wrote: > > > > Alejandro Colomar <alx@kernel.org> writes: > > > > > -floating-point value. If @code{FLT_RADIX} is two, @code{logb} is equal > > > -to @code{floor (log2 (fabs (x)))}, except > > > -it's probably faster. > > > > > +floating-point value. If @code{FLT_RADIX} is two, @code{logb (x)} is similar > > > +to @code{floor (log2 (fabs (x)))}, except > > > +that the latter may give an incorrect integer due to intermediate rounding. > > > > So we're replacing "is equal to" with "is similar to", and replacing > > "it's probably faster" (understatement ;) with a note about correctness. > > > > I can't think of a different description that is both more correct and > > more succinct, nor do I think it's worth the effort to try to come up > > with such. > > > > LGTM. > > Reviewed-by: DJ Delorie <dj@redhat.com> > > Thanks! > > > Also, if you could avoid unnecessary reformating, that would help with > > reviews. Thanks! > > Actually, I believe it's the other way around. I did that because the > patch was already horrible without reformatting, since breaking lines at > the 80-col right margin makes for pretty much unreadable patches. > > I transformed the sentence to use semantic newlines, which will make > subsequent editions of the sentence much easier to diff. > > Here's the original diff before I started breaking the lines at sensible > points: > > diff --git a/manual/math.texi b/manual/math.texi > index c54eaebb65..ecb77af94d 100644 > --- a/manual/math.texi > +++ b/manual/math.texi > @@ -560,8 +560,9 @@ These functions return the base-2 logarithm of @var{x}. > @standardsx{logbfNx, TS 18661-3:2015, math.h} > @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} > These functions extract the exponent of @var{x} and return it as a > -floating-point value. If @code{FLT_RADIX} is two, @code{logb} is equal > -to @code{floor (log2 (fabs (x)))}, except it's probably faster. > +floating-point value. If @code{FLT_RADIX} is two, @code{logb (x)} is > +similar to @code{floor (log2 (fabs (x)))}, except that the latter may > +give an incorrect integer due to intermediate rounding. > > If @var{x} is de-normalized, @code{logb} returns the exponent @var{x} > would have if it were normalized. If @var{x} is infinity (positive or > > To me, it doesn't look any better, since it also reflows the text, but > at random points, instead of breaking at sensible points as I did. > > Here's a small description about semantic newlines that we provide in > man-pages(7): > > $ MANWIDTH=64 man man-pages \ > | sed -n '/Use semantic newlines/,/^$/p'; > Use semantic newlines > In the source of a manual page, new sentences should be > started on new lines, long sentences should be split into > lines at clause breaks (commas, semicolons, colons, and > so on), and long clauses should be split at phrase bound‐ > aries. This convention, sometimes known as "semantic > newlines", makes it easier to see the effect of patches, > which often operate at the level of individual sentences, > clauses, or phrases. > > For more details, you may also find interesting the commit message of a > recent-ish commit that I applied to that text, which contains a quote > from Brian W. Kernighan, who also recommended that practice: > > commit 6ff6f43d68164f99a8c3fb66f4525d145571310c > Author: Alejandro Colomar <alx.manpages@gmail.com> > Date: Fri Nov 12 22:38:11 2021 +0100 > > man-pages.7: Add phrasal semantic newlines advise > > Brian W. Kernighan, 1974 [UNIX For Beginners]: > > [ > Hints for Preparing Documents > > Most documents go through several versions > (always more than you expected) > before they are finally finished. > Accordingly, > you should do whatever possible > to make the job of changing them easy. > > First, > when you do the purely mechanical operations of typing, > type so subsequent editing will be easy. > Start each sentence on a new line. > Make lines short, > and break lines at natural places, > such as after commas and semicolons, > rather than randomly. > Since most people change documents > by rewriting phrases and > adding, deleting and rearranging sentences, > these precautions simplify any editing you have to do later. > ] > > He mentioned phrases, > and they are indeed commonly the operands of patches > (see this patch's changes (the second part) as an example), > so they make for a much better breaking point than random > within a clause that is too long to fit a line. > > The downside is that they are more difficult to automatically spot > than clause breaks (which tend to have associated punctuation). > But we are humans writing patches, > not machines, > and therefore we should be able to decide and detect them better. > > Link: <https://rhodesmill.org/brandon/2012/one-sentence-per-line/> > Cc: G. Branden Robinson <g.branden.robinson@gmail.com> > Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com> > > diff --git a/man7/man-pages.7 b/man7/man-pages.7 > index 23015b00a..b52a2260a 100644 > --- a/man7/man-pages.7 > +++ b/man7/man-pages.7 > @@ -640,11 +640,13 @@ .SS Formatting conventions for manual pages describing functions > .SS Use semantic newlines > In the source of a manual page, > new sentences should be started on new lines, > -and long sentences should be split into lines at clause breaks > -(commas, semicolons, colons, and so on). > +long sentences should be split into lines at clause breaks > +(commas, semicolons, colons, and so on), > +and long clauses should be split at phrase boundaries. > This convention, sometimes known as "semantic newlines", > makes it easier to see the effect of patches, > -which often operate at the level of individual sentences or sentence clauses. > +which often operate at the level of > +individual sentences, sentence clauses, or phrases. > .\" > .SS Formatting conventions (general) > Paragraphs should be separated by suitable markers (usually either > > I would recommend using that practice in glibc, at least for new > paragraphs (that is, I'm not saying you should reflow every line of > current documentation), and also when existing paragraphs would need to > be reflowed anyway due to a patch. > > Have a lovely day! > Alex > > -- > <https://www.alejandro-colomar.es/> -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 2/3] manual: floor(log2(fabs(x))) has rounding errors 2024-03-30 0:24 ` DJ Delorie 2024-03-30 9:27 ` Alejandro Colomar @ 2024-03-30 9:47 ` Andreas Schwab 1 sibling, 0 replies; 32+ messages in thread From: Andreas Schwab @ 2024-03-30 9:47 UTC (permalink / raw) To: DJ Delorie; +Cc: Alejandro Colomar, libc-alpha On Mär 29 2024, DJ Delorie wrote: > Also, if you could avoid unnecessary reformating, that would help with > reviews. Thanks! Try diff-mode or diff-minor-mode. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 3/3] manual: Cube roots are rarely representable 2024-03-05 16:12 ` [PATCH v2 0/3] manual/math.texi: logb(3) and cbrt(3) fixes Alejandro Colomar 2024-03-05 16:12 ` [PATCH v2 1/3] manual: logb(x) is floor(log2(fabs(x))) Alejandro Colomar 2024-03-05 16:12 ` [PATCH v2 2/3] manual: floor(log2(fabs(x))) has rounding errors Alejandro Colomar @ 2024-03-05 16:12 ` Alejandro Colomar 2024-03-30 0:27 ` DJ Delorie 2024-03-31 20:38 ` [PATCH v3 0/4] manual: arith.texi and math.texi fixes Alejandro Colomar 3 siblings, 1 reply; 32+ messages in thread From: Alejandro Colomar @ 2024-03-05 16:12 UTC (permalink / raw) To: libc-alpha Cc: Alejandro Colomar, Morten Welinder, Vincent Lefevre, Adhemerval Zanella Netto [-- Attachment #1: Type: text/plain, Size: 1257 bytes --] Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#mff0ab388000c6afdb5e5162804d4a0073de481de> Reported-by: Morten Welinder <mwelinder@gmail.com> Cowritten-by: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Vincent Lefevre <vincent@vinc17.net> Signed-off-by: Alejandro Colomar <alx@kernel.org> --- manual/math.texi | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/manual/math.texi b/manual/math.texi index 79bf3a1401..dfb685a71e 100644 --- a/manual/math.texi +++ b/manual/math.texi @@ -700,8 +700,12 @@ Mathematically, it should return a complex number. @standardsx{cbrtfN, TS 18661-3:2015, math.h} @standardsx{cbrtfNx, TS 18661-3:2015, math.h} @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} -These functions return the cube root of @var{x}. They cannot -fail; every representable real value has a representable real cube root. +These functions return the cube root of @var{x}. +They cannot fail; +every representable real value +has a real cube root, +and rounding it to a representable value +never causes overflow nor underflow. @end deftypefun @deftypefun double hypot (double @var{x}, double @var{y}) -- 2.43.0 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 3/3] manual: Cube roots are rarely representable 2024-03-05 16:12 ` [PATCH v2 3/3] manual: Cube roots are rarely representable Alejandro Colomar @ 2024-03-30 0:27 ` DJ Delorie 2024-03-30 7:07 ` Paul Zimmermann 0 siblings, 1 reply; 32+ messages in thread From: DJ Delorie @ 2024-03-30 0:27 UTC (permalink / raw) To: Alejandro Colomar; +Cc: libc-alpha Alejandro Colomar <alx@kernel.org> writes: > -These functions return the cube root of @var{x}. They cannot > -fail; every representable real value has a representable real cube root. > +These functions return the cube root of @var{x}. They cannot > +fail; every representable real value has a real cube root, > +and rounding it to a representable value > +never causes overflow nor underflow. Wording is OK but the $subject says the exact opposite... ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 3/3] manual: Cube roots are rarely representable 2024-03-30 0:27 ` DJ Delorie @ 2024-03-30 7:07 ` Paul Zimmermann 2024-03-30 16:51 ` DJ Delorie 0 siblings, 1 reply; 32+ messages in thread From: Paul Zimmermann @ 2024-03-30 7:07 UTC (permalink / raw) To: DJ Delorie; +Cc: alx, libc-alpha > From: DJ Delorie <dj@redhat.com> > Cc: libc-alpha@sourceware.org > Date: Fri, 29 Mar 2024 20:27:44 -0400 > > Alejandro Colomar <alx@kernel.org> writes: > > > -These functions return the cube root of @var{x}. They cannot > > -fail; every representable real value has a representable real cube root. > > > +These functions return the cube root of @var{x}. They cannot > > +fail; every representable real value has a real cube root, > > +and rounding it to a representable value > > +never causes overflow nor underflow. > > Wording is OK but the $subject says the exact opposite... It is fine to me. The subject says that the cube root of a floating-point number is rarely a floating-point number, which is true: for a p-bit format, only about 2^(p/3) numbers have an exact cube root. Paul ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 3/3] manual: Cube roots are rarely representable 2024-03-30 7:07 ` Paul Zimmermann @ 2024-03-30 16:51 ` DJ Delorie 2024-03-30 18:42 ` Alejandro Colomar 0 siblings, 1 reply; 32+ messages in thread From: DJ Delorie @ 2024-03-30 16:51 UTC (permalink / raw) To: Paul Zimmermann; +Cc: alx, libc-alpha Paul Zimmermann <Paul.Zimmermann@inria.fr> writes: >> From: DJ Delorie <dj@redhat.com> >> Cc: libc-alpha@sourceware.org >> Date: Fri, 29 Mar 2024 20:27:44 -0400 >> >> Alejandro Colomar <alx@kernel.org> writes: >> >> > -These functions return the cube root of @var{x}. They cannot >> > -fail; every representable real value has a representable real cube root. >> >> > +These functions return the cube root of @var{x}. They cannot >> > +fail; every representable real value has a real cube root, >> > +and rounding it to a representable value >> > +never causes overflow nor underflow. >> >> Wording is OK but the $subject says the exact opposite... > > It is fine to me. The subject says that the cube root of a floating-point > number is rarely a floating-point number, which is true: for a p-bit format, > only about 2^(p/3) numbers have an exact cube root. Let me rephrase: The $subject does not convey the intent of the patch. If the patch adds wording that "the result never errors" the subject should reflect that change, not some other aspect of the issue. Something like "Note why cube roots always give representable results." ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 3/3] manual: Cube roots are rarely representable 2024-03-30 16:51 ` DJ Delorie @ 2024-03-30 18:42 ` Alejandro Colomar 2024-03-30 18:50 ` DJ Delorie 0 siblings, 1 reply; 32+ messages in thread From: Alejandro Colomar @ 2024-03-30 18:42 UTC (permalink / raw) To: DJ Delorie; +Cc: Paul Zimmermann, libc-alpha [-- Attachment #1: Type: text/plain, Size: 3243 bytes --] Hi DJ, On Sat, Mar 30, 2024 at 12:51:35PM -0400, DJ Delorie wrote: > Paul Zimmermann <Paul.Zimmermann@inria.fr> writes: > >> From: DJ Delorie <dj@redhat.com> > >> Cc: libc-alpha@sourceware.org > >> Date: Fri, 29 Mar 2024 20:27:44 -0400 > >> > >> Alejandro Colomar <alx@kernel.org> writes: > >> > >> > -These functions return the cube root of @var{x}. They cannot > >> > -fail; every representable real value has a representable real cube root. > >> > >> > +These functions return the cube root of @var{x}. They cannot > >> > +fail; every representable real value has a real cube root, > >> > +and rounding it to a representable value > >> > +never causes overflow nor underflow. > >> > >> Wording is OK but the $subject says the exact opposite... > > > > It is fine to me. The subject says that the cube root of a floating-point > > number is rarely a floating-point number, which is true: for a p-bit format, > > only about 2^(p/3) numbers have an exact cube root. > > Let me rephrase: The $subject does not convey the intent of the patch. > If the patch adds wording that "the result never errors" the subject > should reflect that change, not some other aspect of the issue. > > Something like "Note why cube roots always give representable results." Hmmm. The rationale for the $subject was that the old text, which I'm removing, claimed that "every representable real value has a representable real cube root". I was confronting that claim with reality: cube roots are rarely representable, since they tend to be real numbers, which cannot be represented exactly. What you can do is approximate them to something that can be represented without failing. It's guaranteed that they won't overflow nor underflow, because a cube root is always closer to 1 in absolute value than the number it roots. If you can think of a better subject, please let me know. I have some comments on your suggested one ("Note why cube roots always give representable results"): - It's actually contrary to the intent of the commit, which is removing text that claims that cube roots are representable, which is false. - I admit my commit $subject didn't specify (nor imply) what the new text says. It only says what it does not say (what I'm removing). Also, if I read your intentions, not just your literal text, I think you wanted to say something like Note why cube roots are not always representable, but still these functions always succeed returning an approximation. While that text would not be lying mathematically: it doesn't claim that cube roots are representable while they aren't; it claims that I note _why_. I've explained why in this email: the root is closer to 1 (in absolute value) than the cube, and numbers closer to 1 (and in general, small integers) are the farthest from a float and double overflow or underflow (I won't give more details, as my knowledge of floating point numbers in C begins to end there :) ). But the commit doesn't actually introduce any text to clarify why that happens. It only notes _what_ happens. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 3/3] manual: Cube roots are rarely representable 2024-03-30 18:42 ` Alejandro Colomar @ 2024-03-30 18:50 ` DJ Delorie 2024-03-30 19:07 ` Alejandro Colomar 0 siblings, 1 reply; 32+ messages in thread From: DJ Delorie @ 2024-03-30 18:50 UTC (permalink / raw) To: Alejandro Colomar; +Cc: Paul.Zimmermann, libc-alpha Alejandro Colomar <alx@kernel.org> writes: > - It's actually contrary to the intent of the commit, which is removing > text that claims that cube roots are representable, which is false. I meant that the function's return value is always representable, i.e., doesn't overflow, underflow, or produce NaNs. I'm not trying to be mathematically pedantic here. I'm just suggesting that the patch subject should reflect the change, so that someone searching for it has something relevent to look for. Even something as trivial as "Cube roots: clarify return values" would be better. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 3/3] manual: Cube roots are rarely representable 2024-03-30 18:50 ` DJ Delorie @ 2024-03-30 19:07 ` Alejandro Colomar 0 siblings, 0 replies; 32+ messages in thread From: Alejandro Colomar @ 2024-03-30 19:07 UTC (permalink / raw) To: DJ Delorie; +Cc: Paul.Zimmermann, libc-alpha [-- Attachment #1: Type: text/plain, Size: 834 bytes --] On Sat, Mar 30, 2024 at 02:50:58PM -0400, DJ Delorie wrote: > Alejandro Colomar <alx@kernel.org> writes: > > - It's actually contrary to the intent of the commit, which is removing > > text that claims that cube roots are representable, which is false. > > I meant that the function's return value is always representable, i.e., > doesn't overflow, underflow, or produce NaNs. > > I'm not trying to be mathematically pedantic here. I'm just suggesting > that the patch subject should reflect the change, so that someone > searching for it has something relevent to look for. Even something as > trivial as "Cube roots: clarify return values" would be better. Hmmm. How about "manual: Clarify return value of cbrt(3)"? I'll send a revision of the patch set with it. -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 0/4] manual: arith.texi and math.texi fixes 2024-03-05 16:12 ` [PATCH v2 0/3] manual/math.texi: logb(3) and cbrt(3) fixes Alejandro Colomar ` (2 preceding siblings ...) 2024-03-05 16:12 ` [PATCH v2 3/3] manual: Cube roots are rarely representable Alejandro Colomar @ 2024-03-31 20:38 ` Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 1/4] manual: logb(x) is floor(log2(fabs(x))) Alejandro Colomar ` (3 more replies) 3 siblings, 4 replies; 32+ messages in thread From: Alejandro Colomar @ 2024-03-31 20:38 UTC (permalink / raw) To: libc-alpha Cc: Alejandro Colomar, Morten Welinder, Adhemerval Zanella Netto, Vincent Lefevre, DJ Delorie, Paul Zimmermann, Andreas Schwab [-- Attachment #1: Type: text/plain, Size: 2883 bytes --] Hi! This addresses DJ's request for a better subject for patch 3. I've also added a 4th patch, with another related fix. Have a lovely night! Alex Alejandro Colomar (4): manual: logb(x) is floor(log2(fabs(x))) manual: floor(log2(fabs(x))) has rounding errors manual: Clarify return value of cbrt(3) manual: significand() uses FLT_RADIX, not 2 manual/arith.texi | 2 +- manual/math.texi | 15 +++++++++++---- 2 files changed, 12 insertions(+), 5 deletions(-) Range-diff against v2: 1: 952e798140 ! 1: 7af080cd63 manual: logb(x) is floor(log2(fabs(x))) @@ Commit message Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#u> Reported-by: Morten Welinder <mwelinder@gmail.com> + Reviewed-by: DJ Delorie <dj@redhat.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Vincent Lefevre <vincent@vinc17.net> + Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> + Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> ## manual/math.texi ## 2: 126b03d160 ! 2: 3854c0ecf8 manual: floor(log2(fabs(x))) has rounding errors @@ Commit message Link: <https://inbox.sourceware.org/libc-alpha/20240305150131.GD3653@qaa.vinc17.org/T/#m3ceecda630012995339bcc5448fee451cf277a8b> Reported-by: Vincent Lefevre <vincent@vinc17.net> Suggested-by: Vincent Lefevre <vincent@vinc17.net> + Reviewed-by: DJ Delorie <dj@redhat.com> Cc: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> + Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> + Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> ## manual/math.texi ## 3: e93ae6c4b4 ! 3: 78bc5bd97b manual: Cube roots are rarely representable @@ Metadata Author: Alejandro Colomar <alx@kernel.org> ## Commit message ## - manual: Cube roots are rarely representable + manual: Clarify return value of cbrt(3) Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#mff0ab388000c6afdb5e5162804d4a0073de481de> Reported-by: Morten Welinder <mwelinder@gmail.com> Cowritten-by: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Vincent Lefevre <vincent@vinc17.net> + Cc: DJ Delorie <dj@redhat.com> + Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> + Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> ## manual/math.texi ## -: ---------- > 4: f9ac1eefe3 manual: significand() uses FLT_RADIX, not 2 -- 2.43.0 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 1/4] manual: logb(x) is floor(log2(fabs(x))) 2024-03-31 20:38 ` [PATCH v3 0/4] manual: arith.texi and math.texi fixes Alejandro Colomar @ 2024-03-31 20:38 ` Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 2/4] manual: floor(log2(fabs(x))) has rounding errors Alejandro Colomar ` (2 subsequent siblings) 3 siblings, 0 replies; 32+ messages in thread From: Alejandro Colomar @ 2024-03-31 20:38 UTC (permalink / raw) To: libc-alpha Cc: Alejandro Colomar, Morten Welinder, Adhemerval Zanella Netto, Vincent Lefevre, DJ Delorie, Paul Zimmermann, Andreas Schwab [-- Attachment #1: Type: text/plain, Size: 1264 bytes --] log2(3) doesn't accept negative input, but it seems logb(3) does accept it. Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#u> Reported-by: Morten Welinder <mwelinder@gmail.com> Reviewed-by: DJ Delorie <dj@redhat.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Vincent Lefevre <vincent@vinc17.net> Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> --- manual/math.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/math.texi b/manual/math.texi index 2f6ee253b9..c54eaebb65 100644 --- a/manual/math.texi +++ b/manual/math.texi @@ -561,7 +561,7 @@ These functions return the base-2 logarithm of @var{x}. @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} These functions extract the exponent of @var{x} and return it as a floating-point value. If @code{FLT_RADIX} is two, @code{logb} is equal -to @code{floor (log2 (x))}, except it's probably faster. +to @code{floor (log2 (fabs (x)))}, except it's probably faster. If @var{x} is de-normalized, @code{logb} returns the exponent @var{x} would have if it were normalized. If @var{x} is infinity (positive or -- 2.43.0 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 2/4] manual: floor(log2(fabs(x))) has rounding errors 2024-03-31 20:38 ` [PATCH v3 0/4] manual: arith.texi and math.texi fixes Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 1/4] manual: logb(x) is floor(log2(fabs(x))) Alejandro Colomar @ 2024-03-31 20:38 ` Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 3/4] manual: Clarify return value of cbrt(3) Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 4/4] manual: significand() uses FLT_RADIX, not 2 Alejandro Colomar 3 siblings, 0 replies; 32+ messages in thread From: Alejandro Colomar @ 2024-03-31 20:38 UTC (permalink / raw) To: libc-alpha Cc: Alejandro Colomar, Morten Welinder, Adhemerval Zanella Netto, Vincent Lefevre, DJ Delorie, Paul Zimmermann, Andreas Schwab [-- Attachment #1: Type: text/plain, Size: 1497 bytes --] Link: <https://inbox.sourceware.org/libc-alpha/20240305150131.GD3653@qaa.vinc17.org/T/#m3ceecda630012995339bcc5448fee451cf277a8b> Reported-by: Vincent Lefevre <vincent@vinc17.net> Suggested-by: Vincent Lefevre <vincent@vinc17.net> Reviewed-by: DJ Delorie <dj@redhat.com> Cc: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> --- manual/math.texi | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/manual/math.texi b/manual/math.texi index c54eaebb65..79bf3a1401 100644 --- a/manual/math.texi +++ b/manual/math.texi @@ -560,8 +560,11 @@ These functions return the base-2 logarithm of @var{x}. @standardsx{logbfNx, TS 18661-3:2015, math.h} @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} These functions extract the exponent of @var{x} and return it as a -floating-point value. If @code{FLT_RADIX} is two, @code{logb} is equal -to @code{floor (log2 (fabs (x)))}, except it's probably faster. +floating-point value. +If @code{FLT_RADIX} is two, +@code{logb (x)} is similar to @code{floor (log2 (fabs (x)))}, +except that the latter may give an incorrect integer +due to intermediate rounding. If @var{x} is de-normalized, @code{logb} returns the exponent @var{x} would have if it were normalized. If @var{x} is infinity (positive or -- 2.43.0 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 3/4] manual: Clarify return value of cbrt(3) 2024-03-31 20:38 ` [PATCH v3 0/4] manual: arith.texi and math.texi fixes Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 1/4] manual: logb(x) is floor(log2(fabs(x))) Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 2/4] manual: floor(log2(fabs(x))) has rounding errors Alejandro Colomar @ 2024-03-31 20:38 ` Alejandro Colomar 2024-04-01 18:57 ` DJ Delorie 2024-03-31 20:38 ` [PATCH v3 4/4] manual: significand() uses FLT_RADIX, not 2 Alejandro Colomar 3 siblings, 1 reply; 32+ messages in thread From: Alejandro Colomar @ 2024-03-31 20:38 UTC (permalink / raw) To: libc-alpha Cc: Alejandro Colomar, Morten Welinder, Adhemerval Zanella Netto, Vincent Lefevre, DJ Delorie, Paul Zimmermann, Andreas Schwab [-- Attachment #1: Type: text/plain, Size: 1381 bytes --] Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#mff0ab388000c6afdb5e5162804d4a0073de481de> Reported-by: Morten Welinder <mwelinder@gmail.com> Cowritten-by: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Vincent Lefevre <vincent@vinc17.net> Cc: DJ Delorie <dj@redhat.com> Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> --- manual/math.texi | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/manual/math.texi b/manual/math.texi index 79bf3a1401..dfb685a71e 100644 --- a/manual/math.texi +++ b/manual/math.texi @@ -700,8 +700,12 @@ Mathematically, it should return a complex number. @standardsx{cbrtfN, TS 18661-3:2015, math.h} @standardsx{cbrtfNx, TS 18661-3:2015, math.h} @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} -These functions return the cube root of @var{x}. They cannot -fail; every representable real value has a representable real cube root. +These functions return the cube root of @var{x}. +They cannot fail; +every representable real value +has a real cube root, +and rounding it to a representable value +never causes overflow nor underflow. @end deftypefun @deftypefun double hypot (double @var{x}, double @var{y}) -- 2.43.0 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 3/4] manual: Clarify return value of cbrt(3) 2024-03-31 20:38 ` [PATCH v3 3/4] manual: Clarify return value of cbrt(3) Alejandro Colomar @ 2024-04-01 18:57 ` DJ Delorie 0 siblings, 0 replies; 32+ messages in thread From: DJ Delorie @ 2024-04-01 18:57 UTC (permalink / raw) To: Alejandro Colomar; +Cc: libc-alpha LGTM Reviewed-by: DJ Delorie <dj@redhat.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 4/4] manual: significand() uses FLT_RADIX, not 2 2024-03-31 20:38 ` [PATCH v3 0/4] manual: arith.texi and math.texi fixes Alejandro Colomar ` (2 preceding siblings ...) 2024-03-31 20:38 ` [PATCH v3 3/4] manual: Clarify return value of cbrt(3) Alejandro Colomar @ 2024-03-31 20:38 ` Alejandro Colomar 2024-04-01 19:09 ` DJ Delorie 3 siblings, 1 reply; 32+ messages in thread From: Alejandro Colomar @ 2024-03-31 20:38 UTC (permalink / raw) To: libc-alpha Cc: Alejandro Colomar, Morten Welinder, Adhemerval Zanella Netto, Vincent Lefevre, DJ Delorie, Paul Zimmermann, Andreas Schwab [-- Attachment #1: Type: text/plain, Size: 1170 bytes --] It's implemented using scalb(), which uses FLT_RADIX, AFAIK. Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#mf21ab57e16b92eb6be6c7df79dc0eb43d4454056> Reported-by: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Vincent Lefevre <vincent@vinc17.net> Cc: DJ Delorie <dj@redhat.com> Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> --- manual/arith.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/arith.texi b/manual/arith.texi index 0742c08ac4..034d9d2ba5 100644 --- a/manual/arith.texi +++ b/manual/arith.texi @@ -1395,7 +1395,7 @@ The @code{scalb} function is the BSD name for @code{ldexp}. @standards{BSD, math.h} @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} @code{significand} returns the mantissa of @var{x} scaled to the range -@math{[1, 2)}. +@math{[1, @code{FLT_RADIX})}. It is equivalent to @w{@code{scalb (@var{x}, (double) -ilogb (@var{x}))}}. This function exists mainly for use in certain standardized tests -- 2.43.0 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 4/4] manual: significand() uses FLT_RADIX, not 2 2024-03-31 20:38 ` [PATCH v3 4/4] manual: significand() uses FLT_RADIX, not 2 Alejandro Colomar @ 2024-04-01 19:09 ` DJ Delorie 0 siblings, 0 replies; 32+ messages in thread From: DJ Delorie @ 2024-04-01 19:09 UTC (permalink / raw) To: Alejandro Colomar Cc: libc-alpha, alx, mwelinder, adhemerval.zanella, vincent, Paul.Zimmermann, schwab Alejandro Colomar <alx@kernel.org> writes: > -@math{[1, 2 )}. > +@math{[1, @code{FLT_RADIX})}. LGTM Reviewed-by: DJ Delorie <dj@redhat.com> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Man page issues: logb, significand, cbrt, log2, log10, exp10 @ 2024-03-04 15:29 Wilco Dijkstra 2024-03-05 8:14 ` Paul Zimmermann 0 siblings, 1 reply; 32+ messages in thread From: Wilco Dijkstra @ 2024-03-04 15:29 UTC (permalink / raw) To: mwelinder; +Cc: 'GNU C Library', Adhemerval Zanella Hi, > FWIW, it appears that the author of the glibc exp10 implementation > agrees with me that the implementation is sub-standard: As Adhemerval pointed out, that was not the implementation used in GLIBC. The version that was used, wasn't perfect, but still better than MUSL: > Compare with musl: > > https://github.com/rofl0r/musl/blob/master/src/math/exp10.c The worst case error of MUSL is 4.14 ULP vs 2.01 ULP of the old GLIBC exp10 [1]. And the new exp10 in GLIBC is 0.513 ULP [2]. As I pointed out in the PR, it would be reasonable for compilers to convert pow (10, x) into exp10 (x) when it is known there is a good implementation available - in GLIBC, exp10 is both faster and slightly more accurate than pow. Cheers, Wilco [1] https://members.loria.fr/PZimmermann/papers/glibc238-20230921.pdf [2] https://members.loria.fr/PZimmermann/papers/accuracy.pdf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Man page issues: logb, significand, cbrt, log2, log10, exp10 2024-03-04 15:29 Man page issues: logb, significand, cbrt, log2, log10, exp10 Wilco Dijkstra @ 2024-03-05 8:14 ` Paul Zimmermann 0 siblings, 0 replies; 32+ messages in thread From: Paul Zimmermann @ 2024-03-05 8:14 UTC (permalink / raw) To: Wilco Dijkstra; +Cc: mwelinder, libc-alpha, adhemerval.zanella Hi Wilco, > The worst case error of MUSL is 4.14 ULP vs 2.01 ULP of the old GLIBC exp10 [1]. > > And the new exp10 in GLIBC is 0.513 ULP [2]. yes the new exp10 is more accurate, nice work! > As I pointed out in the PR, it would be reasonable for compilers to convert > pow (10, x) into exp10 (x) when it is known there is a good implementation > available - in GLIBC, exp10 is both faster and slightly more accurate than pow. ok at compile time, but there should be a way to disable this optimization, for example if you want to compare pow(10,x) and exp10(x). (At run time such a conversion would slow down the critical path of pow.) Paul ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2024-04-01 19:09 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CANv4PNkVv_0eLgiSP3L_KfC-eZJaVLZ5AP1AGfD0GNrR5M4Hrg@mail.gmail.com> [not found] ` <ZeEnJB96mMC5bfBz@debian> [not found] ` <CANv4PNmMpiwfv5acr7U6VEVe7PE_AMTzkkpNoNN9jrtVzk_93Q@mail.gmail.com> 2024-03-02 21:54 ` Man page issues: logb, significand, cbrt, log2, log10, exp10 Alejandro Colomar 2024-03-03 2:02 ` Morten Welinder 2024-03-03 2:21 ` Alejandro Colomar 2024-03-03 11:46 ` Vincent Lefevre 2024-03-03 12:21 ` Alejandro Colomar 2024-03-03 22:26 ` Morten Welinder 2024-03-04 12:17 ` Adhemerval Zanella Netto 2024-03-05 16:12 ` [PATCH v2 0/3] manual/math.texi: logb(3) and cbrt(3) fixes Alejandro Colomar 2024-03-05 16:12 ` [PATCH v2 1/3] manual: logb(x) is floor(log2(fabs(x))) Alejandro Colomar 2024-03-29 22:08 ` DJ Delorie 2024-03-29 23:00 ` Alejandro Colomar 2024-03-05 16:12 ` [PATCH v2 2/3] manual: floor(log2(fabs(x))) has rounding errors Alejandro Colomar 2024-03-30 0:24 ` DJ Delorie 2024-03-30 9:27 ` Alejandro Colomar 2024-03-30 9:30 ` Alejandro Colomar 2024-03-30 9:47 ` Andreas Schwab 2024-03-05 16:12 ` [PATCH v2 3/3] manual: Cube roots are rarely representable Alejandro Colomar 2024-03-30 0:27 ` DJ Delorie 2024-03-30 7:07 ` Paul Zimmermann 2024-03-30 16:51 ` DJ Delorie 2024-03-30 18:42 ` Alejandro Colomar 2024-03-30 18:50 ` DJ Delorie 2024-03-30 19:07 ` Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 0/4] manual: arith.texi and math.texi fixes Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 1/4] manual: logb(x) is floor(log2(fabs(x))) Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 2/4] manual: floor(log2(fabs(x))) has rounding errors Alejandro Colomar 2024-03-31 20:38 ` [PATCH v3 3/4] manual: Clarify return value of cbrt(3) Alejandro Colomar 2024-04-01 18:57 ` DJ Delorie 2024-03-31 20:38 ` [PATCH v3 4/4] manual: significand() uses FLT_RADIX, not 2 Alejandro Colomar 2024-04-01 19:09 ` DJ Delorie 2024-03-04 15:29 Man page issues: logb, significand, cbrt, log2, log10, exp10 Wilco Dijkstra 2024-03-05 8:14 ` Paul Zimmermann
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).