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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-30 06:27 -0700 |
| Message-ID | <238cf128-9367-4638-94ce-a77c951cd0eb@googlegroups.com> |
| In reply to | #71470 |
On Wednesday, September 30, 2015 at 4:49:30 AM UTC-5, Tim Rentsch wrote: > I read about this somewhere. I think it was a DR but may > have been discussion from one of the meetings, I don't > remember exactly where. The intent was (and is, AFAIK) > to allow non-standard representations to be used, within > certain limits; in particular there is an expectation > that zero must be representable exactly. IIRC an example > was mentioned using a logarithmic encoding. So AFAIK the > intent was not to preclude non-integer bases (among many > other possibilities). Another possibility might be having a bi-quinary base, which could e.g. represent values: 1.00000000 to 2.49999999 (15000000 values) 2.50000000 to 9.99999995 (15000000 values) 10.0000000 to 24.9999999 (15000000 values) 25.0000000 to 99.9999995 (15000000 values) etc. Although this would make the effect of reaching rounding boundaries less consistent (half would cause a five-fold drop in precision and half would cause a two-fold drop), the effective loss of precision upon reaching 2.5 would be less than the loss of precision in a pure-decimal system upon reaching 10.0.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-29 10:43 -0700 |
| Message-ID | <kfnzj05azol.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71390 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 09/28/2015 01:59 PM, Richard Heathfield wrote:
> ...
>> 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.
>
> From 5.2.4.2.2p2, "A floating-point number (x) is defined by the
> following model:
> x = s*b^e * (the sum from k=1 to p of (f_k * b^(-k)) )"
>
> [Note: the model actually given relies upon sub-scripts, super-scripts,
> one greek letter, and three levels of printing, none of which are
> guaranteed to display meaningfully in a usenet message. I've therefore
> taken the liberty of re-writing it to avoid those problems, without
> changing the underlying meaning. f_k corresponds to 'k' being a
> subscript of f, b^e corresponds to pow(b,e), and I've converted a
> three-level sigma symbol into English words.]
>
> For any given x, you can represent x+1 by increasing f_e by 1 - if the
> result is b, then replace it by 0 and carry on to the next digit. But
> you can only do this only if f_e exists. Therefore, the smallest
> positive (so s==1) integer x such that x+1 can't be represented has
> e==p+1, f_0==1, and f_k==0 for all other values of k. That number has
> the value 1*b^(p+1)*1*b^(-1), or simply b^p.
>
> 5.2.4.2.2p13 says that DBL_EPSILON == b^(1-p) == FLT_RADIX/(b^p).
> Therefore, the number you're looking for is FLT_RADIX/DBL_EPSILON. The
> smallest permitted value for FLT_RADIX is 2; the largest permitted value
> of DBL_EPSILON is 1e-9, so the number you're looking for can't be
> smaller than 2e9. You can get exactly that limit using p=1, b=2e9. That
> would require 31 bits to store the significand, and only 3 bits for the
> exponent, with e_min==-3 and e_max=4, so it would fit in 35 bits. b=2^31
> would make more efficient use of that amount of space.
>
> I can't vouch for the accuracy of the above analysis - I'm too error
> prone; but if it is in error, it should at least be correctable to give
> the right answer.
It's easy to see that this result cannot be right. The Standard
requires each of the mathematical values
0.1000000000
0.1000000001
0.1000000002
...
0.9999999999
to have the property that it can be converted to a floating-point
(double) value and back again, and get the same digits out.
There are 9e9 such values. Furthermore the same is true for each
power of ten between 1e37 and 1e-36, which is an additional
factor of 74, and for the negatives of those, which is another
factor of 2. Each of these mathematical values must correspond to
a distinct bit pattern in a (double) value. That puts a lower
bound on the number of bits needed, namely,
log2( 2 * 74 * 9e9 )
which is approximately
40.2767312210575241
There also must be values for zero, 1e37, and -1e37, giving a
just slightly higher lower bound
log2( 2 * 74 * 9e9 + 3 )
which is approximately
40.2767312210607713
or, rounding up, 41 bits. This result can be achieved in a
conforming implementation of double by using, eg, an encoding
like the one I described for a bit-efficient decimal format.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-28 22:51 +0000 |
| Message-ID | <mucg9j$ufm$1@speranza.aioe.org> |
| In reply to | #71380 |
Richard Heathfield <rjh@cpax.org.uk> wrote: > On 28/09/15 18:33, Keith Thompson wrote: (snip) >> 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. (snip) > 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? If DBL_DIG is 10, it should be 9999999999. > 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. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-30 02:11 -0700 |
| Message-ID | <kfnmvw4b7ax.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71380 |
Richard Heathfield <rjh@cpax.org.uk> writes: > 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? In some theoretical sense ISO C doesn't require floating-point to be able to represent any positive integer values exactly (except perhaps a handful of small values, with 1 being the most obvious example). I remember reading somewhere (was it a DR?) that the intention is that zero be representable exactly. More practically, for any implementation that uses a representation like the floating-point model described in the Standard, which all existing implementations do (and with high probability all future implementations will), the answer is 10,000,000,000.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-28 22:48 +0000 |
| Message-ID | <mucg3n$tv0$1@speranza.aioe.org> |
| In reply to | #71378 |
Keith Thompson <kst-u@mib.org> wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: (snip on bits for float and double) >> 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. > 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. For radix 2, yes. For large radix, fewer exponent bits are needed. > 10 decimal digits is about 33 bits, so double needs to be about 41 > bits or more. For radix 10, 33.3 for this significand, 6.2 for a biased exponent, and also sign bit, so, yes, it fits in 41. (Or two in 81.) > 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. Well, you didn't count the sign bit, but I think it still fits in 41. I believe there are, or have been, machines with 48 bit floating point, none as far as I know with 41. 36 used to be somewhat more common. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-28 22:03 -0500 |
| Message-ID | <hovj0b10qhtdnik7ktkfec7smsfm60m1fc@4ax.com> |
| In reply to | #71402 |
On Mon, 28 Sep 2015 22:48:23 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Keith Thompson <kst-u@mib.org> wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: > >(snip on bits for float and double) > >>> 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. > >> 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. > >For radix 2, yes. For large radix, fewer exponent bits are needed. > >> 10 decimal digits is about 33 bits, so double needs to be about 41 >> bits or more. > >For radix 10, 33.3 for this significand, 6.2 for a biased exponent, >and also sign bit, so, yes, it fits in 41. (Or two in 81.) > >> 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. > >Well, you didn't count the sign bit, but I think it still fits in 41. > >I believe there are, or have been, machines with 48 bit floating point, >none as far as I know with 41. 36 used to be somewhat more common. Some of the Burroughs machines (6700 family) had 48-bit FP. While I don't know anyone who did 41 bits, Some of the early 8-bit micros (for example the Apple II), did a 40-bit FP format in software.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-30 01:13 -0700 |
| Message-ID | <kfnvbasba05.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71378 |
Keith Thompson <kst-u@mib.org> writes: > 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. > > 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. The end results are close to right. How the calculation is done is off in a couple of ways. The calculation for the exponent size assumes a binary base. If a binary base is used, that means 21 bits and 35 bits for float and double respectively, which by taking advantange of a "hidden bit" can be reduced to 20 and 34 bits. For the exponent, you left out half the exponent range. The range needs to cover 1e-37 to 1e37, which for a binary exponent is just under 2**246, or 8 exponent bits. So if a binary base is used, float needs 29 bits (20 + 8 + 1), and double 43 bits (34 + 8 + 1). If a decimal base is used, along with a compact encoding, these numbers go down to 28 bits and 41 bits respectively, fortuitously exactly the same as the results you got. Note the 21 and 35 numbers above follow from the formula shown in the Standard for FLT_DIG and DBL_DIG.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-30 17:06 +0100 |
| Message-ID | <muh162$rq5$1@dont-email.me> |
| In reply to | #71366 |
On 28/09/2015 11:35, Richard Heathfield wrote: > On 28/09/15 10:22, Bartc wrote: >> 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. Yes, floats are generally 32 bits. But what about doubles? >> And >> even if it did say it, what is the likelihood of any C implementation on >> an actual computer (not some micro-controller) not giving you a 64-bit >> floating point type? > > I have no idea. I don't generally concern myself with data type sizes, > because they vary between platforms, so I find it easier to work only > within the guarantees provided by the Standard. What would you do in this situation: you have an application that runs on x86 processors (which was used by a big chunk of the world's desktop computers at one point; perhaps it still is). And a client that is demanding 64-bit floating point precision [which actually happened to me]. You've chosen to program in C; what are you going to do: tell the client what he wants is not guaranteed by the language so it is not possible? Or rewrite the entire application in a language where that guarantee is made? Even though every known C implementation for that platform, including the one you're using, also makes use of IEEE 64-bit floating point format. >> If we all took into account that double might only be 32-bits, then what >> is the point of having 64-bit doubles? > > Analogy: some bridges on the main UK road network can't take the strain > of any vehicle with a laden weight greater than 7.5 tonnes. If you need > to be able to cross any bridge, you need to keep the weight down. But if > you're happy to stick to the more robust bridges (which, let's face it, > is most of them), then you can carry heavier loads. So it's all about > just how badly you need to be able to do your work *everywhere*. > > If portability is not a concern, there is no need to be concerned about > portability. (Until, of course, the situation changes, by which time > it's probably too late.) A closer analogy is that some UK roads aren't metalled and aren't suitable for the ordinary family car that everyone has (ie. 64-bit floating point). But the vast majority are. We're not talking any any specialist requirements here, such as 1024-bit floating point; 64-bit is mainstream. It can also be emulated on most processors. If a C implementation hasn't got it, then complain or choose a different one. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-09-30 17:26 +0100 |
| Message-ID | <muh2c3$qj$1@dont-email.me> |
| In reply to | #71487 |
On 30/09/15 17:06, Bartc wrote: > On 28/09/2015 11:35, Richard Heathfield wrote: >> On 28/09/15 10:22, Bartc wrote: > >>> 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. > > Yes, floats are generally 32 bits. But what about doubles? Others have provided evidence that doubles need at least forty-something bits, of which at least 34 (I think it was) must be available for the intended purpose - and we have already seen that this isn't enough. > >>> And >>> even if it did say it, what is the likelihood of any C implementation on >>> an actual computer (not some micro-controller) not giving you a 64-bit >>> floating point type? >> >> I have no idea. I don't generally concern myself with data type sizes, >> because they vary between platforms, so I find it easier to work only >> within the guarantees provided by the Standard. > > What would you do in this situation: you have an application that runs > on x86 processors (which was used by a big chunk of the world's desktop > computers at one point; perhaps it still is). And a client that is > demanding 64-bit floating point precision [which actually happened to me]. I'd give the client 64-bit floating point precision. This seems to have nothing to do with what we were talking about. > You've chosen to program in C; what are you going to do: tell the client > what he wants is not guaranteed by the language so it is not possible? No, but neither would I say that floating point is a great way to express penny amounts. > Or rewrite the entire application in a language where that guarantee is > made? Even though every known C implementation for that platform, > including the one you're using, also makes use of IEEE 64-bit floating > point format. <shrug> I don't dispute that 64-bit floating point is widely available. I dispute that floating point is a good way to store penny amounts (or, to be more general, large integer values whose precise value is important). Try doing RSA in floating point and see how far you get. >>> If we all took into account that double might only be 32-bits, then what >>> is the point of having 64-bit doubles? >> >> Analogy: some bridges on the main UK road network can't take the strain >> of any vehicle with a laden weight greater than 7.5 tonnes. If you need >> to be able to cross any bridge, you need to keep the weight down. But if >> you're happy to stick to the more robust bridges (which, let's face it, >> is most of them), then you can carry heavier loads. So it's all about >> just how badly you need to be able to do your work *everywhere*. >> >> If portability is not a concern, there is no need to be concerned about >> portability. (Until, of course, the situation changes, by which time >> it's probably too late.) > > A closer analogy is that some UK roads aren't metalled and aren't > suitable for the ordinary family car that everyone has (ie. 64-bit > floating point). But the vast majority are. Sure. That still doesn't make it a good idea to store penny amounts in floating point. > We're not talking any any specialist requirements here, such as 1024-bit > floating point; 64-bit is mainstream. It can also be emulated on most > processors. If a C implementation hasn't got it, then complain or choose > a different one. You seem to be suggesting that I should take action if the implementation I am using doesn't have a double large enough to store something that would be better stored in an integer type anyway. Call me Mr Lazy, but rather than complain or change my implementation I'd find it quicker and easier to use integer types (including a big-integer library if need be) to store integers than to either bother complaining to a vendor who isn't going to listen to me or change to an implementation where I would /still/ end up using integer types for storing integers. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-30 13:04 -0700 |
| Message-ID | <lnoagj3c95.fsf@kst-u.example.com> |
| In reply to | #71487 |
Bartc <bc@freeuk.com> writes:
[...]
> What would you do in this situation: you have an application that runs
> on x86 processors (which was used by a big chunk of the world's desktop
> computers at one point; perhaps it still is). And a client that is
> demanding 64-bit floating point precision [which actually happened to me].
(Richard answered this, but I'll answer it too.)
If the requirement is specifically for 64-bit floating-point, I'd
probably do something like:
int main(int argc, char **argv) {
if (sizeof (double) * CHAR_BIT != 64) {
fprintf(stderr, "Sorry, double is not 64 bits\n");
exit(EXIT_FAILURE);
}
/* Do the actual work here */
}
The error probably won't be triggered on any x86 system. If it is,
I'd have to look into alternatives, perhaps resorting to long double
(though that's not guaranteed to be wider than double).
This assumes the client wants *exactly* 64 bits; change "!=" to "<" if
he'd be satisfied with more than 64 bits.
If the requirements are stated in terms of range and precision, I can do
the check at compile time, using the macros defined in <float.h>. (The
preprocessor doesn't know about `sizeof`.)
If, as is more likely, the client actually wants IEEE (IEC 60559)
floating-point arithmetic, it's a bit easier:
#ifndef __STDC_IEC_559__
#error "IEC 559 is not supported"
#endif
which guarantees that the type double matches the IEC 60559 double
format.
> You've chosen to program in C; what are you going to do: tell the client
> what he wants is not guaranteed by the language so it is not possible?
If the client insists on 100% portable C code, that's exactly what
I'd tell him. If the client is willing to pay for a software IEEE
implementation written in 100% portable C, I might try to talk him
out of it because it's unlikely to be worth the effort -- but it's
possible that's what the customer really needs. (There are probably
existing software implementations out there; I haven't checked.)
If he merely wants 64-bit IEEE floating-point for some particular set of
platforms, or even just one, I wouldn't bother mentioning that it's not
guaranteed by the language, because that wouldn't be relevant.
[...]
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-28 09:12 +0000 |
| Message-ID | <mub0a1$6sj$1@speranza.aioe.org> |
| In reply to | #71360 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: (snip, someone wrote) >> Floating point is fine for roll-up calcs when you only have to be >> accurate to within (roughly) a millionth of a pound, but it's hopeless >> for keeping exact track of pennies. If a long int can't handle the >> amounts involved (or, if you're posh and up-to-date, a long long int), >> then you need bigger integers. Libraries exist that give you bigger >> integers, or you can of course roll your own. > That's because you've been seduced by the idea that one dollar ten cents > must be represented a 1.10. Represent as 110 cents instead. 2^53 > gives us 90 trillion dollars - uncomfortably close to Obama's > credit card amount outstanding. But if he borrows more than 90 trillon > dollars, the number just loses a bit of accuracy. OK, but if you are going to use 64 bits, might as well use them in the form of a 64 bit integer instead of a 53 bit integer. Many machiines now directly do 64 bit arithmetic, but before that it wasn't all that hard to do add, subtract, multiply with a 64 bit product, or divide a 64 bit dividend. > OK a fraudster can then maybe siphon off a thousand dollars > or so from the American national accounts, but that's not a > disaster in the big scheme of things. -- glen
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-28 12:28 +0200 |
| Message-ID | <mub4ko$g2$1@dont-email.me> |
| In reply to | #71340 |
On 28/09/15 03:23, Malcolm McLean wrote: > On Thursday, September 24, 2015 at 11:09:44 AM UTC+1, Ben Bacarisse wrote: >> >> Much C is written with a hidden assumption that int is 32 bits (so >> uint32_t won't promote), or that integer overflow is harmless in that it >> will "wrap round" as so many processors now do. >> I think supercat makes some good points. C has all sorts of annoyances >> that make writing fast portable code hard, and he or she is clearly not >> just another of the "C should define everything like Java does" posters >> that pop up with such regularity. >> > The vast majority of integers in most programs are indices, > array sizes, or intermediate values used to calculate indices. I thought that was complete nonsense last time you made this claim with no evidence, and I still think it is complete nonsense. And even if it were true - and that a mere 0.1% of all integers used in C was for something other than calculating indices, you still need a good selection of integer types for those 0.1% uses - because it is those uses that make the computing world go round. > Data is real if it represents a measurement of something in > the physical world - not inherently so, it's just that most things > we measure are continuous, and even things we count we tend to > express as averages or percentage changes. If the data represents > a human to human message, it's text. The major exception I can > think of is data the represents amounts of money, really you > need a currency type, especially because such data is likely to > be attractive to criminals. > > (A scaled integer is, almost always, another representation of > a real number. This point caused a lot of confusion a while ago.) > > So essentially the solution to the integer / overflow problem > is to have a type that can index any array, and that traps on > overflow conditions, because overflow has to represent either a > coding bug, an attack, or a dataset too large for the program to > handle. In all of those cases, you want to terminate the currently- > executing function. > > Then you've got a few cases like hashing where you do need defined > width types. And very low level routines where the integers are > really flags which manipulate attached hardware. They're relatively > rare, the fixed width types should be held back for special use. > >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-28 20:44 +0100 |
| Message-ID | <87612ue3cr.fsf@bsb.me.uk> |
| In reply to | #71340 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, September 24, 2015 at 11:09:44 AM UTC+1, Ben Bacarisse wrote: >> >> Much C is written with a hidden assumption that int is 32 bits (so >> uint32_t won't promote), or that integer overflow is harmless in that it >> will "wrap round" as so many processors now do. >> I think supercat makes some good points. C has all sorts of annoyances >> that make writing fast portable code hard, and he or she is clearly not >> just another of the "C should define everything like Java does" posters >> that pop up with such regularity. >> > The vast majority of integers in most programs are indices, > array sizes, or intermediate values used to calculate indices. <snip> > So essentially the solution to the integer / overflow problem > is to have a type that can index any array, and that traps on > overflow conditions, because overflow has to represent either a > coding bug, an attack, or a dataset too large for the program to > handle. It's not clear if you are talking about C or about programming in general here. If you are making a non-C point, I would agree, but I'd amend the remark to say that what is wanted in many programming contexts is an integer type that either traps on overflow or does not overflow at all (as in, say, Haskell). And I don't think how many integers are being used as indexes matters much -- the key is the number of integer operations where an overflow is an error (a point you make about indexes overflowing but it's really more general than that). Of course you need non-trapping types (or operations) as well, but we all agree on that. But if you are talking about C, I think that boat has sailed. C can only permit and not require a trap on overflow because so much hardware (well, Intel, mainly) does not provide hardware support for it. Programmers use C, in part, to avoid the costs that the types used by some higher-level languages impose. It's possible that some future C could mandate access to an overflow flag. I wonder how many implementations would find that hard or costly? > In all of those cases, you want to terminate the currently- > executing function. That seems a little prescriptive. > Then you've got a few cases like hashing where you do need defined > width types. I think you mean types (or operations) that wrap without overflow. The definedness of the type's width is not really the issue, only what happens when the range is exceeded. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-01 01:39 -0700 |
| Message-ID | <bb4e2fb6-56c9-4c53-a2d9-51dcc9733972@googlegroups.com> |
| In reply to | #71391 |
On Monday, September 28, 2015 at 8:44:18 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > It's possible that some future C could mandate access to an overflow > flag. I wonder how many implementations would find that hard or costly? > You'd do it gently. You'd recommend that implementations behave thus. Then you make it mandatory to have a compiler option to switch the behaviour on. Then you'd make it mandatory to have that behaviour the default (allowing a switch off). Processor design would gradually catch up. > > > In all of those cases, you want to terminate the currently- > > executing function. > > That seems a little prescriptive. > Not really. If you're about to index an array out of bounds, it's almost better for someone to switch you to error-handling code than to go ahead and do it. > > > Then you've got a few cases like hashing where you do need defined > > width types. > > I think you mean types (or operations) that wrap without overflow. The > definedness of the type's width is not really the issue, only what > happens when the range is exceeded. > If you need a 64 bit hash, you need to know that long long is at least 64 bits (or write it in a very fiddly and inefficient way). You also need to know that bytes are 8 bits, as a rule. You can of course AND instead of using the overflow as a free modulus.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-01 08:55 -0700 |
| Message-ID | <lnfv1u37nw.fsf@kst-u.example.com> |
| In reply to | #71528 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, September 28, 2015 at 8:44:18 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> It's possible that some future C could mandate access to an overflow
>> flag. I wonder how many implementations would find that hard or costly?
>>
> You'd do it gently. You'd recommend that implementations behave
> thus. Then you make it mandatory to have a compiler option to
> switch the behaviour on. Then you'd make it mandatory to have that
> behaviour the default (allowing a switch off). Processor design
> would gradually catch up.
Having the standard require a compiler option would be unprecedented, as
would mandating a default behavior. Most compilers don't even conform
to the standard by default, and the standard has nothing to say about
non-conforming implementations beyond the fact that they're
non-conforming.
A more consistent way to do this would be to introduce an optional
feature, with a predefined macro that indicates whether that features
is implemented. Some compilers could provide a compile-time option
that enables or disables the feature; others could just enable or
disable it.
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-01 09:02 -0700 |
| Message-ID | <a73b4d15-47e4-48e1-b586-1a7caa459627@googlegroups.com> |
| In reply to | #71528 |
On Thursday, October 1, 2015 at 3:40:18 AM UTC-5, Malcolm McLean wrote: > On Monday, September 28, 2015 at 8:44:18 PM UTC+1, Ben Bacarisse wrote: > > It's possible that some future C could mandate access to an overflow > > flag. I wonder how many implementations would find that hard or costly? > > > You'd do it gently. You'd recommend that implementations behave > thus. Then you make it mandatory to have a compiler option to > switch the behaviour on. Then you'd make it mandatory to have that > behaviour the default (allowing a switch off). Processor design > would gradually catch up. The approach I would like to see would be to have standardized macros that would say, in essence, "for XXX behavior that would otherwise be implementation-defined or undefined, I need the compiler to do YYY", with a requirement that every compiler must either do YYY or refuse compilation; the syntax should be designed in such a way that existing compilers which would *naturally* do Y could be made to compile the code merely be adding a header file which defines macros suitably. Taking such an approach would make it possible to write a fairly simple utility which, given a collection of C files, could produce a machine- readable specification which could then be run against a database of compilers, and identify which compilers would be capable of correctly handling those C files. For compilers which (as is common) allow options to be controlled by command-line switches (e.g. -fwrapv), such an approach would also provide a standardized means by which programs that require e.g. wrapping-integer-overflow semantics could refuse compilation when switches are set incorrectly, rather than yielding code that compiles cleanly but will malfunction badly at runtime. For overflow, the prescribable behavior I'd like to see would be something a little bit like a "try-catch" block [implemented using macros in such a way that compilers could ignore it if needed] with the semantics that a compiler could set the error flag and jump to the fault-handling block *at any time within a controlled section* if a computation within that block would overflow *in such a way as to yield a numerically-inaccurate result* The compiler would be required to set an overflow flag if overflow caused a wrong result, and could exit the controlled block immediately in such a case, but would not be required to do so (on some processors, jumping to an overflow handling routine which sets a flag may be cheaper than setting a flag but continuing execution, but on others the reverse would be true). Consider, for example, a program which is supposed to compute the 32-bit sum of a bunch of 32-bit numbers, report the result if there is no overflow, report an error if the arithmetically-correct result is not representable, and arbitrarily report the correct result or an error in cases where computations done purely with 32-bit integers would have overflowed, but the arithmetically-correct result is nonetheless known. On many 32-bit systems, using a "jump-on-overflow" to an error routine would be the simplest way to meet those requirements; requiring that code result loop execution after setting an error flag would make things less efficient. In a 64-bit system, however, it may be fastest to perform the computation using a 64-bit register and then simply check at the end whether it is within 32-bit integer range. A major key to optimization is to have things specified in the loosest possible way *that still meets requirements*. If what is necessary is that the program never do anything other than report an arithmetically- correct result or an error, and there are cases in which either course of action would be equally valid, being able to write code that lets the compiler decide which approach is more "convenient" in various cases will allow more optimization opportunities than writing code whose behavior is *rigidly* defined in all cases.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-01 14:55 -0700 |
| Message-ID | <1df728fa-313d-4c20-a60f-cbb966d4498f@googlegroups.com> |
| In reply to | #71545 |
On Thursday, October 1, 2015 at 5:02:29 PM UTC+1, supe...@casperkitty.com wrote: > Consider, for example, a program which is supposed to compute the 32-bit > sum of a bunch of 32-bit numbers, report the result if there is no overflow, > report an error if the arithmetically-correct result is not representable, > and arbitrarily report the correct result or an error in cases where > computations done purely with 32-bit integers would have overflowed, but > the arithmetically-correct result is nonetheless known. > But, to give a real example, a bit of code I'm working on at the moment uses a pathfinding algorithm to trace a path through an image intended for human viewing. It then scores the path based on a penalty for each cell, the numbers not going above about 50. Now, pretty clearly, images intended for human viewing and manipulated on desktop systems don't go above 4000 pixels a side. And any path longer than about five times the straight line distance is going to be thrown out by other logic. So the highest value we can get is 4000 * 5 * 50, or a million, and that's a generous estimate. 32 bits is perfectly safe. But there's no way an automated optimiser can arrive at that conclusion. Width and height are of course read in (plug for my tiff file loader, has anyone actually found it useful?). And for all it knows, the path might loop endlessly. If the value does overflow, then of course it means either a corrupt cell value or an infinite loop.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-01 16:48 -0700 |
| Message-ID | <615eb73d-e13a-41c8-a150-a7838cd7e2f0@googlegroups.com> |
| In reply to | #71573 |
On Thursday, October 1, 2015 at 4:55:59 PM UTC-5, Malcolm McLean wrote:
> But there's no way an automated optimiser can arrive at that conclusion.
> Width and height are of course read in (plug for my tiff file loader,
> has anyone actually found it useful?). And for all it knows, the
> path might loop endlessly.
IMHO, efforts to facilitate optimization would be far better targeted at
defining means by which programmers can tell compilers what they know about
the inputs a program will receive, than by trying to have compilers draw
inferences based upon Undefined Behavior.
I would like, for example, to see a concept of "checked assumptions" which
would basically instruct a compiler that if the assumptions are violated it
may trap immediately and thereafter not have to deal with inputs that would
violate the assumption, but it would not be required to trap in cases where
the cost of the trap would receive the benefit of any optimizations enabled
thereby.
If, for example, one is allowed to report an error if any input value is
exceeds +/- 5000, a smart compiler producing machine code for a platform
where branches are expensive, which was informed that it could arbitrarily
report or not report errors when n was outside the indicate range, might
optimize the code as something like:
int32_t local_sum;
int64_t global_sum;
uint32_t bit_or, inner_ct,outer_ct;
global_sum = 0; bit_or = 0;
inner_ct=n & 262143; outer_ct = n >> 18;
while (outer_ct-- > 0)
{
local_sum = 0;
while(inner_ct-- > 0)
{
int temp = *p++;
bit_or |= (temp + 8192u); // Cheaper constant than 5000 on some CPUs
local_sum += temp;
}
inner = 65536;
global_sum += temp;
}
// Result will be correct if bit_or is less than 16384.
No branches at all for any overflow condition, and only a minimal amount of
64-bit math, but the code would be guaranteed to yield arithmetically
correct results in every case where all inputs were in range, and report an
error in every case where the final result was not arithmetically-correct,
without invoking Undefined Behavior for any combination of input values.
Informing the compiler about the range of values would let it determine how
much it could safely unroll the loop; letting the compiler figure out such
things seems nicer than making programmers guess.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-02 11:46 +0000 |
| Message-ID | <560e6e67.10088203@news.xs4all.nl> |
| In reply to | #71573 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > But, to give a real example, a bit of code I'm working on at the moment > uses a pathfinding algorithm to trace a path through an image intended > for human viewing. It then scores the path based on a penalty for > each cell, the numbers not going above about 50. > Now, pretty clearly, images intended for human viewing and manipulated > on desktop systems don't go above 4000 pixels a side. And any path > longer than about five times the straight line distance is going to > be thrown out by other logic. So the highest value we can get is 4000 > * 5 * 50, or a million, and that's a generous estimate. 32 bits is > perfectly safe. What happens if your input file has got corrupted? Or if someone accidentally feeds the program the wrong file entirely? Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-06 00:15 -0700 |
| Message-ID | <81d49b6c-17ba-4399-9410-116b06d30ed0@googlegroups.com> |
| In reply to | #71598 |
On Friday, October 2, 2015 at 12:46:44 PM UTC+1, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > But, to give a real example, a bit of code I'm working on at the moment > > uses a pathfinding algorithm to trace a path through an image intended > > for human viewing. It then scores the path based on a penalty for > > each cell, the numbers not going above about 50. > > Now, pretty clearly, images intended for human viewing and manipulated > > on desktop systems don't go above 4000 pixels a side. And any path > > longer than about five times the straight line distance is going to > > be thrown out by other logic. So the highest value we can get is 4000 > > * 5 * 50, or a million, and that's a generous estimate. 32 bits is > > perfectly safe. > > What happens if your input file has got corrupted? Or if someone > accidentally feeds the program the wrong file entirely? > Garbage in, garbage out. You could construct an image that is one pixel high by millions of pixels wide, and of course the path finding algorithm would sum the penalties of each pixel, until eventually a 32 bit int overflowed. It would then decide that the single possible path was the cheapest one, and report it. If you allowed 2 pixels wide, you'd probably get the wrong path, as you've then got several alternative paths which would be pruned badly as the total penalties flowed over and became negative. A really good compiler would of course detect arithmetical overflow and terminate the function, but that's rare.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web