Re: [boost] Boost.Test feature request

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2006-11-16 05:30:13

I've had some further thoughts on this.

I think a few macros will allow things to be easily 'personaized'

I can agree that not everyone wants tons of decimal digits, or trailing zeros all the time.

So why not use a macro BOOST_TEST_SHOW_ZEROS, so

#ifdef BOOST_TEST_SHOW_ZEROS
  ostr << std::showpoint;  // show trailing zeros to indicate the FP precision.
#endif

#ifdef BOOST_TEST_SHOW_PRECISION
  #if (BOOST_TEST_SHOW_PRECISION > 0)
    ostr.precision(BOOST_TEST_SHOW_PRECISION) // provides a simple way to fix the precision you want.

// For example with some arbitrary precision type that would show hundreds of digits, you might want to limit the output from test.
// Or you are only interested in the first few digits because test failures are likely to be big differences.
  #else
    // leave at default precision (6)
 #endif
#else
  set_precision(...) // as at present, so existing behaviour is unchanged.
#endif

We could also meet some peoples very reasonable desire to have the integer output in hex with

#ifdef BOOST_TEST_SHOW_HEX
  ostr << std;;hex;
#endif

and even BOOST_TEST_SHOW_HEX_FP

to show the hex representation of floating-point values.
But this would be much more work ;-)

HTH more.

Paul
---
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone] & SMS, Mobile [phone] & SMS
pbristow_at_[hidden]
|  |  -----Original Message-----
|  |  From: boost-bounces_at_[hidden] 
|  |  [mailto:boost-bounces_at_[hidden]] On Behalf Of 
|  Gennadiy Rozental
|  |  Sent: 09 November 2006 20:42
|  |  To: boost_at_[hidden]
|  |  Subject: Re: [boost] Boost.Test feature request
|  |  
|  |  Also I would like to hear from 
|  |  you the rationale for all the conditions and selected precisions.
|  
|  My thinking is:
|  
|  1  The number of digits shown should be only those that are 
|  potentially significant for the Floating-point type being 
|  reported.  For
|  float 9, double 17, long double - varies.
|  
|  2  Despite the clutter caused by trailing zeros, these have 
|  the advantage of showing the meaningful precision for the value.
|  
|  3  The precision is very important because many obscure 
|  not-equal, and not-quite-close-enough errors involve 
|  computation, round-off
|  errors and unexpected conversions losing accuracy.  The last 
|  thing we want is error messages saying  "{1.2345} and 
|  {1.2345} are not
|  equal":  this appears to be nonsense and some users will 
|  immediately assume Boost.Test is at fault.
|  
|  Ideally precision should be 
|  std::numeric_limits<T>::max_digits10, as now accepted for 
|  C++0X, and this should be defined for ALL
|  types, built-in as User-defined; but we should not attempt 
|  this yet until it becomes standard.  However we might consider
|  designating a BOOST_HAS_MAX_DIGITS10 macro (but not yet 
|  defining it) and using this now thus:
|  
|  #ifdef BOOST_HAS_MAX_DIGITS10 && 
|  std::numeric_limits<T>::is_specialized
|    precision  = std::numeric_limits<T>::max_digits10)
|  #else
|  	existing code
|  #endif
|  
|  So for the time being - it's already complicated enough;):
|  
|  For all Decimal types, and this includes User-defined 
|  decimal types like NTL::RR, a typical arbitrary but pre-set 
|  precision, the
|  existing std::numeric_limits<T>::digit10 is correct.
|  Since std::numeric_limits<T>::digits may also be correct, it 
|  is essential to test for radix == 10 first.  As supplied, 
|  NTL::RR does
|  not have numeric_limits specialized and digits10 is 
|  undefined, but users can do this if they wish.  However, the 
|  precision in bits
|  is set at compile time, but the displayed digits, 
|  effectively digits10, can be altered at run-time.
|  
|  For built-in floating point types, the formula you are now 
|  using, which derives from  std::numeric_limits<T>digits, the 
|  number of
|  significand bits, is correct.
|  
|  For UD floating-point types, provided 
|  std::numeric_limits<T>digits is valid (has been specilized, 
|  and has had a value assigned (all
|  unassigned are zero by default), this formula is correct.
|  
|  If digits is (still) zero, then the most likely reason is a 
|  high (but not necessarily fixed at compile time) precision.
|  
|  For any other radix or where std::numeric_limits<T>::digits 
|  = 0 (almost certainly unassigned), we really don't have much 
|  to go on.
|  But the default precision of 6 decimal digits is almost 
|  certainly not the most helpful - far too few.  So John 
|  Maddock has suggested
|  using the precision of the most accurate built-in long 
|  double type std::numeric_limits<long double>::digits.  This 
|  deals with the
|  case of a composite type like <complex>.  It may give some 
|  superflous, but harmless decimal digits, but should never produce an
|  unhelpful "{1.2345} and {1.2345} are not equal" message.
|  
|  Ideally the user should always specialize numeric_limits for 
|  his type, and assign a suitable value to digits, digits10 and/or
|  eventually max_digits10.
|  
|  For integer types, precision is meaningless, so ideally 
|  set_precision should not be called at all, or do nothing.
|  
|  HTH