Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Peter.V<anroose@es...>  20020904 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. 
From: Peter.V<anroose@es...>  20020904 15:26:33

> 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:: The simplest solution would then be to remove vcl_sqrt(vnl_bignum). BUT... that breaks e.g. vnl_vector<vnl_bignum> 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. 
From: Peter.V<anroose@es...>  20020904 15:30:04

> Yes. Moreover, vnl_bignum is an *integral* type. sqrt is not > "welldefined" anyway. Which also argues that complex<vnl_bignum> > shouldn't exist. Well, vnl_rational has similar problems. And is not integral, so sqrt(vnl_rational) and complex<vnl_rational> make more sense than for vnl_bignum. Peter. 
From: Peter.V<anroose@es...>  20020904 17:11:21

> ... It's with instantiating complex<bignum>. In > particular, with instantiating abs( complex<bignum> ). 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<T>, for nonbuiltin types T) remains of course open. Peter. 
From: Frederik Schaffalitzky <fsm@ro...>  20020905 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 doubleextended 1 + 15 + 64 = 80 quad 1 + 15 + 112 = 128 But I am no expert and I have not read the wonderful IEEE754 document. So far as I can see, the x86 80bit 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 zeropadding on the left. With sparc/gcc it seems that "long double" is the quad IEEE type and takes 16 bytes. 
From: Peter Vanroose <Peter.V<anroose@es...>  20020905 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 64bit 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... 
Sign up for the SourceForge newsletter:
No, thanks