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