Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site uwmcsd1.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!dual!qantel!ihnp4!uwmcsd1!jgd From: jgd@uwmcsd1.UUCP (John G Dobnick) Newsgroups: net.lang.c Subject: Re: More Naughty Bits Message-ID: <387@uwmcsd1.UUCP> Date: Mon, 12-Aug-85 16:52:31 EDT Article-I.D.: uwmcsd1.387 Posted: Mon Aug 12 16:52:31 1985 Date-Received: Sun, 18-Aug-85 21:29:51 EDT References: <575@brl-tgr.ARPA> <132@rtp47.UUCP> Distribution: net Organization: U of Wis - Milwaukee, Computing Services Lines: 32 [Just who was that masked line eater, anyway?] > > BTW, I believe the machine with the unusual floating point might have been a > univac 1100, but I could be mistaken. > > Michael Meissner > Data General Speaking of the Sperry 1100 (Univac ceased to exist when Sperry Corp., in their infinite wisdom, decided to make a name change at the start of their fiscal year (April 1 -- yup! You heard me right!)) floating point formats... It *is* possible to have a floating point zero on the Sperry 1100 that is *not* all zero bits (or all *one* bits -- this is a one's-complement machine and thus has *two* zeros). However, such a F.P. zero is *un*-normalized, and is likely to cause undefined results when used in computations. A *normalized* F.P. zero is defined as a floating point number with *all* bits the same as the sign bit; this is what one normally sees and uses. Aside: Un-normalized F.P. operands *do* produce defined results when used with the ADD and ADD-NEGATIVE (also known as SUBTRACT in certain circles) operations. You may get less precision in the results if you do this. I have seen one case where this was, in fact, done deliberately to produce a *scaled* result. Needless to say, such *trickery* is highly machine dependent. -- -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee (...ihnp4!uwmcsd1!jgd)