🚀 go-pugleaf

In article <12526@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
In reply to:
 > In article <9105200213.AA05095@ucbvax.Berkeley.EDU>, James B. Shearer
 > (jbs@WATSON.IBM.COM) writes:
Who again replies to:
 > >         Herman Rubin writes:
etc.  I hope I get everything right.

JBS:
 > >                 Regarding unnormalized floating point what is this good
 > > for besides simulating multiple precision integer arithmetic?
I do not find it even good for that either.
 > 
 > The last question first:  How about multiple precision floating (or fixed)
 > arithmetic?  Considering that there are quite a few papers on this, it is
 > certainly a topic of interest.  I do not believe it should be necessary here
 > to go into the full range of situations I can list NOW where this would be
 > useful.  
Considering that the oldest paper I know about multiple precision FP is from
T.J.Dekker, and as it only considers normalizing FP (eh. standardizing as
on the Electrologica X8, but he does not use it), I find this answer
surprizing.
 > 
 > Now what is the benefit of allowing only normalized floating point?  It 
 > eliminates the need for a normalization option in floating instructions,
 > and it provides ONE more bit of accuracy.  Is that ONE bit exactly what
 > is needed?  This is very unlikely.
Nope.  That bit is not exactly what is needed, but it came in as a surplus bit,
so why not use it?  For multi-precision FP arithmetic unnormalized arithmetic
is not needed, as for multi-precision integer arithmetic.
 > 
 > Now what is the cost of not having forced normalization, besides the one
 > bit?  There would have to be a method for indicating which result of the
 > operation is wanted (upper, lower, normalized).  There would be little
 > additional hardware other than the decoding, by the floating unit, of
 > this information.
This is the 205 way, but the 205 implemented it awful (and the reason is
just that: cost).  On the 205 you could specify for an add that one of the
three results was returned.  But the normalizing add was just that: it first
took the upper 47 bits of the result, normalizing afterwards.  This gives
a loss in precision.
 > 
 > There are algorithms which benefit from using both Boolean and arithmetic
 > operations on either fixed point or floats.  These are not even readily
 > available on many of the newer machines.
Just the same as on other machines.  If current machines do not implement a
specific round float to integer instruction, one can add a simple constant
to a float to get the integer part in a specific portion of the register.
Again I ask, how much is it used?  You say table look up for some elementary
functions.  My reply is, maybe on scalar machines, but if you do that on
vector machines, expect a big loss in performance.  So table look up is not
in general the most efficient way.  (Oh, btw, the same may hold for scalar
machines because of cache misses etc.)
 > 
 > >         Herman Rubin also writes:
 > > In the early FP computers, much function calculation was done in fixed point,
 > > to get increased accuracy at little cost.
Eh?  I always thought it was because of speed (FP was slow, fixed point was
fast).  At least on the Electrologica X8 (1964 vintage) no calculation in
those functions was done in fixed point.  And yes, fixed point was much faster
than floating point.  Some timings (in milliseconds):
	fixed		FP
add	5.0		8.75-18.75
mul	8.75-40.0	12.5-68.75
(for some reasons I have a manual here at home!)  As you see, especially
fixed point add (and sub) were much faster.
 > > 
 > So why not have increased integer accuracy?  It is no harder to do this, and
 > the same units can be used.  To someone with a mathematical outlook, the 
 > distinction is not integer/float but short integer/good arithmetic.
But you are not advocating 'good' arithmetic.  At least from the viewpoint
of many people.  And why do you think that 64 bit integer arithmetic is not
much harder?  If we consider the time it took for micros to go from 8 to 16
and again to 32 bit integer arithmetic....
 > 
 >                                                      Converting the fixed
 > point results to floating can be a major problem, as 0 is a possible value,
 > again a real problem only with automatic normalization.
I do not understand thgis at all.  If the hardware does not provide instructions
to convert fixed point results to floating points, only 2 instructions are
required to do it.  That 0 is a possible value is no problem at all.  But I
think you mean 'converting fixed point results to floating by a single
boolean operation', i.e. or'ing in the exponent.  But in that case negative
numbers are also a problem.
 > 
 >                        This is clearly not the case.  An example is the
 > attempt to add integer multiplication to the CDC 6x00 series.  The fact
 > that floating multiplication automatically normalized the product when
 > both factors were normalized made the operation far less useful than
 > intended.  There was too much already in the hardware to correct this.
This is taking it backwards.
1.  Integer multiplication was not added later, but designed in from the start.
2.  The fact that multiplication automatically normalizes has nothing to do
    with the problems.
3.  The fact that mutliplication assumes that apparently normalized fp numbers
    are indeed normalized fp numbers has all to do with it.
But on the CDC 6x00 series you could get a 94 bit integer product from two
47 bit integer factors; although it was undocumented.

On the other hand, we see with the Cray (were normalization is done too late)
that we can lose a lot of precision in the fp multiplication.

 >                                  There are provisions for octal and hex
 > integers, but none for explicitly writing floats or fixed-point numbers to
 > those bases.
Ada provides all this.  However, upto now I have not seen many use of the
possibility to write fp numbers in any than decimal base.  To wit:
	8#0.12345#e-4
means 0.12345 in octal times 8^-4.

 > Like the infamous frexp function in C?  For those not familiar with it,
 > frexp(x,&n) took a floating number x and transformed it to y*2^k, where
 > .5 <= |y| < 1, and the value of k is stored as n.
Not *took* Herman, it still *takes*.

 >                                                    Instead of completely
 > inlining this operation, which would have made the whole thing simple and
 > suggested the obvious alternate form
 > 	y,n = frexp(x)
(Yup, *you* design the language where that is possible.  Start looking at Mesa.)
 > which also assigns the values to registers or memory as wanted, and avoids
 > a clumsy function call, they did the other.
The fact that it is formally declared as a function does not inhibit inlining,
nor the assignement of values to registers.
 >                                              The 4.2BSD library even used
 > a machine independent algorithm, which needless to say was frequently slower
 > by a factor of more than 100.  It even went into an infinite loop in 0.  
Yes, yell at the language designers if the implementers goof it.
 > Of course the work has to be done in machine-dependent code, and in the
 > integer registers, if they are separate.
Not at all.  If the hardware completely implements IEEE, I want it in the
FP registers!

I get tired.  Perhaps more tomorrow.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl