Guillaume Melquiond wrote:

To fix these problems, I need to know where (header, namespace) the inverse hyperbolic functions acosh, asinh, atanh are defined for this platform/compiler/standard library. As a side note, the same question

it's not defined in MinGW at all. Here's relevant part of math.h /* * TODO: asinh, acosh, atanh */ This math.h belongs to MinGW runtime. I have most recent version, mingw-runtime-3.3, released May 02, 2004. MD5 of my math.h is fad9df375a225e55f7b399c1481e683e, file size 21194 bytes, file time 2004-05-02 11:43. Interestingly, the same mingw-runtime is used with GCC 3.3.1 (toolset "mingw" in tests I'm running) and all tests pass on this compiler. I guess some workaround is applied here? B.

Guillaume Melquiond wrote:

#if defined(__GLIBC__) && !defined(__GLIBCPP__) && (defined(__USE_MISC) || defined(__USE_XOPEN_EXTENDED) || defined(__USE_ISOC99)) && !defined(__ICC) # define BOOST_HAS_INV_HYPERBOLIC #endif

it's defined on both - mingw-3.4.1 and mingw. However there's something wrong with BOOST_NUMERIC_INTERVAL_using_ahyp . Here's preprocessor output from both compilers (sorry for line breaks): mingw (GCC-3.3.1) # 1 "C:/MinGW/Bronek/regression/boost/boost/numeric/interval/rounded_transc.hpp" 1 # 17 "C:/MinGW/Bronek/regression/boost/boost/numeric/interval/rounded_transc.hpp" namespace boost { namespace numeric { namespace interval_lib { template<class T, class Rounding> struct rounded_transc_exact: Rounding { T exp_down(const T& x) { using std::exp; return exp(x); } T exp_up (const T& x) { using std::exp; return exp(x); } T log_down(const T& x) { using std::log; return log(x); } T log_up (const T& x) { using std::log; return log(x); } T sin_down(const T& x) { using std::sin; return sin(x); } T sin_up (const T& x) { using std::sin; return sin(x); } T cos_down(const T& x) { using std::cos; return cos(x); } T cos_up (const T& x) { using std::cos; return cos(x); } T tan_down(const T& x) { using std::tan; return tan(x); } T tan_up (const T& x) { using std::tan; return tan(x); } T asin_down(const T& x) { using std::asin; return asin(x); } T asin_up (const T& x) { using std::asin; return asin(x); } T acos_down(const T& x) { using std::acos; return acos(x); } T acos_up (const T& x) { using std::acos; return acos(x); } T atan_down(const T& x) { using std::atan; return atan(x); } T atan_up (const T& x) { using std::atan; return atan(x); } T sinh_down(const T& x) { using std::sinh; return sinh(x); } T sinh_up (const T& x) { using std::sinh; return sinh(x); } T cosh_down(const T& x) { using std::cosh; return cosh(x); } T cosh_up (const T& x) { using std::cosh; return cosh(x); } T tanh_down(const T& x) { using std::tanh; return tanh(x); } T tanh_up (const T& x) { using std::tanh; return tanh(x); } T asinh_down(const T& x) { ; return asinh(x); } T asinh_up (const T& x) { ; return asinh(x); } T acosh_down(const T& x) { ; return acosh(x); } T acosh_up (const T& x) { ; return acosh(x); } T atanh_down(const T& x) { ; return atanh(x); } T atanh_up (const T& x) { ; return atanh(x); } }; mingw-3.4.1 (GCC-3.4.1) # 1 "C:/MinGW/Bronek/regression/boost/boost/numeric/interval/rounded_transc.hpp" 1 # 17 "C:/MinGW/Bronek/regression/boost/boost/numeric/interval/rounded_transc.hpp" namespace boost { namespace numeric { namespace interval_lib { template<class T, class Rounding> struct rounded_transc_exact: Rounding { T exp_down(const T& x) { using std::exp; return exp(x); } T exp_up (const T& x) { using std::exp; return exp(x); } T log_down(const T& x) { using std::log; return log(x); } T log_up (const T& x) { using std::log; return log(x); } T sin_down(const T& x) { using std::sin; return sin(x); } T sin_up (const T& x) { using std::sin; return sin(x); } T cos_down(const T& x) { using std::cos; return cos(x); } T cos_up (const T& x) { using std::cos; return cos(x); } T tan_down(const T& x) { using std::tan; return tan(x); } T tan_up (const T& x) { using std::tan; return tan(x); } T asin_down(const T& x) { using std::asin; return asin(x); } T asin_up (const T& x) { using std::asin; return asin(x); } T acos_down(const T& x) { using std::acos; return acos(x); } T acos_up (const T& x) { using std::acos; return acos(x); } T atan_down(const T& x) { using std::atan; return atan(x); } T atan_up (const T& x) { using std::atan; return atan(x); } T sinh_down(const T& x) { using std::sinh; return sinh(x); } T sinh_up (const T& x) { using std::sinh; return sinh(x); } T cosh_down(const T& x) { using std::cosh; return cosh(x); } T cosh_up (const T& x) { using std::cosh; return cosh(x); } T tanh_down(const T& x) { using std::tanh; return tanh(x); } T tanh_up (const T& x) { using std::tanh; return tanh(x); } T asinh_down(const T& x) { using ::asinh; return asinh(x); } T asinh_up (const T& x) { using ::asinh; return asinh(x); } T acosh_down(const T& x) { using ::acosh; return acosh(x); } T acosh_up (const T& x) { using ::acosh; return acosh(x); } T atanh_down(const T& x) { using ::atanh; return atanh(x); } T atanh_up (const T& x) { using ::atanh; return atanh(x); } }; Best regards B.

On Tue, Sep 21, 2004 at 06:58:23PM +0200, Guillaume Melquiond wrote:

Le mar 21/09/2004 ? 18:16, Bronek Kozicki a ?crit :

...

Guillaume Melquiond wrote:

...

To fix these problems, I need to know where (header, namespace) the inverse hyperbolic functions acosh, asinh, atanh are defined for this platform/compiler/standard library. As a side note, the same question

it's not defined in MinGW at all. Here's relevant part of math.h

/* * TODO: asinh, acosh, atanh */

This math.h belongs to MinGW runtime. I have most recent version, mingw-runtime-3.3, released May 02, 2004. MD5 of my math.h is fad9df375a225e55f7b399c1481e683e, file size 21194 bytes, file time 2004-05-02 11:43.

Interestingly, the same mingw-runtime is used with GCC 3.3.1 (toolset "mingw" in tests I'm running) and all tests pass on this compiler. I guess some workaround is applied here?

The logic behind the inverse hyperbolic functions is in the numeric/interval/detail/bugs.hpp header. There are two parts: first finding if the three functions exist, then defining the namespace they lie in. The first part is:

#if defined(__GLIBC__) && !defined(__GLIBCPP__) && (defined(__USE_MISC) || defined(__USE_XOPEN_EXTENDED) || defined(__USE_ISOC99)) && !defined(__ICC) # define BOOST_HAS_INV_HYPERBOLIC #endif

This test is outdated, GCC 3.4 changed the stdlib macro from __GLIBCPP__ to __GLIBCXX__, so this test fails to catch GCC 3.4's stdlib.

However, in the meantime, could you tell me which test to add to the line so that the macro is not defined when MinGW is used?

Something like this: #if defined(__GLIBC__) && !(defined(__GLIBCPP__) || defined(__GLIBCXX__)) && (defined(__USE_MISC) || defined(__USE_XOPEN_EXTENDED) || defined(__USE_ISOC99)) && !defined(__ICC) # define BOOST_HAS_INV_HYPERBOLIC #endif jon -- "It is useless to attempt to reason a man out of a thing he was never reasoned into." - Jonathan Swift

Aaron W. LaFramboise wrote:

Actually, the newest is 3.5,

indeed, however it's not listed at http://www.mingw.org/download.shtml I wonder if should I switch regression tests of mingw 3.3.1 and mingw 3.4.1 release candidate to runtime 3.5? And possibly w32api 3.1?

-The compiler: GCC or something else -The linker and assembler: binutils or something else -The C library: glibc, mingw-runtime, or something else. The functionality of the whole is described by the functionality of each of these three parts.

right. Version of GCC is being used in numeric/interval/detail/bugs.hpp to discover capabilities of runtime, thus problem. B.

On Wed, Sep 22, 2004 at 11:27:09AM +0200, Guillaume Melquiond wrote:

Le mar 21/09/2004 ? 22:59, Bronek Kozicki a ?crit :

...

Aaron W. LaFramboise wrote:

...

Actually, the newest is 3.5,

indeed, however it's not listed at http://www.mingw.org/download.shtml

I wonder if should I switch regression tests of mingw 3.3.1 and mingw 3.4.1 release candidate to runtime 3.5? And possibly w32api 3.1?

...

-The compiler: GCC or something else -The linker and assembler: binutils or something else -The C library: glibc, mingw-runtime, or something else. The functionality of the whole is described by the functionality of each of these three parts.

right. Version of GCC is being used in numeric/interval/detail/bugs.hpp to discover capabilities of runtime, thus problem.

Not to discover capabilities, it is to discover namespaces. At the time of GCC 3.4, the developers decided that the inverse hyperbolic functions should not be in the std namespace anymore (they were before). It is the reason why the GCC version is tested.

You still haven't say how I can detect that it's the mingw runtime that will be used. I need to know a preprocessor test so that i can adapt the interval library to this runtime.

http://lists.boost.org/MailArchives/boost/msg71816.php However, another test in boost/numeric/interval/detail/bugs.hpp seems wrong to me: # if defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ > 3) # define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using ::a # elif defined(BOOST_HAS_INV_HYPERBOLIC) # define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using std::a # endif This implies that GCC 3.3 (and earlier) puts the inverse hyperbolic functions in namespace std. According to a simple test (*) I've just run, none of GCC 3.0.4 on linux, 3.3.3 on FreeBSD or 3.4.3 on FreeBSD declares acosh in namespace std. Only GCC 2.x seems to declare those functions in namespace std, but that's probably because namespace std == global namespace in GCC 2.x (all std:: qualifiers are effectively ignored) Should the first line of the test above be changed as follows? # if defined(__GNUC__) && (__GNUC__ == 3) I believe the regression tests pass because the top of the file says: #if defined(__GLIBC__) && !defined(__GLIBCPP__) && (defined(__USE_MISC) || defined(__USE_XOPEN_EXTENDED) || defined(__USE_ISOC99)) && !defined(__ICC) # define BOOST_HAS_INV_HYPERBOLIC #endif This is not true if using GCC 3.3's libstdc++ (which defines __GLIBCPP__), so BOOST_HAS_INV_HYPERBOLIC is not defined. This means neither condition here is met: # if defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ > 3) # define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using ::a # elif defined(BOOST_HAS_INV_HYPERBOLIC) # define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using std::a # endif And so this runs instead: #ifndef BOOST_NUMERIC_INTERVAL_using_ahyp # define BOOST_NUMERIC_INTERVAL_using_ahyp(a) #endif This means that no using decl is given for the inverse hyperbolics, but they are in the global namespace and so are found anyway. i.e. if I understand correctly there is a lot of jumping through hoops for GCC that is completely inneffective and doesn't help, at least for GCC 3.3 on linux/freebsd. After all the messing about Boost ends up just assuming the functions are in the global namespace, and that works. For GCC 3.4 the first test at the top of the file fails (because libstdc++ defines __GLIBCXX__ not __GLIBCPP__) so BOOST_HAS_INV_HYPERBOLIC is defined (this should be fixed by adding __GLIBCXX__ to the first test, I believe). However, the next test is true because __GNUC_MINOR__ > 3, so the global namespace is used. Why is BOOST_HAS_INV_HYPERBOLIC defined if you're using Glibc but not libstdc++? libstdc++ doesn't make the functions unavailable, it just doesn't put them in namespace std. Why does one test look at the stdlib macro, but the next one looks at the compiler version? I assume the stdlib check is to account for GCC with STLPort, but then the next test ignores that possiblity and only looks at the compiler version. I won't pretend to understand exactly what that file is trying to do. Comments might help. jon (*) test was #include <cmath> int main() { using std::acosh; } -- "You can have my encryption algorithm, I thought to myself, when you pry my cold dead fingers from its private key." - Decrypting the Puzzle Palace, John Perry Barlow

On Wed, Sep 22, 2004 at 02:20:01PM +0200, Guillaume Melquiond wrote:

Le mer 22/09/2004 ? 12:19, Jonathan Wakely a ?crit :

...

On Wed, Sep 22, 2004 at 11:27:09AM +0200, Guillaume Melquiond wrote:

...

...

right. Version of GCC is being used in numeric/interval/detail/bugs.hpp to discover capabilities of runtime, thus problem.

Not to discover capabilities, it is to discover namespaces. At the time of GCC 3.4, the developers decided that the inverse hyperbolic functions should not be in the std namespace anymore (they were before). It is the reason why the GCC version is tested. [snip] However, another test in boost/numeric/interval/detail/bugs.hpp seems wrong to me:

# if defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ > 3) # define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using ::a # elif defined(BOOST_HAS_INV_HYPERBOLIC) # define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using std::a # endif

This implies that GCC 3.3 (and earlier) puts the inverse hyperbolic functions in namespace std. According to a simple test (*) I've just run, none of GCC 3.0.4 on linux, 3.3.3 on FreeBSD or 3.4.3 on FreeBSD declares acosh in namespace std.

FreeBSD is not necessarily a good example since there has been a few problems with respect to supporting C99 mathematical functions. But I verified with Linux, and you are right: the C99 functions did leave the std namespace a lot sooner than what I thought.

Agreed, but it's the only system I have available right now to test GCC 3.3 and higher. Since FreeBSD doesn't use glibc the functions come from a different source - but the namespace they end up in is decided by libstdc++ and AFAIK is consistent across FreeBSD and Linux.

...

Only GCC 2.x seems to declare those functions in namespace std, but that's probably because namespace std == global namespace in GCC 2.x (all std:: qualifiers are effectively ignored)

Should the first line of the test above be changed as follows?

# if defined(__GNUC__) && (__GNUC__ == 3)

According to your information, even the version number could be ignored since GCC 2.x assumes the root and the std namespaces are equivalent.

Possibly, yes - although I can't remember the details of how GCC 2.x ignores std:: qualifiers. But the above test won't catch MinGW, where all this trouble started. Doh. The attached patch might be better. It ignores libstdc++ when deciding whether to set BOOST_HAS_INV_HYPERBOLIC (since that depends on the C runtime, not C++). Since MinGW doesn't use GlibC that macro should not be set. Then later when finding the namespaces (which does depend on C++ library) we check whether BOOST_HAS_INV_HYPERBOLIC before deciding on the namespace to use. Because BOOST_HAS_INV_HYPERBOLIC is not set for MinGW it won't define a using decl at all. This might break FreeBSD, which does have those functions but doesn't get them from glibc, so the __GLIBC__ check won't be true, and BOOST_HAS_INV_HYPERBOLIC won't get set. We should do an additional check for a recent-enough FreeBSD libc, and set BOOST_HAS_INV_HYPERBOLIC if found.

...

Why is BOOST_HAS_INV_HYPERBOLIC defined if you're using Glibc but not libstdc++? libstdc++ doesn't make the functions unavailable, it just doesn't put them in namespace std.

I don't know; it's also something I was wondering. But since the library works and is used on a lot more platform than what I have access to, I refrained from experimenting.

Understandable - I don't have access to MinGW (or linux during the day) so can't verify my "fixes" work.

However, in the meantime, let's see what we can do to improve the current situation. I would modify the BOOST_HAS_INV_HYPERBOLIC macro so that it really means these C99 functions are defined.

Yes, agreed. That's what the attached patch tries to do.

In case they are not, dummy functions would be defined in a detail namespace so that the compilers don't complain about unknown identifier, and ADL could still be used (this is mandatory). And in all cases, the BOOST_NUMERIC_INTERVAL_using_ahyp macro would point to the correct namespace (root, std, or the dummy detail one). How does it sound?

Much better. This way the two properties (if the functions are available, and if so which namespace they are in) are tested for separately. If BOOST_HAS_INV_HYPERBOLIC means the functions are available we can fix it later to account for FreeSBD and other cases where the functions are provided by something other than Glibc. Another possiblity would be to make use of the _GLIBCXX_USE_C99 (formerly _GLIBCPP_USE_C99) macro that libstdc++ defines to say whether the C runtime is C89 or C99 (I think this is false for MinGW?) but that would exclude FreeBSD, which has the inverse hyperbolic functions, but not a complete C99 runtime, so libstdc++ doesn't set _GLIBCXX_USE_C99. It would also only work for libstdc++, and we've said it is better to set BOOST_HAS_INV_HYPERBOLIC independently of the stdlib. jon -- [Inlines] are the third most-misused C++ feature (after inheritance and overloading). - Nathan Myers

Bronek Kozicki writes:

Jonathan Wakely wrote:

...

RCS file: /cvsroot/boost/boost/boost/numeric/interval/detail/bugs.hpp,v [...]

I tested this patch in my system (the one running regression tests for mingw-3.4.1 release candidate), it's OK. No failures in numeric/interval

Applied, thanks to everyone who helped to figure this out! -- Aleksey Gurtovoy MetaCommunications Engineering

On Thu, Sep 23, 2004 at 12:59:50PM -0500, Aleksey Gurtovoy wrote:

Bronek Kozicki writes:

...

Jonathan Wakely wrote:

...

RCS file: /cvsroot/boost/boost/boost/numeric/interval/detail/bugs.hpp,v [...]

I tested this patch in my system (the one running regression tests for mingw-3.4.1 release candidate), it's OK. No failures in numeric/interval

Applied, thanks to everyone who helped to figure this out!

Cool. btw I noticed the FreeBSD man page says that the inv. hyperbolics were added in BSD 4.3, so should be available in any BSD-derived libc. I'll look into it more and send a suggestion so that BOOST_HAS_INV_HYPERBOLIC gets defined. Probably possible to enable it for all the BSDs. jon -- "In theory, practice and theory are the same, but in practice they are different." - Larry McVoy

On Sun, Sep 26, 2004 at 02:40:25AM -0500, Aleksey Gurtovoy wrote:

Aleksey Gurtovoy writes:

...

Bronek Kozicki writes:

...

Jonathan Wakely wrote:

...

RCS file: /cvsroot/boost/boost/boost/numeric/interval/detail/bugs.hpp,v [...]

I tested this patch in my system (the one running regression tests for mingw-3.4.1 release candidate), it's OK. No failures in numeric/interval

Applied, thanks to everyone who helped to figure this out!

Hmm, it looks like GCC 2.95.3/STLPort didn't get covered by the patch -- http://tinyurl.com/6e3g5. Is this something we can fix easily?

Probably. I don't have access to that configuration though. Presumably the definitions for the inv hyperbolics come from Glibc, so the question is whether STLPort pulls them into namespace std or not.

From the error message I'd guess they are in namespace std, but BOOST_HAS_INV_HYPERBOLIC is not being defined, so the using decls aren't defined so we get a "using std::cosh;"

Maybe the first test in boost/numeric/interval/detail/bugs.hpp needs to be extended to cover this config? GCC 2.95 (without STLPort) defines __USE_MISC when std headers are included (I'm not sure exactly where it gets set). I guess STLPort takes some detour that prevents it being defined. jon -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rich Cook

Le mar 28/09/2004 à 14:18, Aleksey Gurtovoy a écrit :

Guillaume Melquiond writes:

...

Le dim 26/09/2004 à 09:40, Aleksey Gurtovoy a écrit :

...

Hmm, it looks like GCC 2.95.3/STLPort didn't get covered by the patch -- http://tinyurl.com/6e3g5. Is this something we can fix easily?

I have committed a small patch. Let's see if it fixes things. I can't be sure it will work since my version of STL is 4.6 and I don't have these problems.

It did! Once again, thanks everybody!

I'm surprised it worked that well. Except for the last one, all the tests now pass. They shouldn't, since a deficiency with respect to name resolution should prevent some cmp*.cpp tests from passing (as can be seen with gcc-2.95.3-linux report). Martin, is the compiler really GCC 2.95 for the STLport tests? As for the last test (test_float), it seems the compiler does not find the abs(float) and abs(double) functions. The compilation warning shows only abs(int) is defined. I guess the problem lies in the current test code: #ifndef BOOST_NO_STDC_NAMESPACE using std::abs; #endif I am not so sure it was a good heuristic. So I committed a small patch that unconditionally put std::abs and std::sqrt in the current namespace for test/test_float.cpp. My quick tests on Linux don't show any difference. Let's see how well it behaves on Windows (maybe some problems with Intel compiler in MSVC6 emulation mode?). Best regards, Guillaume

On Tue, Sep 28, 2004 at 03:20:13PM +0200, Guillaume Melquiond wrote:

Le mar 28/09/2004 ? 14:18, Aleksey Gurtovoy a ?crit :

...

Guillaume Melquiond writes:

...

Le dim 26/09/2004 ? 09:40, Aleksey Gurtovoy a ?crit :

...

Hmm, it looks like GCC 2.95.3/STLPort didn't get covered by the patch -- http://tinyurl.com/6e3g5. Is this something we can fix easily?

I have committed a small patch. Let's see if it fixes things. I can't be sure it will work since my version of STL is 4.6 and I don't have these problems.

It did! Once again, thanks everybody!

I'm surprised it worked that well. Except for the last one, all the tests now pass. They shouldn't, since a deficiency with respect to name resolution should prevent some cmp*.cpp tests from passing (as can be seen with gcc-2.95.3-linux report). Martin, is the compiler really GCC 2.95 for the STLport tests?

As for the last test (test_float), it seems the compiler does not find the abs(float) and abs(double) functions. The compilation warning shows only abs(int) is defined.

I guess the problem lies in the current test code: #ifndef BOOST_NO_STDC_NAMESPACE using std::abs; #endif

Hmm, this might be due to the fact that <math.h> on linux doesn't include the C++-specific overloads for abs(). If STLPort's <cmath> includes <math.h> (not a <cmath> from e.g. libstdc++) then it won't get the abs() overloads. libstdc++ suffers from the same problem, if you include <math.h> not <cmath> then you don't get the C++-specific parts, only those parts that are part of C89. For STLPort the problem may be compounded because even <cmath> may not add the extra overloads if all it does is forward to the system's <math.h> (which I _think_ is the case if there's no <cmath> installed on the system, or it's not visible to STLPort). jon -- "A foolish consistency is the hobgoblin of little minds..." - Ralph Waldo Emerson

Aaron W. LaFramboise wrote:

If you are willing to contribute a public domain implementation of the real arc-hyperbolic trig functions, I am sure MinGW would not reject them.

If Boost license is compatible with requirements of MinGW, then maybe following will be good enough? http://www.boost.org/libs/math/special_functions/special_functions.html (quick check in CVS - yes, these headers has been upgraded to boost license) B.

Le mar 21/09/2004 à 23:46, Aaron W. LaFramboise a écrit :

Bronek Kozicki wrote:

...

Aaron W. LaFramboise wrote:

...

If you are willing to contribute a public domain implementation of the real arc-hyperbolic trig functions, I am sure MinGW would not reject them.

If Boost license is compatible with requirements of MinGW, then maybe following will be good enough?

Unfortunately, it isn't. For various reasons, the MinGW runtime is public domain, meaning that authors have disclaimed any copyright interest that they might have. The author of special_functions could do this, of course, but it would undermine his legal ability to enforce the Boost license for this code, if this was something he was interested in.

For Boost's purposes, isn't it best just to use Boost's implementation of these functions on MinGW?

Unfortunately no. It has already been discussed on this mailing-list, and so I will just give a quick summary here. The Boost implementation of these functions is not correctly rounded. When used with the interval library, it would systematically lead to wrong results. If you think the same hold true for standard libm, you are right. But at least the user has the possibility of using a precise libm as a replacement. And it is not just theoretical, such libraries exist (the crlibm project for example). Regards, Guillaume