[Simh] Looking for a milestone

[Clem Cole]

"Correct" is difficult check out:  http://www.netlib.org/paranoia/paranoia.c
This set of programs lead to the IEEE FP format work.   And Paul is 100%
correct, Seymour was never worried about correctness, just being fast and
"close enough for government work.".  He used reciprocal approximation, not
full dividers for the Cray and CDC boxes because they took too long,
ones-complement for binary etc..; basically set the dial to be fast, not
accurate.   Remember he came from a time when a the slide-rule and 3
significant digits was king.    So much, if not all, of the input data was
not that precise.

It was only after years of working with scientific computers, that people
realized that some of the errors were being magnified and made worse and
worse because of the lack of correctness in the encoding.

Clem

On Mon, Oct 17, 2016 at 11:55 AM, Paul Koning <paulkoning at comcast.net>
wrote:

>
> On Oct 14, 2016, at 7:22 PM, Leo Broukhis <leob at mailcom.com> wrote:
>
> I wonder what is the historically first programming environment with
> native binary floating point which had been proved/demonstrated to handle
> f.p. binary<->decimal I/O conversions 100% correctly?
> By 100% correctly I mean that all valid binary representations of floating
> point numbers could be, given a format with enough significant digits,
> converted to unique text strings, and these strings could be converted back
> to the corresponding unique binary representations.
>
> Of course, there is enquire.c which facilitated finding bugs in the
> Unix/Posix environments, but has anyone cared about this during the
> mainframe era?
>
>
> I believe so, yes.  For the design of the floating point feature of the
> Electrologica X8 (early 1960s) the design documents discuss correctness,
> including what the definition of "correct" should be.
>
> There is a very nice and very detailed correctness proof of that floating
> point design, documented in http://repository.tue.nl/674735 .  That paper
> was written long after the fact, but by one of the people originally
> involved in that machine.
>
> Apart from proofs of the correctness of each of the floating point
> instructions, that paper also describes the sqrt library function.
> Interestingly enough, the implementation of that function does not use
> floating point operations.  But the analysis, in appendix B of the paper,
> clearly shows the error terms of the approximation used and why the number
> of steps used is sufficient for correctness of the sqrt implementation.
>
> For a different machine, the CDC 6000 series, I remember reading
> complaints about its bizarre rounding behavior (rounding at 1/3 ?).  I
> forgot where that appeared; possibly a paper by prof. Niklaus Wirth of ETH
> Zürich.
>
> paul
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20161017/5c3743b3/attachment.html>