Velocity Reviews > double cast to int reliable?

# double cast to int reliable?

sandeep
Guest
Posts: n/a

 06-02-2010
In the following code:

int i,j;
double d;

i = 1; // or any integer
d = (double)i;
j = (int)d;

Is there any chance that "i" will not equal "j" due to the double
being stored inexactly?

Sjouke Burry
Guest
Posts: n/a

 06-02-2010
sandeep wrote:
> In the following code:
>
> int i,j;
> double d;
>
> i = 1; // or any integer
> d = (double)i;
> j = (int)d;
>
> Is there any chance that "i" will not equal "j" due to the double
> being stored inexactly?

Yep. Rounding while converting do double will for most integers
mean that the double is slightly smaller then the int.
converting then to int, will not give you the original.

Dann Corbit
Guest
Posts: n/a

 06-02-2010
In article <hu6gg8\$lim\$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed) says...
>
> In the following code:
>
> int i,j;
> double d;
>
> i = 1; // or any integer
> d = (double)i;
> j = (int)d;
>
> Is there any chance that "i" will not equal "j" due to the double
> being stored inexactly?

It is possible for int to be 64 bits, and represent values as large as
(for instance) 9223372036854775807.

It is possible for double to have as little as 6-7 significant digits,
though for the most part you will see 15-16 significant digits.

It is possible (though unlikely) to see the problem you describe. I
would be very surprised to see a system with 64 bit ints and 32 bit
doubles. But even with 64 bit ints and 64 bit doubles, the int values
will have greater precision because they do not store an exponent.

Far more likely is this

double d = <some value>;
int i = d; /* undefined behavior due to integer overflow */

At this point, i may not be equal to floor(d) if floor(d) is not
representible as an integer.

There will always be some situations where information can be lost
because it is very unlikely that the precisions are identical.

Hence, if you want the integral value that is stored in a double, far
better is:

double integral_part = floor(some_double);

Dann Corbit
Guest
Posts: n/a

 06-02-2010
In article <4c06c7db\$0\$14122\$(E-Mail Removed)>,
(E-Mail Removed) says...
>
> sandeep wrote:
> > In the following code:
> >
> > int i,j;
> > double d;
> >
> > i = 1; // or any integer
> > d = (double)i;
> > j = (int)d;
> >
> > Is there any chance that "i" will not equal "j" due to the double
> > being stored inexactly?

> Yep. Rounding while converting do double will for most integers
> mean that the double is slightly smaller then the int.
> converting then to int, will not give you the original.

Since he specified an integer assignment:
> > i = 1; // or any integer

the difficulties are not due to rounding, as I see it.

Tim Streater
Guest
Posts: n/a

 06-02-2010
In article <4c06c7db\$0\$14122\$(E-Mail Removed)>,
Sjouke Burry <(E-Mail Removed)> wrote:

> sandeep wrote:
> > In the following code:
> >
> > int i,j;
> > double d;
> >
> > i = 1; // or any integer
> > d = (double)i;
> > j = (int)d;
> >
> > Is there any chance that "i" will not equal "j" due to the double
> > being stored inexactly?

> Yep. Rounding while converting do double will for most integers
> mean that the double is slightly smaller then the int.
> converting then to int, will not give you the original.

Won't this be exact if the integer in question occupies fewer bits than
the mantissa size in bits? On the CDC 6600 (60-bit word), all integer
arithmetic was in fact done by the floating point unit (apart from
integer addition), so integers were limited to 48 bits (mantissa length).

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689

Ben Pfaff
Guest
Posts: n/a

 06-02-2010
Dann Corbit <(E-Mail Removed)> writes:

> It is possible for double to have as little as 6-7 significant digits,
> though for the most part you will see 15-16 significant digits.

The 'float' type must have at least 6 significant digits.
The 'double' and 'long double' types must have at least 10
significant digits.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}

Ben Bacarisse
Guest
Posts: n/a

 06-02-2010
Tim Streater <(E-Mail Removed)> writes:

> In article <4c06c7db\$0\$14122\$(E-Mail Removed)>,
> Sjouke Burry <(E-Mail Removed)> wrote:
>
>> sandeep wrote:
>> > In the following code:
>> >
>> > int i,j;
>> > double d;
>> >
>> > i = 1; // or any integer
>> > d = (double)i;
>> > j = (int)d;
>> >
>> > Is there any chance that "i" will not equal "j" due to the double
>> > being stored inexactly?

>> Yep. Rounding while converting do double will for most integers
>> mean that the double is slightly smaller then the int.
>> converting then to int, will not give you the original.

>
> Won't this be exact if the integer in question occupies fewer bits than
> the mantissa size in bits?

Yes. 6.3.1.4 p2 (part of the section on conversions) starts:

When a value of integer type is converted to a real floating type, if
the value being converted can be represented exactly in the new type,
it is unchanged.

The standard does not use the term mantissa but section 5.2.4.2.2
("Characteristics of floating types") defines C's model of floating
types in such a way that the expected range of integers will be exactly
representable.

<snip>
--
Ben.

kathir
Guest
Posts: n/a

 06-02-2010
On Jun 2, 1:55*pm, sandeep <(E-Mail Removed)> wrote:
> In the following code:
>
> int i,j;
> double d;
>
> i = 1; // or any integer
> d = (double)i;
> j = (int)d;
>
> Is there any chance that "i" will not equal "j" due to the double
> being stored inexactly?

The way how floating point numbers are stored internally are
different, uses mantissa and exponent portion. If you do any floating
point calculation (multiplication and division) and convert back to
integer, you will see a minor difference between int and double value.
To understand the bit pattern of floating points, visit at
http://softwareandfinance.com/Resear...Point_Ind.html

Thanks and Regards,
Kathir
http://programming.softwareandfinance.com

Nick Keighley
Guest
Posts: n/a

 06-03-2010
On 2 June, 22:06, Sjouke Burry <(E-Mail Removed)>
wrote:
> sandeep wrote:
> > In the following code:

>
> > int i,j;
> > double d;

>
> > i = 1; // or any integer
> > d = (double)i;
> > j = (int)d;

>
> > Is there any chance that "i" will not equal "j" due to the double
> > being stored inexactly?

>
> Yep. Rounding while converting do double will for most integers
> mean that the double is slightly smaller then the int.
> converting then to int, will not give you the original.

really? Can you name an implementation where this is so? Is it a valid
implementation of C?

Nick Keighley
Guest
Posts: n/a

 06-03-2010
On 3 June, 00:58, kathir <(E-Mail Removed)> wrote:
> On Jun 2, 1:55*pm, sandeep <(E-Mail Removed)> wrote:
>
> > In the following code:

>
> > int i,j;
> > double d;

>
> > i = 1; // or any integer
> > d = (double)i;
> > j = (int)d;

>
> > Is there any chance that "i" will not equal "j" due to the double
> > being stored inexactly?

>
> The way how floating point numbers are stored internally are
> different, uses mantissa and exponent portion. If you do any floating
> point calculation (multiplication and division) and convert back to
> integer, you will see a minor difference between int and double value.

depending what operations you do you might see huge differences

> To understand the bit pattern of floating points, visit athttp://softwareandfinance.com/Research_Floating_Point_Ind.html
>
> Thanks and Regards,
> Kathirhttp://programming.softwareandfinance.com