
Boost : 
From: Daniel Frey (daniel.frey_at_[hidden])
Date: 20030611 02:23:22
Paul A. Bristow wrote:
>
>  Original Message
>  From: boostbounces_at_[hidden]
>  [mailto:boostbounces_at_[hidden]]On Behalf Of Daniel Frey
>  Sent: Tuesday, June 10, 2003 10:18 AM
>  To: boost_at_[hidden]
>  Subject: [boost] Re: Math Constants Formal Review  is extensible.
> 
> 
>  Paul A. Bristow wrote:
>  > Your example is interesting. I think that providing a Macro value
>  allows this
>  > sort of UDT extensions code (very like Michael Kenniston's examples).
> 
>  I fail to see how this should work. Could you elaborate a bit, please?
> 
>  > My thesis that 40 decimal digits are enough is because it is enough for all
>  > existing floating point hardware, up to 128 significands. I
>  believe that anyone
>  > wanting more is likely to be using a separate 'unlimited' precision package
>  > anyway.
> 
>  That exactly is my point: People will choose such a package, but how can
>  it be glued by the user to boost's constants? And to the code the user
>  already wrote? Taking into account that boost is intended to be some
>  kind of prestandardlibrary, I think we should allow the extension of
>  constants to be used with new floattypes. Using the constants in a
>  generic way is only possible when we have a standardized way of
>  accessing them. This is why I concentrated on allowing explicit casting
>  and the direct use as in pi*(float)(...). I don't see how the user could
>  use Roguewave's decimal type with Macros (or any other user defined
>  floatlike type. And I don't think that using such a library should
>  result in a choice for the user to either use constants from boost with
>  the according interface or hope for the vendor to specify the constants
>  and use their interface.
>
> I imagine that any package will have some decimal digits C string to UDT
> conversion, for example for quad_float it is to_quad_float(const char*) so ones
> writes
>
> NTL::quad_float my_quad_float = to_quad_float(BOOST_PI);
>
> where BOOST_PI is defined as 3.1415926535897932384626433832794 say.
>
> I see the 40 decimal digit representations as the 'lowest common denominator'.
>
> How else do you propose?
>
> 
>  > There is also an example of a UDT _interval_  a 128bit quad_float
>  type, used
>  > by Victor Shoup's NTL package. But it does require using the NTL generator
>  > program to create the exactly representable values. (See
>  test_quad_float.cpp
>  > example).
>  > I believe that interval constants are an important feature  and
>  quite novel.
> 
>  I don't understand that example, sorry. Thus I also miss the importance
>  of this feature. What exactly are interval constants? What problem are
>  they addressing?
>
> If you are using the interval library to calculate the intervals of areas of a
> circle, you need the smallest interval containing pi (as well as interval
> containing the radius of course).
>
>
> Isn't it an orthogonal concept to constants like 'pi',
>  'e', ...? Should / could it be placed into a separate library (maybe on
>  top of the basic constants library)?
>
> I proposed a separate file containing the interval constants (or should I say
> constants intervals?)
>
>  I also looked at other examples
>  like test_pi_interval, but I still don't understand the idea that's
>  behind it. All that I see is a lot of pi_f_l, pi_l_l, pi_l_u4, etc. and
>  this is IMHO unacceptable for generic programming.
>
>
> The file template_intervals_constants.hpp contains some examples of how the
> interval library authors and others discussions concluded that the interval
> values would appear to users  analogous to other intervals. Users would not see
> pi_f_l, pi_l_l. These are to show that the exactly representable values work OK.
>
> Paul
>
>
> Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
> +44 1539 561830 Mobile +44 7714 33 02 04
> Mobile mailto:pabristow_at_[hidden]
> mailto:pbristow_at_[hidden]
>
>
>
> 
>  Regards, Daniel
> 
>  PS: The toyexample I posted only worked for the GCC 3.x, but I extended
>  it a bit to make it work with the Intel compiler and with older GCCs
>  (2.95.x). If there is any interest, I can post it...
> 
>  
>  Daniel Frey
> 
>  aixigo AG  financial training, research and technology
>  SchloßRaheStraße 15, 52072 Aachen, Germany
>  fon: +49 (0)241 93673742, fax: +49 (0)241 93673799
>  eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
> 
> 
>  _______________________________________________
>  Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 
> 
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
 Daniel Frey aixigo AG  financial training, research and technology SchloßRaheStraße 15, 52072 Aachen, Germany fon: +49 (0)241 93673742, fax: +49 (0)241 93673799 eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk