Re: [boost] Re: Math Constants Formal Review
>From: "Daniel Frey" <[EMAIL PROTECTED]>
> On Sun, 22 Jun 2003 03:32:52 +0200, Terje Slettebø wrote:
> >
> > --- Start ---
> >
> > #include
> >
> > #define BOOST_DEFINE_MATH_CONSTANT(name)\ const struct name##_type\
> > {\
> > name##_type() {}\
> > template\
> > operator T() const;\
> > } name;
> >
> > #define BOOST_MATH_CONSTANT_VALUE(name, type, value)\
> > template<>\
> > name##_type::operator type() const { return value; }
> >
> > --- End ---
> >
> > My question is: Is there any reason why it can't be done this simple?
>
> Yes. AFAICS wrong use of your constants with unsupported types is only
> cought at link-time, not at compile-time. This is IMHO a big problem, big
> enough to reject this approach.
Ok. So maybe an extra level of indirection, as in your code (and
Kenniston's) may be preferable. I was wondering what was the point with it.
:)
Another thing, are the ADD_OPERATOR macro in your code necessary? It
compiles fine without it on Intel C++ 7.1.
> Also, I'm not sure whether it's standard compliant code.
I think it is. It specialises a member. What could be the problem with this?
As you say, errors are caught at link time.
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - using namespacestoselectfloat size is simpler?
| Well, you wanted to know what is likely to be accepted. In a | formal review (this isn't anymore, AFAIU, is it?) I would | vote no to your approach. But would you vote yes if the only presentation was Daniel's method? I am only really concerned that the accurate constants become more standardised, in name and value. Paul PS I'd like to hear more views on this - previous review comments were quite different, being very cautious about an 'advanced' scheme like this. Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK +44 1539 561830 [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - using namespaces toselect float size is simpler?
I stand better informed than I really wanted to be,
and only quacking quietly from getting my mind round
the implications of these rather complex rules.
(They remind me of PL/1 automatic conversions which were
designed by IBM sales managers to sell computers
but ended up being a maze of snares for the unwary.)
This scheme may offer more surprises to the many naive users (like me)
than an explicit (and convenient 'global') choice, for example:
using boost::math::double_constants;
to ensure that the expected size is used.
One can make the compiler warn you about size conversions,
whereas I have the impression that these rules will mean
that you won't get any warnings.
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK
+44 1539 561830
[EMAIL PROTECTED]
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] On Behalf Of Gennaro Prota
| Sent: 19 June 2003 11:10
| To: [EMAIL PROTECTED]
| Subject: [boost] Re: Math Constants Formal Review - does
| static_cast merely select?
|
|
| On Wed, 18 Jun 2003 22:27:27 +0100, "Paul A Bristow"
| <[EMAIL PROTECTED]> wrote:
|
| >| -Original Message-
| >| From: [EMAIL PROTECTED]
| >| [mailto:[EMAIL PROTECTED] On Behalf Of Gennaro Prota
| >| [...]
| >|
| >| In Daniel's solution static_cast(x) simply "selects"
| >| the corresponding specialization of x_value. So
| >|
| >|static_cast(pi)
| >|
| >| is fundamentally different from, say,
| >|
| >|double pi = ...;
| >|static_cast(pi)
| >
| >Perhaps naively, I find this surprising - but I am not a
| language guru.
| >
| >Can you/anyone confirm that this is required by the Standard
| > - and is in fact what happens when compilers process this?
|
| Yes :-) Note that all "conversions" from a constant
| pass through
|
|template< typename U > operator U() const { return F< U >()(); }
|
| Now, F()() means (ignoring some technical differences irrelevant
| here):
|
|F object; // construct an x_value object
|return object(); // invoke operator() on it and return
|
| Now, if you use the binary operators, like in:
|
| pi * f;
|
| with f being a float then the selected specialization is
| float; i.e. the constant "takes the type" of its adjacent
| operand (left operand if it exists, right operand
| otherwise). This is, of course, different from what normally
| happens when you do
|
|double pi = ...;
|pi * f; // floating point promotion on f
|
| and is IMHO a caveat. But, still, there are no truncations.
| Only selection of the target specialization. If no target
| specialization exists, e.g.
|
|static_cast(pi)
|
| you have a compile-time error.
|
| >
| >If it walks like a duck and quacks like a duck ...
|
| This walks quite differently. And doesn't quack :-)
|
|
| Genny.
|
| ___
| Unsubscribe & other changes:
| http://lists.boost.org/mailman/listinfo.cgi/b| oost
|
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - accuracy is vital too
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Reece Dunn | Sent: 18 June 2003 20:23 | To: [EMAIL PROTECTED] | Subject: Re: [boost] Re: Math Constants Formal Review - | Also, using constructs like this is easier for the | programmer. You don't have to search to see if there is a pi/2 constant and find | out what it is called, you simply use: | boost::pi / boost::two or whatever. Previous opinions were in favour of a larger set of constants, and there was considerable discussion about a set of names which were finally agreed to be reasonably consistent. Are you forgetting the very important need that the constants mesh with the Boost interval library? For these I think you need pi_div_3, for example, to provide the upper and lower interval values. (These in turn depend on the floating-point format). What about the complex case, for which an example is provided by Michael Kennistons scheme? Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - does static_castmerely select?
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Gennaro Prota | Sent: 18 June 2003 15:45 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review - accuracy | is vital too | | > the proposed code uses namespaces | >to allow selection of the FP size either individually: | | In Daniel's solution static_cast(x) simply "selects" | the corresponding specialization of x_value. So | |static_cast(pi) | | is fundamentally different from, say, | |double pi = ...; |static_cast(pi) Perhaps naively, I find this surprising - but I am not a language guru. Can you/anyone confirm that this is required by the Standard - and is in fact what happens when compilers process this? If it walks like a duck and quacks like a duck ... Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - optimal code?
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 18 June 2003 11:15 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review | >>Paul A Bristow wrote: | >>>I am confident that your system also generates efficient | code using | >>>an efficient compiler. But have you considered or tried debugging? | > What should be verified? Previous work using this templating technique produced some code in debug mode which was rather confusing to debug. Every time a constant like pi was used, you had to step through procedure call code. This was a minor but most irritating and distracting feature compared to code from plain const double pi. | How efficient different compilers work with the template-approach I | showed. I'll try to do that for the GCC 2.95 / 3.x and for the Intel | compiler (v7) at the weekend, but my experience with reading | x86-assembler is limited, so maybe I'll just run some | benchmarks. As I don't have/use Windows, I can't verify compilers for this platform. Ed Brey has recently verified that with MSVC 7.1 the Kenniston code looks optimal, and that no code is generated for unused constants. (You can see the previous MSVC 6.SP5 assembly output as comments at the end of testFunctionConstants.cpp 6.SP5 did create unwanted code in 'strict' mode). I strongly recommend looking at the code as well - you might find benchmarks by themselves misleading. You should see a Fstp or fld qword ops - I think. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK +44 1539 561830 [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Math Constants Formal Review - accuracy is vital too
Gennaro Prota wrote: In fact it's not a matter of speed, but of precision. I'm sure there are compilers where the -sin(pi/2.) in the example code is faster than -sin(pi/two ). However an overload allows you to specify that the value of, say, arccos(-1) [math::acos(minus_one)] is exactly pi. Also, using constructs like this is easier for the programmer. You don't have to search to see if there is a pi/2 constant and find out what it is called, you simply use: boost::pi / boost::two or whatever. This also makes it easier to read, rather than arccos_minusone and pi_2 What about 2/pi: 2_pi // illegal _2_pi or two_pi // counter intuitive Using overloads makes it easier to extend this set in a clean, consistent way. Regards, Reece _ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - accuracy is vital too
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 17 June 2003 11:19 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review I have now studied your code - only on paper - rather more carefully, which I apologise for not doing carefully enough before. It seems to have some similarities to the code written by Michael Kenniston which is now being reviewed. I am not sure that I fully understand how and why it works, and I do not yet see what advantages it may have. I would much welcome more independent expert input, but I do note: The float and long double constant values do not include F and L. Previous agreement was that this was needed to to avoid any chance of computation by the compiler. This could of course be easily added. A vital feature is that the compiler should only use the 40 decimal digit literal values provided and should NOT do any calculation. This is because the compiler will only use the floating-point accuracy of the hardware whereas the important feature of the values provided is that they are calculated by a much higher precision software system, in this case NTL. It is difficult to foresee compiler writers opting to use higher accuracy floating-point because it would be much slower, and only rarely add any value. Maximum possible accuracy is a central feature, promising the best possible portability, especially for intervals where every really bit really counts. It was also agree that any casting to obtain other types did not garanteed accuracy and this was why the proposed code uses namespaces to allow selection of the FP size either individually: boost::math::double_constants::pi or boost::math::float_constants::pi or 'globally' - suiting most applications using namespace boost::math::double_constants; and then accessing using just plain pi. I feel that static_casting definitely needs to be avoided. Perhaps your code can achieve this by some modification? Although your operators are neat, speeding -sin(pi/two), my suspicion is that it is better to pre-calculate as many constants as possible, and as accurately as possible. I don't think this counts as "premature optimisation" :-) Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK +44 1539 561830 [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - ()s are a key issue.
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 17 June 2003 11:19 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review - ()s are | > 1 Control of precision is essential, | > and some users wanted to be able to use | > float, double and long double at the same time. | "at the same time" is exactly what the "separate headers approach" | doesn't provide if you can only include one at a time IIUC. Absolutely, but on the previous review, many users wanted to "Keep It Simple Sir" and deliberately only have (for example) double const pi - avoiding the complexity of other schemes, get warnings of conversions, difficulty during debugging, and inefficient code from older compilers. They would chose just the plain double const files. You would just ignore them - at no cost to you! | > 2 Avoiding paying for what you don't use, which leads to | Hm, there is some small overhead, but not much IMHO. In fact | far less than a lot of other boost libraries. :) Agreed, though don't forget there are dozens of constants, not just pi. | > 2a MACROS provide a simple way of avoiding some cost for | > constants you don't use, (Although some Boosters were opposed | > to MACROs because they pollute the global namespace). | | I'd like to backup the latter. | With MACROs, you cannot add a 'using | namespace boost::math;' and use a plain 'pi' instead of 'BOOST_PI'. | Using MACROs is a pain and should be avoided if possible. Agreed but ... Some users wanted to "Keep It Really Simple Sirs" and for them the MACROS files are available. For systems where every byte counts, they may be best. (For me, while generating the other files, the extra cost of generating the MACROS file is negligible). If you hate MACROs them don't use these files - at no cost to you! | But this is exactly what my code tries to do. You write | 'pi', and when | using it, all calcalations are forwarded to use the value | returned from | a function (actually pi_value::operator()). Some magic is | provided | for convenience like in the example above and you can select | the type | explicitly be using a static_cast. AFAICS you get all what you are | asking for... I will try to compare your proposal more carefully with Michael Kenniston's version - which seems to work efficiently and conveniently and extensibly with small enough risk of surprises about precision for novice users. As Ed Brey reported during this review, Kenniston's method files DO generate efficent code with Optimising MSVC 7.1 and gcc, not creating any code for unused constants - an important requirement. So the only cost is in compile time - which should be tolerable. However I am away from my machine at present so it may be a day or two. If you have more examples of use similar to those in the folder "testFunctionConstants", containing a test.cpp with lots of comments and header functionconstants.hpp these will be helpful. the Folder pi also gives his examples of extending to handle complex. quadfloat folder gives an example of a UDT (a 128bit floating point software type). I am confident that your system also generates efficient code using an efficient compiler. But have you considered or tried debugging? Paul ___ 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: 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
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey
| Sent: Tuesday, June 10, 2003 4:51 PM
| To: [EMAIL PROTECTED]
| Subject: [boost] Re: Math Constants Formal Review
|
|
| > [3] Physics-based constants should be definable within the constants
| > framework and should be set to their current accuracy (possibly making
| > use of intervals).
|
| Maybe we could provide some defaults that can be overwritten by the
| user? Something like:
|
| --- header physics_constant_values.hpp
|
| template< typename T > struct g_default_value;
| template<> struct g_default_value< double >
| { double operator()() const { return 9.81; };
|
| template< typename T > g_value : g_default_value< T > {};
|
| --- header physics_constants.hpp
|
| #include
| struct g_t : constant< g_t, g_value > {} g;
|
| --- user adds to his project-header physics_constants.h:
|
| #include
| template<> struct g_value< double >
| { double operator()() const { 9.81424242424; } }; // Ha, I know better!
| #include
No objections to this but I really would like to follow the conclusion of the
previous review that we should concentrate on math constants FIRST - getting
agreement on them seems to be plenty difficult enough!
Paul
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review
This could be further optimized by adding the rules
T operator*( T val, one_t ){ return( val ); }
T operator*( T val, minus_one_t ){ return( -val ); }
T operator+( T val, zero_t ){ return( val ); }
-
Of course you could do the others as well.
T operator/( T val, one_t ){ return( val ); }
T operator/( T val, minus_one_t ){ return( -val ); }
T operator-( T val, zero_t ){ return( val ); }
zero_t operator*( T val, zero_t ){ return( zero_t ); }
T operator/( T val, zero_t ) { throw divide_by_zero; }
The nice thing is that if you are copying a formula into some code you don't have to
do the optimizations by hand.
-Gary-
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Math Constants Formal Review
At 01:57 PM 6/8/2003, Gennaro Prota wrote: >On Sun, 8 Jun 2003 15:56:53 +0100, "Paul A Bristow" ><[EMAIL PROTECTED]> wrote: > >>If someone would like to do this, I'd be grateful. >> >>(Memories of how to use commandlines and CVS have decayed). > >IIUC, the boost sandbox is, so to speak, a more precious resource than >the Yahoo files section. So, unless there's a need to "develop there" >(for instance because many people should simultaneously work at the >files, or because it's appropriate to have a record of all the changes >and who made them) the Yahoo section or any private web spaces should >be preferred. It seems a waste to use a cvs repository just to provide >a place to get things from. But, maybe, the policy is different and I >don't know. It would be nice to have a confirmation. I'm sure Beman or >Dave can give it. > What Daryle is talking about is not the sandbox CVS itself, but boost-sandbox project web space that you get from SourceForge, separate from the CVS. We use that space on the main boost SourceForge project for publishing daily regression tests, for example. Yes, it would definitely be a good idea. It means that those wishing to grab code for a review do not have to deal with yahoogroups. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Math Constants Formal Review - recap & summary
A Mini-recapitulation of the _long_ saga so far:
Briefly I propose many different representations for constants,
because after much discussion and experimentation, no
universally-acceptable format and no disadvantage-free format has
been found.
1 We agree on the need for accurate mathematical constants
- pi, e, sqrt(2) for a start, but many others are 'essential' to
some people.
2 Physical constants are a separate matter for their accuracy is not
constant.
3 Some constants cannot be calculated accurately by current
compilers because they use 'built-in' hardware floating-point, and
this is unlikely to change. Only constants calculated with a higher
precision software system, like NTL,
will ensure that the constant is stored
as accurately as the floating-point hardware will allow.
4 40 decimal digits are sufficient for all practical purposes
(except intervals see below), and compilers are (or really should
be) capable of reading decimal digits into their various internal
formats (float, double, long double).
5 A C++ naming scheme for math constants has been devised which is
at least acceptable (if inevitably a compromise).
6 Control of precision is essential, but there is opposition to a
C-style solution using three names for each constant, for example:
float pi_F, double pi_D, long double pi_L. Nor, in Boost
discussions, did use of namespaces to separate different precisions
seem acceptable.
7 There are dozens of constants that some users rate 'essential'.
Splitting into several #include files still risks violating the
"don't pay for what you don't use" principle.
8 Only MACROS provide a simple way of avoiding some cost for
constants you don't use. (but Boosters expressed strong opposition
to MACROs because they pollute the global namespace, even if #undefs
are provided).
9 Users extremely strongly prefer to write "float area = pi * r * r;"
10 There is evidence that some compilers can generate better code
from functions like "double pi() { return 3.1459;}"
but that this implies writing pi() instead of plain "long double pi". So
the ()s remain a major issue.
Michael Kenniston had a previous interesting suggestion
but which did not seem entirely satisfactory.
He has now produced another which is attached.
Briefly, this allows 'novice' users to write "pi" but
get the effect of "pi()" without too many precision surprises. Yet
it still allows the 'expert' to write "pi()" and control precision
explicitly. But there remain some disadvantages - see FAQ.
11 Finally the acceptance of the Interval Library into Boost means
there is a real need for intervals containing constants - upper and
lower limits. Examples have been calculated as 'exact representations'
and
discussed before. This increases the number of constants potentially
required to achieve the required accuracy (for example, 2_pi
interval IS needed).
| -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
|
|
| I currently vote neither yes nor no. I just need to get a
| better understanding of what is intended to be included into
| boost from the files provided.
|
| On Fri, 06 Jun 2003 19:21:08 +0200, Paul A Bristow wrote:
|
| > but I hope the review can concentrate on what emerged
| previously as
| > the _really_ tricky issue of how to _present_ the values in C++,
|
| I looked at the files and I think that they need some clean
| ups. Also, I don't really see the concept behind it. How are
| the values presented and how does your way compare to other
| options? (Well, I basically can fiure out the first part,
| but without the second, I can't really understand it). Maybe
| you can provide some links to the key messages of the
| discussion that lead to it or give us a short summary.
|
| 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
RE: [boost] Re: Math Constants Formal Review
If someone would like to do this, I'd be grateful. (Memories of how to use commandlines and CVS have decayed). Paul Paul A Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daryle Walker | Sent: 06 June 2003 23:47 | To: Boost | Subject: [boost] Re: Math Constants Formal Review | | | On Friday, June 6, 2003, at 6:45 AM, Jaap Suter wrote: | | > Today is the start of the formal review of the Math | Constants library | > by Paul Bristow. The review will run until Sunday June | 15th. I will | > be serving as review manager. | > | [SNIP] | > You can find the latest documentation, including a bigger | FAQ section, | > at: | > | > http://groups.yahoo.com/group/boost/files/MathConstants/ | > Math_Constants_doc_3.zip | > | > Some examples are available at: | > | > http://groups.yahoo.com/group/boost/files/MathConstants/ | > Math_Constants3.zip | [TRUNCATE] | | In the previous review, copies of the code and documentation of the | Command & Config Option library were copied to the web space | SourceForge reserved for the Boost-Sandbox. Maybe we could | do the same | for this review (and all later ones). | | Daryle | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review
| Genny wrote | Paul> What I would like to get is agreement on the presentation | of constants. | | You mean macros vs. constant variables vs. inline functions? | This is another thing I didn't understand by looking at the | documentation: the FAQ section seems sometimes to imply you | have already done a choice in this regard; In the previous review, Boosters suggested strongly different views on different ways of presenting constants. As I have tried to explain, there are pros and cons and valid reasons for wanting all of these. for instance: | | Q. Why not use floating-point hardware constants? | A. Because only a few are available, they are often not the right | size, are not available on all processors, and most important | are sometimes not accurate enough. | | but then, in another point: | | Q. Why are functions like double pi() which return constants | provided? | A. It provides a framework whereby users can plug in special | implementation and hardware-specific versions. Indeed - so the _user_ needs to be able to make the choice, and this implies that a single representation of constants won't do. | "Because some compilers may be able to produce smaller | and/or faster code.(For example, note that MSVC 7 Standard | edition only inlines "__inline", so this will produce slower | and longer code)." | | Maybe you meant: "because some compilers generate better | code with a manifest constant and others better code with a | function"? You could also say that - I'm open to suggestions. Paul ___ 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
RE: [boost] Re: Math Constants Formal Review
None of the material is yet ready for inclusion in Boost, (with the possible exception of the C Macro values). What I would like to get is agreement on the presentation of constants. (Because there is much work in preparing the constants and I am reluctant to do this without assurance that it will finally be accepted.) I suggest unzipping the documentation in the docs file - in effect everything I am proposing from the previous dicussions is there. Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Gennaro Prota | Sent: 06 June 2003 18:20 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review | | | On Fri, 6 Jun 2003 06:45:45 -0700, "Jaap Suter" | <[EMAIL PROTECTED]> wrote: | | >To all, | > | >Today is the start of the formal review of the Math | Constants library | >by Paul Bristow. The review will run until Sunday June 15th. | | I tried to have a look but was assailed by a fairly large | amount of material :-) Can we a have a .zip with just what | is candidate for inclusion into boost? | | | Genny. | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
