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

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-06-10 16:32:15

| -----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
|
|