Math constants - update & files removed
As requested by Beman, I have purged all my math constants proposals, except the latest version, from the files section. I have also updated the copyright notices on the macro (36 decimal digit) constants values, and posted these zipped. Until we can agree a better method of presenting math constants, these may save users surfing the net for individual values. (Since some people seem to find the files section inaccessible, should they be copied to the CVS sandbox too?) Since the two files (to #define and #undef) are quite short, they are also attached for your convenience. Please tell me of any mistakes you find. Paul PS If anyone has any suggestions on solving the presentation problem please say so. Daniel Frey seems close to a portable solution, but "a miss is a good as a mile" :-( Type deduction seems the nub of the problem: can anything from FC++ help? Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
Paul A Bristow wrote:
As requested by Beman, I have purged all my math constants proposals, except the latest version, from the files section.
I have also updated the copyright notices on the macro (36 decimal digit) constants values, and posted these zipped.
BOOST_E is #defined twice. Is that intentional? // Fredrik
Ooops - but harmless. Will be corrected - this is only an interim until we resolve the C++ presentation problem. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Fredrik Blomqvist | Sent: 19 February 2004 20:22 | To: boost@lists.boost.org | Subject: [boost] Re: Math constants - update & files removed | BOOST_E is #defined twice. Is that intentional?
On Thu, 19 Feb 2004 15:55:08 -0000, "Paul A Bristow" <boost@hetp.u-net.com> wrote:
Daniel Frey seems close to a portable solution, but <...>
Daniel, could you please summarize your problem? Actually I saw a sketch implementation of your idea a while ago and I quite liked it. I know there were problems with some compilers though and that there were doubts as to whether the code was standard conforming or not, but I can't recall the details. I would search the list archives but it's likely that the old discussions refer to a version of the code that you have changed later. Please, bring me up to date 8-) -- Genny.
Gennaro Prota wrote:
On Thu, 19 Feb 2004 15:55:08 -0000, "Paul A Bristow" <boost@hetp.u-net.com> wrote:
Daniel Frey seems close to a portable solution, but <...>
Daniel, could you please summarize your problem? Actually I saw a sketch implementation of your idea a while ago and I quite liked it. I know there were problems with some compilers though and that there were doubts as to whether the code was standard conforming or not, but I can't recall the details. I would search the list archives but it's likely that the old discussions refer to a version of the code that you have changed later. Please, bring me up to date 8-)
OK, here we go: - The latest version can be found in the files section <http://groups.yahoo.com/group/boost/files/MathConstants/>. Have a look at _m2_v2 and also at the examples for the unit libraries. They are probably good to show why a simple approach using #define is doomed to fail in the light of generic programming :) - I don't have enough time (as usual) - No documentation yet (will come next) - The current version works on GCC3+ and Intel7+, but there were some problem with the VC7.1, which gave an internal compiler error. As I don't have the VC7.1 (not even Windows), I need help here. The code itself should be standard conforming, though, but I admit it's driving compilers to the edge - and further ;) OTOH, I don't see the point in providing bad interfaces to support old, non-conforming compilers - YMMV. - typeof would be a great help, otherwise I have to switch back to some other system to deduce the operator's return types. Probably like bind/lambda do. I think that there is a need for such a general component which should IMHO use typeof when available and manually configuration from the user otherwise. Due to the mentioned lack of time, I haven't done anything useful in that direction yet. IIUC, FC++ would also benefit from such a component, so I think we should really attack this topic soon. Anyone? :o) HTH Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de
participants (4)
-
Daniel Frey -
Fredrik Blomqvist -
Gennaro Prota -
Paul A Bristow