
Boost : 
From: Paul A. Bristow (boost_at_[hidden])
Date: 20030610 16:32:15
 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk