RE: [boost] Math constants - naming convention?

From: Stewart, Robert (stewart_at_[hidden])
Date: 2001-10-30 08:36:06

From: Paul A. Bristow [mailto:boost_at_[hidden]]
> Sent: Tuesday, October 30, 2001 7:53 AM

> > From: Stewart, Robert [mailto:stewart_at_[hidden]]
> >
> > I prefer all uppercase for constants.  This helps them stand
> > apart from most other code.
> 
> Many people use all caps for MACROS.

I do too.  OTOH, I don't use many macros, so they can share that
"namespace."  (I use all lower case for things like enumerated type tags.)

> And there are lots of precedents for lower case.

Sure.  All lower case is used by code in std for classes, structs, typedefs,
functions, etc.  That's why I generally avoid all lower case identifiers.
However, given that Boost aims to produce code that may be included in the
standard at some point in the future, I'll grant that all lower case would
be consistent with the result of such standardization.

Nevertheless, I prefer to have constants stand apart from other code, so I
still like them to be all upper case.

> PI_SQRT_2

> I really don't like this at all - I think it is most confusing - you HAVE
to
> know the rules.
> SQRT_2_pi is obvious.

Given that 2 * pi and pi * 2 are mathematically equivalent, there is no
objective rationale for PI_SQRT_2 being more confusing than SQRT_2_PI.
(That does not mean you can't have a subjective preference for one over the
other.)  Furthermore, SQRT_2_PI might mean the square root of 2pi.  My
version didn't have that ambiguity.

> > These suggest using a common root prefix, "ROOT" perhaps, followed by
the
> > number of the root: 3 for cube, 4 for fourth, etc.  Note that there is
no
> > "_" between "ROOT" and the number, since the number indicates
> > which kind of root rather than a multiplier.
> >
> This is rational but I feel over the top - we only need 2, 3 & 4 (if
that).
> PI_pow_4 perhaps instead?

Given that PI_pow_4 is not the same as ROOT4_PI, I don't understand your
point.

My approach means that you can write ROOT3_* and ROOT4_* instead of
CUBE_ROOT_* and QUADRATIC_ROOT_* which, I'm sure you'll agree is shorter
and, perhaps, more readable due to the consistency.

> > This could be turned into a functional arrangement:
> > POW_2_3_2 but is that 2/3 ** 2 or 2 ** 3/2?
> 
> This is trying to be too clever?

Certainly, but I was simply trying to find a way to standardize the
constants originally listed.

> > Reverse the order since the important aspect is phi, not ln():
> >
> > PHI_LN
> 
> I disagree here - I think ln_phi is much more intutive.

The question is where ln_phi would appear in a list.  Does it go with the
phi values or the ln_* values?  By putting the value first, and the
operation after it, there is greater consistency among all of the
identifiers.  Besides, function ordering notwithstanding (that is, ln(phi)),
some languages put modifiers after what they modify, so I would expect my
version to be more natural for speakers of such languages.

I'm not stuck on my approach, but I do favor consistency.  Without
consistency, the names are just a hodge-podge that someone thought was
"nice."  That leads to naming problems such as are lamented in the STL,
making it difficult to divine the name of what you're after.  Furthermore,
with some consistent style in place, future constants that may be added --
by Boost or others -- will be more obvious because they follow the pattern
rather than because they continue to be contrived according to subjective
notions enforced at the time.

I hope this explains my rationale better, even if it doesn't change your
mind.

Rob

IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the
sender immediately by reply and immediately delete this message and all its
attachments.  Any review, use, reproduction, disclosure or dissemination of
this message or any attachment by an unintended recipient is strictly
prohibited.  Neither this message nor any attachment is intended as or
should be construed as an offer, solicitation or recommendation to buy or
sell any security or other financial instrument.  Neither the sender, his or
her employer nor any of their respective affiliates makes any warranties as
to the completeness or accuracy of any of the information contained herein
or that this message or any of its attachments is free of viruses.