[boost] Re: Math Constants Formal Review - is extensible.

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-06-11 02:23:22

Paul A. Bristow wrote:
> 
> | -----Original Message-----
> | From: boost-bounces_at_[hidden]
> | [mailto:boost-bounces_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 pre-standard-library, I think we should allow the extension of
> | constants to be used with new float-types. 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
> | float-like 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 128-bit 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
> [phone]   Mobile [phone]
> Mobile mailto:pabristow_at_[hidden]
> mailto:pbristow_at_[hidden]
> 
> 
> 
> |
> | Regards, Daniel
> |
> | PS: The toy-example 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ß-Rahe-Straße 15, 52072 Aachen, Germany
> | fon: [phone], fax: [phone]
> | 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ß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de