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)