| -----Original Message----- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Tuesday, June 10, 2003 10:18 AM | To: [EMAIL PROTECTED] | 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 +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | | 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: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 | eMail: [EMAIL PROTECTED], 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
