Thorsten Ottosen wrote:

Yes, of course. BTW, I've attached the file since my messages seems to format the code like ****.

br

Thorsten

With no offense intended, but that's a very simple version which doesn't work in many situations. The problems of your solution are: - Doesn't work well for UDTs (try std::complex, some conversions are ambiguous then) - Doesn't scale for new types (you need to know all of them in the single header that defines the constant) - Doesn't work for more complex expressions (pi*pi*t instead of T(pi)*pi*t) - Doesn't work for function calls (srqt(pi)*t instead of sqrt(T(pi))*t) - Doesn't solve the naming dilemma (how to spell the constant "pi*pi"?) - Doesn't work well with unit libraries AFAICS (again not scaling well) I really suggest you look at my code at <http://groups.yahoo.com/group/boost/files/MathConstants/>, which solves all of the above points. Feel free to ask questions. 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

Thorsten Ottosen wrote:

...

With no offense intended, but that's a very simple version which doesn't work in many situations. The problems of your solution are:

- Doesn't work well for UDTs (try std::complex, some conversions are ambiguous then)

What rule of the language prohibit this conversion? My vc71 compiler can do it, como and g++ cannot.

It depends on what exactly you tried. The basic problem is, that T(pi) tries to call a ctor for T, but std::complex has several candidates available. std::complex<double>(std::complex<double>) and std::complex<double>(double) might conflict here, except you don't provide conversion to std::complex<double> for your constants. But you cannot assume this for other UDT. What happens if a UDT has ctors taking float, double and long-double? You can't use your constants any more, even a new conversion to the type directly won't help. This is (one of the reasons) why I provide .get<T>() instead of T(pi), static_cast<T>(pi) or pi.operator T(). While the alternatives all look very promising, they have some severe problem: You can't influence what they actually do. This becomes important when you think of unit-libraries, see the examples I put into the files section.

...

- Doesn't scale for new types (you need to know all of them in the single header that defines the constant)

You could add the overloads with eg a macro in your own header. What should hinder this?

Macro's are ugly. OK, not a very compelling reason :-) Still I would feel somewhat limited when I have to provide all of this stuff through macros. Also, I can't add values only for selected constants, once I start using macros, I have to prove them for all constants. Maybe this can - again - be fixed by some preprocessor magic, but it's well possible without the preprocessor at all.

...

- Doesn't work for more complex expressions (pi*pi*t instead of T(pi)*pi*t)

true, but what precision does pi*pi have? IMO, it's good to have that information in the code.

I disagree. You already found out that a certain convenience is necessary. You don't write T(pi)*t (t being of type T), just pi*t. This automatically selects the type/precision for pi in this expression. Why shouldn't this scale to pi*pi*t? Or sqrt(pi)*t. The first non-constant should select the type, no matter how the constants are used before.

...

- Doesn't solve the naming dilemma (how to spell the constant "pi*pi"?)

is pi_square that bad?

Yes. It clutters my brain with more names. pi*pi is a general principle I already know. Also, 1/srqt(e) is easy to remember, but what would the name be when using you scheme? It also makes the code less readable IMHO.

...

- Doesn't work well with unit libraries AFAICS (again not scaling well)

how?

Because they need to return a different type than what they are asked for. And casting them is not an option, as you need to know the unit and spell it out explicitly. Look at the ideal-gas-law-examples. You want to use the constant without spelling out it's type over and over again, won't you?

Is there any documentation?

Well, that's the weak point currently. I hope that I can come up with some docs in the next weeks. Currently, all I can offer is that I answer questions. Sorry.

...

From your example file:

std::cout << pi.get< float >() << std::endl;

which is float( pi ) spelt more elaborate.

As mentioned, this is a very important thing to note that .get<T> is free to return something else than T!

std::cout << pi + pi - pi * pi / pi + d << std::endl;

how often does such an expression occur in practice? Afterall, a single pi would do.

Look at some physical laws. There are often combinations of several constants and if possible, I don't want to limit the programmer if there isn't a compelling reason to do so. People should be able to express their thoughts as direct as possible. They shouldn't be forced to care about the language more than neccessary.

std::cout << sqrt( sqrt( two + pi ) ) + d << std::endl;

will everything left of d be a constant? If so, what would the point be?

Basically, it's not a single constant. The constants are both casts to d's type, added and sent through sqrt two times. But you can - if you want to - make it a single, fast constant if you think it's worth the effort for your program. 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

Thorsten Ottosen wrote:

"Daniel Frey" <daniel.frey@aixigo.de> wrote in message news:c1vlqp$90l$1@sea.gmane.org... Thorsten Ottosen wrote: [snip]

...

It depends on what exactly you tried. The basic problem is, that T(pi) tries to call a ctor for T, but std::complex has several candidates available. std::complex<double>(std::complex<double>) and std::complex<double>(double) might conflict here, except you don't provide conversion to std::complex<double> for your constants. But you cannot assume this for other UDT. What happens if a UDT has ctors taking float, double and long-double? You can't use your constants any more, even a new conversion to the type directly won't help.

Sorry, but I don't get this.

complex<float> z = float( pi );

should work just fine.

Sure, but what about complex<float> z = complex<float>(pi)? Indeed, think about a generic algorithm: template<typename T> T area(const T& r) { return pi * r * r; } (or even T(pi)*r*r). You need constants that work well for all types with no special treatment of some types.

...

Why shouldn't this scale to pi*pi*t? Or sqrt(pi)*t. The first non-constant should select the type, no matter how the constants are used before.

Yeah, I could let pi * pi return a two_pi object.

No. OK, "yes" for this example, but "no" in general. You cannot predict all combinations the user could write. Simply providing all possible combinations is ridiculous overhead which doesn't scale well. My constant library works for any combination, whether predefined (that is, there is a real constant pi_square (ha, you got fooled by your own names - the naming dilemma! :) ) ) or not.

...

...

...

From your example file:

std::cout << pi.get< float >() << std::endl;

which is float( pi ) spelt more elaborate.

As mentioned, this is a very important thing to note that .get<T> is free to return something else than T!

maybe not the best way to spell the function then?

I'm open to suggestions. I don't like .get<T>() very much myself, but I can't imagine any better solution. 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

Thorsten Ottosen wrote:

"Daniel Frey" <daniel.frey@aixigo.de> wrote in message news:c21jp0$2i8$1@sea.gmane.org...

...

...

Sorry, but I don't get this.

complex<float> z = float( pi );

should work just fine.

Sure, but what about complex<float> z = complex<float>(pi)?

works.

OK, bad example. Your version of pi works, because it doesn't offer a conversion to complex<float> directly. But what about boost::rational<T>, RWDecimal<RWMP3Int>, qdouble, etc.? Note that it's intended that you don't know all of them by heart :) You rely on special properties of std::complex, which are not given in general. Effectively, I'd say that you don't support complex, you ignore it. But complex supports conversions from/to float, double and long double as required, which makes it compatible with your constants. To put it another way: You require a specific design of compatible types for your constants. This is an unnecessary restriction which limits the use of your constants, as there are several types out there that won't match these requirements.

...

Indeed, think about a generic algorithm:

template<typename T> T area(const T& r) { return pi * r * r; }

also works. At least for float, double, and long double. Do you mean that your version will work with physical quantities like meters?

No, I was talking about the types listed above (rational, RWDecimal, ...). Currently, unit libraries require their own version. Although the decltype/auto-proposal would allow us to write a really cool generic version: template<typename T> auto area(const T& r) { return pi*r*r; } :))

If so, could I achieve the same effect by adding

template< typename T > inline T operator*( T l, pi_t ) { return something; }

?

Depends on the ctors of T.

...

...

...

Why shouldn't this scale to pi*pi*t? Or sqrt(pi)*t. The first non-constant should select the type, no matter how the constants are used before.

Yeah, I could let pi * pi return a two_pi object.

No. OK, "yes" for this example, but "no" in general. You cannot predict all combinations the user could write. Simply providing all possible combinations is ridiculous overhead which doesn't scale well. My constant library works for any combination, whether predefined (that is, there is a real constant pi_square (ha, you got fooled by your own names - the naming dilemma! :) ) ) or not.

:-) Ok, but I don't quite see how your approach works for all combinations without coding support for them. But I'm willing to wait till you write some docs about it to find out.

Well, all I can say is: It works. The type selection is defered and intermediate constants (and expressions with constants) are automatically generated by the compiler. As they are themself constants, they finally convert to the right type. But I'll try to explain it better in the docs. :) 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

On Mon, 01 Mar 2004 18:09:20 +0000, Paul A Bristow wrote: [Daniel Frey said:]

| I really suggest you look at my code at | <http://groups.yahoo.com/group/boost/files/MathConstants/>, which solves | all of the above points. Except that VC 7.1 doesn't think it is legal C++ :-(( I think we need to establish if it is correct (as gcc and Intel think it is)

Nope, as has been said a number of times, it is not valid C++. typeof is not in the existing C++ standard. It is a very useful extension implemented by a number of vendors, but that doesn't make it standard.

Or to find some workaround that VC 7.1 will accept.

Indeed.

It would be helpful to know what do other highly conformant compilers, like CodeWarrior and Comeau, say about Daniel Frey's proposal?

Well, you still have to get over the boost Guidelines saying: Aim for ISO Standard C++. Than means making effective use of the standard features of the language, and avoiding non-standard compiler extensions. It also means using the C++ Standard Library where applicable. It doesn't forbid using extensions, but I seem to remember David Abrahams being a little more assertive about not using non-standard extensions :-) phil -- change name before "@" to "phil" for email

Sorry to bang on about this, but we still haven't sorted it out. To re-cap, it seems that the solution proposed a long time ago by Michael Kenniston and recently by Thorsten Ottosen don't give as much 'extendibility' to user defined floating point types (quaddoubles, RWsuper doubles, rational, interval, etc) as some would like. Daniel Frey has produced two solutions which seem to provide this extendibility, BUT 1 His version 2 works on Intel (EDG?) and GCC compilers, but trips VC7.1 (see below). Is this because VC7.1 is 'broken', or is it because it isn't really legal code (or is the language ill-defined in this area). Opinions on this would be most welcome. What the other compilers make of his code may be revelevant? If there is a consensus that VC is wrong, then we can perhaps get it fixed? 2 Daniel's Version 3 uses typeof which is not yet part of the language - but is very likely to become so eventually. Our other option is to wait until it is added before we try to provide the ultimate 'constants' solution. 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 Daniel Frey | Sent: 01 March 2004 21:40 | To: boost@lists.boost.org | Subject: [boost] Re: [math constants] C++ Language gurus | views needed and Codewarrior & Comeau testers | | | Phil Richards wrote: | > On Mon, 01 Mar 2004 18:09:20 +0000, Paul A Bristow wrote: | > [Daniel Frey said:] | > | >>| I really suggest you look at my code at | >>| | <http://groups.yahoo.com/group/boost/files| /MathConstants/>, | which solves | >>| all of the above points. | | >>Except that VC 7.1 doesn't think it is legal C++ :-(( | >>I think we need to establish if it is correct (as gcc and | Intel think it | >>is) | > | > Nope, as has been said a number of times, it is not valid | C++. typeof is | > not in the existing C++ standard. It is a very useful extension | > implemented by a number of vendors, but that doesn't make | it standard. | | That's not fair. VC7.1 is *not* failing because of my use of | typeof. We | could provide a fallback for retrieving the return type of the | expressions. The point is, that the VC7.1 already failed with an | "Internal compiler failure" on previous version that were | 100% ISO-C++. | Please try to understand the problem first before accusing me | of writing | offending non-standard code which hurts the poor, innocent VC7.1 :-) |

I believe it is in the files section math constants - second try by Daniel Frey. Daniel Frey's constant library milestone 2 /MathConstants/constant_library_m2_v1.tgz 21 Aug 2003 (The typeof using version is _v2 dated 24 Jan 2004 A test (and views on the sighnificance of the result) would most helpful. (Or even better if you can say if any workaround is possible). Thanks 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 Bronek Kozicki | Sent: 07 March 2004 16:56 | To: boost@lists.boost.org | Subject: [boost] Re: [math constants] C++ Language gurus | views needed andCodewarrior & Comeau testers | | | On Mon, 01 Mar 2004 22:40:06 +0100, Daniel Frey wrote: | > That's not fair. VC7.1 is *not* failing because of my use | of typeof. We | > could provide a fallback for retrieving the return type of the | > expressions. The point is, that the VC7.1 already failed with an | > "Internal compiler failure" on previous version that were | 100% ISO-C++. | | I'd like to test it and report to vendor (assuming VC71 is to blame | here). Where is the code (the one without "typeof") I could test? | | Thanks | | | B. | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cg| i/boost | |

On Sun, 7 Mar 2004 17:54:37 -0000, Paul A Bristow wrote:

Daniel Frey's constant library milestone 2

/MathConstants/constant_library_m2_v1.tgz 21 Aug 2003

Ok, thanks. I have it. After some fixing (change file extension from .cc to .cpp, change line endings from LF to CRLF, append one more directory to INCLUDE) I received following error: example.cpp(18) : error C3200: 'boost::math::pi_value<T>' : invalid template argument for template parameter 'F', expected a class template example.cpp(18) : see reference to class template instantiation 'boost::math::pi_value<T>' being compiled example.cpp(81) : fatal error C1903: unable to recover from previous error(s); stopping compilation I have stripped down problematic code to very simple: #include <iostream> template <template <typename> class F, typename T> struct constant_value { T operator()() const { return T(); } }; template <typename T> struct pi_value : constant_value <pi_value, T> {}; int main() { pi_value<double> t; std::cout << t(); } and tried it under Comeau (online), with no problems. It also compiles fine under GCC 3.3.1 (mingw). From my (limited) understanding of templates this code is fine, thus apparently there's problem with VC71. Looks like using template being just defined as template template parameter makes VC71 confused. I reported it to Microsoft (on its private newsgroup). B.

On Sun, 7 Mar 2004 22:53:43 -0000, Paul A Bristow wrote:

Many thanks - that is most helpful and may eventually solve the problem.

It's just a beginning :) anyway, Jim Apple pointed out that using namespace qualifier can fix *this* problem, indeed it did. After changing line 18 of example.cc (example.cpp on my computer) to: template< typename T > struct pi_value : constant_value< boost::math::pi_value, T > {}; I received nice INTERNAL COMPILER ERROR. Now I need to reproduce this error in some smaller sample code, and then post it to MS newsgroups. This task have to wait (it's midnight here in Poland, and I have plenty of work starting tommorow morning - deadlines are killing me :( ). Kind regards B.

Daniel Frey wrote:

As the documentation is making only slow progress (that's not: "no progress" :), I think I'll try to hack together a non-typeof-version to give you some more stuff to test. Maybe this evening, otherwise it will be by the end of the week.

OK, I uploaded a new version (m3) to the files section. It fixes the bug with the template template parameter mentioned and it doesn't use typeof. You can reenable typeof (and thus added functionality) by defining BOOST_HAS_TYPEOF in the new header file constant/config.hpp. The example-program included (which is still the same as in m2) works without the typeof, but the unit-library examples won't work. This is IMHO not a big problem as we can add better workaround for missing typeof later (other Boost-libs show what's possible, see bind/lambda). The m3-version should thus be a standard conformant version which can be tested on any compiler. Please give it a try and report results (and probably analysis and workarounds when it fails) here, thanks. Regards, Daniel

Bronek Kozicki wrote:

On Mon, 08 Mar 2004 20:11:19 +0100, Daniel Frey wrote: Good news is that there is no ICE, bad news is that it does not compile. I have a lot of compilation errors, please find attached file.

There is no attachment. Can you repost it, please? (Or is it a problem on my side and anyone else sees it?) Regards, Daniel

OK, thanks for the tests so far. What we can see is that operator T() caused the ICE (as I suspected), but now we need to find out what exactly the problems with the current version is. It seems to me that the VC7.1 has problems deducing template template parameters. Could the interested folks please test whether is_constant works as expected? It's AFAICS the basic requirement for anything else to work. The next step is to test whether it's a problem for the VC to deduce parameters from base classes. Here's some code to illustrate the idea: template< typename T > class V {}; template< template<typename> class T > struct B {}; struct D : B<V> {}; template< typename T > void f( const B<V>& ) {} int main() { D d; f( d ); } Regards, Daniel

Daniel Frey <d.frey@gmx.de> wrote: [...] I tried following code: #include <iostream> template <typename T> class V {}; template <template <typename> class T> struct B {}; struct D : B<V> {}; template <typename T> void f (const B<T>&) { std::cout << typeid(T).name() << std::endl; } int main() { D d; f (d); } According to Comeau compiler and GCC this program is invalid. I have following error messages (from GCC 3.3.1): T246.cpp:6: error: type/value mismatch at argument 1 in template parameter list for `template<template<class> class T> struct B' T246.cpp:6: error: expected a class template, got `T' T246.cpp:7: error: ISO C++ forbids declaration of `parameter' with no type T246.cpp: In function `int main()': T246.cpp:13: error: no matching function for call to `f(D&)' (from Comeau online 4.3.3 beta) "ComeauTest.c", line 6: error: template parameter "T" is not a class template void f (const B<T>&) ^ "ComeauTest.c", line 13: error: no instance of function template "f" matches the argument list The argument types that you used are: (D) f (d); ^ ... however it compiles under VC71, and the output of this program is: class V I think that's a surprise? B.

Out of curiousity: What does the VC say abou this: #include <iostream> template <typename T> struct V { void g() const { std::cout << typeid(T).name() << std::endl; } }; template <template <typename> class T> struct B {}; struct D : B<V> {}; template <typename U> void f (const B<U>&) { U<double> v; v.g(); } int main() { D d; f(d); } 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

Bronek Kozicki wrote:

Daniel Frey <daniel.frey@aixigo.de> wrote:

...

template <typename U> void f (const B<U>&) { U<double> v; v.g(); }

There's an error:

Obviously, as that was on purpose.

I think that instead should be:

template <template <typename> class U> void f (const B<U>&) { U<double> v; v.g(); }

after this small change it compiles fine, and result is: double

Hm. Well, this means that the VC seems to accept the correct code in *some* cases, but not always? I'm puzzled and I don't know how to help you to find the problem. Can you try to reduce the _m3 to a small example which still shows some of the problems you reported? TIA. Regards, Daniel

Phil Richards <news@derived-software.ltd.uk> writes:

On Mon, 01 Mar 2004 18:09:20 +0000, Paul A Bristow wrote: [Daniel Frey said:]

...

| I really suggest you look at my code at | <http://groups.yahoo.com/group/boost/files/MathConstants/>, which solves | all of the above points. Except that VC 7.1 doesn't think it is legal C++ :-(( I think we need to establish if it is correct (as gcc and Intel think it is)

Nope, as has been said a number of times, it is not valid C++. typeof is not in the existing C++ standard. It is a very useful extension implemented by a number of vendors, but that doesn't make it standard.

...

Or to find some workaround that VC 7.1 will accept.

Indeed.

...

It would be helpful to know what do other highly conformant compilers, like CodeWarrior and Comeau, say about Daniel Frey's proposal?

Well, you still have to get over the boost Guidelines saying: Aim for ISO Standard C++. Than means making effective use of the standard features of the language, and avoiding non-standard compiler extensions. It also means using the C++ Standard Library where applicable.

It doesn't forbid using extensions, but I seem to remember David Abrahams being a little more assertive about not using non-standard extensions :-)

To be precise, code should usually not *rely* on non-standard extensions. It's fine to use non-standard extensions if they can make the library perform better, use less code, etc., but there should be a fallback position for compilers that don't support the extension. -- Dave Abrahams Boost Consulting www.boost-consulting.com