18 Oct
2019
18 Oct
'19
5:52 p.m.
10-36-55.pdf user-mode programs: pool game
This game, written by ken, used the Graphic 2. One of its
earliest tests--random starting positions and velocities on
a frictionless table with no collision detection--produced
a mesmerizing result. This was saved in a program called
"weird1", which was carried across to the PDP11.
Weird1 was a spectacular accidental demonstration of structure
in pseudo-random numbers. After several minutes the dots
representing pool balls would evanescently form short local
alignments. Thereafter from time to time ever-larger alignments
would materialize. Finally in a grand climax all the balls
converged to a single point.
It was stunning to watch perfect order emerge from apparent
chaos. One of my fondest hopes is to see weird1 revived.
Doug
19 Oct
19 Oct
12:36 a.m.
Doug McIlroy wrote in <201910181152.x9IBq95P001809(a)coolidge.cs.Dartmouth\
.EDU>:
|> 10-36-55.pdf user-mode programs: pool game
|
|This game, written by ken, used the Graphic 2. One of its
|earliest tests--random starting positions and velocities on
|a frictionless table with no collision detection--produced
|a mesmerizing result. This was saved in a program called
|"weird1", which was carried across to the PDP11.
|
|Weird1 was a spectacular accidental demonstration of structure
|in pseudo-random numbers. After several minutes the dots
|representing pool balls would evanescently form short local
|alignments. Thereafter from time to time ever-larger alignments
|would materialize. Finally in a grand climax all the balls
|converged to a single point.
|
|It was stunning to watch perfect order emerge from apparent
|chaos. One of my fondest hopes is to see weird1 revived.
Not about random orders chaos, no, quite the opposite, but the
IOCCC context 2012 was won by endoh1, a fluid simulator using
"Smoothed-particle hydrodynamics (SPH)", and the "marching
squares" algorithm to render particles. If the defaults for
gravity (1 -> 0), pressure (4 -> 1) and viscosity (8 -> 2) are
changed entertaining effects can be seen.
It is like swirling, not self-organizing order out of chaos, but
i wanted to post it nonetheless because of some properties of the
code, for example the IOCCC Makefile introduces "make love", may
also echo "You are not expected to understand this", and what else
can be expected. The xxx.txt is an input file i made for this
post, the competition ones are neat (a fountain, for example), but
for normal gravity etc.
$ make endoh1_color
$ ./endoh1_color < xxx.txt
And spend some time.
|Doug
--End of <201910181152.x9IBq95P001809(a)coolidge.cs.Dartmouth.EDU>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
2:19 a.m.
Well, It appears that CHM has published an article about "Space Travel"
code...
https://computerhistory.org/blog/the-earliest-unix-code-an-anniversary-sour…
Cordiales saludos / Kind Regards.
Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations
--
*Sergio Pedraja*
--
4:04 a.m.
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.
i look forward to the OCR of the code.
On Fri, Oct 18, 2019 at 1:20 PM SPC <spedraja(a)gmail.com> wrote:
Well, It appears that CHM has published an article about "Space Travel"
code...
https://computerhistory.org/blog/the-earliest-unix-code-an-anniversary-sour…
Cordiales saludos / Kind Regards.
Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations
--
Sergio Pedraja
--
5:20 a.m.
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.
6:57 a.m.
At 2019-10-18T19:20:35-0400, Arthur Krewat wrote:
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.
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 ?
It sounds like it could be a simple matter of precision to me.
It takes 32 bits to store a single-precision floating point value.
Double-precision requires 64. In IEEE 754, the significand is 53 bits
(52 bits plus the implicit leading 1).
I can never remember the C type promotion rules without looking them up,
but IIRC at least in some circumstances C promotes floats to doubles, at
least for intermediate results. And the software floating-point library
you used could well have done the same, or perhaps it used doubles all
the way internally. Either of these could have prevented accumulated
roundoff.
I've heard, with a level of conviction somewhere between folklore and
formal demonstration[1], that for many practical numerical problems,
single-precision is just not quite good enough, but double-precision is
ample. Somewhere between 24 and 53 bits of significant, perhaps, there
is a sweet spot.
The wisdom I've absorbed is, if you have to do floating-point, use
doubles, unless you can clearly and convincingly articulate why you
absolutely need more precision, or can get away with less. (For same 3D
game-rendering applications, half-precision is adequate.)
A non-quantified "single-precision will be faster" declaration should be
understood to include a lot of "!!1!11" punctuation after it, and such
people should be handled as delicately as any other Gentoo user.
Regards,
Branden
[1] Example: Ben Klemens, _21st-Century C_, O'Reilly.
29 Oct
29 Oct
8:18 a.m.
On 2019, Oct 18, at 6:04 PM, Ken Thompson via TUHS
<tuhs(a)minnie.tuhs.org> 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.
i look forward to the OCR of the code.
I think this must be a variant of “Symplectic Integration”.
My son had an internship at Mitre having something to do with orbit
determination and I got to reading papers about it.
Symplectic integration is what you want for systems described by a Hamiltonian,
such as orbits because the usual integrators (Euler, Runge-Kutta) don’t conserve
the interchange between position and momentum, or something like that.
As far as I can tell, this sort of stuff started getting published in the 1980s,
so Hamming may well have tossed it off earlier and just not written it up.
Could be a nice historical footnote for the development of orbit calculations.
Could be fun to reverse engineer the code.
-L
26 Oct
26 Oct
9:10 p.m.
Doug McIlroy <doug(a)cs.dartmouth.edu> writes:
This is what the pool game looks like:
https://github.com/simh/simh/issues/754#issuecomment-546611076
10-36-55.pdf
user-mode programs: pool game
This game, written by ken, used the Graphic 2. One of its
earliest tests--random starting positions and velocities on
a frictionless table with no collision detection--produced
a mesmerizing result.
1880
days inactive
1891
days old
8 comments
8 participants
participants (8)
-
Arthur Krewat -
Doug McIlroy -
G. Branden Robinson -
Ken Thompson -
Lars Brinkhoff -
Lawrence Stewart -
SPC -
Steffen Nurpmeso