Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #113595 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2025-10-03 08:58 +0000 |
| Last post | 2025-12-28 21:34 +0000 |
| Articles | 20 on this page of 215 — 26 participants |
Back to article view | Back to comp.arch
Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-03 08:58 +0000
Re: Linus Torvalds on bad architectural features BGB <cr88192@gmail.com> - 2025-10-03 05:40 -0500
Re: Linus Torvalds on bad architectural features Michael S <already5chosen@yahoo.com> - 2025-10-03 13:46 +0300
SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-10-03 11:26 -0400
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-03 15:42 +0000
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) kegs@provalid.com (Kent Dickey) - 2025-10-03 16:18 +0000
Re: SASOS and virtually tagged caches Stefan Monnier <monnier@iro.umontreal.ca> - 2025-10-03 15:44 -0400
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) George Neuner <gneuner2@comcast.net> - 2025-10-06 06:54 -0400
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) kegs@provalid.com (Kent Dickey) - 2025-10-06 16:44 +0000
Re: SASOS and virtually tagged caches BGB <cr88192@gmail.com> - 2025-10-03 17:42 -0500
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) kegs@provalid.com (Kent Dickey) - 2025-10-04 04:36 +0000
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) John Levine <johnl@taugh.com> - 2025-10-04 18:36 +0000
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-04 19:00 +0000
Re: SASOS and virtually tagged caches Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-10-04 12:31 -0700
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) Michael S <already5chosen@yahoo.com> - 2025-10-05 01:05 +0300
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) John Levine <johnl@taugh.com> - 2025-10-04 22:44 +0000
Re: SASOS and virtually tagged caches BGB <cr88192@gmail.com> - 2025-10-04 17:57 -0500
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) Michael S <already5chosen@yahoo.com> - 2025-10-05 02:18 +0300
Re: SASOS and virtually tagged caches EricP <ThatWouldBeTelling@thevillage.com> - 2025-10-05 13:02 -0400
Re: SASOS and virtually tagged caches Lynn Wheeler <lynn@garlic.com> - 2025-10-04 14:17 -1000
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) kegs@provalid.com (Kent Dickey) - 2025-10-06 15:49 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-03 15:41 +0000
Re: Linus Torvalds on bad architectural features BGB <cr88192@gmail.com> - 2025-10-03 16:19 -0500
Re: Linus Torvalds on bad architectural features John Savard <quadibloc@invalid.invalid> - 2025-10-09 13:57 +0000
Re: Linus Torvalds on bad architectural features John Savard <quadibloc@invalid.invalid> - 2025-10-09 21:41 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-09 22:10 +0000
Re: Linus Torvalds on bad architectural features scott@slp53.sl.home (Scott Lurndal) - 2025-10-09 22:21 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-10 08:30 +0000
Re: Linus Torvalds on bad architectural features scott@slp53.sl.home (Scott Lurndal) - 2025-10-10 15:02 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-11 07:18 +0000
Re: Linus Torvalds on bad architectural features John Levine <johnl@taugh.com> - 2025-10-12 02:37 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 07:13 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 09:51 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 10:14 +0000
Re: Linus Torvalds on bad architectural features Michael S <already5chosen@yahoo.com> - 2025-10-12 13:56 +0300
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 11:38 +0000
Re: Linus Torvalds on bad architectural features Michael S <already5chosen@yahoo.com> - 2025-10-12 15:31 +0300
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 13:36 +0000
Re: Linus Torvalds on bad architectural features Michael S <already5chosen@yahoo.com> - 2025-10-12 20:13 +0300
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 17:47 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-12 19:31 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 13:31 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 15:10 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 15:48 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 16:25 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 17:25 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 20:03 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 21:07 +0000
Re: Linus Torvalds on bad architectural features Robert Swindells <rjs@fdy2.co.uk> - 2025-10-13 17:26 +0000
Re: Linus Torvalds on bad architectural features Michael S <already5chosen@yahoo.com> - 2025-10-12 19:56 +0300
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 17:02 +0000
Re: Linus Torvalds on bad architectural features John Levine <johnl@taugh.com> - 2025-10-12 21:07 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-12 16:11 +0000
Re: Linus Torvalds on bad architectural features BGB <cr88192@gmail.com> - 2025-10-12 13:04 -0500
Re: Linus Torvalds on bad architectural features Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-28 00:10 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-28 17:43 +0000
Re: Linus Torvalds on bad architectural features EricP <ThatWouldBeTelling@thevillage.com> - 2025-12-28 13:34 -0500
Re: Linus Torvalds on bad architectural features Stefan Monnier <monnier@iro.umontreal.ca> - 2025-12-28 13:55 -0500
Re: Linus Torvalds on bad architectural features BGB <cr88192@gmail.com> - 2025-12-28 16:09 -0600
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-12-28 23:00 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-12-29 06:59 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-12-29 08:17 +0000
word order and byte order (was: Linus Torvalds ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-12-29 09:08 +0000
Re: word order and byte order (was: Linus Torvalds ...) Thomas Koenig <tkoenig@netcologne.de> - 2025-12-29 13:39 +0000
Re: word order and byte order (was: Linus Torvalds ...) John Levine <johnl@taugh.com> - 2025-12-31 02:54 +0000
Re: word order and byte order (was: Linus Torvalds ...) Thomas Koenig <tkoenig@netcologne.de> - 2025-12-31 09:43 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) John Levine <johnl@taugh.com> - 2026-01-01 17:46 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Thomas Koenig <tkoenig@netcologne.de> - 2026-01-04 00:21 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) John Levine <johnl@taugh.com> - 2026-01-04 04:12 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-04 08:06 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-04 12:20 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-04 18:01 +0000
Re: floating point history, word order and byte order Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-01-04 15:20 -0800
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 09:08 +0000
Re: floating point history, word order and byte order jgd@cix.co.uk (John Dallman) - 2026-01-06 22:06 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-07 13:34 +0200
Re: floating point history, word order and byte order jgd@cix.co.uk (John Dallman) - 2026-01-07 13:16 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-07 17:55 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 17:39 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-07 18:58 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 20:05 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-07 23:47 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 22:10 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 00:59 +0000
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-07 14:23 -0600
Re: floating point history, word order and byte order Robert Finch <robfi680@gmail.com> - 2026-01-07 21:16 -0500
Re: floating point history, word order and byte order kegs@provalid.com (Kent Dickey) - 2026-01-28 13:25 +0000
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-28 15:26 -0600
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-28 23:03 +0000
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-28 17:43 -0600
Re: floating point history, word order and byte order Robert Finch <robfi680@gmail.com> - 2026-01-29 03:47 -0500
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-29 21:30 +0000
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-29 17:44 -0600
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-07 18:56 +0100
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-07 14:38 -0600
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 21:18 +0000
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-07 16:10 -0600
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-08 00:05 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-08 02:38 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-08 10:52 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-08 18:50 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 13:10 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-08 18:54 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 21:35 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-09 01:24 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-10 18:02 +0100
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-11 15:01 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 18:18 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-11 20:50 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 22:11 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-12 12:20 +0200
Re: floating point history, word order and byte order Stefan Monnier <monnier@iro.umontreal.ca> - 2026-01-13 14:45 -0500
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-21 01:44 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-21 11:05 +0200
Re: floating point history, word order and byte order Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-14 20:49 -0800
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-21 22:33 +0100
Re: floating point history, word order and byte order Robert Finch <robfi680@gmail.com> - 2026-01-22 14:37 -0500
Re: floating point history, word order and byte order George Neuner <gneuner2@comcast.net> - 2026-01-22 15:12 -0500
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-22 22:57 +0200
Re: floating point history, word order and byte order George Neuner <gneuner2@comcast.net> - 2026-01-23 13:47 -0500
[OT] Usenet (was: floating point history ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-24 15:58 +0000
Re: [OT] Usenet (was: floating point history ...) David LaRue <huey.dll@tampabay.rr.com> - 2026-01-25 01:09 +0000
Re: [OT] Usenet (was: floating point history ...) George Neuner <gneuner2@comcast.net> - 2026-01-25 18:12 -0500
Re: [OT] Usenet (was: floating point history ...) scott@slp53.sl.home (Scott Lurndal) - 2026-01-26 21:38 +0000
Re: [OT] Usenet Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2026-01-27 12:19 +0200
Re: [OT] Usenet (was: floating point history ...) George Neuner <gneuner2@comcast.net> - 2026-01-27 06:33 -0500
Re: floating point history, word order and byte order jgd@cix.co.uk (John Dallman) - 2026-01-24 09:11 +0000
Re: floating point history, word order and byte order Brett <ggtgp@yahoo.com> - 2026-01-25 22:13 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 22:30 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-12 01:07 +0200
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-12 01:10 +0200
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-12 00:57 +0200
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 01:14 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-11 12:52 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 18:07 +0000
Re: floating point history, word order and byte order "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-11 12:40 -0800
Re: floating point history, word order and byte order "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-11 15:41 -0800
Re: floating point history, word order and byte order "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-11 15:40 -0800
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 13:05 +0100
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 00:33 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-11 14:31 +0200
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-10 23:21 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 00:03 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 11:21 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 18:08 +0000
Re: floating point history, word order and byte order Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-01-11 08:38 -0800
Re: floating point history, word order and byte order John Levine <johnl@taugh.com> - 2026-01-11 19:03 +0000
Re: floating point history, word order and byte order Thomas Koenig <tkoenig@netcologne.de> - 2026-01-12 22:22 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-13 09:55 +0100
Re: floating point history, word order and byte order (was: Linus Torvalds ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-04 18:47 +0000
Re: floating point history, word order and byte order Stefan Monnier <monnier@iro.umontreal.ca> - 2026-01-04 14:12 -0500
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-04 20:14 +0000
Re: floating point history, word order and byte order Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-01-04 13:05 -0800
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 08:51 +0000
Re: floating point history, word order and byte order Stefan Monnier <monnier@iro.umontreal.ca> - 2026-01-05 11:55 -0500
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-05 19:26 +0200
Re: floating point history, word order and byte order Stefan Monnier <monnier@iro.umontreal.ca> - 2026-01-05 14:33 -0500
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-06 17:26 +0000
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 17:40 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-07 17:57 +0000
Re: floating point history, word order and byte order Thomas Koenig <tkoenig@netcologne.de> - 2026-01-09 16:32 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 11:49 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 18:11 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-12 00:37 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-12 02:05 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-12 16:28 +0100
Re: floating point history, word order and byte order (was: Linus Torvalds ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 08:16 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 10:21 +0000
Re: floating point history, word order and byte order EricP <ThatWouldBeTelling@thevillage.com> - 2026-01-05 11:05 -0500
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 18:03 +0000
Re: floating point history, word order and byte order EricP <ThatWouldBeTelling@thevillage.com> - 2026-01-05 13:51 -0500
Re: floating point history, word order and byte order EricP <ThatWouldBeTelling@thevillage.com> - 2026-01-05 14:21 -0500
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-06 17:50 +0000
Re: floating point history, word order and byte order EricP <ThatWouldBeTelling@thevillage.com> - 2026-01-05 10:31 -0500
Re: floating point history, word order and byte order EricP <ThatWouldBeTelling@thevillage.com> - 2026-01-05 11:02 -0500
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-06 18:14 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) scott@slp53.sl.home (Scott Lurndal) - 2026-01-05 15:40 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-04 13:22 +0100
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-04 12:36 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Thomas Koenig <tkoenig@netcologne.de> - 2026-01-04 16:45 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-04 19:35 +0200
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-06 12:35 +0100
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-06 15:26 +0200
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-06 17:06 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-06 17:59 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-06 20:15 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-06 19:35 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-06 23:09 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-06 17:56 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-06 20:12 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-06 19:29 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-07 15:06 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) scott@slp53.sl.home (Scott Lurndal) - 2026-01-07 15:24 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-07 18:06 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) scott@slp53.sl.home (Scott Lurndal) - 2026-01-07 16:41 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-07 17:32 +0000
Re: floating point history, word order and byte order scott@slp53.sl.home (Scott Lurndal) - 2026-01-07 19:14 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 12:50 +0100
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-08 15:41 +0200
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 21:25 +0100
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-08 22:50 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 17:44 +0000
Re: floating point history, word order and byte order Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-01-07 10:22 -0800
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-07 18:47 +0100
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-07 18:38 +0100
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-07 18:38 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 20:11 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 13:01 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-08 18:52 +0000
Re: floating point history, word order and byte order scott@slp53.sl.home (Scott Lurndal) - 2026-01-07 19:19 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 19:56 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-04 13:17 +0100
Re: Linus Torvalds on bad architectural features Stefan Monnier <monnier@iro.umontreal.ca> - 2025-12-29 13:48 -0500
Re: Linus Torvalds on bad architectural features Bill Findlay <findlaybill@blueyonder.co.uk> - 2025-12-28 19:21 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-28 21:34 +0000
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-08 18:50 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1767898214-5857@newsgrouper.org> |
| In reply to | #114693 |
Michael S <already5chosen@yahoo.com> posted:
> On Thu, 08 Jan 2026 02:38:57 GMT
> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>
> > MitchAlsup <user5857@newsgrouper.org.invalid> posted:
> > -------------------
> > >
> > > My Transcendentals get to 1ULP when the multiplier tree is
> > > 59×59-bits {a bit more than ½ of the get 1ULP at 58×58}. I gave a
> > > lot of though to this {~1 year} before deciding that a "Do
> > > everything else" function unit was "overall" better than a couple
> > > of "near miss" FUs. So, IMUL comes in at 4 cycles, FMUL at 4
> > > cycles, FDIV at 17, SQRT at 22, and IDIV at 25. The fast IMUL makes
> > > up a lot for the "size" of the FU.
> >
> > I forgot to add that my transcendentals went from <just barely>
> > faithfully rounded 0.75ULP RMS to 5.002ULP RMS when the tree was
> > expanded.
> >
>
> Don't you mean '0.5002 ULP' ?
>
Technically, and rounding that is not !EEE correct is at least 1 ULP.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-01-08 13:10 +0100 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10jo6r6$1f1e9$3@dont-email.me> |
| In reply to | #114691 |
MitchAlsup wrote:
>
> MitchAlsup <user5857@newsgrouper.org.invalid> posted:
> -------------------
>>
>> My Transcendentals get to 1ULP when the multiplier tree is 59×59-bits
>> {a bit more than ½ of the get 1ULP at 58×58}. I gave a lot of though
>> to this {~1 year} before deciding that a "Do everything else" function
>> unit was "overall" better than a couple of "near miss" FUs. So, IMUL
>> comes in at 4 cycles, FMUL at 4 cycles, FDIV at 17, SQRT at 22, and
>> IDIV at 25. The fast IMUL makes up a lot for the "size" of the FU.
>
> I forgot to add that my transcendentals went from <just barely>
> faithfully rounded 0.75ULP RMS to 5.002ULP RMS when the tree was
> expanded.
You obviously intended 0.5002 ulp, so you have about 11-13 guard bits to
get the rounding correct?
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-08 18:54 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1767898480-5857@newsgrouper.org> |
| In reply to | #114697 |
Terje Mathisen <terje.mathisen@tmsw.no> posted:
> MitchAlsup wrote:
> >
> > MitchAlsup <user5857@newsgrouper.org.invalid> posted:
> > -------------------
> >>
> >> My Transcendentals get to 1ULP when the multiplier tree is 59×59-bits
> >> {a bit more than ½ of the get 1ULP at 58×58}. I gave a lot of though
> >> to this {~1 year} before deciding that a "Do everything else" function
> >> unit was "overall" better than a couple of "near miss" FUs. So, IMUL
> >> comes in at 4 cycles, FMUL at 4 cycles, FDIV at 17, SQRT at 22, and
> >> IDIV at 25. The fast IMUL makes up a lot for the "size" of the FU.
> >
> > I forgot to add that my transcendentals went from <just barely>
> > faithfully rounded 0.75ULP RMS to 5.002ULP RMS when the tree was
> > expanded.
>
> You obviously intended 0.5002 ulp, so you have about 11-13 guard bits to
> get the rounding correct?
64-53 = 11 yes
But a single incorrect rounding is 1 ULP all by itself.
>
> Terje
>
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-01-08 21:35 +0100 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10jp4e5$1qr00$1@dont-email.me> |
| In reply to | #114703 |
MitchAlsup wrote:
>
> Terje Mathisen <terje.mathisen@tmsw.no> posted:
>
>> MitchAlsup wrote:
>>>
>>> MitchAlsup <user5857@newsgrouper.org.invalid> posted:
>>> -------------------
>>>>
>>>> My Transcendentals get to 1ULP when the multiplier tree is 59×59-bits
>>>> {a bit more than ½ of the get 1ULP at 58×58}. I gave a lot of though
>>>> to this {~1 year} before deciding that a "Do everything else" function
>>>> unit was "overall" better than a couple of "near miss" FUs. So, IMUL
>>>> comes in at 4 cycles, FMUL at 4 cycles, FDIV at 17, SQRT at 22, and
>>>> IDIV at 25. The fast IMUL makes up a lot for the "size" of the FU.
>>>
>>> I forgot to add that my transcendentals went from <just barely>
>>> faithfully rounded 0.75ULP RMS to 5.002ULP RMS when the tree was
>>> expanded.
>>
>> You obviously intended 0.5002 ulp, so you have about 11-13 guard bits to
>> get the rounding correct?
>
> 64-53 = 11 yes
For many of the functions you can do a lot by letting the final
operation be a merging of the first/largest term, particularly if you do
that with extended precision.
I.e something like fpatan2() works quite nicely this way, just not
enough for exact rounding.
You need to combine this with extended precision range adjustment at the
end.
>
> But a single incorrect rounding is 1 ULP all by itself.
:-)
Yeah, there are strong forces who want to have, at least as a
suggested/recommended option, a set of transcendental functions which
are exactly rounded.
It is provably doable for float, in very close to the same cycle count
as the best libraries in current use, double is "somewhat" harder to
totally verify/prove.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-09 01:24 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1767921857-5857@newsgrouper.org> |
| In reply to | #114705 |
Terje Mathisen <terje.mathisen@tmsw.no> posted:
> MitchAlsup wrote:
> >
> > Terje Mathisen <terje.mathisen@tmsw.no> posted:
> >
> >> MitchAlsup wrote:
> >>>
> >>> MitchAlsup <user5857@newsgrouper.org.invalid> posted:
> >>> -------------------
> >>>>
> >>>> My Transcendentals get to 1ULP when the multiplier tree is 59×59-bits
> >>>> {a bit more than ½ of the get 1ULP at 58×58}. I gave a lot of though
> >>>> to this {~1 year} before deciding that a "Do everything else" function
> >>>> unit was "overall" better than a couple of "near miss" FUs. So, IMUL
> >>>> comes in at 4 cycles, FMUL at 4 cycles, FDIV at 17, SQRT at 22, and
> >>>> IDIV at 25. The fast IMUL makes up a lot for the "size" of the FU.
> >>>
> >>> I forgot to add that my transcendentals went from <just barely>
> >>> faithfully rounded 0.75ULP RMS to 5.002ULP RMS when the tree was
> >>> expanded.
> >>
> >> You obviously intended 0.5002 ulp, so you have about 11-13 guard bits to
> >> get the rounding correct?
> >
> > 64-53 = 11 yes
>
> For many of the functions you can do a lot by letting the final
> operation be a merging of the first/largest term, particularly if you do
> that with extended precision.
>
> I.e something like fpatan2() works quite nicely this way, just not
> enough for exact rounding.
>
> You need to combine this with extended precision range adjustment at the
> end.
>
> >
> > But a single incorrect rounding is 1 ULP all by itself.
>
> :-)
>
> Yeah, there are strong forces who want to have, at least as a
> suggested/recommended option, a set of transcendental functions which
> are exactly rounded.
After the final addition, I know 1 of the top 3-bits is a 1, and I
have 69-bits in the accumulated result. I also know that the poly-
nomial error is below the 3rd least significant bit.
> It is provably doable for float, in very close to the same cycle count
> as the best libraries in current use, double is "somewhat" harder to
> totally verify/prove.
I have logic (patented) that allows the FU to raise an UNCERTAIN
rounding exception, so SW can take over and change 0.5002 into
0.5000 at the cost of the exception and running the long winded
SW correctly rounded subroutine. I expect this to be used only
during verification and on the 3 machines owned by Kahan, Coonen,
and someone else I forgot.
> Terje
>
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-01-10 18:02 +0100 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10ju0nm$3a92q$1@dont-email.me> |
| In reply to | #114707 |
MitchAlsup wrote: > > Terje Mathisen <terje.mathisen@tmsw.no> posted: > >> MitchAlsup wrote: >>> But a single incorrect rounding is 1 ULP all by itself. >> >> :-) >> >> Yeah, there are strong forces who want to have, at least as a >> suggested/recommended option, a set of transcendental functions which >> are exactly rounded. > > After the final addition, I know 1 of the top 3-bits is a 1, and I > have 69-bits in the accumulated result. I also know that the poly- > nomial error is below the 3rd least significant bit. > >> It is provably doable for float, in very close to the same cycle count >> as the best libraries in current use, double is "somewhat" harder to >> totally verify/prove. > > I have logic (patented) that allows the FU to raise an UNCERTAIN > rounding exception, so SW can take over and change 0.5002 into > 0.5000 at the cost of the exception and running the long winded > SW correctly rounded subroutine. I expect this to be used only > during verification and on the 3 machines owned by Kahan, Coonen, > and someone else I forgot. <BG> Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-11 15:01 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260111150116.00000f04@yahoo.com> |
| In reply to | #114705 |
On Thu, 8 Jan 2026 21:35:16 +0100 Terje Mathisen <terje.mathisen@tmsw.no> wrote: > MitchAlsup wrote: > > > > > > But a single incorrect rounding is 1 ULP all by itself. > > :-) > > Yeah, there are strong forces who want to have, at least as a > suggested/recommended option, a set of transcendental functions which > are exactly rounded. > I wonder who are those forces and what is the set they push for. I would guess that they are mostly software and hardware verification people rather than people that use transcendental functions in engineering and physical calculations. The majority of the latter crowd would likely have no objections against 0.75 ULP RMS as long as implementation is both fast and preserving few invariant, of which I can primarily think of two: 1. Evenness/odness If precise function F(x) is even or odd then approximate functions f(x) is also even or odd. 2. Weak preservation of sign of delta. If F(x) < F(x+ULP) then f(x) <= f(x+ULP) If F(x) > F(x+ULP) then f(x) >= f(x+ULP) In practice, it's probably unlikely to have these invariant preserved when RMS error is 0.75 ULP, but for RMS error = 0.60-0.65 ULP I don't see difficulties. For many transcendental functions there will be only few problematic values of x near edges of implementation-specific ranges where one has to be careful. > It is provably doable for float, in very close to the same cycle > count as the best libraries in current use, double is "somewhat" > harder to totally verify/prove. > > Terje >
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-11 18:18 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1768155480-5857@newsgrouper.org> |
| In reply to | #114723 |
Michael S <already5chosen@yahoo.com> posted:
> On Thu, 8 Jan 2026 21:35:16 +0100
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>
> > MitchAlsup wrote:
> > >
> > >
> > > But a single incorrect rounding is 1 ULP all by itself.
> >
> > :-)
> >
> > Yeah, there are strong forces who want to have, at least as a
> > suggested/recommended option, a set of transcendental functions which
> > are exactly rounded.
> >
>
> I wonder who are those forces and what is the set they push for.
The problem, here, is that even when one gets all the rounding correct,
one has still lost various algebraic identities.
CRSIN(x)^2 + CRCOS(X)^2 ~= 1.0
> I would guess that they are mostly software and hardware verification
> people rather than people that use transcendental functions in
> engineering and physical calculations.
Numerical people, almost never engineers, physicists, or chemists.
> The majority of the latter crowd would likely have no objections
> against 0.75 ULP RMS as long as implementation is both fast and
> preserving few invariant, of which I can primarily think of two:
>
> 1. Evenness/odness
> If precise function F(x) is even or odd then approximate functions f(x)
> is also even or odd.
Odd functions need to be monotonic around zero.
> 2. Weak preservation of sign of delta.
> If F(x) < F(x+ULP) then f(x) <= f(x+ULP)
> If F(x) > F(x+ULP) then f(x) >= f(x+ULP)
Small scale Monotonicity.
>
> In practice, it's probably unlikely to have these invariant preserved
> when RMS error is 0.75 ULP, but for RMS error = 0.60-0.65 ULP I don't
> see difficulties.
> For many transcendental functions there will be only few problematic
> values of x near edges of implementation-specific ranges where one
> has to be careful.
>
> > It is provably doable for float, in very close to the same cycle
> > count as the best libraries in current use, double is "somewhat"
> > harder to totally verify/prove.
> >
> > Terje
> >
>
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-11 20:50 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260111205004.00002d9f@yahoo.com> |
| In reply to | #114728 |
On Sun, 11 Jan 2026 18:18:00 GMT MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > Michael S <already5chosen@yahoo.com> posted: > > > On Thu, 8 Jan 2026 21:35:16 +0100 > > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > > > > > MitchAlsup wrote: > > > > > > > > > > > > But a single incorrect rounding is 1 ULP all by itself. > > > > > > :-) > > > > > > Yeah, there are strong forces who want to have, at least as a > > > suggested/recommended option, a set of transcendental functions > > > which are exactly rounded. > > > > > > > I wonder who are those forces and what is the set they push for. > > The problem, here, is that even when one gets all the rounding > correct, one has still lost various algebraic identities. > > CRSIN(x)^2 + CRCOS(X)^2 ~= 1.0 > > > I would guess that they are mostly software and hardware > > verification people rather than people that use transcendental > > functions in engineering and physical calculations. > > Numerical people, almost never engineers, physicists, or chemists. > > > The majority of the latter crowd would likely have no objections > > against 0.75 ULP RMS as long as implementation is both fast and > > preserving few invariant, of which I can primarily think of two: > > > > 1. Evenness/odness > > If precise function F(x) is even or odd then approximate functions > > f(x) is also even or odd. > > Odd functions need to be monotonic around zero. > > > 2. Weak preservation of sign of delta. > > If F(x) < F(x+ULP) then f(x) <= f(x+ULP) > > If F(x) > F(x+ULP) then f(x) >= f(x+ULP) > > Small scale Monotonicity. > Yes, that's a better name. I just wanted to express it as simple non-equality conditions and made it too simple and stronger than necessary. In fact I would not complain if my conditions do not hold when F(x) has extremum in between x and x+ULP. That is, it's nice if condition holds here as well, but it is relatively less important than holding on monotonous intervals. > > > > In practice, it's probably unlikely to have these invariant > > preserved when RMS error is 0.75 ULP, but for RMS error = 0.60-0.65 > > ULP I don't see difficulties. > > For many transcendental functions there will be only few problematic > > values of x near edges of implementation-specific ranges where one > > has to be careful. > > > > > It is provably doable for float, in very close to the same cycle > > > count as the best libraries in current use, double is "somewhat" > > > harder to totally verify/prove. > > > > > > Terje > > > > >
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-11 22:11 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1768169515-5857@newsgrouper.org> |
| In reply to | #114729 |
Michael S <already5chosen@yahoo.com> posted: > On Sun, 11 Jan 2026 18:18:00 GMT > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > Michael S <already5chosen@yahoo.com> posted: > > > > > On Thu, 8 Jan 2026 21:35:16 +0100 > > > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > > > > > > > MitchAlsup wrote: > > > > > > > > > > > > > > > But a single incorrect rounding is 1 ULP all by itself. > > > > > > > > :-) > > > > > > > > Yeah, there are strong forces who want to have, at least as a > > > > suggested/recommended option, a set of transcendental functions > > > > which are exactly rounded. > > > > > > > > > > I wonder who are those forces and what is the set they push for. > > > > The problem, here, is that even when one gets all the rounding > > correct, one has still lost various algebraic identities. > > > > CRSIN(x)^2 + CRCOS(X)^2 ~= 1.0 > > > > > I would guess that they are mostly software and hardware > > > verification people rather than people that use transcendental > > > functions in engineering and physical calculations. > > > > Numerical people, almost never engineers, physicists, or chemists. > > > > > The majority of the latter crowd would likely have no objections > > > against 0.75 ULP RMS as long as implementation is both fast and > > > preserving few invariant, of which I can primarily think of two: > > > > > > 1. Evenness/odness > > > If precise function F(x) is even or odd then approximate functions > > > f(x) is also even or odd. > > > > Odd functions need to be monotonic around zero. > > > > > 2. Weak preservation of sign of delta. > > > If F(x) < F(x+ULP) then f(x) <= f(x+ULP) > > > If F(x) > F(x+ULP) then f(x) >= f(x+ULP) > > > > Small scale Monotonicity. > > > > Yes, that's a better name. > I just wanted to express it as simple non-equality conditions and made > it too simple and stronger than necessary. > In fact I would not complain if my conditions do not hold when F(x) has > extremum in between x and x+ULP. That is, it's nice if condition holds > here as well, but it is relatively less important than holding on > monotonous intervals. Consider COS(x) near 0.0 The transition from 1.0 to .99999999 and later to 0.99999998 (in both directions) is small scale monotonic. AND it is exactly at this trans- ition where my rounding takes the biggest number of hits (incorrect roundings). Seen in binary, one has a prerounded result of: 0.1111111111 1111111111 1111111111 1111111111 1111111111 1111 and digits behind where rounding transpires. If those digits start with 01111111111 or 1000000000 then we are in the situation where we cannot know if we can choose a correct rounding; the next term of the polynomial could sway the balance. J. M. Mueller chapter 11 shows that one might need as many as 2×n+13 bits in order to get the rounding "correct". This must include, polynomial error, arithmetic error, and certain boundary conditions. If rounding that begins 01 contains a second 0, correct rounding happens. if rounding that begins 10 contains a second 1, correct rounding happens. And it is exactly at these points that a) while the result remains monotonic, the point of change can be "off" by a small number of Δs b) when the slope is shallow, one can get several rounding errors in a row without loosing the property of monotonicity or overall RMS. > > > > > > > In practice, it's probably unlikely to have these invariant > > > preserved when RMS error is 0.75 ULP, but for RMS error = 0.60-0.65 > > > ULP I don't see difficulties. > > > For many transcendental functions there will be only few problematic > > > values of x near edges of implementation-specific ranges where one > > > has to be careful. > > > > > > > It is provably doable for float, in very close to the same cycle > > > > count as the best libraries in current use, double is "somewhat" > > > > harder to totally verify/prove. > > > > > > > > Terje > > > > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-12 12:20 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260112122048.000075da@yahoo.com> |
| In reply to | #114732 |
On Sun, 11 Jan 2026 22:11:55 GMT MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > Consider COS(x) near 0.0 > sin/cos is not an interesting or hard case, because for sin/cos the value at extremum is exactly 1 or -1, i.e. it is representable exactly by any BFP format. Plus, slop is very shallow. It means that any sane implementation of sin/cos will have no troubles correctly rounding both sides of interval that contains extremum to 1 (or -1). At least it holds as long as x is in the sane range (abs(x) < 2**26). For x outside that range, you (i.e. engineer, chemist, phisicist) just know that you are doing something very wrong, and implementation of trigs is among last things that you should be concerned about. More challenging cases are transcendental functions that have extrema with values that are non-representable exactly, especially so when the value is close to the mid-point between two representable numbers.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-01-13 14:45 -0500 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <jwvjyxlwbx5.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #114728 |
MitchAlsup [2026-01-11 18:18:00] wrote: > Michael S <already5chosen@yahoo.com> posted: >> Terje Mathisen <terje.mathisen@tmsw.no> wrote: >>> Yeah, there are strong forces who want to have, at least as a >>> suggested/recommended option, a set of transcendental functions which >>> are exactly rounded. >> I wonder who are those forces and what is the set they push for. One reason to want it comes from portability and bit-for-bit reproducibility. These requirements don't actually care about the rounding being *correct* as much as the rounding always being the same across different hardware and libm implementations, but it seems rather unlikely that the various actors involved would agree on a particular return value if it's not the correctly-rounded one, so in practice this becomes a push for correctly rounded results. > The problem, here, is that even when one gets all the rounding correct, > one has still lost various algebraic identities. > > CRSIN(x)^2 + CRCOS(X)^2 ~= 1.0 Which properties are preserved and which ones aren't is inevitably a compromise since, for example, the above one cannot be preserved without breaking several others. - Stefan
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-21 01:44 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1768959848-5857@newsgrouper.org> |
| In reply to | #114745 |
Anyone still here and active ??? Mitch
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-21 11:05 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260121110530.00001540@yahoo.com> |
| In reply to | #114746 |
On Wed, 21 Jan 2026 01:44:08 GMT MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > Anyone still here and active ??? > > Mitch https://www.linfo.org/rule_of_silence.html I have serious doubts about universality of wisdom of this rule in the field of human-machine interfaces, but for Usenet interaction it is golden.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-02-14 20:49 -0800 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <86fr72hari.fsf@linuxsc.com> |
| In reply to | #114747 |
Michael S <already5chosen@yahoo.com> writes: > On Wed, 21 Jan 2026 01:44:08 GMT > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >> Anyone still here and active ??? > > https://www.linfo.org/rule_of_silence.html > > I have serious doubts about universality of wisdom of this rule in the > field of human-machine interfaces, but for Usenet interaction it is > golden. Thank you for this.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-01-21 22:33 +0100 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10krgml$2fb90$1@dont-email.me> |
| In reply to | #114746 |
MitchAlsup wrote: > > Anyone still here and active ??? > > Mitch > Yes! -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2026-01-22 14:37 -0500 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10ktua6$39hjp$1@dont-email.me> |
| In reply to | #114748 |
On 2026-01-21 4:33 p.m., Terje Mathisen wrote: > MitchAlsup wrote: >> >> Anyone still here and active ??? >> >> Mitch >> > Yes! > Still here. I thought maybe the snow put a damper on things. I have been working away on Q+4 doing simulation runs while waiting for posts on comp.arch. The timing goal has been bumped up to 100 MHz from 40 MHz. Been toying with a couple of ideas. One is to give the machine a wider or perhaps narrower datapath to support 80 or 96 bits operations. A few extra digits for finance. Do not really want to go to 128-bits. A 48-bit machine could have 96-bit double precision support. Another idea is to go six wide.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-01-22 15:12 -0500 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <gs05nkhve77fqdd74a84voich0pneqh8gd@4ax.com> |
| In reply to | #114746 |
On Wed, 21 Jan 2026 01:44:08 GMT, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: >Anyone still here and active ??? > >Mitch Still here. Given that Usenet as a whole seems to be dying, sudden pauses in postings are eerie.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-22 22:57 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260122225750.00002cb5@yahoo.com> |
| In reply to | #114752 |
On Thu, 22 Jan 2026 15:12:06 -0500 George Neuner <gneuner2@comcast.net> wrote: > On Wed, 21 Jan 2026 01:44:08 GMT, MitchAlsup > <user5857@newsgrouper.org.invalid> wrote: > > >Anyone still here and active ??? > > > >Mitch > > Still here. > > Given that Usenet as a whole seems to be dying, sudden pauses in > postings are eerie. Usenet as a whole is dying for several years longer than the time since I first discovered it 23+ years ago.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-01-23 13:47 -0500 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <mad7nkhgpjjf7u6alnsjppmu3qo20dpca5@4ax.com> |
| In reply to | #114753 |
On Thu, 22 Jan 2026 22:57:50 +0200, Michael S <already5chosen@yahoo.com> wrote: >On Thu, 22 Jan 2026 15:12:06 -0500 >George Neuner <gneuner2@comcast.net> wrote: > >> On Wed, 21 Jan 2026 01:44:08 GMT, MitchAlsup >> <user5857@newsgrouper.org.invalid> wrote: >> >> >Anyone still here and active ??? >> > >> >Mitch >> >> Still here. >> >> Given that Usenet as a whole seems to be dying, sudden pauses in >> postings are eerie. > >Usenet as a whole is dying for several years longer than the time since >I first discovered it 23+ years ago. > I discovered Usenet in the late 80's. I participated in about 20 of the comp.* and sci.* groups. All through the 90's and even into the early 00's many of them were quite lively. I recognized early on that the file sharing groups were in trouble - mainly due to legal issues - but I didn't get the sense that Usenet was in decline more generally until the late 00's. And it wasn't for lack of GUIs: I can't recall names now, but there were at least 2 different terminal hosted GUIs (one of which had a Windows port), Netscape mail did NN natively, and AltaVista had a quite nice [text but browser hosted] interface to Usenet. Google managed to f_ up everything AltaVista did, Microsoft pushed Netscape aside, Firefox came along but quickly removed its initial email and NN support, Thunderbird and SeaMonkey took too long to appear, and too many web providers were trying to cash in by luring people to pay-walled forums. It seems all it would have taken was one decent web site providing a good user experience for Usenet. Yeah, I know ... why didn't I do it? Well, I don't do web sites. [Actually, that's incorrect: I do do middle and backend work, but I don't do any user facing (GUI) stuff. I've been told my sense of what is "easy to use" is somewhat stunted ... I've been in computing since 1980 and I am mostly satisfied that something works. Moreover, I don't consider very much "modern" software - and almost nothing that runs on a phone or in a browser - to be particularly easy to use.] YMMV.
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.arch
csiph-web