Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #3118 > unrolled thread
| Started by | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| First post | 2011-08-23 10:48 -0700 |
| Last post | 2011-08-29 09:18 -0700 |
| Articles | 20 on this page of 246 — 39 participants |
Back to article view | Back to comp.arch
Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-23 10:48 -0700
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-23 16:24 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-24 07:20 +0200
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-23 23:22 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-24 14:38 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-25 17:42 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 09:45 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 18:03 -0700
Re: Solving the Floating-Point Goldilocks Problem! Brett Davis <ggtgp@yahoo.com> - 2011-08-26 20:31 -0500
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-26 20:08 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 02:35 -0700
Re: Solving the Floating-Point Goldilocks Problem! Brett Davis <ggtgp@yahoo.com> - 2011-08-27 15:27 -0500
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 13:41 -0700
Re: Solving the Floating-Point Goldilocks Problem! Brett Davis <ggtgp@yahoo.com> - 2011-08-27 17:34 -0500
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 17:40 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-27 17:50 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-28 23:49 -0700
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-27 22:40 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-28 19:33 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-29 13:56 +0200
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 09:07 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-29 17:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 11:56 -0700
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-08-29 16:12 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-29 20:46 +0100
Re: Solving the Floating-Point Goldilocks Problem! Kalle Olavi Niemitalo <kon@iki.fi> - 2011-08-30 07:48 +0300
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-30 08:22 +0100
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-31 11:34 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 22:22 -0700
Re: Solving the Floating-Point Goldilocks Problem! Andrew Reilly <areilly---@bigpond.net.au> - 2011-08-30 11:17 +0000
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-30 12:35 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-30 07:02 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-30 15:18 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-30 15:12 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-08-31 08:30 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 09:54 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 10:09 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-01 18:01 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 12:25 -0700
Re: Solving the Floating-Point Goldilocks Problem! sidd <sidd@situ.com> - 2011-09-01 20:02 -0400
Re: Solving the Floating-Point Goldilocks Problem! Elliott Roper <nospam@yrl.co.uk> - 2011-09-02 10:27 +0100
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-02 11:33 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 08:09 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 08:12 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-02 15:50 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 08:49 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-02 17:00 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 15:55 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-03 18:06 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 07:58 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-02 15:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-02 07:42 -0700
Re: Solving the Floating-Point Goldilocks Problem! Andreas Eder <andreas_eder@gmx.net> - 2011-09-02 17:51 +0200
Re: Solving the Floating-Point Goldilocks Problem! sidd <sidd@situ.com> - 2011-08-31 12:11 -0400
Complex Number Representation nmm1@cam.ac.uk - 2011-09-02 21:22 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-30 07:08 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-31 10:39 +0200
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-31 08:00 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-31 18:38 +0200
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-08-31 13:18 -0400
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-31 19:09 -0700
Re: Solving the Floating-Point Goldilocks Problem! Brett Davis <ggtgp@yahoo.com> - 2011-08-30 00:19 -0500
Re: Solving the Floating-Point Goldilocks Problem! Brett Davis <ggtgp@yahoo.com> - 2011-08-31 23:46 -0500
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-31 09:56 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-01 08:23 +0200
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-31 14:02 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 04:02 -0700
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-01 19:42 +0200
Re: Solving the Floating-Point Goldilocks Problem! BGB <cr88192@hotmail.com> - 2011-08-31 23:20 -0700
Re: Solving the Floating-Point Goldilocks Problem! "James Van Buskirk" <not_valid@comcast.net> - 2011-09-12 15:53 -0600
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-12 22:31 +0100
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-12 22:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-12 21:00 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-13 10:10 +0100
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-13 04:58 +0200
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-01 07:25 -0400
Re: Solving the Floating-Point Goldilocks Problem! Tim Shoppa <shoppa@trailing-edge.com> - 2011-09-01 10:37 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-01 18:25 +0100
Re: Solving the Floating-Point Goldilocks Problem! Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-09-01 19:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 12:30 -0700
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 12:38 -0700
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-01 17:13 -0400
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-01 14:48 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-01 22:49 +0100
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-01 18:08 -0500
Re: Solving the Floating-Point Goldilocks Problem! "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> - 2011-09-02 00:26 -0800
Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-02 05:06 -0700
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 10:46 -0500
Re: Solving the Floating-Point Goldilocks Problem! Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-02 12:08 -0700
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-02 13:54 -0700
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-03 14:57 +0000
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-03 15:33 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-03 13:42 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-04 08:46 +1000
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-04 08:05 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-04 17:44 +1000
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-04 08:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-04 18:52 +1000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-04 08:55 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 16:46 +0100
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-04 13:21 +0000
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 14:03 +0100
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 14:15 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 18:52 +0100
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 15:00 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 21:02 +0100
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 19:22 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-05 07:09 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-05 04:48 +1000
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-04 20:18 -0400
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-04 03:53 +1000
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-04 13:21 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-05 03:57 +1000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-04 08:47 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-05 04:03 +1000
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 14:30 -0400
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-05 04:49 +1000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-04 15:53 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-05 09:55 +1000
Re: Solving the Floating-Point Goldilocks Problem! Piotr Wyderski <peter.pan@neverland.mil> - 2011-10-19 19:17 +0200
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-04 19:54 +0100
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 20:56 +0100
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 19:16 -0400
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-04 16:26 -0700
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-05 13:45 +0200
Re: Solving the Floating-Point Goldilocks Problem! Bakul Shah <usenet@bitblocks.com> - 2011-09-05 12:09 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-05 20:51 +0100
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-06 10:57 +0200
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-06 19:43 +1000
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-06 10:55 +0200
Re: Solving the Floating-Point Goldilocks Problem! Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-09-06 11:36 +0100
OT English Re: Solving the Floating-Point Goldilocks Problem! wclodius@lost-alamos.pet (William Clodius) - 2011-09-05 13:33 -0600
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-05 23:12 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> - 2011-09-07 09:44 -0800
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-03 13:41 -0500
Re: Solving the Floating-Point Goldilocks Problem! scott@slp53.sl.home (Scott Lurndal) - 2011-09-03 21:36 +0000
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-03 20:18 -0500
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-04 08:31 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 13:11 +0100
Re: Solving the Floating-Point Goldilocks Problem! scott@slp53.sl.home (Scott Lurndal) - 2011-09-05 17:14 +0000
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-07 09:07 +0000
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-07 12:15 +0100
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-07 08:37 -0400
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-07 13:50 +0100
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-07 09:21 -0400
Re: Solving the Floating-Point Goldilocks Problem! Bernd Felsche <berfel@innovative.iinet.net.au> - 2011-09-08 08:42 +0800
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-08 14:10 +0000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-08 19:09 -0700
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-05 22:50 -0700
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-06 13:45 +0000
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-06 09:08 -0700
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-07 14:13 +0000
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-07 09:42 -0700
Re: Solving the Floating-Point Goldilocks Problem! Bernd Felsche <berfel@innovative.iinet.net.au> - 2011-09-08 09:05 +0800
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-08 14:10 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-08 04:49 +1000
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-08 14:09 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-09 03:17 +1000
Re: Solving the Floating-Point Goldilocks Problem! Gene Wirchenko <genew@ocis.net> - 2011-09-10 23:07 -0700
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-11 09:06 +0100
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-11 10:07 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-11 06:48 -0700
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-11 08:26 -0400
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-11 13:00 +0100
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-11 07:36 -0700
Re: Solving the Floating-Point Goldilocks Problem! Piotr Wyderski <peter.pan@neverland.mil> - 2011-10-19 19:15 +0200
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-10-19 14:45 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> - 2011-10-19 17:13 -0800
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-10-20 13:38 +0000
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-27 09:01 +0000
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-02 20:41 -0400
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-03 06:58 +0100
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-03 07:19 +0100
Re: Solving the Floating-Point Goldilocks Problem! Bakul Shah <usenet@bitblocks.com> - 2011-09-02 21:54 -0700
Re: Solving the Floating-Point Goldilocks Problem! Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-03 09:05 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-03 16:42 +0100
Re: Solving the Floating-Point Goldilocks Problem! scott@slp53.sl.home (Scott Lurndal) - 2011-09-03 21:00 +0000
Re: Solving the Floating-Point Goldilocks Problem! Bakul Shah <usenet@bitblocks.com> - 2011-09-03 11:01 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-03 19:18 +0100
Re: Solving the Floating-Point Goldilocks Problem! Bakul Shah <usenet@bitblocks.com> - 2011-09-03 13:05 -0700
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 08:09 +0100
Re: Solving the Floating-Point Goldilocks Problem! scott@slp53.sl.home (Scott Lurndal) - 2011-09-03 21:34 +0000
Re: Solving the Floating-Point Goldilocks Problem! Jean-Marc Bourguet <jm@bourguet.org> - 2011-09-04 22:15 +0200
Re: Solving the Floating-Point Goldilocks Problem! nmm1@cam.ac.uk - 2011-09-04 21:07 +0100
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-02 20:21 -0400
Re: Solving the Floating-Point Goldilocks Problem! Tim Shoppa <shoppa@trailing-edge.com> - 2011-09-06 09:32 -0700
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-07 09:09 +0000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-07 07:17 -0700
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-07 16:00 +0100
Re: Solving the Floating-Point Goldilocks Problem! Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-09-07 16:40 +0100
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-07 09:57 -0700
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-07 09:39 -0700
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-07 20:47 +0200
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-08 14:09 +0000
Re: Solving the Floating-Point Goldilocks Problem! Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-08 09:13 -0700
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-08 18:59 +0200
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-09 15:21 +0000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-09 12:48 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-10 06:27 +1000
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-09 23:04 +0200
Re: Solving the Floating-Point Goldilocks Problem! Bernd Felsche <berfel@innovative.iinet.net.au> - 2011-09-08 08:57 +0800
Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-08 14:10 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> - 2011-09-08 07:50 -0800
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-08 12:07 -0400
Re: Solving the Floating-Point Goldilocks Problem! Walter Bushell <proto@panix.com> - 2011-09-08 12:10 -0400
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-08 17:38 +0100
Re: Solving the Floating-Point Goldilocks Problem! Seebs <usenet-nospam@seebs.net> - 2011-09-09 03:43 +0000
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-08 12:21 -0500
Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-01 17:09 -0400
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-02 08:59 +1000
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-07 09:07 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-07 20:03 +1000
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-08 16:55 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-09 03:52 +1000
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-01 15:57 +0000
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-10-02 05:51 +1100
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-10-07 11:31 +0000
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-07 14:08 +0200
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-07 14:18 +0100
Re: Solving the Floating-Point Goldilocks Problem! Huge <Huge@nowhere.much.invalid> - 2011-09-07 14:05 +0000
Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-07 20:54 +0200
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-08 05:27 +1000
Re: Solving the Floating-Point Goldilocks Problem! timcaffrey@aol.com (Tim McCaffrey) - 2011-09-16 18:48 +0000
Re: Solving the Floating-Point Goldilocks Problem! sidd <sidd@situ.com> - 2011-09-07 18:53 -0400
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-08 04:37 +1000
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-08 10:19 +0200
Re: Solving the Floating-Point Goldilocks Problem! kenney@cix.compulink.co.uk - 2011-09-08 05:14 -0500
Re: Solving the Floating-Point Goldilocks Problem! Gene Wirchenko <genew@ocis.net> - 2011-09-11 12:58 -0700
Re: Solving the Floating-Point Goldilocks Problem! Ahem A Rivet's Shot <steveo@eircom.net> - 2011-09-12 10:01 +0100
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-12 19:35 +1000
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-12 09:25 -0700
Re: Solving the Floating-Point Goldilocks Problem! Michael Black <et472@ncf.ca> - 2011-09-12 13:27 -0400
Re: Solving the Floating-Point Goldilocks Problem! Ben Pfaff <blp@cs.stanford.edu> - 2011-09-12 10:41 -0700
Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-12 11:34 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-13 05:40 +1000
Re: Solving the Floating-Point Goldilocks Problem! Michael Black <et472@ncf.ca> - 2011-09-12 15:53 -0400
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-12 13:08 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-08 04:14 +1000
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-07 11:31 -0700
Re: Solving the Floating-Point Goldilocks Problem! "Rod Speed" <rod.speed.aaa@gmail.com> - 2011-09-08 05:35 +1000
Re: Solving the Floating-Point Goldilocks Problem! Bernd Felsche <berfel@innovative.iinet.net.au> - 2011-09-08 08:40 +0800
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-07 20:25 +0200
Re: Solving the Floating-Point Goldilocks Problem! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-08 16:58 +0000
Re: Solving the Floating-Point Goldilocks Problem! Robert Wessel <robertwessel2@yahoo.com> - 2011-09-08 12:31 -0500
Re: Solving the Floating-Point Goldilocks Problem! Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-30 13:46 +0200
Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-08-29 09:18 -0700
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-08-29 09:07 -0700 |
| Message-ID | <4E5BB93F.2030406@SPAM.comp-arch.net> |
| In reply to | #3228 |
On 8/29/2011 4:56 AM, Terje Mathisen wrote: > Andy "Krazy" Glew wrote: >> On 8/26/2011 6:31 PM, Brett Davis wrote: >>> Survey of Floating-Point Formats >>> http://mrob.com/pub/math/floatformats.html >> >> In case you are interested, I have run into FP7 and FP8, 7 and 8 bit >> formats, in Intel and ATI GPUs. >> >> http://semipublic.comp-arch.net/wiki/Collection_of_Unusual_Datatypes_and_Formats >> >> > > Nice article, thanks! > > Block fp formats have been quite common afaik in the embedded world, > where you would store an array of (integer) mantissas, all sharing a > common exponent. > > With a few guard bits to reduce the need for block renormalization this > seems like an efficient layout. I'd appreciate any references to block FP. BGB provided a few. (Hell, I'd love it if you could/would just post, although my current wiki security kerfuffle may delay that a bit.) > Re the various packed pixel formats, and how BMM can extract what you > need, even from the wrong byte order: > > It seems vastly more power efficient to have a plain byte swapper in > front of the usual shift & mask bitfield extractor? AND-OR BMM is much more power efficient than AND-XOR BMM. I don't see how what you describe can extract arbitrary discontiguous bitfields. It could suffice for bitfields rendered discontiguous by endianness. I am increasingly interested in extracted multiple bitfields at once. Possibly into different elements of a vector. Perhaps a vector bitfield extract is all we need. I may just be seduced by the elegance of BMM - and the desire to kill two birds with one stone.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-08-29 17:56 +0100 |
| Message-ID | <j3ggbl$4du$1@gosset.csi.cam.ac.uk> |
| In reply to | #3236 |
In article <4E5BB93F.2030406@SPAM.comp-arch.net>, Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote: >On 8/29/2011 4:56 AM, Terje Mathisen wrote: >> >> Block fp formats have been quite common afaik in the embedded world, >> where you would store an array of (integer) mantissas, all sharing a >> common exponent. >> >> With a few guard bits to reduce the need for block renormalization this >> seems like an efficient layout. > >I'd appreciate any references to block FP. > >BGB provided a few. > >(Hell, I'd love it if you could/would just post, although my current >wiki security kerfuffle may delay that a bit.) Modern Computing Methods, 1948 :-) More seriously, it's just an example of scaled fixed-point, which was in widespread use until the 1960s. It isn't just computationally less demanding, but is often (not always) numerically better for homogenous problems like linear algebra (including FFTs). It lost out because it's more hassle to use. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-08-29 11:56 -0700 |
| Message-ID | <4E5BE0C4.3020403@SPAM.comp-arch.net> |
| In reply to | #3239 |
On 8/29/2011 9:56 AM, nmm1@cam.ac.uk wrote: > In article<4E5BB93F.2030406@SPAM.comp-arch.net>, > Andy \"Krazy\" Glew<andy@SPAM.comp-arch.net> wrote: >> On 8/29/2011 4:56 AM, Terje Mathisen wrote: >>> >>> Block fp formats have been quite common afaik in the embedded world, >>> where you would store an array of (integer) mantissas, all sharing a >>> common exponent. >>> >>> With a few guard bits to reduce the need for block renormalization this >>> seems like an efficient layout. >> >> I'd appreciate any references to block FP. >> >> BGB provided a few. >> >> (Hell, I'd love it if you could/would just post, although my current >> wiki security kerfuffle may delay that a bit.) > > Modern Computing Methods, 1948 :-) > > More seriously, it's just an example of scaled fixed-point, which > was in widespread use until the 1960s. It isn't just computationally > less demanding, but is often (not always) numerically better for > homogenous problems like linear algebra (including FFTs). It lost > out because it's more hassle to use. > > > Regards, > Nick Maclaren. I was unclear. I *know* what block FP is. What I want is examples of packed data formats for block FP. That are in common use, i.e. not imagined, or used by only one programmer Like: * 1 bit sign * 15 bit exponent * 16 bits x,y,z mantissa => 64 bit total. I am not so interested in such simple formats, flavours of 8 and 16 bit components. I am more interested in funny bitwidths. I am collecting these against the next time I am involved in an effort like MMX. Where shortsighted people will say "all we need to support is 4:2:2 YUV, and we should add a special instruction just for that", rather than more general support. Or vice versa. E.g. block FP for a restricted complex: * 1 bit sign * 7 bit exponent * 12 bit real and imaginary parts => a 32 bit small complex number.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter_Flass@Yahoo.com> |
|---|---|
| Date | 2011-08-29 16:12 -0400 |
| Message-ID | <j3grs4$ek2$2@dont-email.me> |
| In reply to | #3242 |
On 8/29/2011 2:56 PM, Andy "Krazy" Glew wrote: > On 8/29/2011 9:56 AM, nmm1@cam.ac.uk wrote: >> In article<4E5BB93F.2030406@SPAM.comp-arch.net>, >> Andy \"Krazy\" Glew<andy@SPAM.comp-arch.net> wrote: >>> On 8/29/2011 4:56 AM, Terje Mathisen wrote: >>>> >>>> Block fp formats have been quite common afaik in the embedded world, >>>> where you would store an array of (integer) mantissas, all sharing a >>>> common exponent. >>>> >>>> With a few guard bits to reduce the need for block renormalization this >>>> seems like an efficient layout. >>> >>> I'd appreciate any references to block FP. >>> >>> BGB provided a few. >>> >>> (Hell, I'd love it if you could/would just post, although my current >>> wiki security kerfuffle may delay that a bit.) >> >> Modern Computing Methods, 1948 :-) >> >> More seriously, it's just an example of scaled fixed-point, which >> was in widespread use until the 1960s. It isn't just computationally >> less demanding, but is often (not always) numerically better for >> homogenous problems like linear algebra (including FFTs). It lost >> out because it's more hassle to use. >> >> >> Regards, >> Nick Maclaren. > > I was unclear. > > I *know* what block FP is. > > What I want is examples of packed data formats for block FP. That are in > common use, i.e. not imagined, or used by only one programmer > > Like: > * 1 bit sign > * 15 bit exponent > * 16 bits x,y,z mantissa > => 64 bit total. > > I am not so interested in such simple formats, flavours of 8 and 16 bit > components. I am more interested in funny bitwidths. > > I am collecting these against the next time I am involved in an effort > like MMX. Where shortsighted people will say "all we need to support is > 4:2:2 YUV, and we should add a special instruction just for that", > rather than more general support. Or vice versa. > > E.g. block FP for a restricted complex: > * 1 bit sign > * 7 bit exponent > * 12 bit real and imaginary parts > => a 32 bit small complex number. > > This is fine if both the real and imaginary parts have the same scale, or close enough that the same exponent will cover both. Or the same sign, for that matter.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-08-29 20:46 +0100 |
| Message-ID | <j3gqb0$5a0$1@gosset.csi.cam.ac.uk> |
| In reply to | #3247 |
In article <j3grs4$ek2$2@dont-email.me>, Peter Flass <Peter_Flass@Yahoo.com> wrote: > >This is fine if both the real and imaginary parts have the same scale, >or close enough that the same exponent will cover both. Or the same >sign, for that matter. The mind boggles. Firstly, the sign is obviously irrelevant, because both integers and fixed-point numbers are almost always signed. Secondly, in mathematics (including numerical analysis) a complex number is a single value and not a Cartesian pair. If one of the parts is large and the other small, then it is a large number with its value close to one of the axes. Your point is a classic non-issue. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Kalle Olavi Niemitalo <kon@iki.fi> |
|---|---|
| Date | 2011-08-30 07:48 +0300 |
| Message-ID | <87liub8pxm.fsf@Niukka.kon.iki.fi> |
| In reply to | #3248 |
nmm1@cam.ac.uk writes: > Firstly, the sign is obviously irrelevant, because both integers and > fixed-point numbers are almost always signed. It's a matter of positive vs. negative, rather than signed vs. unsigned. The format proposed by Andy "Krazy" Glew * 1 bit sign * 7 bit exponent * 12 bit real and imaginary parts => a 32 bit small complex number. would be unable to encode e.g. 1-i, because it has only one sign bit. I wonder if it'd be feasible to have something like a hidden bit in such a format. If you have a hidden bit in each mantissa, you cannot encode e.g. 4+i, because there is no exponent that covers both parts. If you don't have any hidden bits, you leave almost 1/4 of the bit combinations unused: those where the msb of each mantissa is zero and the exponent is not special.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-08-30 08:22 +0100 |
| Message-ID | <j3i33n$89o$1@gosset.csi.cam.ac.uk> |
| In reply to | #3257 |
In article <87liub8pxm.fsf@Niukka.kon.iki.fi>, Kalle Olavi Niemitalo <kon@iki.fi> wrote: > >> Firstly, the sign is obviously irrelevant, because both integers and >> fixed-point numbers are almost always signed. > >It's a matter of positive vs. negative, rather than signed vs. unsigned. >The format proposed by Andy "Krazy" Glew > > * 1 bit sign > * 7 bit exponent > * 12 bit real and imaginary parts > => a 32 bit small complex number. > >would be unable to encode e.g. 1-i, because it has only one sign >bit. Ah. Misunderstandings. Andy has already clarified that he didn't mean that anyway! >I wonder if it'd be feasible to have something like a hidden bit >in such a format. If you have a hidden bit in each mantissa, you >cannot encode e.g. 4+i, because there is no exponent that covers >both parts. If you don't have any hidden bits, you leave almost >1/4 of the bit combinations unused: those where the msb of each >mantissa is zero and the exponent is not special. Right, but why is that a problem? Seriously, in most of the homogeneous uses where scaled fixed-point is most appropriate (definitely including complex numbers), the excluded bit combinations don't actually carry significant (or even any) numeric information. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-08-31 11:34 -0700 |
| Message-ID | <j3kkmb$30d$1@news.albasani.net> |
| In reply to | #3257 |
On 8/29/2011 9:48 PM, Kalle Olavi Niemitalo wrote: > nmm1@cam.ac.uk writes: > >> Firstly, the sign is obviously irrelevant, because both integers and >> fixed-point numbers are almost always signed. > > It's a matter of positive vs. negative, rather than signed vs. unsigned. > The format proposed by Andy "Krazy" Glew > > * 1 bit sign > * 7 bit exponent > * 12 bit real and imaginary parts > => a 32 bit small complex number. > > would be unable to encode e.g. 1-i, because it has only one sign > bit. > > I wonder if it'd be feasible to have something like a hidden bit > in such a format. If you have a hidden bit in each mantissa, you > cannot encode e.g. 4+i, because there is no exponent that covers > both parts. If you don't have any hidden bits, you leave almost > 1/4 of the bit combinations unused: those where the msb of each > mantissa is zero and the exponent is not special. idle thought: 8 bits, exponent; 8 bits, phase; 16 bits, mantissa. phase: 0=+real 64=+imaginary 128=-real 192=-imaginary 1..63: +real, +imag 65..127: -real, +imag 129..191: -real, -imag 193..255: +real, -imag the phase basically shows the relative relation between the real and imaginary parts, and operates similarly to an angle. the exponent and mantissa then encode a unified scalar portion (always>=0). would be more accurate in-general than the use of 2 16-bit float values, but would tend to greatly reduce accuracy if there is a strong difference between components. random related idea: 8 bits: phi 7 bits: theta 10 bits: mantissa 7 bits: exponent roughly encodes a point in 3D space within 32 bits, having a max distance of around 2^63. positional accuracy will degrade with distance. possible 64 bit version: 16 bits: phi 15 bits: theta 24 bits: mantissa 9 bits: exponent an interesting experiment would be how big of a cube (or sphere) this could map out while retaining an accuracy of at least 1 unit.
[toc] | [prev] | [next] | [standalone]
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-08-29 22:22 -0700 |
| Message-ID | <4E5C7386.20300@SPAM.comp-arch.net> |
| In reply to | #3242 |
On 8/29/2011 11:56 AM, Andy "Krazy" Glew wrote: > On 8/29/2011 9:56 AM, nmm1@cam.ac.uk wrote: >> In article<4E5BB93F.2030406@SPAM.comp-arch.net>, >> Andy \"Krazy\" Glew<andy@SPAM.comp-arch.net> wrote: >>> On 8/29/2011 4:56 AM, Terje Mathisen wrote: >>>> >>>> Block fp formats have been quite common afaik in the embedded world, >>>> where you would store an array of (integer) mantissas, all sharing a >>>> common exponent. >>>> >>>> With a few guard bits to reduce the need for block renormalization this >>>> seems like an efficient layout. >>> >>> I'd appreciate any references to block FP. >>> >>> BGB provided a few. >>> >>> (Hell, I'd love it if you could/would just post, although my current >>> wiki security kerfuffle may delay that a bit.) >> >> Modern Computing Methods, 1948 :-) >> >> More seriously, it's just an example of scaled fixed-point, which >> was in widespread use until the 1960s. It isn't just computationally >> less demanding, but is often (not always) numerically better for >> homogenous problems like linear algebra (including FFTs). It lost >> out because it's more hassle to use. >> >> >> Regards, >> Nick Maclaren. > > I was unclear. > > I *know* what block FP is. > > What I want is examples of packed data formats for block FP. That are in > common use, i.e. not imagined, or used by only one programmer > > Like: > * 1 bit sign > * 15 bit exponent > * 16 bits x,y,z mantissa > => 64 bit total. > > I am not so interested in such simple formats, flavours of 8 and 16 bit > components. I am more interested in funny bitwidths. > > I am collecting these against the next time I am involved in an effort > like MMX. Where shortsighted people will say "all we need to support is > 4:2:2 YUV, and we should add a special instruction just for that", > rather than more general support. Or vice versa. > > E.g. block FP for a restricted complex: > * 1 bit sign > * 7 bit exponent > * 12 bit real and imaginary parts > => a 32 bit small complex number. My bad - I was too hasty to provide examples, cutting and pasting some of my existing scalar FP examples, without deleting the sign bit. How about 3-component vector block FP * 16 bit exponent (possibly signed, or biased) * 16 bit signed x,y,z mantissae => 16 bit total. (not very interesting) Or 2-component block FP for complex * 8 bit exponent (signed or biased) * 12 bit real and imaginary parts => a 32 bit small complex Anyway, I am not so much interested in what I can imagine, as what has already been used, which may be in somewhat wide use. (Overall I am down on block FP, but still...)
[toc] | [prev] | [next] | [standalone]
| From | Andrew Reilly <areilly---@bigpond.net.au> |
|---|---|
| Date | 2011-08-30 11:17 +0000 |
| Message-ID | <9c3v67FfbvU1@mid.individual.net> |
| In reply to | #3259 |
On Mon, 29 Aug 2011 22:22:14 -0700, Andy \"Krazy\" Glew wrote:
> Anyway, I am not so much interested in what I can imagine, as what has
> already been used, which may be in somewhat wide use.
I'd be very surprised if most uses weren't exactly of the form: {int data
[N]; int scale};
That's semantically how I've always done block floating point, only I
don't recall ever actually putting the exponent into a struct along with
the data...
Well, Brett's already pointed out a packed coordinate scheme, for which I
can see some merit, but mostly I consider block floating point a special
case where an algorithm on an array of data requires more dynamic range
than can be absorbed by the basic machine precision. Your choices then
are:
* extended precision per element (often implies quadratic expense for
multiplication)
* simulated floating point per element (keeps multiplication cost but
adds a bunch of complication to addition and handling)
* block floating point (keeps most of the per-word performance at the
cost of block-normalization, irregular code structures and a reliance on
a block-level precision bound.)
> (Overall I am down on block FP, but still...)
I'm down on block floating point too. Unfortunately it's the best
tradeoff for a bunch of situations when you don't have hardware floating
point available...
Cheers,
--
Andrew
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-08-30 12:35 +0100 |
| Message-ID | <j3ihum$b6h$1@gosset.csi.cam.ac.uk> |
| In reply to | #3261 |
In article <9c3v67FfbvU1@mid.individual.net>,
Andrew Reilly <areilly---@bigpond.net.au> wrote:
>On Mon, 29 Aug 2011 22:22:14 -0700, Andy \"Krazy\" Glew wrote:
>
>> (Overall I am down on block FP, but still...)
>
>I'm down on block floating point too. Unfortunately it's the best
>tradeoff for a bunch of situations when you don't have hardware floating
>point available...
Grrk. I think that's primarily because you are still thinking in
terms of the current model - I fully agree that it's a bad way of
implementing that, but what most people miss is that is itself a
poor solution to the actual requirements.
When floating-point replaced fixed-point for numerics, it was because
it provided 'automatic scaling' - except that every numerical analyst
and reference pointed out that using floating-point DIDN'T remove the
need for scaling in many common problems!
Also, there are many other representations that have some advantages
over floating-point under some circumstances. When floating-point
took over, most thinking in that area stopped - a clear example is
for complex numbers, where virtually nobody questions the merits of
the Cartesian pair representation any longer. But, actually, a polar
one gives the following advantages:
1) It can handle infinity/NaN correctly.
2) It can handle winding numbers - whereas the truly ghastly
signed zero hack can only handle branch cuts.
Efficiency is a matter of swings and roundabouts. But, you say, a
polar representation isn't homogeneous - nor it is, but the exponent
is needed only for the radius.
And there are a lot of homogeneous vectors. A 3-D value is also
homogeneous, and quaternions are apparently now used, too.
So there is a strong argument that a block floating-point form is
useful, and would fit well with SSE-like primitives.
Regards,
Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-30 07:02 -0700 |
| Message-ID | <4c73d0a3-c3a4-4f5a-8655-85d122dd66e3@c19g2000yqe.googlegroups.com> |
| In reply to | #3264 |
On Aug 30, 5:35 am, n...@cam.ac.uk wrote: > When floating-point > took over, most thinking in that area stopped - a clear example is > for complex numbers, where virtually nobody questions the merits of > the Cartesian pair representation any longer. But, actually, a polar > one gives the following advantages: > > 1) It can handle infinity/NaN correctly. > > 2) It can handle winding numbers - whereas the truly ghastly > signed zero hack can only handle branch cuts. > > Efficiency is a matter of swings and roundabouts. But, you say, a > polar representation isn't homogeneous - nor it is, but the exponent > is needed only for the radius. Two floating-point numbers which constitute the Cartesian representation of a complex number can: - be added to produce the sum of two complex numbers; - form the product of two complex numbers through the relationship (x +iy)(u+iv) = ((ux-vy)+(uy+vx)i). Two complex numbers in the polar representation can be easily multiplied, but _not_ easily added without time-consuming trigonometric and inverse trigonometric functions. This is the same reason we use floating-point numbers instead of a logarithmic representation of numbers. One can always take the logarithm to convert to a polar representation when it is desired to keep track of winding number, so the option of enduring this huge computational overhead is not lost. But the option is gained of obtaining the results of calculations more quickly when this information is not needed. John Savard
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-08-30 15:18 +0100 |
| Message-ID | <j3irfn$cba$1@gosset.csi.cam.ac.uk> |
| In reply to | #3268 |
In article <4c73d0a3-c3a4-4f5a-8655-85d122dd66e3@c19g2000yqe.googlegroups.com>,
Quadibloc <jsavard@ecn.ab.ca> wrote:
>
>> When floating-point
>> took over, most thinking in that area stopped - a clear example is
>> for complex numbers, where virtually nobody questions the merits of
>> the Cartesian pair representation any longer. But, actually, a polar
>> one gives the following advantages:
>>
>> 1) It can handle infinity/NaN correctly.
>>
>> 2) It can handle winding numbers - whereas the truly ghastly
>> signed zero hack can only handle branch cuts.
>>
>> Efficiency is a matter of swings and roundabouts. But, you say, a
>> polar representation isn't homogeneous - nor it is, but the exponent
>> is needed only for the radius.
>
>Two floating-point numbers which constitute the Cartesian
>representation of a complex number can:
>
>- be added to produce the sum of two complex numbers;
>
>- form the product of two complex numbers through the relationship (x
>+iy)(u+iv) =3D ((ux-vy)+(uy+vx)i).
>
>Two complex numbers in the polar representation can be easily
>multiplied, but _not_ easily added without time-consuming
>trigonometric and inverse trigonometric functions.
>
>This is the same reason we use floating-point numbers instead of a
>logarithmic representation of numbers.
Sigh. Look, I have looked into this - not deeply, but more deeply
than that.
Consider also absolute value, division and other functions. There
is a strong sense in which the most-used operations in code have
been influenced by which have been fastest, and it isn't clear how
much difference this would make to real codes:
a) As they stand at present.
b) If they had been written or were rewritten to use algorithms
and code more appropriate for polar representation.
I think that Cartesian would still win, but it's not certain, and
the main argument for polar is definitely correctness.
>One can always take the logarithm to convert to a polar representation
>when it is desired to keep track of winding number, so the option of
>enduring this huge computational overhead is not lost. But the option
>is gained of obtaining the results of calculations more quickly when
>this information is not needed.
Er, no. Think it through. The problem about winding number is that
you need it preserved through more-or-less arbitrary calculations,
and rewriting those to use a logarithmic form is both hard and makes
the code very different from the mathematics.
You have missed the whole point about the use of signed zeroes for
branch cuts - it isn't the simple testing that is the problem, but
the maintenance of the information.
Regards,
Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-08-30 15:12 -0700 |
| Message-ID | <83e7ad21-cec1-4199-bcd3-524bb5315359@c8g2000prn.googlegroups.com> |
| In reply to | #3274 |
On Aug 30, 8:18 am, n...@cam.ac.uk wrote: > Er, no. Think it through. The problem about winding number is that > you need it preserved through more-or-less arbitrary calculations, > and rewriting those to use a logarithmic form is both hard and makes > the code very different from the mathematics. > > You have missed the whole point about the use of signed zeroes for > branch cuts - it isn't the simple testing that is the problem, but > the maintenance of the information. Basically, in an object-oriented language like C, one could write a bunch of methods that work on a new complex type that is represented in polar form. So, with operator overloading, the code could be made to "look like the mathematics". Of course, even conventional complex number arithmetic is really done in software - with some specialized graphics architectures excepted. It sometimes is needed to preserve winding number - but this sounds to me like a very specialized requirement that people would likely use Mathematica for instead of FORTRAN. (Although what you are seeking may indeed be a feature that does need to be added *there*.) John Savard
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-08-31 08:30 +0100 |
| Message-ID | <j3knv5$ren$1@gosset.csi.cam.ac.uk> |
| In reply to | #3287 |
In article <83e7ad21-cec1-4199-bcd3-524bb5315359@c8g2000prn.googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: > >> Er, no. Think it through. The problem about winding number is that >> you need it preserved through more-or-less arbitrary calculations, >> and rewriting those to use a logarithmic form is both hard and makes >> the code very different from the mathematics. >> >> You have missed the whole point about the use of signed zeroes for >> branch cuts - it isn't the simple testing that is the problem, but >> the maintenance of the information. > >Basically, in an object-oriented language like C, one could write a >bunch of methods that work on a new complex type that is represented >in polar form. So, with operator overloading, the code could be made >to "look like the mathematics". You mean C++, and object-orientation has nothing to do with it; it's type extension, which is a different concept. But, yes, it is possible and that is how it has been done. >Of course, even conventional complex number arithmetic is really done >in software - with some specialized graphics architectures excepted. Precisely. My point about the hardware in this thread is that the use of block floating-point and SSE-like facilities are both useful for this. >It sometimes is needed to preserve winding number - but this sounds to >me like a very specialized requirement that people would likely use >Mathematica for instead of FORTRAN. (Although what you are seeking may >indeed be a feature that does need to be added *there*.) You clearly haven't been following the lunacies to do with signed zeroes. The claim of those proponents is that branch cut support is so essential that breaking other semantics is a small price :-( However, as I said, the main argument in favour of polar is that it enables reliable exception value handling, which Cartesian does not. That is not a small matter. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-09-01 09:54 -0700 |
| Message-ID | <635ca4f4-c895-4517-acda-c1b6b50f93aa@z7g2000vbp.googlegroups.com> |
| In reply to | #3294 |
On Aug 31, 1:30 am, n...@cam.ac.uk wrote: > You clearly haven't been following the lunacies to do with signed > zeroes. The claim of those proponents is that branch cut support > is so essential that breaking other semantics is a small price :-( No, I haven't. > However, as I said, the main argument in favour of polar is that it > enables reliable exception value handling, which Cartesian does not. > That is not a small matter. I don't say it is a small matter. In the areas of scientific computing with which I am most familiar, however, speed is the _sine qua non_, and principal values and the like are not a major issue. And, on general principles, if the hardware or language or floating- point package implements something the "elegant" way, then trying to do it some other, faster, way usually involves extra overhead (because it isn't built-in and you're cobbling together the means of doing it by hand at your higher level) that little is gained. So the rule is to provide facilities that are simple, fast, and close to the hardware - and allow those with special requirements to use specialized packages to meet them. That is a very sound rule, and the importance of winding number for some problems involving complex numbers is not sufficient to create an exception to that rule. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-09-01 10:09 -0700 |
| Message-ID | <4f7c7b71-69b2-40f8-b392-21c7fc9f2ca7@n12g2000yqh.googlegroups.com> |
| In reply to | #3331 |
And, in fact, I remember having seen a graphic example of how important winding number can be when dealing with complex numbers, as the contour diagram of the Hankel function at the bottom of this page shows: http://people.math.sfu.ca/~cbm/aands/page_359.htm John Savard
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-09-01 18:01 +0100 |
| Message-ID | <j3odpv$fli$1@gosset.csi.cam.ac.uk> |
| In reply to | #3331 |
In article <635ca4f4-c895-4517-acda-c1b6b50f93aa@z7g2000vbp.googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: > >> You clearly haven't been following the lunacies to do with signed >> zeroes. =A0The claim of those proponents is that branch cut support >> is so essential that breaking other semantics is a small price :-( > >No, I haven't. I recommend you not to bother! >> However, as I said, the main argument in favour of polar is that it >> enables reliable exception value handling, which Cartesian does not. >> That is not a small matter. > >I don't say it is a small matter. In the areas of scientific computing >with which I am most familiar, however, speed is the _sine qua non_, >and principal values and the like are not a major issue. I am not talking about those. I am talking about correctness and error detection. Getting a totally bogus answer faster is, I know, strongly favoured, but I will have no truck with it. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-09-01 12:25 -0700 |
| Message-ID | <0fea3046-95d9-44b3-ac45-ed1eb367cf56@k15g2000yqd.googlegroups.com> |
| In reply to | #3334 |
On Sep 1, 11:01 am, n...@cam.ac.uk wrote: > Getting a totally bogus answer faster is, I know, > strongly favoured, but I will have no truck with it. Neither will I. But as I noted after the part you quoted, it's easier to do things the slower way _when it is required_ if the fast way is the default. If it isn't, one doesn't have the choice, the speed is no longer available to be gained. People can and will use computers to solve problems that are at the very limit of what the computational resources available to them are capable of doing. This does mean, of course, that the computer system in question is designed for people _who know what they're doing_ - and this does make sense if one is shipping a supercomputer to physicists. That's the situation where I see complex numbers being used. Tools which do handle winding number carefully, so that the assumption that it won't matter for a given problem (because expressions have been designed to keep the numbers in the correct range) can be *tested*, of course, are important to have as well. If even older versions of Mathematica couldn't do this, of course, I despair of it being a selectable option on a FORTRAN compiler - but, yes, I agree that this sort of thing is needed. Turning the world's FORTRAN compilers into safety scissors with blunt ends, however, is something with which I will have no truck either. John Savard
[toc] | [prev] | [next] | [standalone]
| From | sidd <sidd@situ.com> |
|---|---|
| Date | 2011-09-01 20:02 -0400 |
| Message-ID | <j3p6e3$9m3$1@speranza.aioe.org> |
| In reply to | #3331 |
On Thursday 01 September 2011 12:54, Quadibloc wrote: > That is a very sound rule, and the importance of winding number for > some problems involving complex numbers is not sufficient to create an > exception to that rule. > I must agree. The Cartesian representation of the complex plane is a very simplified version. Under exponentiation, the plane becomes helical, and this is only a shadow of the real difficulties in representation enforced by analyticity (Cauchy-Riemann conditions) across branch cuts. Considering that floating point is an approximation to real line anyway attempting to represent complex numbers as an ordered pair of floating points might be considered hubris... The best way i have found is to do most calculation with complex numbers is by hand, only use complex variables in a program when i am fairly sure i know what i am doing. then when i get a ridiculous answer, i go back and redo. Complex numbers are the last stop on the route from integers, thru the rationals and the reals, before you have to give up commutativity ab=ba Then you get quarternions, and if you are willing to give up associativity (ab)c=a(bc) you can go further... I would not recommend trying to do any real math for quaternions or octonions or Clifford numbers implemented as ordered sets of floats except under draconian supervision. sidd
[toc] | [prev] | [next] | [standalone]
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
Back to top | Article view | comp.arch
csiph-web