From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] Space Travel, was New: The Earliest UNIX Code
Date: Sat, 19 Oct 2019 11:57:55 +1100 [thread overview]
Message-ID: <20191019005752.3r7srxe73v47rtuy@localhost.localdomain> (raw)
In-Reply-To: <9053c41b-e306-8547-50fd-207e0bfb49af@kilonet.net>
[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-10-19 0:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-18 11:52 Doug McIlroy
2019-10-18 18:36 ` Steffen Nurpmeso
2019-10-18 20:19 ` SPC
2019-10-18 22:04 ` Ken Thompson via TUHS
2019-10-18 23:20 ` Arthur Krewat
2019-10-19 0:57 ` G. Branden Robinson [this message]
2019-10-19 1:11 ` Arthur Krewat
2019-10-29 2:18 ` Lawrence Stewart
2019-10-26 15:10 ` Lars Brinkhoff
-- strict thread matches above, loose matches on Subject: below --
2019-10-19 14:40 Doug McIlroy
2019-10-19 18:32 ` Abhinav Rajagopalan
2019-10-19 18:44 ` Abhinav Rajagopalan
2019-10-19 19:19 ` Clem Cole
2019-10-19 19:50 ` Henry Bent
2019-10-19 20:24 ` Arthur Krewat
2019-10-19 13:13 Doug McIlroy
2019-10-17 19:21 [TUHS] New: The Earliest UNIX Code - From the Collection of the Software History Center, Computer History Museum Lyle Bickley
2019-10-17 20:44 ` [TUHS] Space Travel, was New: The Earliest UNIX Code Warren Toomey
2019-10-17 22:39 ` Warner Losh
2019-10-17 22:51 ` Warren Toomey
2019-10-18 5:59 ` Lars Brinkhoff
2019-10-18 9:30 ` SPC
2019-10-18 17:36 ` Nemo
2019-10-18 3:01 ` Warren Toomey
2019-10-18 5:07 ` Lars Brinkhoff
2019-10-18 5:10 ` Lars Brinkhoff
2019-10-18 13:37 ` Warner Losh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191019005752.3r7srxe73v47rtuy@localhost.localdomain \
--to=g.branden.robinson@gmail.com \
--cc=tuhs@minnie.tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).