Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #17207 > unrolled thread
| Started by | Alex Vinokur <alex.vinokur@gmail.com> |
|---|---|
| First post | 2012-02-13 04:41 -0800 |
| Last post | 2012-02-13 12:14 -0800 |
| Articles | 20 on this page of 73 — 19 participants |
Back to article view | Back to comp.lang.c
C/C++ pitfalls related to 64-bits (unsigned long & double) Alex Vinokur <alex.vinokur@gmail.com> - 2012-02-13 04:41 -0800
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Leigh Johnston <leigh@i42.co.uk> - 2012-02-13 12:49 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Alex Vinokur <alex.vinokur@gmail.com> - 2012-02-13 04:59 -0800
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Leigh Johnston <leigh@i42.co.uk> - 2012-02-13 13:07 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Goran <goran.pusic@gmail.com> - 2012-02-13 04:54 -0800
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Alex Vinokur <alex.vinokur@gmail.com> - 2012-02-13 05:00 -0800
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 13:27 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Goran <goran.pusic@gmail.com> - 2012-02-13 07:14 -0800
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-13 08:14 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-13 08:17 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-13 21:52 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) James Kuyper <jameskuyper@verizon.net> - 2012-02-13 17:08 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-13 20:44 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 13:16 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 11:18 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-13 15:18 -0600
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) James Kuyper <jameskuyper@verizon.net> - 2012-02-13 16:26 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-13 16:05 -0600
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) James Kuyper <jameskuyper@verizon.net> - 2012-02-13 17:13 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 23:35 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 17:25 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-14 01:45 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 18:55 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Miles Bader <miles@gnu.org> - 2012-02-14 11:51 +0900
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-14 03:13 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 20:39 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Miles Bader <miles@gnu.org> - 2012-02-14 13:25 +0900
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 23:22 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-14 02:56 -0600
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-14 09:13 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-14 11:16 -0600
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-14 12:27 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-13 23:04 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Miles Bader <miles@gnu.org> - 2012-02-14 14:00 +0900
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Robert Wessel <robertwessel2@yahoo.com> - 2012-02-14 00:45 -0600
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-14 14:22 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Robert Wessel <robertwessel2@yahoo.com> - 2012-02-14 13:06 -0600
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-14 12:40 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) James Kuyper <jameskuyper@verizon.net> - 2012-02-13 23:05 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Miles Bader <miles@gnu.org> - 2012-02-14 14:01 +0900
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Keith Thompson <kst-u@mib.org> - 2012-02-14 03:01 -0800
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-02-14 12:53 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) James Kuyper <jameskuyper@verizon.net> - 2012-02-14 14:39 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) jgk@panix.com (Joe keane) - 2012-02-14 20:45 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-14 22:57 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Keith Thompson <kst-u@mib.org> - 2012-02-14 15:38 -0800
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-15 00:22 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Robert Wessel <robertwessel2@yahoo.com> - 2012-02-15 00:39 -0600
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-15 08:00 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 22:00 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 17:04 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-13 16:15 -0800
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-14 00:46 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 18:31 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 18:41 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-14 02:33 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 20:20 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-14 03:26 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 20:49 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Robert Wessel <robertwessel2@yahoo.com> - 2012-02-14 00:24 -0600
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-13 23:42 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) James Kuyper <jameskuyper@verizon.net> - 2012-02-14 06:48 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-14 13:51 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-14 08:42 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-14 19:58 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-14 14:27 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) BGB <cr88192@hotmail.com> - 2012-02-14 09:10 -0700
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-14 20:02 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Noob <root@127.0.0.1> - 2012-02-13 15:22 +0100
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) legalize+jeeves@mail.xmission.com (Richard) - 2012-02-13 18:49 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) James Kuyper <jameskuyper@verizon.net> - 2012-02-13 13:55 -0500
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Juha Nieminen <nospam@thanks.invalid> - 2012-02-13 19:14 +0000
Re: C/C++ pitfalls related to 64-bits (unsigned long & double) Barry Schwarz <schwarzb@dqel.com> - 2012-02-13 12:14 -0800
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-02-13 17:25 -0700 |
| Message-ID | <jhc9n6$8ni$1@news.albasani.net> |
| In reply to | #17262 |
On 2/13/2012 4:35 PM, Ben Bacarisse wrote:
> James Kuyper<jameskuyper@verizon.net> writes:
>
>> On 02/13/2012 05:05 PM, MikeWhy wrote:
>>> James Kuyper wrote:
>>>> On 02/13/2012 04:18 PM, MikeWhy wrote:
>>>>> BGB wrote:
>>>>>> ... even though double has more bits than, say, an integer, does not
>>>>>> mean it will reliably encode an integer's value (it can do so in
>>>>>> theory, and will most often do so, but whether or not it will
>>>>>> actually always do so is more "up for grabs").
>> ...
>>> documented for the architecture in numeric_limits. Still wondering here
>>> about the "up for grabs" part. It seems to imply some edge condition that
>>> isn't accounted for.
>>
>> It sounds to me like he's not sure how to detect situations where the
>> conversion would be unsafe.
>
> That's not how I took it. I think the condition "even though double has
> more bits than, say, an integer" is meant to suggest that exact
> conversion is possible. Of course, that's not a literal consequence of
> double having more bits (it must have a nearly equal number of mantissa
> bits) but it's the only way I could make sense of "it can do so in
> theory". All such things are guesses, of course, so I anticipate being
> wrong.
>
as I understand it, the entire range of 32 bit integers can be exactly
represented by a double.
theoretically, it should be a matter of sticking the bits into the
mantissa and adjusting the exponent as needed (so that the value is
normalized).
the issue is that, assuming my memory is correct, I had seen systems
where it didn't always work, but it was more like "once in a great
while", rather than the conversion being consistently wrong.
this wasn't being an issue with large values either, but more like a
value of "1000" would occasionally end up as "999" and similar, but it
did seem to always tend towards 0, so it wasn't like it was getting
"1001" or similar.
IIRC, when measuring, it was typically off by a tiny amount.
I am not certain whether or not any arithmetic was being performed on
the values.
what I remember about the configuration I saw it on:
Linux x86-64 (Fedora 11 IIRC), compiling with GCC;
CPU: AMD Athlon X2 (I forget which core).
at the time I was also compiling for Win64 ("Windows XP x64") using
MSVC, but did not see the issue with this configuration.
IIRC, there was a difference, namely that GCC was doing conversions
directly using "cvtsi2sd" and "cvtsd2si", whereas MSVC was doing the
conversion via internal function calls (this particular difference
seemed fairly common between GCC and MSVC, where GCC would typically
directly use math instructions, but MSVC would call functions to do
stuff like this, even with compiler optimizations turned on).
but, this is not to say my memory is being entirely accurate though (all
this was several years ago).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-02-14 01:45 +0000 |
| Message-ID | <0.a4992fde206ad25190a0.20120214014547GMT.8739ae427o.fsf@bsb.me.uk> |
| In reply to | #17267 |
BGB <cr88192@hotmail.com> writes: > On 2/13/2012 4:35 PM, Ben Bacarisse wrote: >> James Kuyper<jameskuyper@verizon.net> writes: >> >>> On 02/13/2012 05:05 PM, MikeWhy wrote: >>>> James Kuyper wrote: >>>>> On 02/13/2012 04:18 PM, MikeWhy wrote: >>>>>> BGB wrote: >>>>>>> ... even though double has more bits than, say, an integer, does not >>>>>>> mean it will reliably encode an integer's value (it can do so in >>>>>>> theory, and will most often do so, but whether or not it will >>>>>>> actually always do so is more "up for grabs"). >>> ... >>>> documented for the architecture in numeric_limits. Still wondering here >>>> about the "up for grabs" part. It seems to imply some edge condition that >>>> isn't accounted for. >>> >>> It sounds to me like he's not sure how to detect situations where the >>> conversion would be unsafe. >> >> That's not how I took it. I think the condition "even though double has >> more bits than, say, an integer" is meant to suggest that exact >> conversion is possible. Of course, that's not a literal consequence of >> double having more bits (it must have a nearly equal number of mantissa >> bits) but it's the only way I could make sense of "it can do so in >> theory". All such things are guesses, of course, so I anticipate being >> wrong. >> > > as I understand it, the entire range of 32 bit integers can be exactly > represented by a double. In the architecture in question, yes. > theoretically, it should be a matter of sticking the bits into the > mantissa and adjusting the exponent as needed (so that the value is > normalized). > > the issue is that, assuming my memory is correct, I had seen systems > where it didn't always work, but it was more like "once in a great > while", rather than the conversion being consistently wrong. > > this wasn't being an issue with large values either, but more like a > value of "1000" would occasionally end up as "999" and similar, but it > did seem to always tend towards 0, so it wasn't like it was getting > "1001" or similar. It would seem you are talking about a hardware bug. I'd say it was one if it weren't for the fact that you are sure you recall correctly. Had it been me, I'd have documented it. You can get famous for finding Intel floating points bugs! Maybe it's not too late (see my other post). Can you recall which part of the round-trip was going wrong? Did cvtsi2sd turn 1000 into something less that 1000 or did cvtsd2si turn 1000 into 999? > IIRC, when measuring, it was typically off by a tiny amount. > I am not certain whether or not any arithmetic was being performed on > the values. Oh, if there might have been arithmetic being done, how do you know the conversion was not being done as it should? Maybe the arithmetic was rounding in some way you did not expect? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-02-13 18:55 -0700 |
| Message-ID | <jhcf13$6jj$1@news.albasani.net> |
| In reply to | #17274 |
On 2/13/2012 6:45 PM, Ben Bacarisse wrote: > BGB<cr88192@hotmail.com> writes: > >> On 2/13/2012 4:35 PM, Ben Bacarisse wrote: >>> James Kuyper<jameskuyper@verizon.net> writes: >>> >>>> On 02/13/2012 05:05 PM, MikeWhy wrote: >>>>> James Kuyper wrote: >>>>>> On 02/13/2012 04:18 PM, MikeWhy wrote: >>>>>>> BGB wrote: >>>>>>>> ... even though double has more bits than, say, an integer, does not >>>>>>>> mean it will reliably encode an integer's value (it can do so in >>>>>>>> theory, and will most often do so, but whether or not it will >>>>>>>> actually always do so is more "up for grabs"). >>>> ... >>>>> documented for the architecture in numeric_limits. Still wondering here >>>>> about the "up for grabs" part. It seems to imply some edge condition that >>>>> isn't accounted for. >>>> >>>> It sounds to me like he's not sure how to detect situations where the >>>> conversion would be unsafe. >>> >>> That's not how I took it. I think the condition "even though double has >>> more bits than, say, an integer" is meant to suggest that exact >>> conversion is possible. Of course, that's not a literal consequence of >>> double having more bits (it must have a nearly equal number of mantissa >>> bits) but it's the only way I could make sense of "it can do so in >>> theory". All such things are guesses, of course, so I anticipate being >>> wrong. >>> >> >> as I understand it, the entire range of 32 bit integers can be exactly >> represented by a double. > > In the architecture in question, yes. > >> theoretically, it should be a matter of sticking the bits into the >> mantissa and adjusting the exponent as needed (so that the value is >> normalized). >> >> the issue is that, assuming my memory is correct, I had seen systems >> where it didn't always work, but it was more like "once in a great >> while", rather than the conversion being consistently wrong. >> >> this wasn't being an issue with large values either, but more like a >> value of "1000" would occasionally end up as "999" and similar, but it >> did seem to always tend towards 0, so it wasn't like it was getting >> "1001" or similar. > > It would seem you are talking about a hardware bug. I'd say it was one > if it weren't for the fact that you are sure you recall correctly. > > Had it been me, I'd have documented it. You can get famous for finding > Intel floating points bugs! Maybe it's not too late (see my other > post). > > Can you recall which part of the round-trip was going wrong? Did > cvtsi2sd turn 1000 into something less that 1000 or did cvtsd2si turn > 1000 into 999? > I don't remember, I think my thoughts at the time were "well, I am getting values which are off by a tiny amount, oh well, I will fudge it". it was a situation roughly along the lines of integers being converted to doubles, maybe having arithmetic done on them (mostly still with integer values), and converted back to integers later. since it was off by a tiny amount, I just added code to fix it. >> IIRC, when measuring, it was typically off by a tiny amount. >> I am not certain whether or not any arithmetic was being performed on >> the values. > > Oh, if there might have been arithmetic being done, how do you know the > conversion was not being done as it should? Maybe the arithmetic was > rounding in some way you did not expect? > it is possible, in my test elsewhere, it seems I can only really recreate the issue if a value is added and then subtracted again from the same value (in double form). so, this may not be a conversion bug, but more of an "integer arithmetic with doubles isn't exact" issue (leads to values ever slightly smaller than what they would need to be). fudging it does fix the problem, which was either-way, the original intent of the "add a tiny amount to fudge it to the correct value" kludge (I was not worried about the exact cause of the inexactness, I just added something to compensate for it). theoretically, the epsilon could probably be a bit smaller though...
[toc] | [prev] | [next] | [standalone]
| From | Miles Bader <miles@gnu.org> |
|---|---|
| Date | 2012-02-14 11:51 +0900 |
| Message-ID | <87obt23z6c.fsf@catnip.gol.com> |
| In reply to | #17275 |
BGB <cr88192@hotmail.com> writes: > so, this may not be a conversion bug, but more of an "integer > arithmetic with doubles isn't exact" issue (leads to values ever > slightly smaller than what they would need to be). Integer arithmetic with doubles _is_ exact though, if the integers can be exactly-represented as doubles (which appears to be the case here). -miles -- Custard, n. A vile concoction produced by a malevolent conspiracy of the hen, the cow, and the cook.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-02-14 03:13 +0000 |
| Message-ID | <0.9d64e8e9e6d753cd2d95.20120214031313GMT.87r4xy2jli.fsf@bsb.me.uk> |
| In reply to | #17278 |
Miles Bader <miles@gnu.org> writes: > BGB <cr88192@hotmail.com> writes: >> so, this may not be a conversion bug, but more of an "integer >> arithmetic with doubles isn't exact" issue (leads to values ever >> slightly smaller than what they would need to be). > > Integer arithmetic with doubles _is_ exact though, if the integers can > be exactly-represented as doubles (which appears to be the case here). I agree it should be, but is it a bug if it isn't? IEEE floating-point mandates that the results of the basic arithmetic operators be exactly rounded (i.e. the result is the closest representable number to the mathematical result) but maybe the hardware in question does not claim to conform to the IEEE spec. Neither C nor C++ require such accuracy on their own (though an implementation can claim to be using IEEE conforming floating-point) so it's not a bug as far as the language is concerned either. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-02-13 20:39 -0700 |
| Message-ID | <jhcl3k$huq$1@news.albasani.net> |
| In reply to | #17278 |
On 2/13/2012 7:51 PM, Miles Bader wrote: > BGB<cr88192@hotmail.com> writes: >> so, this may not be a conversion bug, but more of an "integer >> arithmetic with doubles isn't exact" issue (leads to values ever >> slightly smaller than what they would need to be). > > Integer arithmetic with doubles _is_ exact though, if the integers can > be exactly-represented as doubles (which appears to be the case here). > yes. the issue may be partly a matter of HW though, as I am seeing it on my HW (using an AMD chip), but apparently someone else is not seeing it (with an Intel chip), but there does seem to be a pattern in the values (apparently: 0x4, 0x40, 0x400, 0x4000, ..., so for whatever reason integer results which should land on one of these values is off by a tiny amount...). it could be a minor issue of the "arithmetic with doubles may not be exact even if the doubles represent integers" variety, which is odd, but whatever (it can be compensated for by fudging the value). in theory though, these sorts of calculations should probably be exact. > -miles >
[toc] | [prev] | [next] | [standalone]
| From | Miles Bader <miles@gnu.org> |
|---|---|
| Date | 2012-02-14 13:25 +0900 |
| Message-ID | <buod39i59dt.fsf@dhlpc061.dev.necel.com> |
| In reply to | #17282 |
BGB <cr88192@hotmail.com> writes: >> Integer arithmetic with doubles _is_ exact though, if the integers can >> be exactly-represented as doubles (which appears to be the case here). > > yes. > > the issue may be partly a matter of HW though, as I am seeing it on my > HW (using an AMD chip), but apparently someone else is not seeing it > (with an Intel chip), but there does seem to be a pattern in the values > (apparently: 0x4, 0x40, 0x400, 0x4000, ..., so for whatever reason > integer results which should land on one of these values is off by a > tiny amount...). Any conventional PC-type system these days is going to use IEEE FP, and if the system claims to support IEEE FP, it has to be exact. If it isn't, it's a bug. I did run your program on my AMD system (phenom I), and it showed no output. It would be interesting to see somebody with an identical CPU to yours try it... > it could be a minor issue of the "arithmetic with doubles may not be > exact even if the doubles represent integers" variety, which is odd, but > whatever (it can be compensated for by fudging the value). I'm not sure you could call it a minor issue. A lot of software assumes that FP arithmetic is exact for integer values within a certain range, and isn't going to do any fudging (because it shouldn't be necessary, and would have a severe performance impact), so such a system where fudging is necessary would have ... problems. -miles -- Clarionet, n. An instrument of torture operated by a person with cotton in his ears. There are two instruments that are worse than a clarionet -- two clarionets.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-02-13 23:22 -0700 |
| Message-ID | <jhcuke$41l$1@news.albasani.net> |
| In reply to | #17286 |
On 2/13/2012 9:25 PM, Miles Bader wrote: > BGB<cr88192@hotmail.com> writes: >>> Integer arithmetic with doubles _is_ exact though, if the integers can >>> be exactly-represented as doubles (which appears to be the case here). >> >> yes. >> >> the issue may be partly a matter of HW though, as I am seeing it on my >> HW (using an AMD chip), but apparently someone else is not seeing it >> (with an Intel chip), but there does seem to be a pattern in the values >> (apparently: 0x4, 0x40, 0x400, 0x4000, ..., so for whatever reason >> integer results which should land on one of these values is off by a >> tiny amount...). > > Any conventional PC-type system these days is going to use IEEE FP, > and if the system claims to support IEEE FP, it has to be exact. If > it isn't, it's a bug. > > I did run your program on my AMD system (phenom I), and it showed no > output. It would be interesting to see somebody with an identical CPU > to yours try it... > I don't know. in the past, the issue seemed specific to Linux x86-64 (and SSE), but I am also currently getting the same results from a 32-bit Windows program (using the x87 FPU, compiled with GCC). testing with MSVC, the results slightly are different (only 4 different values show up), but the basic issue is still present. >> it could be a minor issue of the "arithmetic with doubles may not be >> exact even if the doubles represent integers" variety, which is odd, but >> whatever (it can be compensated for by fudging the value). > > I'm not sure you could call it a minor issue. A lot of software > assumes that FP arithmetic is exact for integer values within a > certain range, and isn't going to do any fudging (because it shouldn't > be necessary, and would have a severe performance impact), so such a > system where fudging is necessary would have ... problems. > potentially, yes. however, other than this, the computer seems to work fine (nothing is obviously acting buggy or crashing...).
[toc] | [prev] | [next] | [standalone]
| From | "MikeWhy" <boat042-nospam@yahoo.com> |
|---|---|
| Date | 2012-02-14 02:56 -0600 |
| Message-ID | <jhd7j6$k21$1@dont-email.me> |
| In reply to | #17290 |
BGB wrote: > On 2/13/2012 9:25 PM, Miles Bader wrote: >> BGB<cr88192@hotmail.com> writes: >>>> Integer arithmetic with doubles _is_ exact though, if the integers >>>> can be exactly-represented as doubles (which appears to be the >>>> case here). >>> >>> yes. >>> >>> the issue may be partly a matter of HW though, as I am seeing it on >>> my HW (using an AMD chip), but apparently someone else is not >>> seeing it (with an Intel chip), but there does seem to be a pattern >>> in the values (apparently: 0x4, 0x40, 0x400, 0x4000, ..., so for >>> whatever reason integer results which should land on one of these >>> values is off by a tiny amount...). >> >> Any conventional PC-type system these days is going to use IEEE FP, >> and if the system claims to support IEEE FP, it has to be exact. If >> it isn't, it's a bug. >> >> I did run your program on my AMD system (phenom I), and it showed no >> output. It would be interesting to see somebody with an identical >> CPU to yours try it... >> > > I don't know. > > in the past, the issue seemed specific to Linux x86-64 (and SSE), but > I am also currently getting the same results from a 32-bit Windows > program (using the x87 FPU, compiled with GCC). > > testing with MSVC, the results slightly are different (only 4 > different values show up), but the basic issue is still present. The MSVC warnings are rather explicit: "... possible loss of data". 'initializing' : truncation from 'const uint_64' to 'const double' 'initializing' : conversion from 'const double' to 'const uint_64', possible loss of data Z:\Foo>fooFP.exe sizeof(uint_64) ==> 8 std::numeric_limits<double>::digits = 53 std::numeric_limits<uint_64>::digits = 64 (18446744073709551615 == 9223372036854775808) ==> false (18446744073709551615 == 9223372036854775808) ==> false On gcc: mikey@boatVPM-Linux:~/Foo$ g++ --version g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. mikey@boatVPM-Linux:~/Foo$ g++ -std=c++0x -Wall -pedantic fooFP.cpp fooFP.cpp: In function âint main()â: fooFP.cpp:21:30: warning: overflow in implicit constant conversion [-Woverflow] mikey@boatVPM-Linux:~/Foo$ ./a.out sizeof(uint_64) ==> 8 std::numeric_limits<double>::digits = 53 std::numeric_limits<uint_64>::digits = 64 (18446744073709551615 == 0) ==> false (18446744073709551615 == 18446744073709551615) ==> true mikey@boatVPM-Linux:~/Foo$ The first case was similar to what you had written it. The second case used 'const uint_64' and const double as hints to the compiler. gcc actually managed to get the second case right. I don't know what MSVC was thinking. The integer value evaluated to (2^64 - 1) as expected. Converting back to ULL from double produced 2^63. It apparently stored 1/2 * 2^64 as the FP value, which is a surprising conversion (but still within the definition of undefined behavior). > however, other than this, the computer seems to work fine (nothing is > obviously acting buggy or crashing...). ??!! It's a coding error. The compiler recognized the error and printed diagnostics, warning about truncation or overflow in the conversion. Comparing std::numeric_limits<double>::digits against std::numeric_limits<unsigned long long>::digits makes clear the nature of the problem.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-02-14 09:13 -0700 |
| Message-ID | <jhe19u$fi7$1@news.albasani.net> |
| In reply to | #17297 |
On 2/14/2012 1:56 AM, MikeWhy wrote: > BGB wrote: >> On 2/13/2012 9:25 PM, Miles Bader wrote: >>> BGB<cr88192@hotmail.com> writes: >>>>> Integer arithmetic with doubles _is_ exact though, if the integers >>>>> can be exactly-represented as doubles (which appears to be the >>>>> case here). >>>> >>>> yes. >>>> >>>> the issue may be partly a matter of HW though, as I am seeing it on >>>> my HW (using an AMD chip), but apparently someone else is not >>>> seeing it (with an Intel chip), but there does seem to be a pattern >>>> in the values (apparently: 0x4, 0x40, 0x400, 0x4000, ..., so for >>>> whatever reason integer results which should land on one of these >>>> values is off by a tiny amount...). >>> >>> Any conventional PC-type system these days is going to use IEEE FP, >>> and if the system claims to support IEEE FP, it has to be exact. If >>> it isn't, it's a bug. >>> >>> I did run your program on my AMD system (phenom I), and it showed no >>> output. It would be interesting to see somebody with an identical >>> CPU to yours try it... >>> >> >> I don't know. >> >> in the past, the issue seemed specific to Linux x86-64 (and SSE), but >> I am also currently getting the same results from a 32-bit Windows >> program (using the x87 FPU, compiled with GCC). >> >> testing with MSVC, the results slightly are different (only 4 >> different values show up), but the basic issue is still present. > > The MSVC warnings are rather explicit: > "... possible loss of data". > 'initializing' : truncation from 'const uint_64' to 'const double' > 'initializing' : conversion from 'const double' to 'const uint_64', > possible loss of data > you sure we are talking about the same piece of code?... my example wasn't using any "uint_64", just a plain "int" type (which is 32 bits). > Z:\Foo>fooFP.exe > sizeof(uint_64) ==> 8 > std::numeric_limits<double>::digits = 53 > std::numeric_limits<uint_64>::digits = 64 > (18446744073709551615 == 9223372036854775808) ==> false > (18446744073709551615 == 9223372036854775808) ==> false > > On gcc: > > mikey@boatVPM-Linux:~/Foo$ g++ --version > g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 > Copyright (C) 2011 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > mikey@boatVPM-Linux:~/Foo$ g++ -std=c++0x -Wall -pedantic fooFP.cpp > fooFP.cpp: In function âint main()â: > fooFP.cpp:21:30: warning: overflow in implicit constant conversion > [-Woverflow] > mikey@boatVPM-Linux:~/Foo$ ./a.out > sizeof(uint_64) ==> 8 > std::numeric_limits<double>::digits = 53 > std::numeric_limits<uint_64>::digits = 64 > (18446744073709551615 == 0) ==> false > (18446744073709551615 == 18446744073709551615) ==> true > mikey@boatVPM-Linux:~/Foo$ > > The first case was similar to what you had written it. The second case > used 'const uint_64' and const double as hints to the compiler. gcc > actually managed to get the second case right. I don't know what MSVC > was thinking. The integer value evaluated to (2^64 - 1) as expected. > Converting back to ULL from double produced 2^63. It apparently stored > 1/2 * 2^64 as the FP value, which is a surprising conversion (but still > within the definition of undefined behavior). > >> however, other than this, the computer seems to work fine (nothing is >> obviously acting buggy or crashing...). > > ??!! It's a coding error. The compiler recognized the error and printed > diagnostics, warning about truncation or overflow in the conversion. > Comparing std::numeric_limits<double>::digits against > std::numeric_limits<unsigned long long>::digits makes clear the nature > of the problem. > >
[toc] | [prev] | [next] | [standalone]
| From | "MikeWhy" <boat042-nospam@yahoo.com> |
|---|---|
| Date | 2012-02-14 11:16 -0600 |
| Message-ID | <jhe4sr$bo9$1@dont-email.me> |
| In reply to | #17314 |
"BGB" <cr88192@hotmail.com> wrote in message
news:jhe19u$fi7$1@news.albasani.net...
> On 2/14/2012 1:56 AM, MikeWhy wrote:
>> The MSVC warnings are rather explicit:
>> "... possible loss of data".
>> 'initializing' : truncation from 'const uint_64' to 'const double'
>> 'initializing' : conversion from 'const double' to 'const uint_64',
>> possible loss of data
>>
>
> you sure we are talking about the same piece of code?...
> my example wasn't using any "uint_64", just a plain "int" type (which is
> 32 bits).
No, I'm not sure at all. At some point, the conversation turned it into
64-bit unsigned, possibly only in my head.
Both gcc and MSVC get this right:
const int_64 ifoo = -1LL;
{
double foox = ifoo;
uint_64 foo2 = foox;
std::cout << '(' << (uint_64)ifoo << " == " << foo2 << ") ==> "
<< ((uint_64)ifoo == foo2 ? "true" : "false")
<< '\n';
}
... but, both get the following wrong:
{
uint_64 foo = ifoo;
double foox = foo;
uint_64 foo2 = foox;
std::cout << '(' << foo << " == " << foo2 << ") ==> "
<< (foo == foo2 ? "true" : "false")
<< '\n';
}
gcc: (18446744073709551615 == 0) ==> false
MSVC: (18446744073709551615 == 9223372036854775808) ==> false
... and gcc gets it right if the values are marked const:
{
const uint_64 foo = ifoo;
const double foox = foo;
const uint_64 foo2 = foox;
std::cout << '(' << foo << " == " << foo2 << ") ==> "
<< (foo == foo2 ? "true" : "false")
<< '\n';
}
gcc: (18446744073709551615 == 18446744073709551615) ==> true
MSVC: (18446744073709551615 == 9223372036854775808) ==> false
gcc apparently keeps enough precision for the const double initializer
value, possibly as a long double. MSVC obviously does not.
All the same, both compilers print diagnostics about signed/unsigned
mismatches; possible loss of data in conversions; truncation/overflow in
conversion.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-02-14 12:27 -0700 |
| Message-ID | <jhecl0$89k$1@news.albasani.net> |
| In reply to | #17316 |
On 2/14/2012 10:16 AM, MikeWhy wrote:
>
> "BGB" <cr88192@hotmail.com> wrote in message
> news:jhe19u$fi7$1@news.albasani.net...
>> On 2/14/2012 1:56 AM, MikeWhy wrote:
>>> The MSVC warnings are rather explicit:
>>> "... possible loss of data".
>>> 'initializing' : truncation from 'const uint_64' to 'const double'
>>> 'initializing' : conversion from 'const double' to 'const uint_64',
>>> possible loss of data
>>>
>>
>> you sure we are talking about the same piece of code?...
>> my example wasn't using any "uint_64", just a plain "int" type (which
>> is 32 bits).
>
> No, I'm not sure at all. At some point, the conversation turned it into
> 64-bit unsigned, possibly only in my head.
>
fair enough, we were talking about different pieces of code with
different behaviors (the "64-bit unsigned" was from a different part of
the thread).
> Both gcc and MSVC get this right:
>
> const int_64 ifoo = -1LL;
> {
> double foox = ifoo;
> uint_64 foo2 = foox;
>
> std::cout << '(' << (uint_64)ifoo << " == " << foo2 << ") ==> "
> << ((uint_64)ifoo == foo2 ? "true" : "false")
> << '\n';
> }
>
> ... but, both get the following wrong:
> {
> uint_64 foo = ifoo;
> double foox = foo;
> uint_64 foo2 = foox;
>
> std::cout << '(' << foo << " == " << foo2 << ") ==> "
> << (foo == foo2 ? "true" : "false")
> << '\n';
> }
>
> gcc: (18446744073709551615 == 0) ==> false
> MSVC: (18446744073709551615 == 9223372036854775808) ==> false
>
> ... and gcc gets it right if the values are marked const:
> {
> const uint_64 foo = ifoo;
> const double foox = foo;
> const uint_64 foo2 = foox;
>
> std::cout << '(' << foo << " == " << foo2 << ") ==> "
> << (foo == foo2 ? "true" : "false")
> << '\n';
> }
>
> gcc: (18446744073709551615 == 18446744073709551615) ==> true
> MSVC: (18446744073709551615 == 9223372036854775808) ==> false
>
> gcc apparently keeps enough precision for the const double initializer
> value, possibly as a long double. MSVC obviously does not.
>
> All the same, both compilers print diagnostics about signed/unsigned
> mismatches; possible loss of data in conversions; truncation/overflow in
> conversion.
>
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Date | 2012-02-13 23:04 -0500 |
| Message-ID | <jhcmg8$j1j$1@dont-email.me> |
| In reply to | #17278 |
On 2/13/2012 9:51 PM, Miles Bader wrote:
> BGB<cr88192@hotmail.com> writes:
>> so, this may not be a conversion bug, but more of an "integer
>> arithmetic with doubles isn't exact" issue (leads to values ever
>> slightly smaller than what they would need to be).
>
> Integer arithmetic with doubles _is_ exact though, if the integers can
> be exactly-represented as doubles (which appears to be the case here).
C doesn't actually guarantee this. It guarantees exact
conversion to an F-P type for all values the type can represent
exactly (for example, 42 must convert to exactly 42.0, not to
42.0000000000000010173 or some such), but it does not guarantee
that 42.0 (exact) plus 1.0 (exact) equals 43.0 (exact).
5.2.4.2.2p4: "The accuracy of the floating-point
operations (+, -, *, /) [...] is implementation-
defined. The implementation may state that the
accuracy is unknown."
C implementations that define __STDC_IEC_559__ provide
additional guarantees that may make your statement true -- for
those implementations. But as far as I can tell, it is not a
guarantee for C with "J. Random Floating-Point."
--
Eric Sosman
esosman@ieee-dot-org.invalid
[toc] | [prev] | [next] | [standalone]
| From | Miles Bader <miles@gnu.org> |
|---|---|
| Date | 2012-02-14 14:00 +0900 |
| Message-ID | <buopqdi3t6o.fsf@dhlpc061.dev.necel.com> |
| In reply to | #17284 |
Eric Sosman <esosman@ieee-dot-org.invalid> writes: >> Integer arithmetic with doubles _is_ exact though, if the integers can >> be exactly-represented as doubles (which appears to be the case here). > > C doesn't actually guarantee this. It guarantees exact > conversion to an F-P type for all values the type can represent > exactly (for example, 42 must convert to exactly 42.0, not to > 42.0000000000000010173 or some such), but it does not guarantee > that 42.0 (exact) plus 1.0 (exact) equals 43.0 (exact). Not C, but C-on-a-system-using-IEEE-FP, which is basically everything mainstream. [In practice it's a pretty good bet that even wackier FP hardware actually maintains the same constraint.] Although C-the-language hedges its bets for extreme portability (and to some degree, history: things were a lot more wild-n-wooly when C was created), people writing the actual applications tend to be a bit more practical, and _do_ assume things that aren't guaranteed by the language, if the likelihood of that assumption being violated is infinitesimal. I think this is a reasonable stance where the cost of not making such assumptions is non-trivial. -miles -- XML is like violence. If it doesn't solve your problem, you're not using enough of it.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-02-14 00:45 -0600 |
| Message-ID | <0hvjj7p2gtbcf3bvuv720v5aa4k32vulko@4ax.com> |
| In reply to | #17287 |
On Tue, 14 Feb 2012 14:00:47 +0900, Miles Bader <miles@gnu.org> wrote: >Eric Sosman <esosman@ieee-dot-org.invalid> writes: >>> Integer arithmetic with doubles _is_ exact though, if the integers can >>> be exactly-represented as doubles (which appears to be the case here). >> >> C doesn't actually guarantee this. It guarantees exact >> conversion to an F-P type for all values the type can represent >> exactly (for example, 42 must convert to exactly 42.0, not to >> 42.0000000000000010173 or some such), but it does not guarantee >> that 42.0 (exact) plus 1.0 (exact) equals 43.0 (exact). > >Not C, but C-on-a-system-using-IEEE-FP, which is basically everything >mainstream. [In practice it's a pretty good bet that even wackier FP >hardware actually maintains the same constraint.] Apparently you never tried to multiply or divide on any early Crays. ;-) Multiplication could be off by a full ULP. So products that exactly filled all 48 bits with significant bits often produced slightly odd results. The divides tended to curdle the low few bits of the quotient. And there were definitely divisions where the dividend, divisor and quotient all had exact representations, but the quotient was a several ULPs off. The basic problem was that division was implemented with the usual reciprocal approximation (hardware) and an iteration of Newton-Raphson (software). That produced a bit less than 47 bits of precision. In a float with a 48 bit mantissa. An extra iteration of N-R wouldn't have helped, since rounding was definitely odd on the Cray, and multiplication had issues in those bit ranges too. It's been said that numerical analysis on the early Crays was a full contact sport.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-02-14 14:22 +0000 |
| Message-ID | <jhdqn1$8n3$1@speranza.aioe.org> |
| In reply to | #17294 |
In comp.lang.c++ Robert Wessel <robertwessel2@yahoo.com> wrote: (snip, someone wrote) >>Not C, but C-on-a-system-using-IEEE-FP, which is basically everything >>mainstream. [In practice it's a pretty good bet that even wackier FP >>hardware actually maintains the same constraint.] > Apparently you never tried to multiply or divide on any early Crays. > ;-) > Multiplication could be off by a full ULP. So products that exactly > filled all 48 bits with significant bits often produced slightly odd > results. Is that also the one with the non-commutative multiplication? -- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-02-14 13:06 -0600 |
| Message-ID | <83clj7pbhu5qaupdcun6t8cf50hpi1j6mj@4ax.com> |
| In reply to | #17309 |
On Tue, 14 Feb 2012 14:22:25 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >In comp.lang.c++ Robert Wessel <robertwessel2@yahoo.com> wrote: > >(snip, someone wrote) >>>Not C, but C-on-a-system-using-IEEE-FP, which is basically everything >>>mainstream. [In practice it's a pretty good bet that even wackier FP >>>hardware actually maintains the same constraint.] > >> Apparently you never tried to multiply or divide on any early Crays. >> ;-) > >> Multiplication could be off by a full ULP. So products that exactly >> filled all 48 bits with significant bits often produced slightly odd >> results. > >Is that also the one with the non-commutative multiplication? Yep. Reverse the operands, get a different "round off" error.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-02-14 12:40 -0700 |
| Message-ID | <jhedde$9s9$1@news.albasani.net> |
| In reply to | #17321 |
On 2/14/2012 12:06 PM, Robert Wessel wrote: > On Tue, 14 Feb 2012 14:22:25 +0000 (UTC), glen herrmannsfeldt > <gah@ugcs.caltech.edu> wrote: > >> In comp.lang.c++ Robert Wessel<robertwessel2@yahoo.com> wrote: >> >> (snip, someone wrote) >>>> Not C, but C-on-a-system-using-IEEE-FP, which is basically everything >>>> mainstream. [In practice it's a pretty good bet that even wackier FP >>>> hardware actually maintains the same constraint.] >> >>> Apparently you never tried to multiply or divide on any early Crays. >>> ;-) >> >>> Multiplication could be off by a full ULP. So products that exactly >>> filled all 48 bits with significant bits often produced slightly odd >>> results. >> >> Is that also the one with the non-commutative multiplication? > > > Yep. Reverse the operands, get a different "round off" error. seems like fun... also reminds me of a tricks used to implement fixed-point multiplies: if the intermediate result wont fit in the word, shift one or both of the arguments right some to make the result smaller. this was a way to do fast/simple fixed point math without needing a larger register to hold the intermediate results, but would also cost some in terms of accuracy. makes me wonder if maybe Cray was doing something similar?... (say, essentially just discarding low-order bits from the operands in an uneven manner?).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-02-13 23:05 -0500 |
| Message-ID | <jhcmip$gq1$1@dont-email.me> |
| In reply to | #17278 |
On 02/13/2012 09:51 PM, Miles Bader wrote: > BGB <cr88192@hotmail.com> writes: >> so, this may not be a conversion bug, but more of an "integer >> arithmetic with doubles isn't exact" issue (leads to values ever >> slightly smaller than what they would need to be). > > Integer arithmetic with doubles _is_ exact though, if the integers can > be exactly-represented as doubles ... For IEEE double precision, 2^100 and 1 are both exactly representable, so is the result of multiplying or dividing them, but their sum and difference are not exactly representable. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Miles Bader <miles@gnu.org> |
|---|---|
| Date | 2012-02-14 14:01 +0900 |
| Message-ID | <buohayu3t5l.fsf@dhlpc061.dev.necel.com> |
| In reply to | #17285 |
James Kuyper <jameskuyper@verizon.net> writes: >>> so, this may not be a conversion bug, but more of an "integer >>> arithmetic with doubles isn't exact" issue (leads to values ever >>> slightly smaller than what they would need to be). >> >> Integer arithmetic with doubles _is_ exact though, if the integers can >> be exactly-represented as doubles ... > > For IEEE double precision, 2^100 and 1 are both exactly representable, > so is the result of multiplying or dividing them, but their sum and > difference are not exactly representable. Well "the integers" should include the answer of course! -miles -- Accordion, n. An instrument in harmony with the sentiments of an assassin.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web