🚀 go-pugleaf

In article <QEbeb.377802$2x.116648@rwcrnsc52.ops.asp.att.net>,
"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> writes:
|> 
|> > But note that means TRUE probabilistic rounding - accept no
|> > imitations!
|> 
|> Not so long ago, someone came up with this statement from the standard:
|> 
|> >> Item (6) listed in Section 1.4 of the Fortran standard explicitly
|> >> states that the standard does not specify
|> >>
|> >>    (6)  The physical properties of the representation of quantities and
|> >>         the method of rounding, approximating, or computing numeric
|> >>         values on a particular processor.
|> 
|> I had tried to argue that at least the rounding would be expected to be
|> consistent (repeatable), but the discussion seems to say that it doesn't
|> need to be.   But yes, I agree that only true probabilistic rounding should
|> be used, if any is.

That is my understanding, too.

|> It seems that some processors now have a hardware random number generator
|> using an electronic noise source.  I don't know how fast it is, though.   It
|> would be interesting to see that work.

It would be very interesting.  Generator efficiency isn't a problem,
because you can have (say) a decent shift register generator running
in parallel (e.g. all the time!), and XOR the hardware generator in
with the results of that when you need them.  It wouldn't matter if
the hardware generator updated a word only every 100 cycles, given
a suitably decent pseudorandom generator.

I am not enough of an expert on the details of the methods used in
hardware to be quite certain that there need be NO performance loss,
but I am 99% sure that it would be negligible at worst and there
might even be a slight gain.  Yes, really.

The reason I say the last is that there is no need to calculate a
multiplication to full accuracy - all you need is to generate
enough bits for a decision.  Of course, this means that operations
can take variable times, which is Not Approved Of.  But it might
help, especially for extended precision multiplication.


Regards,
Nick Maclaren.