Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #71022 > unrolled thread
| Started by | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| First post | 2015-09-21 20:17 +0200 |
| Last post | 2015-09-22 11:23 +0200 |
| Articles | 20 on this page of 145 — 21 participants |
Back to article view | Back to comp.lang.c
How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-21 20:17 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-21 20:43 +0200
Re: How to write this sign function in Delphi. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-21 19:51 +0100
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-21 23:26 +0200
Re: How to write this sign function in Delphi. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-21 22:47 +0100
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-22 16:29 +0200
Re: How to write this sign function in Delphi. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-22 16:11 +0100
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-23 11:18 +0200
Re: How to write this sign function in Delphi. David Brown <david.brown@hesbynett.no> - 2015-09-23 13:01 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-21 20:53 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-21 20:54 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-21 20:58 +0200
Re: How to write this sign function in Delphi. M Philbrook <jamie_ka1lpa@charter.net> - 2015-09-21 18:15 -0400
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-21 15:21 -0700
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-09-21 17:51 -0500
Re: How to write this sign function in Delphi. James Kuyper <jameskuyper@verizon.net> - 2015-09-21 19:15 -0400
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-09-21 23:59 -0500
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-22 09:22 -0700
Re: How to write this sign function in Delphi. Keith Thompson <kst-u@mib.org> - 2015-09-22 10:32 -0700
Re: How to write this sign function in Delphi. jt@toerring.de (Jens Thoms Toerring) - 2015-09-22 18:17 +0000
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-22 12:25 -0700
Re: How to write this sign function in Delphi. jt@toerring.de (Jens Thoms Toerring) - 2015-09-22 22:33 +0000
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-22 15:52 -0700
Re: How to write this sign function in Delphi. raltbos@xs4all.nl (Richard Bos) - 2015-09-22 23:09 +0000
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-23 09:07 -0700
Re: How to write this sign function in Delphi. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-23 16:55 +0000
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-23 10:46 -0700
Re: How to write this sign function in Delphi. jt@toerring.de (Jens Thoms Toerring) - 2015-09-23 23:18 +0000
Re: How to write this sign function in Delphi. James Kuyper <jameskuyper@verizon.net> - 2015-09-23 22:29 -0400
Re: How to write this sign function in Delphi. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-24 11:09 +0100
Re: How to write this sign function in Delphi. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-27 18:23 -0700
Re: How to write this sign function in Delphi. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-28 05:20 +0000
Re: How to write this sign function in Delphi. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-27 23:23 -0700
Re: How to write this sign function in Delphi. Richard Heathfield <rjh@cpax.org.uk> - 2015-09-28 09:03 +0100
Re: How to write this sign function in Delphi. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 01:24 -0700
Re: How to write this sign function in Delphi. Richard Heathfield <rjh@cpax.org.uk> - 2015-09-28 09:32 +0100
Re: How to write this sign function in Delphi. Bartc <bc@freeuk.com> - 2015-09-28 10:22 +0100
Re: How to write this sign function in Delphi. Richard Heathfield <rjh@cpax.org.uk> - 2015-09-28 11:35 +0100
Re: How to write this sign function in Delphi. Keith Thompson <kst-u@mib.org> - 2015-09-28 10:33 -0700
Re: How to write this sign function in Delphi. Richard Heathfield <rjh@cpax.org.uk> - 2015-09-28 18:59 +0100
Re: How to write this sign function in Delphi. Rosario19 <Ros@invalid.invalid> - 2015-09-28 20:09 +0200
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-09-28 13:39 -0500
Re: How to write this sign function in Delphi. Richard Heathfield <rjh@cpax.org.uk> - 2015-09-28 20:04 +0100
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-09-28 16:43 -0500
Re: How to write this sign function in Delphi. Martin Shobe <martin.shobe@yahoo.com> - 2015-09-28 18:55 -0500
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-09-28 19:31 -0500
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-28 12:16 -0700
Re: How to write this sign function in Delphi. Keith Thompson <kst-u@mib.org> - 2015-09-28 14:31 -0700
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-09-28 16:47 -0500
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-29 11:54 -0700
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-10-01 00:36 -0500
Re: How to write this sign function in Delphi. raltbos@xs4all.nl (Richard Bos) - 2015-10-02 10:53 +0000
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-02 09:48 -0700
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-10-03 11:27 -0500
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-03 12:32 -0700
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-10-03 11:26 -0500
Re: How to write this sign function in Delphi. Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:46 -0700
Re: How to write this sign function in Delphi. Keith Thompson <kst-u@mib.org> - 2015-09-28 14:23 -0700
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-09-28 16:52 -0500
Re: How to write this sign function in Delphi. Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 01:39 -0700
Re: How to write this sign function in Delphi. Keith Thompson <kst-u@mib.org> - 2015-09-30 12:37 -0700
Re: How to write this sign function in Delphi. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-30 21:28 +0000
Re: How to write this sign function in Delphi. James Kuyper <jameskuyper@verizon.net> - 2015-09-30 17:54 -0400
Re: How to write this sign function in Delphi. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-01 03:59 +0000
Re: How to write this sign function in Delphi. James Kuyper <jameskuyper@verizon.net> - 2015-10-01 01:42 -0400
Re: How to write this sign function in Delphi. Keith Thompson <kst-u@mib.org> - 2015-09-30 16:20 -0700
Re: How to write this sign function in Delphi. Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:39 -0700
Re: How to write this sign function in Delphi. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-28 23:23 +0000
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-29 09:35 -0700
Re: How to write this sign function in Delphi. raltbos@xs4all.nl (Richard Bos) - 2015-10-02 11:06 +0000
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-02 09:23 -0700
Re: How to write this sign function in Delphi. Martin Shobe <martin.shobe@yahoo.com> - 2015-10-02 12:07 -0500
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-02 10:47 -0700
Re: How to write this sign function in Delphi. Keith Thompson <kst-u@mib.org> - 2015-10-02 17:48 -0700
Re: How to write this sign function in Delphi. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-03 16:46 +0100
Re: How to write this sign function in Delphi. Martin Shobe <martin.shobe@yahoo.com> - 2015-10-05 10:41 -0500
Re: How to write this sign function in Delphi. James Kuyper <jameskuyper@verizon.net> - 2015-09-28 15:31 -0400
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-09-28 16:40 -0500
Re: How to write this sign function in Delphi. James Kuyper <jameskuyper@verizon.net> - 2015-09-28 18:17 -0400
Re: How to write this sign function in Delphi. Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 02:49 -0700
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-30 06:27 -0700
Re: How to write this sign function in Delphi. Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-29 10:43 -0700
Re: How to write this sign function in Delphi. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-28 22:51 +0000
Re: How to write this sign function in Delphi. Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 02:11 -0700
Re: How to write this sign function in Delphi. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-28 22:48 +0000
Re: How to write this sign function in Delphi. Robert Wessel <robertwessel2@yahoo.com> - 2015-09-28 22:03 -0500
Re: How to write this sign function in Delphi. Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 01:13 -0700
Re: How to write this sign function in Delphi. Bartc <bc@freeuk.com> - 2015-09-30 17:06 +0100
Re: How to write this sign function in Delphi. Richard Heathfield <rjh@cpax.org.uk> - 2015-09-30 17:26 +0100
Re: How to write this sign function in Delphi. Keith Thompson <kst-u@mib.org> - 2015-09-30 13:04 -0700
Re: How to write this sign function in Delphi. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-28 09:12 +0000
Re: How to write this sign function in Delphi. David Brown <david.brown@hesbynett.no> - 2015-09-28 12:28 +0200
Re: How to write this sign function in Delphi. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-28 20:44 +0100
Re: How to write this sign function in Delphi. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-01 01:39 -0700
Re: How to write this sign function in Delphi. Keith Thompson <kst-u@mib.org> - 2015-10-01 08:55 -0700
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-01 09:02 -0700
Re: How to write this sign function in Delphi. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-01 14:55 -0700
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-01 16:48 -0700
Re: How to write this sign function in Delphi. raltbos@xs4all.nl (Richard Bos) - 2015-10-02 11:46 +0000
Re: How to write this sign function in Delphi. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-06 00:15 -0700
Re: How to write this sign function in Delphi. Les Cargill <lcargill99@comcast.com> - 2015-10-06 02:43 -0500
Re: How to write this sign function in Delphi. David Brown <david.brown@hesbynett.no> - 2015-10-06 10:13 +0200
Re: How to write this sign function in Delphi. Les Cargill <lcargill99@comcast.com> - 2015-10-06 19:14 -0500
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-06 21:36 -0700
Re: How to write this sign function in Delphi. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-06 09:25 +0100
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-06 09:28 -0700
Re: How to write this sign function in Delphi. Keith Thompson <kst-u@mib.org> - 2015-10-06 13:11 -0700
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-06 13:56 -0700
Re: How to write this sign function in Delphi. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-07 00:25 +0000
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-06 09:44 -0700
Re: How to write this sign function in Delphi. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-06 10:08 -0700
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-06 12:00 -0700
Re: How to write this sign function in Delphi. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-07 01:58 -0700
Re: How to write this sign function in Delphi. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-07 10:12 +0100
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-08 00:40 -0700
Re: How to write this sign function in Delphi. Philip Lantz <prl@canterey.us> - 2015-10-03 12:29 -0700
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-03 13:20 -0700
Re: How to write this sign function in Delphi. Philip Lantz <prl@canterey.us> - 2015-10-03 12:33 -0700
Re: How to write this sign function in Delphi. James Kuyper <jameskuyper@verizon.net> - 2015-10-03 17:02 -0400
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-03 15:04 -0700
Re: How to write this sign function in Delphi. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-04 05:12 +0000
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-04 12:58 -0700
Re: How to write this sign function in Delphi. Philip Lantz <prl@canterey.us> - 2015-10-03 12:37 -0700
Re: How to write this sign function in Delphi. James Kuyper <jameskuyper@verizon.net> - 2015-10-03 16:21 -0400
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-03 16:05 -0700
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-10-03 14:02 -0700
Re: How to write this sign function in Delphi. supercat@casperkitty.com - 2015-09-24 09:39 -0700
Re: How to write this sign function in Delphi. raltbos@xs4all.nl (Richard Bos) - 2015-09-27 16:26 +0000
Re: How to write this sign function in Delphi. M Philbrook <jamie_ka1lpa@charter.net> - 2015-09-21 22:06 -0400
Re: How to write this sign function in Delphi. James Kuyper <jameskuyper@verizon.net> - 2015-09-22 10:17 -0400
Re: How to write this sign function in Delphi. M Philbrook <jamie_ka1lpa@charter.net> - 2015-09-22 19:48 -0400
Re: How to write this sign function in Delphi. Noob <root@127.0.0.1> - 2015-09-23 13:15 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-21 21:25 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-21 21:54 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-21 22:02 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-21 21:50 +0200
Re: How to write this sign function in Delphi. M Philbrook <jamie_ka1lpa@charter.net> - 2015-09-21 18:08 -0400
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-22 08:31 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-22 10:18 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-22 10:50 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-22 11:00 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-22 11:07 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-22 11:20 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-22 11:15 +0200
Re: How to write this sign function in Delphi. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-22 11:23 +0200
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-09-28 20:09 +0200 |
| Message-ID | <h90j0bp313tqedr7466fmfm7rm1t118uob@4ax.com> |
| In reply to | #71380 |
On Mon, 28 Sep 2015 18:59:22 +0100, Richard Heathfield wrote: >On 28/09/15 18:33, Keith Thompson wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >>> On 28/09/15 10:22, Bartc wrote: >>>> On 28/09/2015 09:32, Richard Heathfield wrote: >>>>> On 28/09/15 09:24, Malcolm McLean wrote: >>>> >>>>>> Represent as 110 cents instead. 2^53 >>>>>> gives us 90 trillion dollars - uncomfortably close to Obama's >>>>>> credit card amount outstanding. >>>>> >>>>> But you're not guaranteed 2^53 pennies. The Standard allows double to be >>>>> as small as 32 bits. >>>> >>>> You'd be short-changed if you specified double and only got >>>> single-precision. Anyway where does it say that in the Standard? >>> >>> The float type can be as small as 32 bits (it /is/ 32 bits on the system >>> I'm using right now) and the Standard does not require DBL_MAX to be >>> greater than FLT_MAX or for DBL_MIN to be lower than FLT_MIN, so >>> presumably it can fit into the same number of bits as a float. >> >> Similar reasoning would imply that long can be as narrow as 16 bits. > >Yes, I suppose so. :-) > >> The standard requires FLT_DIG to be at least 6, and DBL_DIG to >> be at least 10. Both FLT_MAX and DBL_MAX are required to be at >> least 1E+37. >> >> 6 decimal digits is about 20 bits, and 1E+37 is about 2**123, which >> implies you need about 7 exponent bits, so float needs to be about >> 28 bits or more. >> >> 10 decimal digits is about 33 bits, so double needs to be about 41 >> bits or more. >> >> I've undoubtedly made one or more off-by-one errors above, but not, >> I think, enough to permit double to be represented in 32 bits. > >I'll buy that. I did look at the Standard, of course, but as usual I >found the FP stuff hard going. > >The important question in the present context is: what is the largest >integer that double is required to be able to represent precisely, such >that all smaller (positive) integers can also be represented? > >It was my belief that this number is considerably lower than 2^53, but >it is now only my opinion. I don't quite see how to get the relevant >number from the Linear B description of floating point provided in the >Standard. possible i understand wrong the problem of float point not fixed we say double 64 bit if i remember well in this number 123456789abcdef g=123456789123456.67123 the 0.67123 can not be represented
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-28 13:39 -0500 |
| Message-ID | <dv1j0b950h81uovnf0l2he5rvebfh9ec5k@4ax.com> |
| In reply to | #71380 |
On Mon, 28 Sep 2015 18:59:22 +0100, Richard Heathfield <rjh@cpax.org.uk> wrote: >On 28/09/15 18:33, Keith Thompson wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >>> On 28/09/15 10:22, Bartc wrote: >>>> On 28/09/2015 09:32, Richard Heathfield wrote: >>>>> On 28/09/15 09:24, Malcolm McLean wrote: >>>> >>>>>> Represent as 110 cents instead. 2^53 >>>>>> gives us 90 trillion dollars - uncomfortably close to Obama's >>>>>> credit card amount outstanding. >>>>> >>>>> But you're not guaranteed 2^53 pennies. The Standard allows double to be >>>>> as small as 32 bits. >>>> >>>> You'd be short-changed if you specified double and only got >>>> single-precision. Anyway where does it say that in the Standard? >>> >>> The float type can be as small as 32 bits (it /is/ 32 bits on the system >>> I'm using right now) and the Standard does not require DBL_MAX to be >>> greater than FLT_MAX or for DBL_MIN to be lower than FLT_MIN, so >>> presumably it can fit into the same number of bits as a float. >> >> Similar reasoning would imply that long can be as narrow as 16 bits. > >Yes, I suppose so. :-) > >> The standard requires FLT_DIG to be at least 6, and DBL_DIG to >> be at least 10. Both FLT_MAX and DBL_MAX are required to be at >> least 1E+37. >> >> 6 decimal digits is about 20 bits, and 1E+37 is about 2**123, which >> implies you need about 7 exponent bits, so float needs to be about >> 28 bits or more. >> >> 10 decimal digits is about 33 bits, so double needs to be about 41 >> bits or more. >> >> I've undoubtedly made one or more off-by-one errors above, but not, >> I think, enough to permit double to be represented in 32 bits. > >I'll buy that. I did look at the Standard, of course, but as usual I >found the FP stuff hard going. > >The important question in the present context is: what is the largest >integer that double is required to be able to represent precisely, such >that all smaller (positive) integers can also be represented? > >It was my belief that this number is considerably lower than 2^53, but >it is now only my opinion. I don't quite see how to get the relevant >number from the Linear B description of floating point provided in the >Standard. Since DBL_DIG is required not required to be more than 10, the upper bound on that is about (10*10-1), or bit over 33 bits worth. It is, however, unclear to me that having a DBL_DIG of 10 is actually sufficient to require that all integers 1..(10*10-1) are representable exactly. For conventional FP systems that would seem to be the case, but FP formats with non-integer bases, for example, you might have very few integers that have an exact representation.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-09-28 20:04 +0100 |
| Message-ID | <muc2sf$ton$1@dont-email.me> |
| In reply to | #71384 |
On 28/09/15 19:39, Robert Wessel wrote: > On Mon, 28 Sep 2015 18:59:22 +0100, Richard Heathfield > <rjh@cpax.org.uk> wrote: > <snip> >> >> The important question in the present context is: what is the largest >> integer that double is required to be able to represent precisely, such >> that all smaller (positive) integers can also be represented? >> >> It was my belief that this number is considerably lower than 2^53, but >> it is now only my opinion. I don't quite see how to get the relevant >> number from the Linear B description of floating point provided in the >> Standard. > > Since DBL_DIG is required not required to be more than 10, the upper > bound on that is about (10*10-1), or bit over 33 bits worth. If we are generous, then, and call it 34, then that's (roughly) 16000000000 pennies, or $160,000,000, which is a fair amount of cash to be carrying around in your wallet, but it is not of such an order of magnitude that an accountant would feel justified in being complacent about the occasional penny going astray. > It is, > however, unclear to me that having a DBL_DIG of 10 is actually > sufficient to require that all integers 1..(10*10-1) are representable > exactly. For conventional FP systems that would seem to be the case, > but FP formats with non-integer bases, for example, you might have > very few integers that have an exact representation. Which takes us right back to ints, or to roll-your-own bignums. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-28 16:43 -0500 |
| Message-ID | <iucj0bh4c4a8lrji3gcrgqrqoblcmq0jsr@4ax.com> |
| In reply to | #71388 |
On Mon, 28 Sep 2015 20:04:37 +0100, Richard Heathfield <rjh@cpax.org.uk> wrote: >On 28/09/15 19:39, Robert Wessel wrote: >> On Mon, 28 Sep 2015 18:59:22 +0100, Richard Heathfield >> <rjh@cpax.org.uk> wrote: >> ><snip> >>> >>> The important question in the present context is: what is the largest >>> integer that double is required to be able to represent precisely, such >>> that all smaller (positive) integers can also be represented? >>> >>> It was my belief that this number is considerably lower than 2^53, but >>> it is now only my opinion. I don't quite see how to get the relevant >>> number from the Linear B description of floating point provided in the >>> Standard. >> >> Since DBL_DIG is required not required to be more than 10, the upper >> bound on that is about (10*10-1), or bit over 33 bits worth. > >If we are generous, then, and call it 34, then that's (roughly) >16000000000 pennies, or $160,000,000, which is a fair amount of cash to >be carrying around in your wallet, but it is not of such an order of >magnitude that an accountant would feel justified in being complacent >about the occasional penny going astray. As I've mentioned before, it's not that 64 bits is really inadequate to describe any practical amount of pennies, it's that intermediate results require more precision. 53 bits, OTOH, starts to feel a bit constrained - it's barely more than the GDP of the planet. >> It is, >> however, unclear to me that having a DBL_DIG of 10 is actually >> sufficient to require that all integers 1..(10*10-1) are representable >> exactly. For conventional FP systems that would seem to be the case, >> but FP formats with non-integer bases, for example, you might have >> very few integers that have an exact representation. > >Which takes us right back to ints, or to roll-your-own bignums. Yep.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-09-28 18:55 -0500 |
| Message-ID | <mucjul$g6$1@dont-email.me> |
| In reply to | #71397 |
On 9/28/2015 4:43 PM, Robert Wessel wrote: > On Mon, 28 Sep 2015 20:04:37 +0100, Richard Heathfield > <rjh@cpax.org.uk> wrote: > >> On 28/09/15 19:39, Robert Wessel wrote: >>> On Mon, 28 Sep 2015 18:59:22 +0100, Richard Heathfield >>> <rjh@cpax.org.uk> wrote: >>> >> <snip> >>>> >>>> The important question in the present context is: what is the largest >>>> integer that double is required to be able to represent precisely, such >>>> that all smaller (positive) integers can also be represented? >>>> >>>> It was my belief that this number is considerably lower than 2^53, but >>>> it is now only my opinion. I don't quite see how to get the relevant >>>> number from the Linear B description of floating point provided in the >>>> Standard. >>> >>> Since DBL_DIG is required not required to be more than 10, the upper >>> bound on that is about (10*10-1), or bit over 33 bits worth. >> >> If we are generous, then, and call it 34, then that's (roughly) >> 16000000000 pennies, or $160,000,000, which is a fair amount of cash to >> be carrying around in your wallet, but it is not of such an order of >> magnitude that an accountant would feel justified in being complacent >> about the occasional penny going astray. > > > As I've mentioned before, it's not that 64 bits is really inadequate > to describe any practical amount of pennies, it's that intermediate > results require more precision. 53 bits, OTOH, starts to feel a bit > constrained - it's barely more than the GDP of the planet. It's two orders of magnitude too small if you're using dongs. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-28 19:31 -0500 |
| Message-ID | <qomj0bt8dtia4bh2j6lqvveg2n25a2f4lq@4ax.com> |
| In reply to | #71408 |
On Mon, 28 Sep 2015 18:55:55 -0500, Martin Shobe <martin.shobe@yahoo.com> wrote: >On 9/28/2015 4:43 PM, Robert Wessel wrote: >> On Mon, 28 Sep 2015 20:04:37 +0100, Richard Heathfield >> <rjh@cpax.org.uk> wrote: >> >>> On 28/09/15 19:39, Robert Wessel wrote: >>>> On Mon, 28 Sep 2015 18:59:22 +0100, Richard Heathfield >>>> <rjh@cpax.org.uk> wrote: >>>> >>> <snip> >>>>> >>>>> The important question in the present context is: what is the largest >>>>> integer that double is required to be able to represent precisely, such >>>>> that all smaller (positive) integers can also be represented? >>>>> >>>>> It was my belief that this number is considerably lower than 2^53, but >>>>> it is now only my opinion. I don't quite see how to get the relevant >>>>> number from the Linear B description of floating point provided in the >>>>> Standard. >>>> >>>> Since DBL_DIG is required not required to be more than 10, the upper >>>> bound on that is about (10*10-1), or bit over 33 bits worth. >>> >>> If we are generous, then, and call it 34, then that's (roughly) >>> 16000000000 pennies, or $160,000,000, which is a fair amount of cash to >>> be carrying around in your wallet, but it is not of such an order of >>> magnitude that an accountant would feel justified in being complacent >>> about the occasional penny going astray. >> >> >> As I've mentioned before, it's not that 64 bits is really inadequate >> to describe any practical amount of pennies, it's that intermediate >> results require more precision. 53 bits, OTOH, starts to feel a bit >> constrained - it's barely more than the GDP of the planet. > >It's two orders of magnitude too small if you're using dongs. I used to use Turkish Lira before they revalued (that was probably over a decade ago) to illustrate that the planetary GDP wouldn't even fit in 64 bits.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-28 12:16 -0700 |
| Message-ID | <756f0eab-f911-4171-b9a5-4e28e9559c6a@googlegroups.com> |
| In reply to | #71384 |
On Monday, September 28, 2015 at 1:35:01 PM UTC-5, robert...@yahoo.com wrote: > Since DBL_DIG is required not required to be more than 10, the upper > bound on that is about (10*10-1), or bit over 33 bits worth. It is, > however, unclear to me that having a DBL_DIG of 10 is actually > sufficient to require that all integers 1..(10*10-1) are representable > exactly. For conventional FP systems that would seem to be the case, > but FP formats with non-integer bases, for example, you might have > very few integers that have an exact representation. How exactly are "significant digits" defined? In some contexts, if a number is said to have N significant figures, that means that changes in the Nth place are meaningful. In other contexts, it would mean that every N-digit decimal number with an exponent that's below the maximum and not within N of the minimum would have a unique representation. Does anything clarify what the Standard actually means? For many embedded applications without floating-point units, a type which used a 32-bit mantissa could be much more efficient than a type with a larger mantissa, and such a type would qualify as ten-digit precision by some definitions but not others.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-28 14:31 -0700 |
| Message-ID | <lna8s644eo.fsf@kst-u.example.com> |
| In reply to | #71389 |
supercat@casperkitty.com writes:
> On Monday, September 28, 2015 at 1:35:01 PM UTC-5, robert...@yahoo.com wrote:
>> Since DBL_DIG is required not required to be more than 10, the upper
>> bound on that is about (10*10-1), or bit over 33 bits worth. It is,
>> however, unclear to me that having a DBL_DIG of 10 is actually
>> sufficient to require that all integers 1..(10*10-1) are representable
>> exactly. For conventional FP systems that would seem to be the case,
>> but FP formats with non-integer bases, for example, you might have
>> very few integers that have an exact representation.
>
> How exactly are "significant digits" defined?
It isn't; why do you ask?. The term isn't used in the standard,
nor did Robert mention it in the article you replied to.
> In some contexts, if a number
> is said to have N significant figures, that means that changes in the Nth
> place are meaningful. In other contexts, it would mean that every N-digit
> decimal number with an exponent that's below the maximum and not within
> N of the minimum would have a unique representation. Does anything clarify
> what the Standard actually means?
Yes, the standard does; see N1570 5.2.4.2.2. DBL_DIG is defined as:
number of decimal digits, q, such that any floating-point number
with q decimal digits can be rounded into a floating-point number
with p radix b digits and back again without change to the q decimal
digits
followed by some clarification using math notation that I won't try to
reproduce here. (This uses "q" because the definition covers FLT_DIG,
DBL_DIG, and LDBL_DIG.)
> For many embedded applications without floating-point units, a type
> which used a 32-bit mantissa could be much more efficient than a type
> with a larger mantissa, and such a type would qualify as ten-digit
> precision by some definitions but not others.
It would not qualify to be called "double" in a conforming C
implementation. Of course it could be called "float", and if you know
that float is much more efficient than double on a given target, you can
just write your code to use float.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-28 16:47 -0500 |
| Message-ID | <i5dj0bl56fbbs16prjqngt4eokphjsnnr1@4ax.com> |
| In reply to | #71389 |
On Mon, 28 Sep 2015 12:16:09 -0700 (PDT), supercat@casperkitty.com wrote: >On Monday, September 28, 2015 at 1:35:01 PM UTC-5, robert...@yahoo.com wrote: >> Since DBL_DIG is required not required to be more than 10, the upper >> bound on that is about (10*10-1), or bit over 33 bits worth. It is, >> however, unclear to me that having a DBL_DIG of 10 is actually >> sufficient to require that all integers 1..(10*10-1) are representable >> exactly. For conventional FP systems that would seem to be the case, >> but FP formats with non-integer bases, for example, you might have >> very few integers that have an exact representation. > >How exactly are "significant digits" defined? In some contexts, if a number >is said to have N significant figures, that means that changes in the Nth >place are meaningful. In other contexts, it would mean that every N-digit >decimal number with an exponent that's below the maximum and not within >N of the minimum would have a unique representation. Does anything clarify >what the Standard actually means? The standard is rather vague on what the actual requirements are. There's some precision about the model in which the stuff in float.h is reported, but not much else. >For many embedded applications without floating-point units, a type which used >a 32-bit mantissa could be much more efficient than a type with a larger >mantissa, and such a type would qualify as ten-digit precision by some >definitions but not others. I have trouble seeing how any definition of "10 (decimal) digits of precision" could be satisfied by a 32 bit value.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-29 11:54 -0700 |
| Message-ID | <3fd80e34-2430-45b4-bb11-9aa79159239c@googlegroups.com> |
| In reply to | #71398 |
On Monday, September 28, 2015 at 4:47:02 PM UTC-5, robert...@yahoo.com wrote: > I have trouble seeing how any definition of "10 (decimal) digits of > precision" could be satisfied by a 32 bit value. There are two useful ways of defining "precision": one is to identify the minimum number of decimal digits such that every floating-point value will yield a unique decimal representation. The other is to identify the maximum number of decimal digits such that every decimal representation may be be mapped to a unique floating-point representation. Code which wants to output numbers unambiguously must use the former definition and for a representation with a 32-bit mantissa would need to output eleven digits (for each ten-digit representation value in the range 100.0000000 to 127.9999999, there would be three or four different floating-point values which would output that if rounded to ten digits). On the flip side, code which needs to guarantee the ability to round-trip decimal representations may only be able to do so for nine-digit ones, since the smallest value greater than 8.0000000037 would be 8.0000000074. The effective decimal precision of a float with a 32-bit mantissa varies from 9 to 11. From the standpoint of judging whether a particular implementation will be adequate to meet needs, the lower figure may be more meaningful, but from the standpoint of determining how a program should behave, I would posit that the 11 is more meaningful [the number of digits a program accepts as input should depend upon the number of digits present, regardless of the implementation's level of precision, but it would be reasonable to output as many digits as are required to uniquely represent a floating-point value].
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-10-01 00:36 -0500 |
| Message-ID | <0ghp0bp0mqb9n1ma96041u6jbcqfdo01cj@4ax.com> |
| In reply to | #71445 |
On Tue, 29 Sep 2015 11:54:19 -0700 (PDT), supercat@casperkitty.com wrote: >On Monday, September 28, 2015 at 4:47:02 PM UTC-5, robert...@yahoo.com wrote: >> I have trouble seeing how any definition of "10 (decimal) digits of >> precision" could be satisfied by a 32 bit value. > >There are two useful ways of defining "precision": one is to identify the >minimum number of decimal digits such that every floating-point value will >yield a unique decimal representation. The other is to identify the maximum >number of decimal digits such that every decimal representation may be be >mapped to a unique floating-point representation. > >Code which wants to output numbers unambiguously must use the former >definition and for a representation with a 32-bit mantissa would need to >output eleven digits (for each ten-digit representation value in the >range 100.0000000 to 127.9999999, there would be three or four different >floating-point values which would output that if rounded to ten digits). > >On the flip side, code which needs to guarantee the ability to round-trip >decimal representations may only be able to do so for nine-digit ones, >since the smallest value greater than 8.0000000037 would be 8.0000000074. But that's not what the standard requires - the standard requires a round trip from decimal, to FP, and back to decimal, not FP-Decimal-FP.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-02 10:53 +0000 |
| Message-ID | <560e6208.6921328@news.xs4all.nl> |
| In reply to | #71525 |
Robert Wessel <robertwessel2@yahoo.com> wrote: > On Tue, 29 Sep 2015 11:54:19 -0700 (PDT), supercat@casperkitty.com > wrote: > > >On the flip side, code which needs to guarantee the ability to round-trip > >decimal representations may only be able to do so for nine-digit ones, > >since the smallest value greater than 8.0000000037 would be 8.0000000074. > > But that's not what the standard requires - the standard requires a > round trip from decimal, to FP, and back to decimal, not > FP-Decimal-FP. Is it even possible to guarantee both? Either one or the other I can see, but both at the same time would run into difficulties. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-02 09:48 -0700 |
| Message-ID | <a2b1dd6a-d5be-46ac-92fc-d6f6951ff127@googlegroups.com> |
| In reply to | #71595 |
On Friday, October 2, 2015 at 5:53:45 AM UTC-5, Richard Bos wrote: > Is it even possible to guarantee both? Either one or the other I can > see, but both at the same time would run into difficulties. Any 64-bit double will be round-tripped if written out as a decimal representation with 17 digits of precision, and read back accurately. Any decimal value with a precision of 15 digits or less may be round-tripped by producing the nearest binary value, and later outputting its value in decimal form rounded to 15 digits of precision. It's even possible to support both forms of round-tripping if, when outputting numbers as decimal, one starts by formatting with 15 digits of precision and checking whether the result, when converted back to double, yields the same value, but there's a rather nasty gotcha with that approach: some 15-digit decimal values fall almost exactly halfway between two adjacent "double" values, either of which would render as the same 15-digit number. It normally wouldn't matter if a decimal-to- binary conversion routine returned a result that was incorrectly rounded by an extra 0.1ulp, but for purposes of round-trip conversions it is imperative that rounding be absolutely consistent (which generally implies that all stages should use extra code to ensure that all results are perfectly rounded).
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-10-03 11:27 -0500 |
| Message-ID | <id001b91ket2d90bmb4nun1k6pm9g5j21e@4ax.com> |
| In reply to | #71623 |
On Fri, 2 Oct 2015 09:48:50 -0700 (PDT), supercat@casperkitty.com wrote: >On Friday, October 2, 2015 at 5:53:45 AM UTC-5, Richard Bos wrote: >> Is it even possible to guarantee both? Either one or the other I can >> see, but both at the same time would run into difficulties. > >Any 64-bit double will be round-tripped if written out as a decimal >representation with 17 digits of precision, and read back accurately. Any >decimal value with a precision of 15 digits or less may be round-tripped >by producing the nearest binary value, and later outputting its value >in decimal form rounded to 15 digits of precision. So this works so long as DBL_DIG is both 15 and 17?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-03 12:32 -0700 |
| Message-ID | <d774fa4a-47c5-4923-a671-3568d300fd9d@googlegroups.com> |
| In reply to | #71674 |
On Saturday, October 3, 2015 at 11:26:35 AM UTC-5, robert...@yahoo.com wrote:
> So this works so long as DBL_DIG is both 15 and 17?
IMHO, the Standard doesn't define enough parameters for floating-point
representations. I would suggest, at minimum:
1. The maximum and minimum powers of ten for which the precision remains
essentially constant.
2. The smallest power of ten which is guaranteed to be greater than any
non-infinite value.
3. The lowest (most negative) power of ten which is guaranteed to be larger
than any finite non-zero value.
4. The largest number of decimal digits which is guaranteed to be mappable
to unique representations within the range specified in #1 above.
5. The smallest number of decimal digits which is guaranteed to be sufficient
to round-trip any machine-representable-value in that range.
6. An indication what guarantees are made with regard to library routines
that convert between machine and decimal-text representations, e.g.
a. If a number with no more than (#4 above) digits is converted to
machine form and then converted back to textual form using an
"automatic precision" method, will it yield the same representation
as the original *without any extra trailing digits*.
b. If a finite number in machine form is converted to text form and
back using library routines, is the process guaranteed to yield
the original number.
c. What is the maximum difference, in units of 1/32768 unit in the
last place (ULP), between a floating-point value and its automatic-
format representation
d. What is the maximum difference, in units of 1/32768 unit in the
last place, units-last-place, between the exact value of a decimal
string and the machine-readable value derived from it.
Note that on a good system, parameter d will be 16384, but many real-world
floating-point systems aren't quite that good (and may thus have a slightly
higher value). If numbers are being output on one system with the intention
of being read in on another precisely, the combined values of parameters c
and d must be below 32768, but parameter d cannot be below 16384 (on a good
system it's 16384 precisely) and while parameter c could be reduced to about
1000 on systems that didn't need to uphold guarantee #1, it can't be much
below 16384 while upholding that guarantee (I don't think the representation
ever needs to be off by more than 16383/32768ulp, but I'm not sure what the
exact worst case is.
Code which needs to input and output floating-point numbers with absolutely
perfect rounding behavior is a lot more complicated than code which does
not need to do so; especially in embedded systems it may often be worthwhile
to have library code be smaller and less precise, provided that one can
ensure that it will meet one's actual requirements.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-10-03 11:26 -0500 |
| Message-ID | <d2001blhoc1d5snv7vdfegg70m938vdlan@4ax.com> |
| In reply to | #71595 |
On Fri, 02 Oct 2015 10:53:36 GMT, raltbos@xs4all.nl (Richard Bos) wrote: >Robert Wessel <robertwessel2@yahoo.com> wrote: > >> On Tue, 29 Sep 2015 11:54:19 -0700 (PDT), supercat@casperkitty.com >> wrote: >> >> >On the flip side, code which needs to guarantee the ability to round-trip >> >decimal representations may only be able to do so for nine-digit ones, >> >since the smallest value greater than 8.0000000037 would be 8.0000000074. >> >> But that's not what the standard requires - the standard requires a >> round trip from decimal, to FP, and back to decimal, not >> FP-Decimal-FP. > >Is it even possible to guarantee both? Either one or the other I can >see, but both at the same time would run into difficulties. I can't see how, unless both bases are decimal(-ish) (which makes the discussion moot). In no cases are the number of values covered the same for any possible pairs of lengths, so the intermediate format always needs to be we a wider type than for initial and final formats. So for A->B->A we need B to be (equal or) wider than A, and for B->A->B we need A to be (equal or) wider than B. And the equal case can't happen with different bases (at least those that are not a simple power of one or another - for instance base 10 and base 100).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 16:46 -0700 |
| Message-ID | <kfn612m6vu6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71595 |
raltbos@xs4all.nl (Richard Bos) writes: > Robert Wessel <robertwessel2@yahoo.com> wrote: > >> On Tue, 29 Sep 2015 11:54:19 -0700 (PDT), supercat@casperkitty.com >> wrote: >> >>> On the flip side, code which needs to guarantee the ability to round-trip >>> decimal representations may only be able to do so for nine-digit ones, >>> since the smallest value greater than 8.0000000037 would be 8.0000000074. >> >> But that's not what the standard requires - the standard requires a >> round trip from decimal, to FP, and back to decimal, not >> FP-Decimal-FP. > > Is it even possible to guarantee both? Either one or the other I can > see, but both at the same time would run into difficulties. Actually both directions have requirements, but the values for the two directions have different names (and may have different values). Compare DBL_DIG and DBL_DECIMAL_DIG in C11. Note that it is possible for the two directions to have the same value, which probably implies base 10 as the radix. The minimum values for DBL_DIG and DBL_DECIMAL_DIG are both 10.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-28 14:23 -0700 |
| Message-ID | <lnh9me44s9.fsf@kst-u.example.com> |
| In reply to | #71384 |
Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> Since DBL_DIG is required not required to be more than 10, the upper
> bound on that is about (10*10-1), or bit over 33 bits worth. It is,
> however, unclear to me that having a DBL_DIG of 10 is actually
> sufficient to require that all integers 1..(10*10-1) are representable
> exactly. For conventional FP systems that would seem to be the case,
> but FP formats with non-integer bases, for example, you might have
> very few integers that have an exact representation.
C's floating-point model doesn't seem to permit non-integer bases.
N1570 5.2.4.2.2 specifies the parameters of a floating-point
type. One of them, called "b", is the "base or radix of exponent
representation (an integer > 1)". This is specified in <float.h>
as FLT_RADIX (which in the same for all floating-point types).
There just might be enough wiggle rooom to permit non-integer bases.
A footnote says:
The floating-point model is intended to clarify the description
of each floating-point characteristic and does not require the
floating-point arithmetic of the implementation to be identical.
and I see no specific wording requiring FLT_RADIX to be an integer.
It is required to expand to a constant expression, but that could
be, say, 2.5, or 2.71828.
But I presume the *intent* is that FLT_RADIX must be an integer;
otherwise there's not much point in requiring it to be at least 2.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-28 16:52 -0500 |
| Message-ID | <sidj0b5qt5v5qt43dp3i8u47hgugtvt0a1@4ax.com> |
| In reply to | #71393 |
On Mon, 28 Sep 2015 14:23:18 -0700, Keith Thompson <kst-u@mib.org> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: >[...] >> Since DBL_DIG is required not required to be more than 10, the upper >> bound on that is about (10*10-1), or bit over 33 bits worth. It is, >> however, unclear to me that having a DBL_DIG of 10 is actually >> sufficient to require that all integers 1..(10*10-1) are representable >> exactly. For conventional FP systems that would seem to be the case, >> but FP formats with non-integer bases, for example, you might have >> very few integers that have an exact representation. > >C's floating-point model doesn't seem to permit non-integer bases. >N1570 5.2.4.2.2 specifies the parameters of a floating-point >type. One of them, called "b", is the "base or radix of exponent >representation (an integer > 1)". This is specified in <float.h> >as FLT_RADIX (which in the same for all floating-point types). > >There just might be enough wiggle rooom to permit non-integer bases. >A footnote says: > > The floating-point model is intended to clarify the description > of each floating-point characteristic and does not require the > floating-point arithmetic of the implementation to be identical. > >and I see no specific wording requiring FLT_RADIX to be an integer. >It is required to expand to a constant expression, but that could >be, say, 2.5, or 2.71828. > >But I presume the *intent* is that FLT_RADIX must be an integer; >otherwise there's not much point in requiring it to be at least 2. OTOH, a base less than two on a machine built of binary bits would be pretty silly.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-30 01:39 -0700 |
| Message-ID | <kfnr3lgb8sw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71393 |
Keith Thompson <kst-u@mib.org> writes: > Robert Wessel <robertwessel2@yahoo.com> writes: > [...] >> Since DBL_DIG is required not required to be more than 10, the upper >> bound on that is about (10*10-1), or bit over 33 bits worth. It is, >> however, unclear to me that having a DBL_DIG of 10 is actually >> sufficient to require that all integers 1..(10*10-1) are representable >> exactly. For conventional FP systems that would seem to be the case, >> but FP formats with non-integer bases, for example, you might have >> very few integers that have an exact representation. > > C's floating-point model doesn't seem to permit non-integer bases. > N1570 5.2.4.2.2 specifies the parameters of a floating-point > type. One of them, called "b", is the "base or radix of exponent > representation (an integer > 1)". This is specified in <float.h> > as FLT_RADIX (which in the same for all floating-point types). > > There just might be enough wiggle rooom to permit non-integer bases. > A footnote says: > > The floating-point model is intended to clarify the description > of each floating-point characteristic and does not require the > floating-point arithmetic of the implementation to be identical. > > and I see no specific wording requiring FLT_RADIX to be an integer. > It is required to expand to a constant expression, but that could > be, say, 2.5, or 2.71828. > > But I presume the *intent* is that FLT_RADIX must be an integer; > otherwise there's not much point in requiring it to be at least 2. I believe FLT_RADIX is the exponent of the model used to report the results, not necessarily what is used in the implementation. Indeed what is used in the implementation may not have a value that corresponds to the value 'b' in the floating-point model. For example, what is stored could be the log of a value rather than the value itself (which would allow multiplications and divisions to be done by addition). Certainly if FLT_RADIX is the model value for 'b' then FLT_RADIX is an integer.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web