[musl] Floating Point Mathematical Constanst in <math.h> ...

[musl] Floating Point Mathematical Constanst in <math.h> ...

[Damian McGuckin]

This is not specific to MUSL but I figured the knowledge exists in the 
list. I was doing a review for a small book I am writing.

As long as one has

   defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)

the constants

 	M_E
 	M_LOG2E
 	M_LOG10E
 	M_LN2
 	M_LN10
 	M_2_SQRT_PI

Has anybody been involved in the global 'need' of these constants, i.e. 
how often they appear in people's code such that the names need to be a
global identified as long as one includes both <math.h> and does the 
appropriate #defines.

The reason I ask is that I cannot find where any of these is used in 
elementary mathematical libraries such as MUSL. Nor can I find the use
of Napier's constant (or Euler's number), i.e. 'e' or M_E, in a few 
million lines of engineering and physics software to which I have access.

The average log() or log2() or log10() programs which one might think 
could use those logarithm constants instead far more accurate ones 
instead.

I would like to say these constants have very little utility in the 
average programmer of technical software for engineering or physics
but that might be a little extreme.

Just curious.  Sadly, the people who made that decision at Berkeley in the 
eighties are quite hard to find these days, most of them enjoying their 
well-earned retirements.

Thanks - Damian

Re: [musl] Floating Point Mathematical Constanst in <math.h> ...

[Markus Wichmann]

Hi,

for questions of this type, Debian Codesearch (codesearch.debian.net) is
just awesome. I type in M_LOG2E and I immediately get something in
libreoffice using it. And GCC apparently as well. xscreensaver, too.

Yes, you get a lot of cruft to filter out. A lot of packages only copy
the definition, probably for sake of completeness, but the ones I wrote
above are actual uses of this constant I found inside of 5 minutes.

Ciao,
Markus

Re: [musl] Floating Point Mathematical Constanst in <math.h> ...

[Damian McGuckin]

On Sat, 25 Jan 2025, Markus Wichmann wrote:

> Yes, you get a lot of cruft to filter out. A lot of packages only copy 
> the definition, probably for sake of completeness, but the ones I wrote 
> above are actual uses of this constant I found inside of 5 minutes.

Thanks heaps - Damian

Re: [musl] Floating Point Mathematical Constanst in <math.h> ...

[Rich Felker]

On Sat, Jan 25, 2025 at 11:24:28AM +1100, Damian McGuckin wrote:
> 
> This is not specific to MUSL but I figured the knowledge exists in
> the list. I was doing a review for a small book I am writing.
> 
> As long as one has
> 
>   defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> 
> the constants
> 
> 	M_E
> 	M_LOG2E
> 	M_LOG10E
> 	M_LN2
> 	M_LN10
> 	M_2_SQRT_PI
> 
> Has anybody been involved in the global 'need' of these constants,
> i.e. how often they appear in people's code such that the names need
> to be a
> global identified as long as one includes both <math.h> and does the
> appropriate #defines.
> 
> The reason I ask is that I cannot find where any of these is used in
> elementary mathematical libraries such as MUSL. Nor can I find the
> use
> of Napier's constant (or Euler's number), i.e. 'e' or M_E, in a few
> million lines of engineering and physics software to which I have
> access.
> 
> The average log() or log2() or log10() programs which one might
> think could use those logarithm constants instead far more accurate
> ones instead.
> 
> I would like to say these constants have very little utility in the
> average programmer of technical software for engineering or physics
> but that might be a little extreme.
> 
> Just curious.  Sadly, the people who made that decision at Berkeley
> in the eighties are quite hard to find these days, most of them
> enjoying their well-earned retirements.

My simple explanation would be that these constants are moderately
useful to software consuming the standard math library and treating
floating point numbers as a good approximation of the reals for
specific real-world purposes, but that they're completely useless
(inadequate) for implementing high-quality general-purpose math
functions accurate across their entire domains.

Rich