Re: [TUHS] Space Travel, was New: The Earliest UNIX Code

[Arthur Krewat <krewat@kilonet.net>]

On 10/18/2019 6:04 PM, Ken Thompson via TUHS wrote:
> while writing "space travel,"
> i could not get the space ship integration
> around a planet to keep from either gaining or
> losing energy due to floating point errors.
> i asked dick hamming if he could help. after
> a couple hours, he came back with a formula.
> i tried it and it worked perfectly. it was some
> weird simple double integration that self
> corrected for fp round off. as near as i can
> ascertain, the formula was never published
> and no one i have asked (including me) has
> been able to recreate it.
>
>
This reminds me of an experiment I performed comparing speeds of x86 
assembler, and C, when I first started working in it. The experiment was 
to generate a 3D cube wireframe, and rotate it about any (or all three) 
of it's axes, moving it X degrees at a time. Simple vector math, really. 
Included perspective, so that the back-end of the wireframe cube would 
look smaller than the front side.

I had been an assembler snob, having started in MACRO-10 on a KA10 
PDP-10 in 9th grade. I always assumed assembler would be faster for 
anything, given the right amount of optimization. The assembler side of 
the experiment, I did the CGA graphics directly. I think in the C 
version, I used the built-in library that came with it. I no longer have 
the source for the C version, but I do, for the assembler version. I 
didn't have an 8087 floating point accelerator, so I wrote my assembler 
example to use two 16-bit words of integers, combining them for a 31-bit 
integer value with sign.

Timing 1000 rotations, the assembler version took X amount of time. The 
C version took X*1.5

Now mind you, the C version used real floating point, and a software 
floating point library with no hardware accelerator. At that point, I 
realized C was the way to go. It had passed my experiment with flying 
colors. The C compiler, I believe, was from Computer Innovations, 
Copyright (c)1981,82,83,84,85

The reason this is similar to Ken's statement above: In the assembler 
version, the cube would deform quite a bit before the run would finish. 
A 31-bit integer didn't accurately reflect the result of the math. Over 
time, that slight inaccuracy really added up. The accuracy of the C 
version using floats was spot on.  So while I basically cheated for the 
assembler version, causing the deformation of the cube over time, the C 
version was 100% accurate even though it was slower.

I wonder, is there something inherently different between PDP-11/7 
floats and Intel's leading to the inaccuracy Ken mentions? Was the 
PDP-11 (or the -7) floating point that much different than IEEE-754 ?

art k.