Boost logo

Boost :

From: Deane_Yang_at_[hidden]
Date: 2001-10-29 12:27:05


I'm impressed. I thought it would be really hard to come up with
good names, but I think these are pretty good suggestions.

I would however vote for no numerals, no abbreviations, and all words.

So I like "sqrt_two", rather than "sqrt_2". I would actually prefer
"sqrt_of_two", but the extra "_of" can get tiresome.

And "pi_squared" instead of "pi_sqr". Especially since "sqr"
is sometimes used to mean square root.

Otherwise, I like it.

I'm also curious. Is sin 1 an interesting constant? Why?

Deane

--- In boost_at_y..., "Paul A. Bristow" <boost_at_h...> wrote:
> I'm open to suggestions -
> but how about the following specifying by example and rationale:
>
> pi // prefer lower case only - use uppercase only for class names.
> half_pi // prefer _ rather than halfPi (even though I prefer this!)
> quarter_pi // rather than pi_div_4 - looks nicer
> third_pi //
> two_thirds_pi // long but can't have 2/3_pi
> // two_div_three_pi is nasty
> // pi_2_3rd - I don't like much.
> two_pi // cos can't have 2_pi
> log_pi // cos () not allowed in name
> sqrt_2 // shorter than sqrt_two and clearer than sqrt2
> // sqrt is commonly used and shoarter than square_root_2
> sqrt_2_pi // shorter than sqrt_two_pi
> sqrt_10 // shorter than sqrt_ten
> cube_root_2 // or what?
> fourth_root_2 // or what?
> pi_sqr // pi * pi or ?
>
> ln_10 // clearer than ln10, shorter (and clearer) than ln_ten
> // more explicit than log_10 - implies base ten?
> one_div_sqrt_2 // shorter than reciprocal_sqrt_2
> // 1_div_sqrt_2 not allowed
> // div more explicit than one_over_sqrt_2 or upon
> two_thirds // longer than two_3rds but clearer?
> one_third // longer but simpler than one_3rd?
> half // clearer than one_div_2
> third // shorter than one_third or one_3rd
> quarter
>
> two_pow_three_halves // two_pow_three_div_two
> // or two_pow_three_div_2 both might be ambiguous?
> five_div_6 // shorter than five_div_six
> gamma_third
> gamma_two_thirds
> e // short and sweet
> e_sqr // e * e - or e_sqrd? or e_squared?
> e_cubed // e * e * e
> e_pow_4 // shorter than e_pow_four
> e_pow_quarter_pi // or e_pow_pi_div_4 is ambiguous?
> ln_ln_2
> minus_ln_ln_2 // can't start with - so use word
> phi // short
> ln_phi // clearer than lnphi
> euler // gamma is more likely to be used already.
> sin_1 // shorter than sine_one
> cos_1 // shorter than cos_one
> sin_0 // or sin_zero?
>
> Paul
>
> PS Yes, I agree it's non-trivial to come up with a
> logical, consistent naming scheme! :-(
>
> PS I will start a new list of actual constants
> when/if we can agree ?!!! on a naming convention.
>
> Dr Paul A Bristow, hetp Chromatography
> Prizet Farmhouse
> Kendal, Cumbria
> LA8 8AB UK
> +44 1539 561830
> Mobile +44 7714 33 02 04
> mailto:pbristow_at_h...
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: jmaurer [mailto:jmaurer]On Behalf Of Jens Maurer
> > Sent: Saturday, October 27, 2001 5:09 PM
> > To: boost_at_y...
> > Subject: Re: [boost] Math constants for naive and gurus? - which
> > constants do you want?
> >
> >
> > "Paul A. Bristow" wrote:
> > >
> > > I have now produced a C++ program which writes constants to
> > several files:
> >
> > > Samples attached, and zip uploaded to the vault.
> >
> > As requested in the formal review, I would appreciate having
documentation
> > about the general rule how the constant names are synthesized.
> > This will answer questions such as:
> > Is 2/3 pi named pi_2_3 or pi_2_3rd ?
> > Is sqrt(2) name sqrt_2 or ... ?
> >
> > I believe having a well-defined rule makes the library easier to use,
> > because users have to look up names in the documentation less often
> > during day-to-day programming.
> >
> > (Yes, I think it's non-trivial to come up with a logical, consistent
> > naming scheme.)
> >
> > Jens Maurer
> >
> >
> >
> > Info: http://www.boost.org Unsubscribe:
> > <mailto:boost-unsubscribe_at_y...>
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
> >


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk