🚀 go-pugleaf

Although I posted the orignal article I was acting on behalf of a
number of us who were interested in the reasons for the lack of math
constants. This reply to Stan's followup post contains several
people's opinions (well, two). Each person's comments are preceeded
with a line containing that person's name. So far its only myself and
Luke Kendall (luke@research.canon.oz.au) have bothered...


brown@NCoast.ORG (Stan Brown) writes:
>I wasn't, but I'll comment anyway.
>
>How many decimal places?  ("The greatest precision that the machine can
>hold" may not always be the desired answer.)  float? double? long
>double?

Andy's reply:
Well "the greatest precision..." would be a start! Why do we have HUGE?
Who's to say its a "huge" value? If the constants were defined it would be
salient to define them appropriately for all data types, just like
<float.h> does for the various limits.

Luke's reply:
Why?  I assert that the useful definition is `The precision needed to
represent PI as a double.'

>
>Why stop with pi?  What about e?  What about log-base-10 of e, or
>log-base-e of 10?  
>

Andy's reply:
Well they all used to be there too!

Luke's reply:
The rationale behind the committee was to tighten up existing practices. 
So, that answers your question.  The constants you used to be able to
depend on being there, were:

M_PI, M_PI_2, M_PI_4, M_SQRT2, M_E, M_LOG2E, M_LOG10E, M_LN2, M_LN10

>
>Why stop with mathematical constants?  h (Planck's constant) is useful,
>too.  What about c (speed of light on vacuum)?  Or the number of
>centimeters in an inch?
>

Andy and Luke's reply:
This is <math.h> not <physics.h>

>
>I'm being facetious, of course, but I think the success of C is due in
>part to its economy, to _not_ loading down the language to things that
>might be useful to some people.  I've been programming in C for a decade
>and have never needed pi, or any of the other constants I mentioned.  If
>I did, I could easily do a #define and get the value I needed.
>
>You might argue that pi is more useful than (say) vsprintf( ), and
>probably used as often in C programs worldwide.  Stipulating your point,
>I see an essential difference even so: pi is something that an ordinary
>user can easily provide portably; vsprintf( ) is something that must be
>provided by the implementation or not at all.
>
>From section 1.1 of the {Rationale}:  "The Committee's goal was to
>develop a ... Standard ... which codifies the common, existing
>definition of C and which promotes the portability of user programs
>across C lanbguage environments."  A couple of pages later I read "...
>the spirit of C can be summarized in phrases like ... 'Keep the language
>small and simple.'"  This I think is the main argument against adding
>things that might be useful but aren't required.
>

Luke:
Adding constants to an include file does not `load down' the language.
You don't use it, you don't see it.  More importantly, it doesn't
complicate the language or the compiler, either.  The reasons M_PI
should be there are:
    1) It always used to be
    2) It's a useful convenience (that's _why_ (1) is true)
As far as _you_ not using M_PI... well, I guess you never used sin() or
cos() either.  All that says is that you don't do much geometry/maths
stuff with C.  Others wouldn't do much system programming.  You can't
reasonably generalise from a sample size of one.

The question is a serious one, and we would still be interested in an
answer from someone on the Standards committee.

Let me emphasise something: the people at NeXT have done the correct
thing: the constants are still _in_ math.h; but they are guarded by
    #ifndef __STRICT_ANSI__
    #endif

The decision that the committee made seems so clearly _wrong_ that I
feel that there _must_ be some logical explanation for it.  So far I
have not seen any.

-- 
Andy Newman (andy@research.canon.oz.au)
"Giving money and power to governments is like giving whiskey and
 car keys to teenage boys" - P.J.O'Rourke