[boost] Re: Math constants - updated.

From: Andy Little (andy_at_[hidden])
Date: 2005-05-11 05:25:31

"Daniel Frey" <d.frey_at_[hidden]> wrote
>
> GCC 3.3.5 says:

[etc]

> To sum it up: *Some* examples do work, but T(c) is not a *generic*
> syntax that works. Thus I went for .get<T>()

Ok. ... but its  ugly to write that. Maybe aesthetics shoulnt count but
unfortunately they do. And in different contexts you
need different invocations.

>> However  IMO it shouldnt be convertible to anything. There needs to be some
>> concept that it models. FWIW I would be content with , float, double long
>> double. IOW numeric types. But ... eg FWIW  my version still  fails in
>> boost::numeric::interval. This is always going to be the problem when
>> trying to make one type maquerade as another :-(
>
> FWIW, the constants I wrote only look as if they convert to anything.
> But in the end, you must have an implementation that yields the value.
> If there is no constant (or explicit mapper) for a type called "fluffy",
> the compiler complains. Static type checking should be preserved - and
> is. I tried to avoid magic that leads to surprises, as this immediatly
> leads to bugs in the real world.

Its tricky to assess this as it wont compile in VC7.1

>> A 'math constant' is expected to be pretty unexciting, which this doesnt
>> deliver. Maybe if  it was repackaged as say a quirky 'smart constant',
>> rather
>> than The std::math_constant it would be more gratefully received.
>
> The constant itself is still simple: two. It should come from some
> header as well as all other constants you usually need. A normal user
> should not be concerned with defining constants. The best example is
> probably still:

> template< typename Y >
> inline typename SI< Y >::quantity
> idealGasLaw( const typename SI< Y >::pressure& p,
>             const typename SI< Y >::volume& v,
>             const typename SI< Y >::temperature& t )
> {
>    using boost::units::si::constants::chemistry::R;
>    return p * v / ( R * t );
> }
>
> The constant comes from a header, the user is not bothered with anything
> else at this point.

Sure the same thing can be done with 'units. Question is though Does the user
think its weird? What happens when the user wants to say std::cout << R ; ?
 std::cout << R.get<double>(); //  is not exactly elegant. If I have to go 
throught this.. why not make the useage consistent and just make the thing a 
function?

> Whatever float-point-type (native or UDT) he uses
> for Y, the algorithm as well as the constant library itself will be
> unaffected. You can define algorithm libraries containing the above,
> unit libraries, constant libraries (that is libraries that yield the
> constants for a certain use-case, not the library that helps to define
> these constants (my lib)) and float-point-types independently. A user
> might need to add some glue to use certain combinations in his projects,
> although most things for float/double will work out-of-the-box. The
> most important point is, that the user should never be forced to
> reinvent the wheel, only assemble some stuff! This is what I consider
> reuseability.

Unfortunately I cant get this to compile in VC7.1 .

>> sure .. .... but of course it isnt doable in the language.
>> (BTW the   pi * pi  stuff is  cool !. Sorry...  it appears I have been
>> dismissive of that.)
>>
>> int val  = my::pow(9,3,2);  eg    replaces std::pow( static_cast<double>(9)
>
> With my library, you can make pow(nine,three,two) a constant. Today.
> Given the ideas I have about constant_<9> nine; etc., this might even
> work for all integer numbers in the future, although I can't promise
> anything. If it works, you could also spell it sqrt(pow(nine,two)) or
> sqrt(nine*nine) - all leading to real constants :)

Yes ... but    my_type / two   is not as nice as my_type / 2, which is my
point.

regards
Andy Little