Re: [boost] [math toolkit] Review results

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2007-05-17 05:12:01

>-----Original Message-----
>From: boost-bounces_at_[hidden] 
>[mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
>Sent: 16 May 2007 18:36
>To: boost_at_[hidden]
>Subject: Re: [boost] [math toolkit] Review results
>
>Paul A Bristow wrote:
>> If we want it to fail at compile time, IMO it MUST be an option
>> becaue there are occasions when it is vital to be able treat all
>> distributions alike.  A typical case is our C# .NET (cue hisses and
>> boos) 'applet' to calculate distribution parameters - for any
>> distribution chosen from a dropdown. (This useful program will be
>> posted somewhere soon).
>
>Two other options: we could remove the definitions of accessor 
>functions 
>that are undefined for that distribution, and then add our own private 
>"catch all" versions when we need them.  Or we could add the 
>"catch all" 
>versions to a separate namespace, and users could bring them 
>into scope when needed. 

These seem more complicated to me, unless I am misunderstanding, again.
There are only quite few *undefined* accessors (mean, etc).

> Do we have customised (as in meaningful and distribution specific) 
>error messages for the current functions though?  If so we 
>should try and keep them.

The compiler outputs:

I:\Boost-sandbox\math_toolkit\boost/math/distributions/cauchy.hpp(218) : error C2027: use of undefined type
'boost::STATIC_ASSERTION_FAILURE<x>'
        with
        [
            x=false
        ]
        .\test_cauchy_mean.cpp(47) : see reference to function template instantiation 'RealType boost::math::mean<double>(const
boost::math::cauchy_distribution<RealType> &)' being compiled
        with
        [
            RealType=double
        ]

but if you click on cauchy.hpp line 218 you see the pretty self-explanatory code below:

template <class RealType>
inline RealType mean(const cauchy_distribution<RealType>& )
{  // There is no mean:
#ifdef BOOST_MATH_COMPILE_FAIL_IF_UNDEFINED
#  ifndef BOOST_MSVC
#    error Mean of the Cauchy distribution is undefined!
#  else 
      BOOST_STATIC_ASSERT(sizeof(RealType) == 0);
#  endif
#endif
   return tools::domain_error<RealType>(
      BOOST_CURRENT_FUNCTION,
      "The Cauchy distribution does not have a mean: "
      "the only possible return value is %1%.",
      std::numeric_limits<RealType>::quiet_NaN());
}

>> So to provide an option, a macro seems sensible, perhaps
>> BOOST_MATH_COMPILE_FAIL_IF_UNDEFINED?
>
>The consensus seems to be for making compiler errors the 
>default, so maybe 
>BOOST_MATH_DEFINE_ALL_ACCESSORS to make them available 
>regardless of whether 
>they are mathematically defined for the distribution.

OK - I assume this is just the inverse of BOOST_MATH_COMPILE_FAIL_IF_UNDEFINED

Are we *sure* this is the consensus?

IMO providing NaN may be more useful?

>> BOOST_STATIC_ASSERT(false); has been one way of providing a compile
>> time trap and fails with a rather long message, although clicking on
>> the 1st line goes straight to the source code above, so it soon
>> becomes pretty clear.
>
>It would have to be BOOST_STATIC_ASSERT(sizeof(T) == 0) as 
>some compilers 
>realise that BOOST_STATIC_ASSERT(false) will always fail and issue a 
>diagnostic irrespective of whether the template is instantiated.

OK - but I hope compilers don't get even smarter.

>> For MSVC at least one can use the #error pragma thus
>>
>> #ifdef BOOST_MATH_COMPILE_FAIL_IF_UNDEFINED
>> #  ifdef BOOST_MSVC
>> #    error Mean of the Cauchy distribution is undefined!
>> #  else
>>      BOOST_STATIC_ASSERT(false);
>> #  endif
>> #endif
>>
>> and this produces the rather more explicit message:
>> 
>I:\Boost-sandbox\math_toolkit\boost/math/distributions/cauchy.hpp(216)
>> : fatal error C1189: #error :  Mean of the Cauchy distribution is
>> undefined!
>
>Surely that just gives an error whenever you include the header?

Seems to work for MSVC 8.0.

>Or we could simply not provide the definitions of these 
>functions at all: 
>but then the error messages might be rather cryptic?

A definite step backwards, IMO.

Paul

---
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone] & SMS, Mobile [phone] & SMS
pbristow_at_[hidden]