Groups > comp.lang.c > #402418 > unrolled thread

official library of tiny functions lacking in c

Started by	fir <profesor.fir@gmail.com>
First post	2026-09-27 10:20 +0200
Last post	2026-09-28 00:02 +0200
Articles	20 on this page of 129 — 16 participants

Back to article view | Back to comp.lang.c

  official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-27 10:20 +0200
    Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-27 20:04 +0200
      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-27 21:38 +0100
        Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-27 23:16 +0200
          Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 00:53 +0100
            Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-28 04:31 +0200
            Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 10:25 +0200
              Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 11:45 +0100
                Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 13:56 +0200
                  Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 14:38 +0100
                    Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 16:12 +0200
                      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 16:52 +0100
                        Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 18:49 +0200
                          Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 20:26 +0100
                            Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 09:45 +0200
                              Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 12:54 +0100
                                Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 15:56 +0200
                                  Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 18:15 +0100
                                    Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 20:24 +0200
                                      Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 19:41 +0000
                                        Re: official library of tiny functions lacking in c cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-29 21:37 +0000
                                          Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 01:33 +0100
                                          Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 09:28 +0200
                                            Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 13:41 +0300
                                              Re: official library of tiny functions lacking in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 07:25 -0700
                                                Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-10-01 17:50 +0300
                                                  Re: official library of tiny functions lacking in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 09:37 -0700
                                      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 01:19 +0100
                                        Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 09:44 +0200
                              Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-29 16:01 +0200
                                Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-30 01:00 -0700
                                  Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 13:01 +0200
                                  Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 08:52 +0000
                            Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 01:56 +0000
                            Re: official library of tiny functions lacking in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 07:15 -0700
                          Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-29 09:28 +0200
                        Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 07:10 +0000
                      Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-28 15:30 -0700
                      Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-29 09:03 +0200
                        Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 11:11 +0100
                          Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 14:38 +0000
                          Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 07:02 +0200
                            Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 11:35 +0100
                              Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 14:14 +0200
                                Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 13:45 +0100
                                  Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 15:30 +0200
                                    Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 17:14 +0300
                                      Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 16:42 +0200
                                        Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 18:02 +0300
                                    Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 16:54 +0100
                                      Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 18:26 +0200
                                        Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 22:12 +0100
                                          Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-01 09:44 +0200
                                            Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-10-01 10:42 +0100
                                              Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-10-01 13:50 +0300
                                                Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-10-01 12:29 +0100
                                                  Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-02 09:35 +0200
                                                    Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-02 04:03 -0700
                                                      Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-02 13:50 +0200
                                                        Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-02 11:22 -0700
                                                          Re: official library of tiny functions lacking in c gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-02 18:33 +0000
                                                          Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-10-03 14:30 +0000
                                                            Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:37 -0700
                                              Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-01 13:29 +0200
                                            Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-10-01 14:46 +0000
                                            Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-01 15:37 -0700
                                              Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-02 08:57 +0200
                                                Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-02 00:37 -0700
                                Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 17:12 +0100
                        Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:09 +0300
                          Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 13:55 +0200
                          Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 14:31 +0200
                            Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 16:12 +0300
                              Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 19:33 +0200
                                Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-30 18:14 +0000
                          Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-01 08:34 -0400
                    Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 07:08 +0000
                      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 15:02 +0100
                        Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 14:43 +0000
                          Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 16:07 +0100
                        Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 22:58 +0000
                          Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 00:13 +0100
                            Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 07:13 +0000
                              Re: official library of tiny functions lacking in c Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-01 02:41 +0800
                            Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:15 +0300
                              Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:18 +0300
                                Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 13:24 +0100
                                  Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 14:45 +0200
                                  Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 15:56 +0300
                                  Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 22:31 +0000
                          Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:32 +0300
                  Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-28 17:22 +0200
                  Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-28 17:24 -0700
                    Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 09:54 +0200
                      Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-29 16:48 -0700
                Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-28 14:16 +0200
                Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-28 11:15 -0400
                  Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 16:40 +0100
                    Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-29 16:50 -0700
                Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 06:38 +0000
                  Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 14:36 +0100
                    Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 22:49 +0000
                      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 23:59 +0100
                        Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-29 16:51 -0700
                        Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 01:54 +0000
                    Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-29 22:09 -0400
                      Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 10:52 +0100
                        Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 12:38 +0200
                        Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 08:49 +0000
                        Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-01 08:48 -0400
      Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-28 06:45 +0000
        Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-28 12:42 +0200
          Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 00:58 +0000
            Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-29 03:02 +0200
              Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:16 +0000
                Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-29 14:20 +0200
                  Re: official library of tiny functions lacking in c Paul <nospam@needed.invalid> - 2026-09-29 12:39 -0400
                  Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 22:50 +0000
                    Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-30 02:57 +0200
                      Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:00 +0000
                        Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-30 10:08 +0200
                          Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-30 13:58 +0200
        Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 11:43 +0100
          Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 01:00 +0000
          Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 07:59 +0200
        Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-28 11:03 -0400
      Re: official library of tiny functions lacking in c NOTE fir <profesor.fir@gmail.com> - 2026-09-28 17:50 +0200
      Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-30 12:42 -0700
    Re: official library of tiny functions lacking in c tTh <tth@none.invalid> - 2026-09-28 00:02 +0200

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →

#402520

From	Lawrence D’Oliveiro <ldo@nz.invalid>
Date	2026-09-29 22:58 +0000
Message-ID	<119hfr3$3nmbu$4@dont-email.me>
In reply to	#402508

On Tue, 29 Sep 2026 15:02:43 +0100, bart wrote:

> On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:
>>
>> So the library routine is still capable of producing meaningful
>> results, while the naïve implementation still breaks down.
>>
>> Any more nitpicks?
>
> Yes: you're being incredibly pedantic and picky for no reason other
> than to be argumentative and superior.

You’re the one failing to appreciate the point, that it takes smarts
to design proper numeric algorithms that work within the practical
*efficient* limits of computer arithmetic.

> These big numbers are ridiculous. If you want to play this game,
> then I've just got my bignum library ...

So those numbers are “ridiculous”, yet your only way to counter
them is to be more “ridiculous”?

Remember, the GNU C routine is capable of giving meaningful results
over the entire representable range of the real type, without having
to take the lazy (and slow) way out of resorting to
higher-precision/magnitude arithmetic.

> So tell me again what is the upper limit when using hypotl()?

All the way out to the edge, kiddo. All the way out to the edge.

    #include <math.h>
    #include <values.h>
    #include <stdio.h>

    static long double len2(long double x,long double y) {  return sqrtl(x*x+y*y);}

    static void compare_for
      (
        long double x
      )
      {
        fprintf
          (
            stdout,
            "for %.7Le: len2 = %.7Le, hypot = %.7Le\n",
            x, len2(x, x), hypotl(x, x)
          );
      } /*compare_for*/

    int main(void)
      {
        fprintf(stdout, "max float value = %.7Le\n", LDBL_MAX);
        compare_for(LDBL_MAX / 1.415);
        compare_for(1.415 / LDBL_MAX);
        return
            0;
      } /*main*/

→

    ./naive_hypot_long_double_2
    max float value = 1.1897315e+4932
    for 8.4079964e+4931: len2 = inf, hypot = 1.1890703e+4932
    for 1.1893440e-4932: len2 = 0.0000000e+00, hypot = 1.6819864e-4932

[toc] | [prev] | [next] | [standalone]

#402522

From	bart <bc@freeuk.com>
Date	2026-09-30 00:13 +0100
Message-ID	<119hgmj$3o8kb$1@dont-email.me>
In reply to	#402520

On 29/09/2026 23:58, Lawrence D’Oliveiro wrote:
> On Tue, 29 Sep 2026 15:02:43 +0100, bart wrote:
> 
>> On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:
>>>
>>> So the library routine is still capable of producing meaningful
>>> results, while the naïve implementation still breaks down.
>>>
>>> Any more nitpicks?
>>
>> Yes: you're being incredibly pedantic and picky for no reason other
>> than to be argumentative and superior.
> 
> You’re the one failing to appreciate the point, that it takes smarts
> to design proper numeric algorithms that work within the practical
> *efficient* limits of computer arithmetic.

OK, so give me a 'smart' square(x) routine where x can go all the way to 
the MAX value.

>> These big numbers are ridiculous. If you want to play this game,
>> then I've just got my bignum library ...
> 
> So those numbers are “ridiculous”, yet your only way to counter
> them is to be more “ridiculous”?

Yes; they're all ridiculous. You're criticising some line-length routine 
because it goes wrong when deltas reach 10**19 (f32), or some 10**153 
(f64) or 10**4000 or whatever (f80).

Mine I think will go wrong at 10**5000000000000000000 or something.

But IT DOESN'T MATTER.

You're also looking at this wrong way: the author of len2() (ie. the 
'naive' version) wrote it with his applications in mind, where its spec 
was perfectly adequate for the job.

The API list was a suggestion for some functions to be standardised, 
rather than be actual official implementations.

As the author of a library function, you don't know to what applications 
it will be used for, so you don't make assumptions.

Also you're not going to get paid much for one line of code so you might 
as well go to town.

[toc] | [prev] | [next] | [standalone]

#402540

From	Lawrence D’Oliveiro <ldo@nz.invalid>
Date	2026-09-30 07:13 +0000
Message-ID	<119icqv$5tm$1@dont-email.me>
In reply to	#402522

On Wed, 30 Sep 2026 00:13:23 +0100, bart wrote:

> On 29/09/2026 23:58, Lawrence D’Oliveiro wrote:
>>
>> On Tue, 29 Sep 2026 15:02:43 +0100, bart wrote:
>>
>>> On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:
>>>>
>>>> So the library routine is still capable of producing meaningful
>>>> results, while the naïve implementation still breaks down.
>>>>
>>>> Any more nitpicks?
>>>
>>> Yes: you're being incredibly pedantic and picky for no reason
>>> other than to be argumentative and superior.
>>
>> You’re the one failing to appreciate the point, that it takes
>> smarts to design proper numeric algorithms that work within the
>> practical *efficient* limits of computer arithmetic.
>
> OK, so give me a 'smart' square(x) routine where x can go all the
> way to the MAX value.

Maybe you need to read that paragraph again.

>>> These big numbers are ridiculous. If you want to play this game,
>>> then I've just got my bignum library ...
>>
>> So those numbers are “ridiculous”, yet your only way to counter
>> them is to be more “ridiculous”?
>
> Yes; they're all ridiculous. You're criticising some line-length
> routine because it goes wrong when deltas reach 10**19 (f32), or
> some 10**153 (f64) or 10**4000 or whatever (f80).

This is why we have floating-point numbers: so that we can have a
large dynamic range to cope with things like real physical data.
What’s the point of having that range if you can’t use most or all of
it? If, in fact, you can only use a small fraction, but you can’t
actually be sure what fraction that might be, because it’s not obvious
from the function?

> Mine I think will go wrong at 10**5000000000000000000 or something.
>
> But IT DOESN'T MATTER.

Yes it does. You forget that, before the widespread adoption of
IEEE-754, floating-point was a subject ridden with black-magic voodoo
spells that programmers had to adopt to try to minimize the chance of
surprising results on particular machine architectures.

It took decades for all those quirks to go extinct. Nobody wants them
back. It seems to be like vaccines: people have forgotten that, if you
take away the only thing keeping the disease out, you will go back to
the Bad Old Days of widespread pain and suffering.

> You're also looking at this wrong way: the author of len2() (ie. the
> 'naive' version) wrote it with his applications in mind, where its
> spec was perfectly adequate for the job.

I doubt that particular author had any kind of actual “application” in
mind. If they did, they would have found it simpler to just use the
existing function, instead of writing their own.

> As the author of a library function, you don't know to what applications
> it will be used for, so you don't make assumptions.

Precisely the point. That includes making assumptions that the user
will know that, even though the argument and expected result are both
within the representable range, some wayward intermediate result will
cause the whole calculation to blow up and produce a meaningless
result. When such a misfeature was totally avoidable.

> Also you're not going to get paid much for one line of code so you
> might as well go to town.

Or, you know, you could avoid wasting everybody’s time, shut up, and
use the existing wonderful library of readily available,
well-documented, standards-compliant open-source routines that already
do the job so well.

[toc] | [prev] | [next] | [standalone]

#402584

From	Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>
Date	2026-10-01 02:41 +0800
Message-ID	<kJcvS.156$%%Oe.58@fx18.ams4>
In reply to	#402540

On 9/30/2026 3:13 PM, Lawrence D’Oliveiro wrote:
> Or, you know, you could avoid wasting everybody’s time, shut up, and
> use the existing wonderful library of readily available,
> well-documented, standards-compliant open-source routines that already
> do the job so well.

Dear Lawrence,

Since you know so much, do you care to enlighten us about the available
literature for people who wish to implement their own -- open source or
not -- wonderful libraries of basic functions?  I mean, I have /Hacker's
Delight/ by Warren on my shelf, but it can't be the only book dedicated
to /readily available well documented standards compliant routines/.

You know as well as I do, that it's all the rage to implement new C lib-
raries these days, and some are probably being written in Rust as we
speak.

So what do you say?  Do you have other books to recommend budding C lib-
rary authors?
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#402552

From	Michael S <already5chosen@yahoo.com>
Date	2026-09-30 14:15 +0300
Message-ID	<20260930141545.00006dda@yahoo.com>
In reply to	#402522

On Wed, 30 Sep 2026 00:13:23 +0100
bart <bc@freeuk.com> wrote:

> On 29/09/2026 23:58, Lawrence D’Oliveiro wrote:
> > On Tue, 29 Sep 2026 15:02:43 +0100, bart wrote:
> >   
> >> On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:  
> >>>
> >>> So the library routine is still capable of producing meaningful
> >>> results, while the naïve implementation still breaks down.
> >>>
> >>> Any more nitpicks?  
> >>
> >> Yes: you're being incredibly pedantic and picky for no reason other
> >> than to be argumentative and superior.  
> > 
> > You’re the one failing to appreciate the point, that it takes smarts
> > to design proper numeric algorithms that work within the practical
> > *efficient* limits of computer arithmetic.  
> 
> OK, so give me a 'smart' square(x) routine where x can go all the way
> to the MAX value.
> 

Come on. You are certainly good enough programmer to figure it out
yourself. It should not take more than few minutes.

If you want hint, it is in the followup.

[toc] | [prev] | [next] | [standalone]

#402553

From	Michael S <already5chosen@yahoo.com>
Date	2026-09-30 14:18 +0300
Message-ID	<20260930141835.000007ce@yahoo.com>
In reply to	#402552

On Wed, 30 Sep 2026 14:15:45 +0300
Michael S <already5chosen@yahoo.com> wrote:

> On Wed, 30 Sep 2026 00:13:23 +0100
> bart <bc@freeuk.com> wrote:
> 
> > On 29/09/2026 23:58, Lawrence D’Oliveiro wrote:  
> > > On Tue, 29 Sep 2026 15:02:43 +0100, bart wrote:
> > >     
> > >> On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:    
> > >>>
> > >>> So the library routine is still capable of producing meaningful
> > >>> results, while the naïve implementation still breaks down.
> > >>>
> > >>> Any more nitpicks?    
> > >>
> > >> Yes: you're being incredibly pedantic and picky for no reason
> > >> other than to be argumentative and superior.    
> > > 
> > > You’re the one failing to appreciate the point, that it takes
> > > smarts to design proper numeric algorithms that work within the
> > > practical *efficient* limits of computer arithmetic.    
> > 
> > OK, so give me a 'smart' square(x) routine where x can go all the
> > way to the MAX value.
> >   
> 
> Come on. You are certainly good enough programmer to figure it out
> yourself. It should not take more than few minutes.
> 
> If you want hint, it is in the followup.
> 

frexp

[toc] | [prev] | [next] | [standalone]

#402560

From	bart <bc@freeuk.com>
Date	2026-09-30 13:24 +0100
Message-ID	<119iv2e$7clk$1@dont-email.me>
In reply to	#402553

On 30/09/2026 12:18, Michael S wrote:
> On Wed, 30 Sep 2026 14:15:45 +0300
> Michael S <already5chosen@yahoo.com> wrote:
> 
>> On Wed, 30 Sep 2026 00:13:23 +0100
>> bart <bc@freeuk.com> wrote:
>>
>>> On 29/09/2026 23:58, Lawrence D’Oliveiro wrote:
>>>> On Tue, 29 Sep 2026 15:02:43 +0100, bart wrote:
>>>>      
>>>>> On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:
>>>>>>
>>>>>> So the library routine is still capable of producing meaningful
>>>>>> results, while the naïve implementation still breaks down.
>>>>>>
>>>>>> Any more nitpicks?
>>>>>
>>>>> Yes: you're being incredibly pedantic and picky for no reason
>>>>> other than to be argumentative and superior.
>>>>
>>>> You’re the one failing to appreciate the point, that it takes
>>>> smarts to design proper numeric algorithms that work within the
>>>> practical *efficient* limits of computer arithmetic.
>>>
>>> OK, so give me a 'smart' square(x) routine where x can go all the
>>> way to the MAX value.
>>>    
>>
>> Come on. You are certainly good enough programmer to figure it out
>> yourself. It should not take more than few minutes.
>>
>> If you want hint, it is in the followup.
>>
> 
> frexp
> 

I don't see how that helps. My made-up square function has a signature 
like (T)->T, and T will have a particular T.MAX value.

So, what is the maximum input that can yield a result that can still be 
represented within a type T? Presumably it is +/- sqrt(T.MAX).

The broader point is that pretty much any arithmetic involving floats 
can overflow the range if the magnitudes are large enough (or small 
enough with divide etc).

You can still work with this, since the ranges of f32 and especially f64 
are generous enough. (And if using the x87 FPU, intermediates use f80.)

In the very, very specific case of hypot, then being able to work with 
as large a range as possible via clever tricks is great, but there is no 
great practical need.

Certainly not enough to dismiss the 'naive' solution out of hand, 
especially if it is faster.

I stated elsewhere that I often worked with 'x*x + y*y' without 
bothering with the square root, so here that cleverness won't help.

[toc] | [prev] | [next] | [standalone]

#402562

From	Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Date	2026-09-30 14:45 +0200
Message-ID	<119j08k$3quji$4@dont-email.me>
In reply to	#402560

On 2026-09-30 14:24, bart wrote:
> 
> I stated elsewhere that I often worked with 'x*x + y*y' without 
> bothering with the square root, so here that cleverness won't help.

Sure. Another function, another conditions. - Shifted goalpost from
hypot() to something else.

Janis

[toc] | [prev] | [next] | [standalone]

#402564

From	Michael S <already5chosen@yahoo.com>
Date	2026-09-30 15:56 +0300
Message-ID	<20260930155605.00003dab@yahoo.com>
In reply to	#402560

On Wed, 30 Sep 2026 13:24:47 +0100
bart <bc@freeuk.com> wrote:

> On 30/09/2026 12:18, Michael S wrote:
> > On Wed, 30 Sep 2026 14:15:45 +0300
> > Michael S <already5chosen@yahoo.com> wrote:
> >   
> >> On Wed, 30 Sep 2026 00:13:23 +0100
> >> bart <bc@freeuk.com> wrote:
> >>  
> >>> On 29/09/2026 23:58, Lawrence D’Oliveiro wrote:  
> >>>> On Tue, 29 Sep 2026 15:02:43 +0100, bart wrote:
> >>>>        
> >>>>> On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:  
> >>>>>>
> >>>>>> So the library routine is still capable of producing meaningful
> >>>>>> results, while the naïve implementation still breaks down.
> >>>>>>
> >>>>>> Any more nitpicks?  
> >>>>>
> >>>>> Yes: you're being incredibly pedantic and picky for no reason
> >>>>> other than to be argumentative and superior.  
> >>>>
> >>>> You’re the one failing to appreciate the point, that it takes
> >>>> smarts to design proper numeric algorithms that work within the
> >>>> practical *efficient* limits of computer arithmetic.  
> >>>
> >>> OK, so give me a 'smart' square(x) routine where x can go all the
> >>> way to the MAX value.
> >>>      
> >>
> >> Come on. You are certainly good enough programmer to figure it out
> >> yourself. It should not take more than few minutes.
> >>
> >> If you want hint, it is in the followup.
> >>  
> > 
> > frexp
> >   
> 
> I don't see how that helps.

I don't see exactly what it is that you don't see. Remember: we are
talking about a specific thing — the `hypot()` function. Try to resist
the urge to confuse us with unnecessary generalizations.

> My made-up square function has a
> signature like (T)->T, and T will have a particular T.MAX value.
> 
> So, what is the maximum input that can yield a result that can still
> be represented within a type T? Presumably it is +/- sqrt(T.MAX).
> 
> The broader point is that pretty much any arithmetic involving floats 
> can overflow the range if the magnitudes are large enough (or small 
> enough with divide etc).
> 

The narrower point is that for some of *standard* library functions
covering range as close as possible to mathematically meaningful input
range is a requirement.
In specific case of hypot() + C Standard there are no strict
requirements like those. However some other Standards, e.g. POSIX, are
more strict, although still not quite as strict as my above formulation.

> You can still work with this, since the ranges of f32 and especially
> f64 are generous enough. (And if using the x87 FPU, intermediates use
> f80.)
> 
> In the very, very specific case of hypot, then being able to work
> with as large a range as possible via clever tricks is great, but
> there is no great practical need.
> 
> Certainly not enough to dismiss the 'naive' solution out of hand, 
> especially if it is faster.
> 
> 
> I stated elsewhere that I often worked with 'x*x + y*y' without 
> bothering with the square root, so here that cleverness won't help.

It can help even here but in less obvious ways.

[toc] | [prev] | [next] | [standalone]

#402592

From	Lawrence D’Oliveiro <ldo@nz.invalid>
Date	2026-09-30 22:31 +0000
Message-ID	<119k2km$la7j$2@dont-email.me>
In reply to	#402560

On Wed, 30 Sep 2026 13:24:47 +0100, bart wrote:

> The broader point is that pretty much any arithmetic involving
> floats can overflow the range if the magnitudes are large enough (or
> small enough with divide etc).

The broader, broader point is that if the overflow or underflow occurs
in intermediate values inside the function that the caller never sees,
rather than in the final result, that just adds to the mystery and
frustration that the caller suffers while trying to debug their
program.

It may not always be possible to avoid this completely, but there are
often ways to rework the algorithm to minimize their impact. Doing
this is worthwhile if it increases the usefulness of the numerics
library.

Which is something that experts in numerics make something of a
specialty.

[toc] | [prev] | [next] | [standalone]

#402554

From	Michael S <already5chosen@yahoo.com>
Date	2026-09-30 14:32 +0300
Message-ID	<20260930143223.000057b8@yahoo.com>
In reply to	#402520

On Tue, 29 Sep 2026 22:58:43 -0000 (UTC)
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:

> On Tue, 29 Sep 2026 15:02:43 +0100, bart wrote:
> 
> > On 29/09/2026 08:08, Lawrence D’Oliveiro wrote:  
> >>
> >> So the library routine is still capable of producing meaningful
> >> results, while the naïve implementation still breaks down.
> >>
> >> Any more nitpicks?  
> >
> > Yes: you're being incredibly pedantic and picky for no reason other
> > than to be argumentative and superior.  
> 
> You’re the one failing to appreciate the point, that it takes smarts
> to design proper numeric algorithms that work within the practical
> *efficient* limits of computer arithmetic.
> 
> > These big numbers are ridiculous. If you want to play this game,
> > then I've just got my bignum library ...  
> 
> So those numbers are “ridiculous”, yet your only way to counter
> them is to be more “ridiculous”?
> 
> Remember, the GNU C routine is capable of giving meaningful results
> over the entire representable range of the real type, without having
> to take the lazy (and slow) way out of resorting to
> higher-precision/magnitude arithmetic.

Pay attention that GNU C is a compiler + comiler support library
(libgcc).
hyport() is part of Standard C library, which is not a part of either.
Some of C Libraries used with GCC can do what you calaim. Others can be
less great at covering full range. Yet others can cover full range by
means of using higher preccision or magnitude. On some platforms,
including some which are popular, the latter could be even a good
idea.

[toc] | [prev] | [next] | [standalone]

#402463

From	fir <profesor.fir@gmail.com>
Date	2026-09-28 17:22 +0200
Message-ID	<119e0ng$2f3bo$1@dont-email.me>
In reply to	#402450

David Brown pisze:
> 
> But Fir could well have included other functions that are not likely to 
> make sense in a standard library for a general-purpose programming 
> language - and to have omitted many that should be there.

those ones for sure have sense in very general library - i use them a lot

float dist2_square(float x1,float y1,float x2,float y2) {   float 
x=x2-x1,y=y2-y1;     return x*x+y*y; }
float dist2(float x1,float y1,float x2,float y2) {    return 
sqrtf(dist2(x1,y1,x2,y2));}
float len2_square(float x,float y) {    return x*x+y*y; }
float len2(float x,float y) {  return sqrtf(x*x+y*y);}
float dot2(float ax,float ay,float bx,float by){   return ax*bx+ay*by;}
float cross2(float ax,float ay,float bx,float by){    return ax*by-ay*bx;}
void  norm2(float *x,float *y) {  float d=sqrtf(*x**x+*y**y);   if(d>0) 
{ *x/=d;  *y/=d; }}
float dist2_to_line(float px,float py,float ax,float ay,float bx,float 
by){    return fabsf(cross2(bx-ax,by-ay,px-ax,py-ay)) 
/sqrtf(dist2_square(ax,ay,bx,by));}


the question i stated is not it if have sense or ot but just to agree 
for names

for example those names above are quite random and people i gues state 
random names her and there is needed of agreement on those "official"
ones

puting their implementation in  c-lib  is one way of doing that but 
there are other ways for example produce a paper with offiical 
recomandations for names of those,

[toc] | [prev] | [next] | [standalone]

#402479

From	Keith Thompson <Keith.S.Thompson+u@gmail.com>
Date	2026-09-28 17:24 -0700
Message-ID	<119f0g6$2r55g$1@kst.eternal-september.org>
In reply to	#402450

David Brown <david.brown@hesbynett.no> writes:
[...]
> It is not a one-line function.  Did you fail to read that bit of my
> post?  My guess is that it was added to C (I have no idea when)

hypot(), hypotf(), and hypotl() were added in C99, along with the
type-generic macro hypot() in <tgmath.h>.

[...]

> A C11 implementation might be :
>
> #define sin(x) \
> 	_Generic((x), \
> 		float : sinf, \
> 		double : sin, \
> 		long double : sinl, \
> 		float complex : csinf, \
> 		double complex : csin, \
> 		long double complex : csinl \
> 	)(x)

That wouldn't be conforming.  The sin() macro with an argument of an
integer type has to work, converting the argument to double.

Handling that correctly and emitting sensible error messages for things
like sin("foo") is difficult if the implementation uses _Generic,
which is why some implementations use compiler "magic".

(tcc uses _Generic for this -- and it appears to have a bug whereby
sin("foo") is not diagnosed and  produces a garbage result).

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#402498

From	David Brown <david.brown@hesbynett.no>
Date	2026-09-29 09:54 +0200
Message-ID	<119fqrm$31nv1$2@dont-email.me>
In reply to	#402479

On 29/09/2026 02:24, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> It is not a one-line function.  Did you fail to read that bit of my
>> post?  My guess is that it was added to C (I have no idea when)
> 
> hypot(), hypotf(), and hypotl() were added in C99, along with the
> type-generic macro hypot() in <tgmath.h>.
> 
> [...]
> 
>> A C11 implementation might be :
>>
>> #define sin(x) \
>> 	_Generic((x), \
>> 		float : sinf, \
>> 		double : sin, \
>> 		long double : sinl, \
>> 		float complex : csinf, \
>> 		double complex : csin, \
>> 		long double complex : csinl \
>> 	)(x)
> 
> That wouldn't be conforming.  The sin() macro with an argument of an
> integer type has to work, converting the argument to double.

I was simplifying somewhat, but you are right about the details.  Real 
standard library implementations require more thought!  As a first step, 
it should have a clause :

		default : sin \

That will handle types that can be converted to double, but reject 
sin("foo").  I don't know if that would be enough, however - I have not 
tried to check everything.

> 
> Handling that correctly and emitting sensible error messages for things
> like sin("foo") is difficult if the implementation uses _Generic,
> which is why some implementations use compiler "magic".

Compiler magic can certainly lead to nicer error messages.

> 
> (tcc uses _Generic for this -- and it appears to have a bug whereby
> sin("foo") is not diagnosed and  produces a garbage result).
> 
> [...]
>

[toc] | [prev] | [next] | [standalone]

#402524

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2026-09-29 16:48 -0700
Message-ID	<119hiof$3oib4$3@dont-email.me>
In reply to	#402498

On 9/29/2026 12:54 AM, David Brown wrote:
[...]

sin("foo"). Hopefully the compiler can say at least wtf? Are you sure?

[toc] | [prev] | [next] | [standalone]

#402454

From	Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Date	2026-09-28 14:16 +0200
Message-ID	<119dlq3$1uucd$2@dont-email.me>
In reply to	#402448

On 2026-09-28 12:45, bart wrote:
> On 28/09/2026 09:25, David Brown wrote:
>> On 28/09/2026 01:53, bart wrote:
>>>
>>> Ones like MIN(x, y) can be considered fundamental, [...]

*shrug* - In my practice I typically just implemented such primitive
functions on the fly. - But what I'd find a lot more useful would be
a generalized form,  <numtype> max ([]<numtype> sequence)  (where the
simple case would then just be a special case).

> 
>> It also has a "hypot" function that returns, approximately, sqrt(x*x + 
>> y*y).
> 
> [...]
> 
> If C's obscure 'hypot' function does that job, then great.

As far as memory serves, hypot() will even work in cases where the
explicit primitive formula (as depicted above) would overflow.

> My point was 
> that that set of functions was too specific for a general purpose 
> language at this level.

My opinion on that is that *most* functions are "too specific" as a
_built-in_. That's what libraries are for! Pay only for what you use.

There are general purpose language implementations that support such
built-ins, though, depending on the environment - which makes these
features de facto non-standard! - Kornshell's user-defined built-ins,
for example. Or the Algol 68 Genie implementation, where you have all
functions of, say, the GNU scientific library directly available if
you compile that compiler with the GSL development package existing
on your system.)

> [...]
>>
>>> I'm sure there are plenty of such libraries about. They don't need to 
>>> be core language features at this level.

Exactly.

>>
>> Agreed.  Things like "min", "abs", trig functions, etc., should 
>> normally not be core language features in any language unless the 
>> language is dedicated to numerical calculations.

Well, it need not be numerical calculations. In Algol 68, for example,
'abs' is also returning the ordinal number of a 'char' entity, or the
numerical value for 'real' and 'int', and since it supports 'complex'
it's also returning the complex 'abs' value (which, incidentally, is
matching the above mentioned hypot() functionality).

What is "normal" or not (in the core of a language) very much depends.

> 
> Many of these are available as machine instructions, so they are 
> considered fundamental there. Some are available on my Casio.

I don't think "machine instructions" are a convincing criterion if
you're thinking about language design on the user's level. (You said
it yourself above.) Though if you're designing a language trimmed for
performance (like "C") there might be a point (for some, not me) to
have the low-level capabilities reflected in the language (as opposed
to the higher-level abstractions).

> 
> You think a cheap calculator should have sin() but not a programming 
> language?

My 45 years old Sharp calculator has for example arc-tan-hyperbolicus
but I don't think that should be inherent part of a general purpose
language in its language core (but certainly in some math library you
can link). It has also some basic statistical primitives (that you'd
have in some statistical math library that's usable in general purpose
languages).

That said; sine() is still widely considered as so basic that even
some shell languages support it. - It would nonetheless be better
placed in a math library than in the core language.

(None of these are typically in CPUs' machine instructions. But some
are available in math co-processors. - It shouldn't affect language
design, though, IMO.)

> 
> Having them via user-functions in standard library is just about 
> acceptable, but it's not ideal - [...]

That's most sensible, I'd rather say. (YMMV.)

> 
> One of fir's points, with which I agree, is that how C does it is a mess.

(We already widely know that fir and you are rabid about C's mess.)

> 
>> Lots can be part of a standard library, however.  There's no rule 
>> where the line should be drawn between standard libraries and 
>> additional libraries - that depends on the language.  Since we are in 
>> c.l.c., the C standards show where the line is drawn in C.
> 
> So why was hypot() ever added? Somebody thought it was a good idea at 
> one time to add a such a one-line function?

Actually hypot() is documented in my 40+ years old Unix book (based
on UNIX Version 7 and its legacy C-version), so we can probably say
it was there since "the beginning" (and not so much "added at one
time", even if the beginning is of course literally also "one time").

> 
> But then a one-line function is also trivial to write in user-code, 
> compared to your own cos() for example.

Janis

> [...]

[toc] | [prev] | [next] | [standalone]

#402462

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2026-09-28 11:15 -0400
Message-ID	<119e0ak$2es7t$1@dont-email.me>
In reply to	#402448

On 28/09/2026 12:45, bart wrote:
> On 28/09/2026 09:25, David Brown wrote:
...>> It also has a "hypot" function that returns, approximately,
sqrt(x*x +
>> y*y).
...> So why was hypot() ever added? Somebody thought it was a good idea at
> one time to add a such a one-line function?
It was part of the major expansion to the <math.h> library that occurred
in C99. It was added because of the "without undue overflow or
underflow." requirement. Achieving that result makes it a bit more
complicated than just a one-line function. Also, even most people who
are well aware of that problem are unaware of how best to avoid it. See
<https://en.wikipedia.org/wiki/Pythagorean_addition#Calculation_order>
for more details.

[toc] | [prev] | [next] | [standalone]

#402464

From	bart <bc@freeuk.com>
Date	2026-09-28 16:40 +0100
Message-ID	<119e1ok$2fheo$1@dont-email.me>
In reply to	#402462

On 28/09/2026 16:15, James Kuyper wrote:
> On 28/09/2026 12:45, bart wrote:
>> On 28/09/2026 09:25, David Brown wrote:
> ...>> It also has a "hypot" function that returns, approximately,
> sqrt(x*x +
>>> y*y).
> ...> So why was hypot() ever added? Somebody thought it was a good idea at
>> one time to add a such a one-line function?
> It was part of the major expansion to the <math.h> library that occurred
> in C99. It was added because of the "without undue overflow or
> underflow." requirement. Achieving that result makes it a bit more
> complicated than just a one-line function. Also, even most people who
> are well aware of that problem are unaware of how best to avoid it. See
> <https://en.wikipedia.org/wiki/Pythagorean_addition#Calculation_order>
> for more details.

I think most will be vaguely aware of such problems, but usually they 
don't matter because they only happen with unlikely, extreme inputs.

One simple way around in this case, is to use 64-bit floats for the 
calculation, even if the inputs are 32-bits.

That might kick the can down the road enough that overflows will 
virtually never occur (eg. it might need inputs over 10**150, and that I 
think is impossible if inputs were promoted from 32 bits).

I'm less familiar with underflows, ie. values smaller than around 
10e-308, but I think the same applies.

The technique demonstrated in LD'O's post I think buys you one more bit 
of exponent range (although the article you linked to seems to suggest 
you can go beyond that with extra scaling).

When such things used to be important to me, I tried to avoid doing the 
square-root part anyway, for example I would compare one set of x*x + 
y*y with another. In that case it is necessary to express the full 
magnitude.

If the values represent length, then another approach would be a choice 
of units. I liked using mm, but if expressed in metres, then I think 
that's another 10 extra bits of binary exponent range, unless the issue 
is underflow, then it might make it worse!

In any case, it was NEVER a problem (well, until someone zoomed in 
enough within my CAD product that they hit the limitations of the 
floating point representation. Things would get jerky).

[toc] | [prev] | [next] | [standalone]

#402525

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2026-09-29 16:50 -0700
Message-ID	<119his0$3oib4$4@dont-email.me>
In reply to	#402464

On 9/28/2026 8:40 AM, bart wrote:
> On 28/09/2026 16:15, James Kuyper wrote:
>> On 28/09/2026 12:45, bart wrote:
>>> On 28/09/2026 09:25, David Brown wrote:
>> ...>> It also has a "hypot" function that returns, approximately,
>> sqrt(x*x +
>>>> y*y).
>> ...> So why was hypot() ever added? Somebody thought it was a good 
>> idea at
>>> one time to add a such a one-line function?
>> It was part of the major expansion to the <math.h> library that occurred
>> in C99. It was added because of the "without undue overflow or
>> underflow." requirement. Achieving that result makes it a bit more
>> complicated than just a one-line function. Also, even most people who
>> are well aware of that problem are unaware of how best to avoid it. See
>> <https://en.wikipedia.org/wiki/Pythagorean_addition#Calculation_order>
>> for more details.
> 
> I think most will be vaguely aware of such problems, but usually they 
> don't matter because they only happen with unlikely, extreme inputs.
> 
> One simple way around in this case, is to use 64-bit floats for the 
> calculation, even if the inputs are 32-bits.
> 
> That might kick the can down the road enough that overflows will 
> virtually never occur (eg. it might need inputs over 10**150, and that I 
> think is impossible if inputs were promoted from 32 bits).
> 
> I'm less familiar with underflows, ie. values smaller than around 
> 10e-308, but I think the same applies.
> 
> The technique demonstrated in LD'O's post I think buys you one more bit 
> of exponent range (although the article you linked to seems to suggest 
> you can go beyond that with extra scaling).
> 
> When such things used to be important to me, I tried to avoid doing the 
> square-root part anyway, for example I would compare one set of x*x + 
> y*y with another. In that case it is necessary to express the full 
> magnitude.
> 
> If the values represent length, then another approach would be a choice 
> of units. I liked using mm, but if expressed in metres, then I think 
> that's another 10 extra bits of binary exponent range, unless the issue 
> is underflow, then it might make it worse!
> 
> In any case, it was NEVER a problem (well, until someone zoomed in 
> enough within my CAD product that they hit the limitations of the 
> floating point representation. Things would get jerky).
> 

ponder on atan vs atan2?

[toc] | [prev] | [next] | [standalone]

#402492

From	Lawrence D’Oliveiro <ldo@nz.invalid>
Date	2026-09-29 06:38 +0000
Message-ID	<119fmd8$315co$1@dont-email.me>
In reply to	#402448

On Mon, 28 Sep 2026 11:45:21 +0100, bart wrote:

> If C's obscure 'hypot' function does that job, then great.

Nothing obscure about it. Every language with a decent maths library
has it. To name but a few:
<https://cppreference.com/cpp/numeric/math/hypot>
<https://docs.python.org/3/library/math.html#math.hypot>
<https://crates.io/crates/core_maths/0.1.1/code/src/lib.rs>
<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java>

Why? Because <https://en.wikipedia.org/wiki/IEEE_754>. We’ve already
discussed elsewhere why implementing it correctly is somewhat
nontrivial, because the obvious naïve implementation is prone to be
... somewhat fragile.

[toc] | [prev] | [next] | [standalone]

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →

csiph-web

official library of tiny functions lacking in c

Contents

#402520

#402522

#402540

#402584

#402552

#402553

#402560

#402562

#402564

#402592

#402554

#402463

#402479

#402498

#402524

#402454

#402462

#402464

#402525

#402492