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.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 f0c2f4b9 for ; Fri, 18 Oct 2019 23:21:19 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id CE1489B883; Sat, 19 Oct 2019 09:21:17 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D26F49B57F; Sat, 19 Oct 2019 09:20:50 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=kilonet.net header.i=@kilonet.net header.b="b80fzwEh"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9E48B9B57F; Sat, 19 Oct 2019 09:20:47 +1000 (AEST) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) by minnie.tuhs.org (Postfix) with ESMTPS id 8FC329B553 for ; Sat, 19 Oct 2019 09:20:46 +1000 (AEST) Received: from medusa.kilonet.net ([72.69.223.115]) by :SMTPAUTH: with ESMTPA id LbY5ikIGeuTcNLbY5ihqTy; Fri, 18 Oct 2019 16:20:46 -0700 Received: from [199.89.231.101] (ender.kilonet.net [199.89.231.101]) by medusa.kilonet.net (8.14.8/8.15.1) with ESMTP id x9INKjgE019554 for ; Fri, 18 Oct 2019 19:20:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kilonet.net; s=default; t=1571440845; bh=S8FwjfVkL2VVmHa6jT/hfI1GKbR9NlrgtsxYlLPMqWw=; h=Subject:To:References:From:Date:In-Reply-To; b=b80fzwEhMr+1/uSMLDM3FHafbEMoM4uusJAc6vpRz22aCX/BHvHj2BTxR/Up3LsIi GYtcFWc3PLPijERhy+Dw6mVr2JPse+eb+BYk2S1aY2V10SU1ETzeTZBRMa3QrwcYix YUdlpu1wA29XRqijadOUS6tVIBXaCZg0Z75WL0cY= To: tuhs@minnie.tuhs.org References: <201910181152.x9IBq95P001809@coolidge.cs.Dartmouth.EDU> <20191018183610.diq_a%steffen@sdaoden.eu> From: Arthur Krewat Message-ID: <9053c41b-e306-8547-50fd-207e0bfb49af@kilonet.net> Date: Fri, 18 Oct 2019 19:20:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CMAE-Envelope: MS4wfGb1GtzPC7/hx+aHVjnwSzNYY4qDa+pgaJl/S8XmcBm6NRFEmQrNlirMTKkP4/6HSTyWBVNAiobrISrtEL4DzlKmBgvOr/mtQAlPRHioaLUUtWvqzNyk Bbd3uT/Os5MgS+gEiCP8TqF0Sb6wpOBEfcJPDXs4FizbvLwPd4ivI1PWuAI8r9umnzciaQ2abcFi7Q== 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" 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.