Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: base 10 float hardware
Message-ID: <540@cresswell.quintus.UUCP>
Date: 15 Jan 88 09:47:32 GMT
References: <8801141342.AA15537@decwrl.dec.com>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 30

In article <8801141342.AA15537@decwrl.dec.com>, kruger@16bits.dec.com (Hart for CCCP chief in '88) writes:
> By definition, base 10 hardware must waste some circuitry, because you are
> consciously deciding not to store the binary values 11-15, which you could
> otherwise do. So you lose range, but gain precision for decimal calculations.
You misunderstood.  I explicitly said that the exponent and significand
were represented in BINARY.  The idea is that you have
	Sign x Significand x 10**Exponent
where Sign is 1 or -1, Significand is a binary integer, and Exponent is a
binary integer.  The precision loss when scaling is intermediate between
that of base-8 (Burroughs) and base-16 (IBM) floating-point.  There is no
range loss (except that you can't use a "hidden bit", so ok, one bit loss).
With 32 bits, you'd get 1 bit for sign, 8 bits for exponent (10**-128 to
10**127, maybe use 10**-128 for NaNs), and 23 bits for significand (not the
24 you get from binary-with-hidden-bit) or roughly 7 decimal digits.
In any case, it isn't circuitry you'd be paying.  (I believe the original
design was for a micro-coded floating-point unit.)  And the point of the
original article was that decimal scaling was very little harder than
binary scaling.

> But this doesn't save you from precision errors, it only saves you fro
> DECIMAL precision errors. What about (x/3)*3 ?
Decimal representation error is all the method is intended to save you.
That matters because we WRITE numbers in base 10, not base 3.  The number
you write in your program or read from a file is EXACTLY the number
represented by the bits, in this scheme.  This was important in the BASIC
application I mentioned:  beginning students were very confused when they
would say	PRINT 2.3
and get		2.29999
back.  You are spared one roundoff error in input and one in output.
If you can avoid that without inefficiency, why not avoid it?