From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 1ef4a806 for ; Sat, 19 Oct 2019 19:50:53 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 7BFED93D48; Sun, 20 Oct 2019 05:50:52 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 42E3A93D31; Sun, 20 Oct 2019 05:50:24 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="QhstpLQH"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 3462893D31; Sun, 20 Oct 2019 05:50:23 +1000 (AEST) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by minnie.tuhs.org (Postfix) with ESMTPS id 5B51F93D2D for ; Sun, 20 Oct 2019 05:50:22 +1000 (AEST) Received: by mail-oi1-f180.google.com with SMTP id g81so7968501oib.8 for ; Sat, 19 Oct 2019 12:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M+QTT96EZpFTPAdwnKuZx+EgO0iO79sI47LecRmDLHM=; b=QhstpLQHlSTk0mUrOJudrYsbxaW2sO4awk7R8pzgD22eTpXSfGJKInRZLyCrOwm54M tZxjTxjSzIvG23kewgoeTdbDABZS1S1ABm0kN+Hx5XvvUJfr/fgWxCtdeHgPD3Sj9Kl7 KDuy28oLu+nl4PTmKLm7idQWL/MKNO8pjXLbgFwcncOKiEk5ch8uHjc1LQUunYl1Xm/p 0era/wKgS9X6ZRCrbYv6Zg/bSQKXJSzq6l1N4RiP3KgoJ3axsmwQ6iVfYbEr+wcjiXnI C7bZyAT71g/ci+0/mVyournjwCb5HITGelytCce+949yZ0gC2RDqWP0u4Wt/ql95cPxm Kvhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M+QTT96EZpFTPAdwnKuZx+EgO0iO79sI47LecRmDLHM=; b=g6+eOhpzYvrpyqZOJax/P/n8T2lcOtxaU2mDxW0Qz7bp0gDj85kGjEHPr/GfRRPBHd PxBcvB5mTa4tJ/p6ASbRTz+IvVZdatPOVVuo3BVijeum34+pfW+YOqk5AK7N7Vzafq5X FYa/Qs9+GfcFVnGAZiaqVh1NZATfq5DafYcdn3y3pHBLf/iI6IokqwGmc5O9wfpzDgh8 yzQ8FIqbaljGtZZufyyAwnrZFGNMpzGHMPEYen0QZU8nA5ZVCUIfqkh66s3DuH4lc8Fv pfULE2lGjZ8yl8CSd6EL9ZmOkMfB8FwUxP8KEIZwFADPhwacNIkCmZ+3DsrLmnmf+Tjd I7ow== X-Gm-Message-State: APjAAAVHsn/sC4McbSqrXuFj62obxeVe3JipFbgqzVph/nhj+UH6pG39 R7nBXCsT5g12+ripSDqL7opqcS24C7NOxs5nAy4= X-Google-Smtp-Source: APXvYqwIvflyToLuaAl5eMXyBdz0U3n+kEVoQUW896A++pb5+w0clUR2SIKsZpnig03lcIhwuvk+McPhvYj+PJ3iRWA= X-Received: by 2002:aca:4884:: with SMTP id v126mr13054174oia.54.1571514621553; Sat, 19 Oct 2019 12:50:21 -0700 (PDT) MIME-Version: 1.0 References: <201910191440.x9JEe8PB035921@tahoe.cs.Dartmouth.EDU> In-Reply-To: From: Henry Bent Date: Sat, 19 Oct 2019 15:50:04 -0400 Message-ID: To: Clem Cole Content-Type: multipart/alternative; boundary="000000000000c6f088059548c25b" Subject: Re: [TUHS] Space Travel, was New: The Earliest UNIX Code X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society , Doug McIlroy Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000c6f088059548c25b Content-Type: text/plain; charset="UTF-8" I think the astonishment is not so much that tailored specialty floating point libraries exist, or that programmers are able to squeeze performance out of processors using hardware floating point and/or vector units. What is impressive to me is that floating point was being done on processors that had essentially no hardware support for floating point whatsoever, and that the processors in question were running at what we would consider infinitesimally slow speeds by the standards of what is inside my barely modern home thermostat. These hacks make me think of the "demoscene" folks who write programs for early '80s home 8 bit microcomputers in assembly. The idea is to squeeze as much apparent visual performance out of a system as possible, so an example might be scrolling characters across the screen while a wireframe cube rotates in the background, all on a Commodore VIC-20 with 4K of RAM. The idea is to start with a mathematically sound algorithm but then cut every corner possible and account for every single timing bug and hardware quirk. It's a fun demonstration for two or three minutes but I imagine that after an hour or two the numerical inaccuracies would set in, just as described earlier in this thread. -Henry On Sat, 19 Oct 2019 at 15:20, Clem Cole wrote: > Abhinav -- it is still done today. For Intel's MKL we must have a team > of programmers that specialize in writing math at the lowest levels. DEC, > CDC, Cray, IBM did the same thing back in the day. Check out: Intel > Math Kernel Library (*a.k.a.* MKL) . > > > On Sat, Oct 19, 2019 at 2:34 PM Abhinav Rajagopalan < > abhinavrajagopalan@gmail.com> wrote: > >> Forgive me for both hijacking this thread, and to address my amateurish >> gnawing concern, but how was it be possible to write differential/integral >> equations at an assembly/machine level at the time, especially in machines >> such as the PDP-7 and such which had IIRC just 16 instructions and operated >> on the basis of mere words, especially the floating point math being done. >> Surmising from some personal experience that writing mathematical programs >> is hard even now, although there exist certain functional paradigms, and >> specialised environments such as MATLAB or Mathematica. The >> complexity seems to remain the same if not more now, due to the vast oodles >> of data to handle stemming from the nature of the world. >> >> Were they loaded as just words as any other instruction or were there >> separate coprocessors that did the number crunching? I'm guessing >> Fortran-ish kind of implementations were done, but the hardware level >> computation itself I just can't process. >> >> It just blows my mind now thinking backwards in terms of those >> monster machines being loaded with trails of paper tape instructions to >> play Space Travel. Being born in the late 90's doesn't help me too. >> >> Also, on a related note, don't know if you've watched the interview >> of Ken done by Brian at the Vintage >> Comptuer Federation 2019, there might be a few surprises lurking around the >> middle of that when they discuss pipes and grep. >> >> Thank you! >> >> On Sat, Oct 19, 2019 at 8:11 PM Doug McIlroy >> wrote: >> >>> I was about to add a footnote to history about >>> how the broad interests and collegiality of >>> Bell Labs staff made Space Travel work, when >>> I saw that Ken beat me to telling how he got >>> help from another Turing Award winner. >>> >>> > 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. >>> >>> If I remember correctly, the cause of Ken's >>> difficulty was not roundoff error. It >>> was discretization error in the integration >>> formula--probably f(t+dt)=f(t)+f'(t)dt. >>> Dick saw that the formula did not conserve >>> energy and found an alternative that did. >>> >> >> >> -- >> >> Abhinav Rajagopalan >> >> >> --000000000000c6f088059548c25b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the astonishment is not so much that tailored= specialty floating point libraries exist, or that programmers are able to = squeeze performance out of processors using hardware floating point and/or = vector units.=C2=A0 What is impressive to me is that floating point was bei= ng done on processors that had essentially no hardware support for floating= point whatsoever, and that the processors in question were running at what= we would consider infinitesimally slow speeds by the standards of what is = inside my barely modern home thermostat.

These hac= ks make me think of the "demoscene" folks who write programs for = early '80s home 8 bit microcomputers in assembly.=C2=A0 The idea is to = squeeze as much apparent visual performance out of a system as possible, so= an example might be scrolling characters across the screen while a wirefra= me cube rotates in the background, all on a Commodore VIC-20 with 4K of RAM= .=C2=A0 The idea is to start with a mathematically sound algorithm but then= cut every corner possible and account for every single timing bug and hard= ware quirk.=C2=A0 It's a fun demonstration for two or three minutes but= I imagine that after an hour or two the numerical inaccuracies would set i= n, just as described earlier in this thread.

-= Henry

On Sat, 19 Oct 2019 at 15:20, Clem Cole <clemc@ccc.com> wrote:
Abhinav -- it is still done today. =C2= =A0 For Intel's MKL we must have a team of programmers that specialize = in writing math at the lowest levels.=C2=A0 DEC, CDC, Cray, IBM did the sam= e thing back in the day. =C2=A0 Check out: =C2=A0Intel Math Kernel Library (a.k.= a. MKL). =C2=A0

On Sat, Oct 19, 2019 at 2:34 PM Abhinav = Rajagopalan <abhinavrajagopalan@gmail.com> wrote:
Forgive me for both hijacking this thread, and = to address my amateurish gnawing concern, but how was it be possible to wri= te differential/integral equations at an assembly/machine level at the time= , especially in machines such as the PDP-7 and such which had IIRC just 16 = instructions and operated on the basis of mere words, especially the floati= ng=C2=A0point=C2=A0math being done. Surmising from some personal experience= that writing mathematical programs is hard even now, although there exist = certain functional paradigms, and specialised environments such as MATLAB o= r Mathematica. The complexity=C2=A0seems to remain the same if not more now= , due to the vast oodles of data to handle stemming from the=C2=A0nature of= the world.

Were they loaded as just words as any other instruction or = were there separate=C2=A0coprocessors that did the number=C2=A0crunching? I= 'm guessing Fortran-ish kind of implementations were done, but the hard= ware level computation itself I just can't process.

It just blows m= y mind now thinking backwards in terms of those monster=C2=A0machines being= loaded with trails of paper tape instructions to play Space Travel. Being = born in the late 90's doesn't help me too.

Also, on a related n= ote, don't know if you've watched the=C2=A0interview=C2=A0of Ken done by Brian = at the Vintage Comptuer Federation 2019, there might be a few surprises lur= king around the middle of that when they discuss pipes and grep.=C2=A0

= Thank you!

On Sat, Oct 19, 2019 at 8:11 PM Doug McIlroy = <doug@cs.dart= mouth.edu> wrote:
I was about to add a footnote to history about
how the broad interests and collegiality of
Bell Labs staff made Space Travel work, when
I saw that Ken beat me to telling how he got
help from another Turing Award winner.

> 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.

If I remember correctly, the cause of Ken's
difficulty was not roundoff error. It
was discretization error in the integration
formula--probably f(t+dt)=3Df(t)+f'(t)dt.
Dick saw that the formula did not conserve
energy and found an alternative that did.


--
=

Abhinav Rajag= opalan

--000000000000c6f088059548c25b--