From: Amitha Perera <perera@cs...>  20020904 15:25:31

Frederik Schaffalitzky wrote: > The definition of vcl_sqrt or std::sqrt in vnl_bignum.h is illformed, as > Bill's client pointed out recently in connection with std::complex and > STLPORT. We are not allowed to add more sqrt() signatures to std:: Yes. Moreover, vnl_bignum is an *integral* type. sqrt is not "welldefined" anyway. Which also argues that complex<vnl_bignum> shouldn't exist. > So vcl_sqrt() for vnl_bignum must be removed or renamed. Does that solve > the problem? Probably. That'll force removal of complex<bignum> from the explicit instantiations. However, with the implicit instantiation of vcl code, people could probably continue to use it if they wish. > I didn't understand what the problem with sqrt() for VCx.y > was. If you are saying that vcl_sqrt(double) returns a long double then > that vcl_sqrt() is wrong: it could and should be fixed in vcl. VCx.y sqrt is broken in general, but that's not the real issue. The problem was that the their implementation of sqrt has long double constants. When those constants interact with vnl_bignums, they cause overloading ambiguities. > long double is unlikely to unavailable on any compiler that we support. > Of course, on some architectures it is 128 bits wide (Sparc) and on some > it is 96 bits (80x86), which is a problem if we expect "long double" to be > binary exchangeable across architectures.... Let's not have that > discussion again. Binary exchange is one issue. Having support for long double is another. It is (should be) perfectly reasonable for vnl to support long double types on any given and fixed platform, regardless of what the size of the underlying type is. There are very few places where is it necessary that the size of the underlying type be known. > The IEEE format allows for any length of mantissa and exponent but only a > few combinations are common. Yes. And I don't think the C++ standard mandates the use of IEEE arithmetic, although that assumption seems to be widespread in vnl. > I can't remember if the vsl people eventually decided to implement > I/O of arbitrary length integers but one could do something like > that for IEEE floating point values. This is the solution for any floating point type: represent as a rational. It will be correct as long as both platforms have types that can represent the number in question. But then, you can't ask for more. Amitha. 