From: Amitha Perera <perera@cs...>  20020904 05:14:51

In trying to clean up vcl code for VC70, we've come across problems relating to the long double type. In particular, the VC70 standard library seems notsobroken that it only requires a few patches in vcl/win32/* (actually, VC60sp5 seems to be similar...). The problem is that the VC70 implementation of some of the math functions uses long double constants (e.g. in the sqrt function). This creates problems when trying to instantiate vnl_bignum because there is no constructor taking a long double as an argument. While there is, no doubt, a reasonable work around for this particular problem, it is indicative of a bigger problem: inconsistent and incomplete support for long double in vnl. The C++ standard explicitly has a long double type. On some platforms, it is bigger than double. (On FreeBSD with gcc, it is 96 bits.) Is there a clean way of getting long double support into vnl_math.{h,cxx}? From there, it should be relatively straight forward to propagate to the rest of vnl. I must admit lack of experience with this level of detail in floating point representations, etc. Can any vnl gurus comment? On a side note: the comment in vnl_math says that vnl_math::maxdouble (and relatives) are only there until there is support for numeric traits. It would seem that we now have widespread support for numeric traits, in terms of complete specialization. Should vnl_math::maxdouble be moved into traits? Amitha. 
From: Peter Vanroose <Peter.V<anroose@es...>  20020904 06:33:23

> The C++ standard explicitly has a long double type. On some platforms, > it is bigger than double. (On FreeBSD with gcc, it is 96 bits.) Is > there a clean way of getting long double support into vnl_math.{h,cxx}? I don't expect much trouble when one just adds a "long double" version anywhere where there are float and double versions of a function. E.g., adding "long double" versions in vnl_bignum was straightforward. (Well, I only tried gcc and SGI's CC.) Shall we just try and do this in vnl_math ? The "maxdouble" issue is more tricky, I guess, since that would require extra configure efforts. But why not... Peter. 
From: Ian Scott <ian.scott@st...>  20020904 08:56:58

vsl currently provides no support for long doubles. In particular we would need to design a unique encoding for long double, and write code to get data into that format from each platform's native long double. We couldn't find any straightforward solution to this during the design of vsl, but if anyone has some suggested code, then it would be fairly easy to try after the upcoming release tagging. I'd be happy to help. Ian. > Original Message > From: Amitha Perera [mailto:perera@...] > Sent: Wednesday, September 04, 2002 6:17 AM > To: vxlmaintainers@... > Subject: [Vxlmaintainers] Numerics and long double > > > In trying to clean up vcl code for VC70, we've come across problems > relating to the long double type. In particular, the VC70 standard > library seems notsobroken that it only requires a few patches in > vcl/win32/* (actually, VC60sp5 seems to be similar...). The problem is > that the VC70 implementation of some of the math functions uses long > double constants (e.g. in the sqrt function). This creates problems > when trying to instantiate vnl_bignum because there is no constructor > taking a long double as an argument. While there is, no doubt, a > reasonable work around for this particular problem, it is indicative > of a bigger problem: inconsistent and incomplete support for long > double in vnl. > > The C++ standard explicitly has a long double type. On some platforms, > it is bigger than double. (On FreeBSD with gcc, it is 96 bits.) Is > there a clean way of getting long double support into > vnl_math.{h,cxx}? From there, it should be relatively straight forward > to propagate to the rest of vnl. > > I must admit lack of experience with this level of detail in floating > point representations, etc. Can any vnl gurus comment? > > On a side note: the comment in vnl_math says that vnl_math::maxdouble > (and relatives) are only there until there is support for numeric > traits. It would seem that we now have widespread support for numeric > traits, in terms of complete specialization. Should > vnl_math::maxdouble be moved into traits? > > Amitha. > > >  > This sf.net email is sponsored by: OSDN  Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > 
From: Frederik Schaffalitzky <fsm@ro...>  20020904 15:05:49

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:: So vcl_sqrt() for vnl_bignum must be removed or renamed. Does that solve the problem? 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. 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. The IEEE format allows for any length of mantissa and exponent but only a few combinations are common. 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. Frederik On Wed, 4 Sep 2002, Amitha Perera wrote: > In trying to clean up vcl code for VC70, we've come across problems > relating to the long double type. In particular, the VC70 standard > library seems notsobroken that it only requires a few patches in > vcl/win32/* (actually, VC60sp5 seems to be similar...). The problem is > that the VC70 implementation of some of the math functions uses long > double constants (e.g. in the sqrt function). This creates problems > when trying to instantiate vnl_bignum because there is no constructor > taking a long double as an argument. While there is, no doubt, a > reasonable work around for this particular problem, it is indicative > of a bigger problem: inconsistent and incomplete support for long > double in vnl. > > The C++ standard explicitly has a long double type. On some platforms, > it is bigger than double. (On FreeBSD with gcc, it is 96 bits.) Is > there a clean way of getting long double support into > vnl_math.{h,cxx}? From there, it should be relatively straight forward > to propagate to the rest of vnl. > > I must admit lack of experience with this level of detail in floating > point representations, etc. Can any vnl gurus comment? > > On a side note: the comment in vnl_math says that vnl_math::maxdouble > (and relatives) are only there until there is support for numeric > traits. It would seem that we now have widespread support for numeric > traits, in terms of complete specialization. Should > vnl_math::maxdouble be moved into traits? > > Amitha. > > >  > This sf.net email is sponsored by: OSDN  Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > 
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. 
From: Amitha Perera <perera@cs...>  20020904 16:37:18

Fred asked a pertinent question which shows I don't really know what I'm talking about: :) Frederik Schaffalitzky wrote: > Sorry, I don't understand what you mean by "long double constants"... > Exactly how does the implementation of the VCx.y sqrt(double) cause long > doubles to be passed to the constructor of vnl_bignum? Investigating further, the problem is not with the sqrt or abs overrides per se. It's with instantiating complex<bignum>. In particular, with instantiating abs( complex<bignum> ). VC70 implements abs(complex<Ty>) with a complicated, and presumably efficient and accurate, routine. In one branch of the routine, there is a statement (Ty)0.423423....545345L which asks for a conversion from a long double to Ty. (It's a high precision representation of sqrt(2), FWIW.) This fails for vnl_bignum, and also fails for vnl_rational when we try to explicitly instantiate abs(complex<rational>). There is no problem with VC60, because there is a "fix" in vcl/win32/vcl_complex.h that defines T abs( complex<T> z ) { return sqrt( norm(z) ); } Now, this "fix" shouldn't be in place for VC70 because the library *does* provide abs(complex<T>). It may not be implemented as we like, but then, the implementation details are not ours to dictate. I think in general, there is trouble when trying to create a userdefined type that acts like a standard numeric type. As Fred mentioned earlier, it is undefined to overload std::sqrt because that is adding to namespace std. Perhaps the solution is to go back to vnl_sqrt for vnl stuff. Has there been previous discussion about this issue? Amitha. 
From: Ian Scott <ian.scott@st...>  20020904 15:46:55

Fred wrote: > The IEEE format allows for any length of mantissa and > exponent but only a > few combinations are common. 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. If someone knows how to consistently convert a long double to and from a triple of integers [Sign, Mantissa, and Exponent] values, I can use that to provide vsl support. I think that would be a better approach than Amitha's suggestion of converting it to a rational. Rational descriptions will not cope with the full range of exceptional values defined by IEEE, i.e. NaNs and Infs. Ian. 