RE: [boost] Re: Math Constants Formal Review - is extensible.
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey
| Sent: Wednesday, June 11, 2003 8:41 AM
| To: [EMAIL PROTECTED]
| Subject: [boost] Re: Math Constants Formal Review - is extensible.
|
| I think that most people are able to look up pi (and any other constant)
| on the internet if they need more precision.
Of course, but I believe there is great merit in avoiding this by having a
collection of the widely used constants all of which have the same precision and
are used by everywhere (unless there is some exceedingly special reason for
higher precision - can you suggest who needs more than 40 decimal digits - apart
from number theoretic work. Should be enough even for accountants!).
| But as shown in the example
| for the Roguewave-type, it's possible to allow the user to extend the
| system. If the pi_value-stuff is placed in a header called
| constant_values.hpp and the definition of the variable pi itself is in
| another header, the user could add a specialization for 1000 digits if
| he likes. See the example I gave for 'g'. The main point in doing this
| is, that you only need to change the header of your project to add a new
| type, not the code where pi is used. Here in the company, we use doubles
| to develop the code, the RWDecimal<>-class for the production system and
| we might replace the latter by another type as we don't want to use
| Roguewave in the future. Of course it might be a nice idea to provide a
| string representation of a constant, probably as a specialization:
|
| template<> struct pi_value< std::string > {
|std::string operator()() const {
| return "3.1415926535897932384626422832794";
|}
| };
|
| Now we could even provide the default case for classes that have a ctor
| taking a string like this:
|
| template< typename T > struct pi_value {
|T operator()() const {
| return T( pi_value< std::string >()() );
|}
| };
|
| And the user is still able to specify his own version like shown:
|
| template<> struct pi_value< RWDecimal< RWMP3Int > > {
|const RWDecimal< RWMP3Int >& operator()() const {
| static const RWDecimal< RWMP3Int > value( "...1000digits..." );
| return value;
|}
| };
I don't believe that anything I propose conflicts with these sensible ideas.
The proposal is for several header files each containing the same constants,
only one of which would be used for any compilation. (Users have been warned
against using more than one! Nobody has suggested a way to guard against this
mistake, but I think that it would be apparent pretty soon, probably at compile
time, and at link time if not.) The macros constants header is the simplest and
could be used to provide the appropiate value(s) above.
|
| Now I'm getting closer to it. And if it is in a separate header, it
| would not mix up the above design, would it?
No, you would only use the intervals constants header if you were using the
interval library. (And if you were not, it would not compile).
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
|
| --
| 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
RE: [boost] Re: Math Constants Formal Review - is extensible.
| -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
RE: [boost] RE: Math Constants Formal Review - is extensible.
You can seen an example of extending to a 'new' constant 'gamma' in the examples testFunctionConstants/gamma_function_constants.hpp. The example by Michael Kenniston also show how complex items could also be added (but not normally to avoid every program dragging in ). Macros could also facilitate the process of course, and it could start with a macro defining the constant as a 40 decimal digit string. If Boosters agree that this scheme is an acceptable way to go, the the example and guidance could be made more helpful to provide the encouragement you rightly say is needed. But first the overall strategy needs agreement. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 07 June 2003 00:20 | To: [EMAIL PROTECTED] | Subject: [boost] RE: Math Constants Formal Review | | Another point I am missing is a way to extend the constants | for user-defined types. Something like numeric_limits<> | comes to mind. I think that this is a must-have feature as | people that write applications that need lots of these | constants are likely also using types with higher precision | that the standard types provided by the language. Without a | way to teach the constants-framework the new types, they | will create wrappers and thus they won't use the intended | boost-/standard-way to access the variables. | | Regards, Daniel | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
