Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #17207 > unrolled thread

C/C++ pitfalls related to 64-bits (unsigned long & double)

Back to article view | Back to comp.lang.c

Contents

  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 1 of 4  [1] 2 3 4  Next page →

#17207 — C/C++ pitfalls related to 64-bits (unsigned long & double)

Hi,

unsigned long a = -1;
double b = a;
unsigned long c = b;

Model 32-bits:   a == c
Model 64-bits:   a != c


It is not a compiler bug for 64-bits.

Is it a design bug of C/C++ languge for 64-bits?

Alex

[toc] | [next] | [standalone]

#17208

On 13/02/2012 12:41, Alex Vinokur wrote:
> Hi,
>
> unsigned long a = -1;
> double b = a;
> unsigned long c = b;
>
> Model 32-bits:   a == c
> Model 64-bits:   a != c
>
>
> It is not a compiler bug for 64-bits.
>
> Is it a design bug of C/C++ languge for 64-bits?

No.

a == c for both "32-bits" and "64-bits" on my compiler (VC9).

/Leigh

[toc] | [prev] | [next] | [standalone]

#17212

On Feb 13, 2:49 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 13/02/2012 12:41, Alex Vinokur wrote:
>
> > Hi,
>
> > unsigned long a = -1;
> > double b = a;
> > unsigned long c = b;
>
> > Model 32-bits:   a == c
> > Model 64-bits:   a != c
>
> > It is not a compiler bug for 64-bits.
>
> > Is it a design bug of C/C++ languge for 64-bits?
>
> No.
>
> a == c for both "32-bits" and "64-bits" on my compiler (VC9).
>
> /Leigh

aCC: HP C/aC++ B3910B A.06.25.01 [May 16 2010]
For 64-bits:
a = 0xffffffffffffffff
c = 0x8000000000000000

Intel(R) C++ Intel(R) 64 Compiler XE for applications running on
Intel(R) 64, Version 12.0.4.191 Build 20110427
For 64-bits:
a = 0xffffffffffffffff
c = 0

[toc] | [prev] | [next] | [standalone]

#17216

On 13/02/2012 12:59, Alex Vinokur wrote:
> On Feb 13, 2:49 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 13/02/2012 12:41, Alex Vinokur wrote:
>>
>>> Hi,
>>
>>> unsigned long a = -1;
>>> double b = a;
>>> unsigned long c = b;
>>
>>> Model 32-bits:   a == c
>>> Model 64-bits:   a != c
>>
>>> It is not a compiler bug for 64-bits.
>>
>>> Is it a design bug of C/C++ languge for 64-bits?
>>
>> No.
>>
>> a == c for both "32-bits" and "64-bits" on my compiler (VC9).
>>
>> /Leigh
>
> aCC: HP C/aC++ B3910B A.06.25.01 [May 16 2010]
> For 64-bits:
> a = 0xffffffffffffffff
> c = 0x8000000000000000
>
> Intel(R) C++ Intel(R) 64 Compiler XE for applications running on
> Intel(R) 64, Version 12.0.4.191 Build 20110427
> For 64-bits:
> a = 0xffffffffffffffff
> c = 0

Well it seems obvious that that won't work if 'sizeof(unsigned long) == 
sizeof(double)' for 64-bit builds on the compilers you are using.  This 
is not a problem with the C++ language but how you are using your 
compilers.  Try using 'unsigned int' instead.

/Leigh

[toc] | [prev] | [next] | [standalone]

#17209

On Feb 13, 1:41 pm, Alex Vinokur <alex.vino...@gmail.com> wrote:
> Hi,
>
> unsigned long a = -1;
> double b = a;
> unsigned long c = b;
>
> Model 32-bits:   a == c
> Model 64-bits:   a != c
>
> It is not a compiler bug for 64-bits.
>
> Is it a design bug of C/C++ languge for 64-bits?

No. Your code snippet will produce "c" that equals "a" on both 32- and
64-bit systems.

If you think there is, post an example that shows the problem, e.g.:

#include <iostream>
int main()
{
 unsigned long a = -1;
 double b = a;
 unsigned long c = b;
 if (a != c)
 {
  std::cout << "error!";
 }
}

Goran.

[toc] | [prev] | [next] | [standalone]

#17215

On Feb 13, 2:54 pm, Goran <goran.pu...@gmail.com> wrote:
> On Feb 13, 1:41 pm, Alex Vinokur <alex.vino...@gmail.com> wrote:
>
> > Hi,
>
> > unsigned long a = -1;
> > double b = a;
> > unsigned long c = b;
>
> > Model 32-bits:   a == c
> > Model 64-bits:   a != c
>
> > It is not a compiler bug for 64-bits.
>
> > Is it a design bug of C/C++ languge for 64-bits?
>
> No. Your code snippet will produce "c" that equals "a" on both 32- and
> 64-bit systems.
>
> If you think there is, post an example that shows the problem, e.g.:
>
> #include <iostream>
> int main()
> {
>  unsigned long a = -1;
>  double b = a;
>  unsigned long c = b;
>  if (a != c)
>  {
>   std::cout << "error!";
>  }
>
> }
>
> Goran.

#include <iostream>
#include <cassert>

typedef unsigned char uchar;

#define SHOW_HEX(x) std::cerr << #x << " = " << std::hex <<
std::showbase << x << std::dec << std::endl
#define SHOW_DOUBLE(x) std::cerr << #x << " = " << x << std::endl
#define SHOW_CHAR(x) std::cerr << #x << " = " << std::hex <<
std::showbase << std::size_t(uchar(x)) << std::dec << std::endl

int main()
{
	// -------------------------------------
	std::cout << "Model: " << sizeof(void*) * CHAR_BIT << "-bits"<<
std::endl;
	// -------------------------------------

	// std::size_t a = std::size_t(-1);
	// double b = a;
	std::size_t a = std::numeric_limits<std::size_t>::max();
	double b = a;
	std::size_t c = b;
	char* pa = reinterpret_cast<char*>(&a);
	char* pb = reinterpret_cast<char*>(&b);
	char* pc = reinterpret_cast<char*>(&c);

	SHOW_HEX(a);
	SHOW_DOUBLE(b);
	SHOW_HEX(c);

	std::cerr << std::endl;
	for (std::size_t i = 0; i < (sizeof(std::size_t)/sizeof(char)); i++)
	{
		SHOW_CHAR(pa[i]);
	}
	std::cerr << std::endl;
	for (std::size_t i = 0; i < (sizeof(double)/sizeof(char)); i++)
	{
		SHOW_CHAR(pb[i]);
	}
	std::cerr << std::endl;
	for (std::size_t i = 0; i < (sizeof(std::size_t)/sizeof(char)); i++)
	{
		SHOW_CHAR(pc[i]);
	}

	assert (a == c);

  return 0;
}

[toc] | [prev] | [next] | [standalone]

#17220

Goran <goran.pusic@gmail.com> writes:

> On Feb 13, 1:41 pm, Alex Vinokur <alex.vino...@gmail.com> wrote:
>> Hi,
>>
>> unsigned long a = -1;
>> double b = a;
>> unsigned long c = b;
>>
>> Model 32-bits:   a == c
>> Model 64-bits:   a != c
>>
>> It is not a compiler bug for 64-bits.
>>
>> Is it a design bug of C/C++ languge for 64-bits?
>
> No. Your code snippet will produce "c" that equals "a" on both 32- and
> 64-bit systems.

Not always.  His (and your) use of "64-bit systems" hides that fact that
they are not all the same:

  $ cat t.c
  #include <stdio.h>
   
  int main(void)
  {
       unsigned long a = -1;
       puts(a == (unsigned long)(double)a ? "same" : "different");
  }
  $ gcc -o t -std=c99 -pedantic t.c
  $ ./t
  different

(g++ will do the same, here).

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17223

On Feb 13, 1:54 pm, Goran <goran.pu...@gmail.com> wrote:
> On Feb 13, 1:41 pm, Alex Vinokur <alex.vino...@gmail.com> wrote:
>
> > Hi,
>
> > unsigned long a = -1;
> > double b = a;
> > unsigned long c = b;
>
> > Model 32-bits:   a == c
> > Model 64-bits:   a != c
>
> > It is not a compiler bug for 64-bits.
>
> > Is it a design bug of C/C++ languge for 64-bits?
>
> No. Your code snippet will produce "c" that equals "a" on both 32- and
> 64-bit systems.

Here I stand ashamed. I overlook the "unsigned" part. :-(

It's what Noob says, first and foremost. max of size_t is likely
2^64-1. That's more digits than number of significant digits "double"
can carry.

Goran.

[toc] | [prev] | [next] | [standalone]

#17217

On 2/13/2012 7:41 AM, Alex Vinokur wrote:
> Hi,
>
> unsigned long a = -1;
> double b = a;
> unsigned long c = b;
>
> Model 32-bits:   a == c
> Model 64-bits:   a != c
>
>
> It is not a compiler bug for 64-bits.
>
> Is it a design bug of C/C++ languge for 64-bits?

     Whether the language design is faulty seems a matter of opinion.
However, part of the "spirit of C" is to stay fairly close to the
hardware.  Since hardware that offers 64 bits of precision in the
floating-point format used for `double', some loss of precision in
`b = a' must be expected.

     The language *could* have been defined to raise an exception
whenever a floating-point operation delivers an inexact result, but
that would have meant raising such exceptions for a large fraction
of all F-P calculations, perhaps many times in a single expression.
Or the language could have left the inexact conversion entirely
undefined, in which case there'd be no reason to expect `a == c'
(or even that the execution would get that far).  The behavior
actually chosen (conversion yields one of the two representable
neighbors) seems fairly benign, not something I'd call a bug.  But,
as I say, that's a matter of opinion.

     (The language *could* have been defined to deliver exact F-P
results for all calculations, widening the representation at need.
That's the approach used on the Starship Enterprise, where Kirk
crippled the computer by asking it to calculate pi ...)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#17219

On 2/13/2012 8:14 AM, Eric Sosman wrote:
> [...] Since hardware that offers 64 bits of precision in the
> floating-point format used for `double', some loss of precision in
> `b = a' must be expected.

     Oh, drat.  There was supposed to be an "is fairly rare" just
before the comma ...

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#17248

In comp.lang.c++ Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> On 2/13/2012 8:14 AM, Eric Sosman wrote:
>> [...] Since hardware that offers 64 bits of precision in the
>> floating-point format used for `double', some loss of precision in
>> `b = a' must be expected.

>     Oh, drat.  There was supposed to be an "is fairly rare" just
> before the comma ...

x87 hardware isn't that rare. Depending on the implementation,
the compiler might do the calculation in temporary real form,
with all 64 bits.

But, yes, the usual double is 64 total bits, so fewer than 64
for the significand. As far as I know, though, there is no
restriction in C or C++ against a larger double, such as
a 64 bit float and 128 bit double.

-- glen

[toc] | [prev] | [next] | [standalone]

#17253

On 02/13/2012 04:52 PM, glen herrmannsfeldt wrote:
...
> for the significand. As far as I know, though, there is no
> restriction in C or C++ against a larger double, such as
> a 64 bit float and 128 bit double.

True. Such a restriction applies only to C implementations that
pre-#define __STDC_IEC_559__, in which case "The double type matches the
IEC 60559 double format" (F.2p1).

It's not clear to me that the C++ standard makes any such requirement if
std::numeric_limits<double>.is_iec559 is true. It seem to me that
is_iec559 could still be true if double is an extended double IEC 559 type.

[toc] | [prev] | [next] | [standalone]

#17273

On 2/13/2012 4:52 PM, glen herrmannsfeldt wrote:
> In comp.lang.c++ Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>> On 2/13/2012 8:14 AM, Eric Sosman wrote:
>>> [...] Since hardware that offers 64 bits of precision in the
>>> floating-point format used for `double', some loss of precision in
>>> `b = a' must be expected.
>
>>      Oh, drat.  There was supposed to be an "is fairly rare" just
>> before the comma ...
>
> x87 hardware isn't that rare. Depending on the implementation,
> the compiler might do the calculation in temporary real form,
> with all 64 bits.

     ... which wouldn't help, as the eventual result must be
converted to plain `double'.  Yes, there are systems that support
a floating-point format with >64 bits' precision, but are there
any that use such a wide precision for `double'?  `long double',
maybe, but plain `double'?

     Hands up: Who's got a C implementation where

	sizeof(double) * CHAR_BIT > 64

?  Or, more accurately to the O.P.'s question, where

	DBL_MANT_DIG * log(FLT_RADIX) / log(2) >= 64?

?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#17218

Alex Vinokur <alex.vinokur@gmail.com> writes:

Talking from the C perspective here...

> unsigned long a = -1;
> double b = a;
> unsigned long c = b;
>
> Model 32-bits:   a == c
> Model 64-bits:   a != c
>
> It is not a compiler bug for 64-bits.

Quite.  Both outcomes are permitted.

> Is it a design bug of C/C++ languge for 64-bits?

No.

Your use of "64-bits" is a little confusing.  Not all 64-bit systems
have 64 bit unsigned longs which is, I think, what you are talking
about.

On systems with 64-bit longs and standard 56-bit mantissa doubles, you
can not represent ULONG_MAX (the value of 'a' in the above code) exactly
in a double.  C mandates that you get one of the two nearest
representable values, but it wont be exact.  When the conversion goes
the other way the result can be undefined (if the floating point values
was rounded up to a value larger that ULONG_MAX), but, even if the
double has a value in the range of unsigned long, it will not longer
equal ULONG_MAX.

I said "no" to it being an error in the design of the language because
solving it would impose the kind of burden on implementations that C
rejects.  C is designed to use native machine types wherever possible.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17232

On 2/13/2012 6:16 AM, Ben Bacarisse wrote:
> Alex Vinokur<alex.vinokur@gmail.com>  writes:
>
> Talking from the C perspective here...
>
>> unsigned long a = -1;
>> double b = a;
>> unsigned long c = b;
>>
>> Model 32-bits:   a == c
>> Model 64-bits:   a != c
>>
>> It is not a compiler bug for 64-bits.
>
> Quite.  Both outcomes are permitted.
>
>> Is it a design bug of C/C++ languge for 64-bits?
>
> No.
>
> Your use of "64-bits" is a little confusing.  Not all 64-bit systems
> have 64 bit unsigned longs which is, I think, what you are talking
> about.
>
> On systems with 64-bit longs and standard 56-bit mantissa doubles, you
> can not represent ULONG_MAX (the value of 'a' in the above code) exactly
> in a double.  C mandates that you get one of the two nearest
> representable values, but it wont be exact.  When the conversion goes
> the other way the result can be undefined (if the floating point values
> was rounded up to a value larger that ULONG_MAX), but, even if the
> double has a value in the range of unsigned long, it will not longer
> equal ULONG_MAX.
>
> I said "no" to it being an error in the design of the language because
> solving it would impose the kind of burden on implementations that C
> rejects.  C is designed to use native machine types wherever possible.
>

yeah.

also, 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").


it is much less reliable with float (since float has only about 23 bits 
to hold an integer's value, vs the 52 bits or so in double).

hence, float can't reliably hold the entire integer range, and double 
can't reliably hold the entire long-long range (the size of long is 
target specific, even for the same CPU architecture and operating mode, 
it may still vary between the OS and compiler in use).


the most common behavior seems to be:
int -> float or double, may produce a value slightly below the integer;
float or double to int, will generally truncate the value, yielding the 
integer representation as rounded towards 0.

the result then is a tendency for an int->double->int conversion to have 
a small chance to drop the integer value towards 0 (why? I don't know 
exactly, but I have observed it before).

one can counteract this by fudging the value with a small epsilon prior 
to converting back into an integer.

say, for example (untested, from memory):
(v>=0)?((int)(v+0.0001)):((int)(v-0.0001));

can't say it will always work, but similar seems to work fairly well IME 
(at least on generic x86 based targets).


or such...

[toc] | [prev] | [next] | [standalone]

#17245

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").

What circumstances are those? Integers hold integer values. AFAIK, all 
integer values encode correctly in FP of higher precision. It's a simple 
matter of normalization. (On Intel, a bit-scan operation.)

[toc] | [prev] | [next] | [standalone]

#17246

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").
> 
> What circumstances are those? Integers hold integer values. AFAIK, all 
> integer values encode correctly in FP of higher precision. It's a simple 
> matter of normalization. (On Intel, a bit-scan operation.)

You've covered the correct point, but have apparently not realized that
it was relevant. He'd talking about converting an integer value to a
floating point type when the floating point type has insufficient
precision to encode the value correctly. This is less than clear,
because he's making all kinds of implementation-specific assumptions
about the sizes of various types, and (inconsistently) using 'integer'
as if it were synonymous with 'int'.

The key point is that, for instance, a 32-bit integer type can represent
values too large to be converted without loss of precision to a 32-bit
floating point type, because the floating point type uses some of those
bits for the exponent. The same thing applies to 64 bit integer types
and and 64 bit floating point types.

[toc] | [prev] | [next] | [standalone]

#17251

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").
>>
>> What circumstances are those? Integers hold integer values. AFAIK,
>> all integer values encode correctly in FP of higher precision. It's
>> a simple matter of normalization. (On Intel, a bit-scan operation.)
>
> You've covered the correct point, but have apparently not realized
> that it was relevant. He'd talking about converting an integer value
> to a floating point type when the floating point type has insufficient
> precision to encode the value correctly. This is less than clear,
> because he's making all kinds of implementation-specific assumptions
> about the sizes of various types, and (inconsistently) using 'integer'
> as if it were synonymous with 'int'.
>
> The key point is that, for instance, a 32-bit integer type can
> represent values too large to be converted without loss of precision
> to a 32-bit floating point type, because the floating point type uses
> some of those bits for the exponent. The same thing applies to 64 bit
> integer types and and 64 bit floating point types.

Point taken, which is the OP point of 64-bit ULL in a 53 bit mantissa (or 
32-bit int in a single precision float). This is easily understood and 
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.

[toc] | [prev] | [next] | [standalone]

#17255

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.

[toc] | [prev] | [next] | [standalone]

#17262

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.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web