Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!agate!riacs!pioneer.arc.nasa.gov!lamaster From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: IEEE floating point Message-ID: <1991May24.161833.20530@riacs.edu> Date: 24 May 91 16:18:33 GMT Article-I.D.: riacs.1991May24.161833.20530 References: <9105240158.AA02761@ucbvax.Berkeley.EDU> Sender: news@riacs.edu Reply-To: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Organization: RIACS, NASA Ames Research Center Lines: 182 Jim Patterson writes: >In article <1991May22.221824.16887@riacs.edu> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes: >>1) It is a standard. It is very important to certain users to be able to >>move binary data between machines without conversion. >This isn't quite correct. While IEEE specifies quite a bit about the >format of its floating point representations, it leaves unsaid a few >details such as endian-ness. The 80x87 chips, for example, follow >INTEL convention I was certainly aware of the "little-endian" problem when I wrote the above :-) I am still wondering which DEC employee writes 10^7 as 00000001, or is that 00010000 ? I always forget. (Add a few smilies here for the humor impaired :-) :-) :-) Even *Digital Review* commented on DEC's choice of little endian for the DECsystem 5xxx product line a while back. However, in any case, I was referring to FP representation conversion, which is much more costly than byte swapping. (But, it can be vectorized for large arrays!) Endian-ness is indeed a problem. As I have stated before, I also support a standard for endian-ness for exactly this reason. However, byte-swapping is a relatively low overhead, even in the kinds of applications I am dealing with. The major problem that it causes is one of convenience, rather than performance: It would be nice to move binary files with mixed data types. I note only that it takes more to do this than agree on an endian standard. It would also be nice to not have to convert somewhere, or write special code to figure out whether the machine you are on is byte- swapped, so that you can write out data in standard metafile order. BTW, you get one guess regarding whether I favor big or little-endian as the standard :-) > Representations >of the extended precision formats are also not pinned down; 80x87 uses >80 bit extended while other implementations e.g. HP-PA use a 128 bit >extended precision. (This is an internal format, though; not a lot of >need to transfer it around between machines). I agree that these are not as pinned down as they should be, and, are also controversial for other reasons as well. However, as you note, they are primarily an internal/computation issue, rather than an external standard issue. >So, while you might get by with doing at most a byte-swap to move IEEE >floats around, you can't blindly assume that all IEEE floats are the >same. Believe me, I am very aware of byte swapping. -- Jim Patterson Cognos Incorporated UUNET:uunet!cognos.uucp!jimp P.O. BOX 9707 BITNET:ccs.carleton.ca!cognos.uucp!jimp 3755 Riverside Drive PHONE:(613)738-1440 x6112 Ottawa, Ont K1G 3Z4 In article <9105240158.AA02761@ucbvax.Berkeley.EDU>, jbs@WATSON.IBM.COM writes: |> |> Hugh LaMaster states: |> But, the reason that the standard is so entrenched is that it is so useful! |> Manufacturers are forced to use it because users have requirements for it. |> |> I believe the standard has become entrenched for reasons other |> than technical merit. If the IEEE had chosen some other standard it |> would probably be equally entrenched by now. Hard to prove or disprove either way. But I can think of lots of standards which people ignore because they are not useful. |> Hugh LaMaster also states: |> There are always programs which run on the ragged edge of precision, |> and which don't work right on a slightly poorer implementation. |> |> I am skeptical about this statement. Do you have some non- |> contrived examples? Over the years I have run into a number of problems like this. Programs which got right answers on a VAX, and didn't converge on an IBM. Other programs which got right answers on a Cray, and didn't converge on an Cyber 205. I have seen such programs even at 64 bits, although 32 is more common. Sometimes, users would get convergence on one machine at 32 bits, and have to go to 64 bits on a different machine to get convergence. Fact is, it happens all the time. What is more dangerous are programs which are verified for correctness on one machine, but don't have built in error checks. Sometimes, when they are moved to another machine, such programs give wrong answers. Just ask any numerical analyst in a consulting group in a big computer center for examples; they can always give you horror stories on demand. I believe 64 bits with any reasonable format is |> enough for most problems. I agree. However, users do not always know how much precision they need, or what they might be doing which increases the precision needed by their program. If it converges to the right answer, why should they? Not everyone understands all the subtleties of error analysis, including myself. The user is frequently not the programmer. When the program stops converging on another machine with a different FP arithmetic, they may be in for a costly delay. The fact is that different FP formats are an obstacle to portability, and, I have plenty of personal experience with this problem. |> Hugh LaMaster also states: |> 2) IEEE is very well behaved, compared with other representations. I won't |> bother to substantiate this, other than to state that many experts agreed |> at the time it was developed that there was no known way to improve it |> numerically. |> |> I do not consider this a point in favor of the IEEE standard. Well, I certainly do. I guess we disagree. . . . |> ... The above statement suggests the IEEE standard gave |> undue weight to numerical quality to the exclusion of factors such as |> performance and ease of implementation. True, it does. This was cause for considerable concern at the time. However, aren't people clever? Pipelined FP units are now available for IEEE. |> Couldn't we do without some or all of the following features of |> the IEEE standard? 4 rounding modes (why only 4? why not 8?). Inf and |> NaN. Denormalized numbers. Distinction between +0 and -0. Inf and NaN are extremely useful, and cost nothing to implement. Denormalized numbers are also extremely useful. They are, unfortunately, very costly to implement, and have been the source of most of the controversy over IEEE. However, see above. |> Will Nasa ever build a spacecraft of which experts will say |> "there is no known way to make this vehicle safer"? I don't speak for NASA. |> Hugh LaMaster also states: |> The down side of IEEE is a performance hit in heavily pipelined FP units, for |> some input values. On the other hand, it is nice to get the right answer, even |> if some cases slow down. |> |> You are understating the downside. The standard is complex |> which increases design time and cost. This added design cost applies |> to software such as compilers as well hardware. The performance hits |> are not confined to heavily pipelined floating point units on denorm- |> alized inputs. I am not aware of any additional design cost to compilers or other system software. Quite the contrary. It is easier to implement a standard math library on a system with a well behaved and well understood FP arithmetic. As for user software, well, I see the benefits of having IEEE FP as the workstation standard every day. As for hardware, there has been a tremendous benefit to microprocessor based systems, from PC's to workstations, in having standard parts available which implement IEEE. It means that both system designers and users have available high performance IEEE parts. Does your System have a Weitek, TI, Cypress, or whatever, FP unit? Do you know, or care? |> As to wrong answers, wrong answers are generally caused by |> users not knowing what they are doing. This argument was addressed above. |> James B. Shearer -- Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 With Good Mailer: lamaster@george.arc.nasa.gov Phone: 415/604-1056 #include