vxl-maintainers

 [Vxl-maintainers] Re: Numerics and long double From: Peter.V - 2002-09-04 15:19:37 ```> 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. Do you have a pointer to the documentation for this? Is the internal representation (and the division between mantissa and exp) fixed once the total length of the representation is known? If not, this has to be tested for in configure. Peter. ```
 Re: [Vxl-maintainers] Numerics and long double From: Peter.V - 2002-09-04 15:26:33 ```> The definition of vcl_sqrt or std::sqrt in vnl_bignum.h is ill-formed, 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:: The simplest solution would then be to remove vcl_sqrt(vnl_bignum). BUT... that breaks e.g. vnl_vector since e.g. normalise() uses vcl_sqrt. One solution could be to systematically use vnl_math_sqrt in vnl_vector and vnl_matrix (and overload it in vnl_bignum), but that looks like overkill to me. Better solutions? Peter. ```
 [Vxl-maintainers] Re: Numerics and long double From: Peter.V - 2002-09-04 15:30:04 ```> Yes. Moreover, vnl_bignum is an *integral* type. sqrt is not > "well-defined" anyway. Which also argues that complex > shouldn't exist. Well, vnl_rational has similar problems. And is not integral, so sqrt(vnl_rational) and complex make more sense than for vnl_bignum. Peter. ```
 Re: [Vxl-maintainers] Numerics and long double From: Peter.V - 2002-09-04 17:11:21 ```> ... It's with instantiating complex. In > particular, with instantiating abs( complex ). This symptom is fixed now, since vnl_bignum now has a constructor that takes "long double". But the more general question (of needing sqrt(T) in vnl, and of complex, for non-built-in types T) remains of course open. Peter. ```
 Re: [Vxl-maintainers] Re: Numerics and long double From: Frederik Schaffalitzky - 2002-09-05 13:28:39 ```On Wed, 4 Sep 2002 Peter.Vanroose@... wrote: > Do you have a pointer to the documentation for this? No, only what I could find on the http://www. Correcting for endianness, the layout is always SEE...EEFF.....FF where S is the sign bit, E the exponent bits and F the mantissa ("fraction") bits. > Is the internal representation (and the division between mantissa and > exp) fixed once the total length of the representation is known? If > not, this has to be tested for in configure. Don't think so but these are the cases I have seen: single 1 + 8 + 23 = 32 double 1 + 11 + 52 = 64 double-extended 1 + 15 + 64 = 80 quad 1 + 15 + 112 = 128 But I am no expert and I have not read the wonderful IEEE-754 document. So far as I can see, the x86 80-bit floating format ("long double" on my linux box) seems to not really be IEEE in that the leading "1" in the fraction part is included in the mantissa whereas in IEEE it is implied. Also, the "sizeof" size of my "long double" seems to be 12 bytes, with 16 bits of zero-padding on the left. With sparc/gcc it seems that "long double" is the quad IEEE type and takes 16 bytes. ```
 Re: [Vxl-maintainers] Re: Numerics and long double From: Peter Vanroose - 2002-09-05 15:24:50 ```> With sparc/gcc it seems that "long double" is the quad IEEE type and takes > 16 bytes. Also on SGI. Stange enough, on the 64-bit Alpha platform, "long double" is 8 bytes, just like "double" ! There is some "Inf" and "NaN" magick in vnl/vnl_math.cxx, which is really needed there, at least it was in the times of gcc 2.95. So it seems that "IEEE float" is not as standard as it should be, at least not in the current compilers' (or platforms' floating point unit's) implementation... Peter. P.S. Do you have simple a C program to extract the number of E and F bits? Could be useful in configure... ```