Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > long -> double -> long

Reply
Thread Tools

long -> double -> long

 
 
Steven Woody
Guest
Posts: n/a
 
      08-28-2007
long i = nnn;
long j;
double d;
d = i;
j = ( long )d;

in this case, i == j ?

thanks.

 
Reply With Quote
 
 
 
 
Jack Klein
Guest
Posts: n/a
 
      08-28-2007
On Tue, 28 Aug 2007 03:09:37 -0000, Steven Woody
<(E-Mail Removed)> wrote in comp.lang.c:

> long i = nnn;
> long j;
> double d;
> d = i;
> j = ( long )d;


The cast is completely unnecessary, and completely useless. The
conversion is performed automatically on assignment, and cast does not
change that. If the value of the double is outside the range of
values representable in an unsigned long, the behavior is undefined,
with or without the cast.

> in this case, i == j ?


Maybe.

> thanks.


You're welcome.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      08-28-2007
In article <(E-Mail Removed). com>,
Steven Woody <(E-Mail Removed)> wrote:
>long i = nnn;
>long j;
>double d;
>d = i;
>j = ( long )d;


>in this case, i == j ?


Not necessarily. double pretty much has to be at least 64 bits,
including the sign and exponent; you end up with about 52 bits
of mantisa as the minimum. If the nnn that you are storing
is more than the radix to the power of (1 more than #bits in mantisa)
(e.g., 2^(1+52), then nnn cannot be stored exactly unless
the last (64-(1+#bits in mantisa)) happen to be 0.

This does come up in practice; on SGI and Sun 64 bit machines
programs compiled in 64 bit mode have 64 bit doubles and 64 bit longs.
((1L<<53)+1L) is too large to be stored in a double in such a system.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
 
Reply With Quote
 
harpreetsingh911@gmail.com
Guest
Posts: n/a
 
      08-28-2007
On Aug 28, 8:09 am, Steven Woody <(E-Mail Removed)> wrote:
> long i = nnn;
> long j;
> double d;
> d = i;
> j = ( long )d;
>
> in this case, i == j ?
>
> thanks.


i==j yes it is true.

 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      08-28-2007

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> On Aug 28, 8:09 am, Steven Woody <(E-Mail Removed)> wrote:
>> long i = nnn;
>> long j;
>> double d;
>> d = i;
>> j = ( long )d;
>>
>> in this case, i == j ?
>>
>> thanks.

>
> i==j yes it is true.
>

Normally, yes. On some systems all integers representable by a long will be
representable exactly by a double, and so i will always equal j. Change the
double to a float and put it a very high value, and assuming four bytes for
each, you will see that j is now usually approximate.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      08-28-2007
Malcolm McLean wrote:
>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) oups.com...
>> On Aug 28, 8:09 am, Steven Woody <(E-Mail Removed)> wrote:
>>> long i = nnn;
>>> long j;
>>> double d;
>>> d = i;
>>> j = ( long )d;
>>>
>>> in this case, i == j ?
>>>
>>> thanks.

>>
>> i==j yes it is true.
>>

> Normally, yes. On some systems all integers representable by a long will
> be representable exactly by a double, and so i will always equal j.
> Change the double to a float and put it a very high value, and assuming
> four bytes for each, you will see that j is now usually approximate.
>

Given a sufficiently high value in that case, j must be approximate.

--
Ian Collins.
 
Reply With Quote
 
harpreetsingh911@gmail.com
Guest
Posts: n/a
 
      08-28-2007
On Aug 28, 8:09 am, Steven Woody <(E-Mail Removed)> wrote:
> long i = nnn;
> long j;
> double d;
> d = i;
> j = ( long )d;
>
> in this case, i == j ?
>
> thanks.


you have nnn to i by using long data type. the output of both i and j
will be 0 because it is not poible to output character through long.

 
Reply With Quote
 
Steven Woody
Guest
Posts: n/a
 
      08-28-2007
On Aug 28, 11:49 am, (E-Mail Removed)-cnrc.gc.ca (Walter Roberson)
wrote:
> In article <(E-Mail Removed). com>,
> Steven Woody <(E-Mail Removed)> wrote:
>
> >long i = nnn;
> >long j;
> >double d;
> >d = i;
> >j = ( long )d;
> >in this case, i == j ?

>
> Not necessarily. double pretty much has to be at least 64 bits,
> including the sign and exponent; you end up with about 52 bits
> of mantisa as the minimum. If the nnn that you are storing
> is more than the radix to the power of (1 more than #bits in mantisa)
> (e.g., 2^(1+52), then nnn cannot be stored exactly unless
> the last (64-(1+#bits in mantisa)) happen to be 0.
>
> This does come up in practice; on SGI and Sun 64 bit machines
> programs compiled in 64 bit mode have 64 bit doubles and 64 bit longs.
> ((1L<<53)+1L) is too large to be stored in a double in such a system.
> --
> "law -- it's a commodity"
> -- Andrew Ryan (The Globe and Mail, 2005/11/26)


thanks for all your inputs. i now understan, if nnn is so large that
it can not be presented in a double with zero exponent, it becomes
unexactly. since my system has a 16bit integer and 32bit double, so i
believe this will not happend and i in above code always equals to j.

thanks again.

 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      08-28-2007
In article <(E-Mail Removed) .com>,
Steven Woody <(E-Mail Removed)> wrote:
>On Aug 28, 11:49 am, (E-Mail Removed)-cnrc.gc.ca (Walter Roberson)
>wrote:
>> In article <(E-Mail Removed). com>,
>> Steven Woody <(E-Mail Removed)> wrote:


>> >long i = nnn;
>> >long j;
>> >double d;
>> >d = i;
>> >j = ( long )d;
>> >in this case, i == j ?


>thanks for all your inputs. i now understan, if nnn is so large that
>it can not be presented in a double with zero exponent, it becomes
>unexactly.


Ummm, not exactly.

The below relates to the most common means of representing floating
point numbers. There are other schemes that differ a bit in the
details:

Take the integer and write it out in binary, with no leading 0's.
Count the number of bits and subtract 1; the result will be the
"unbiased" exponent used. Internally, a constant will be added to
this exponent to produce a "biased exponent" that will actually
be stored (the reasons for this have to do with storing numbers less
than 1.) Thus, the unbiased exponent will be non-zero for any integer
greater than 1. Now discard the leading 1 bit from the binary
representation of the integer, *leaving any leading 0s there*.
Start storing this binary number into the available
mantissa digits (e.g., 23 bits for IEEE 32 bit floats),
starting from the "left" (highest bit position) and progressing
towards the right. If you run out of binary digits before you
run out of available bits, then you were able to store the integer
exactly in the floating point number; pad any remaining mantissa
bits out with binary 0's. If you run out of available mantissa
bits before you run out of binary digits, then you were not
able to store the integer exactly.

Or, as a simpler wording: count the number of binary digits in
the representation of the integer, and subtract 1 from that count.
If the result is more than the number of mantissa bits available,
then you cannot store the integer exactly.


>since my system has a 16bit integer and 32bit double, so i
>believe this will not happend and i in above code always equals to j.


There are two problems with that.

A) Your code is written around -long-, not around -int-, and it is not
valid in C for a long to be as little as 16 bits. long in C requires at
least 32 bits.

B) Secondly, in any conforming C program, it is not valid for
double to be as little as 32 bits: 32 bits is not enough to
achieve the requirement that DBL_DIG (the number of decimal
digits that can be reliably stored) be at least 10;
32 bits is only enough for 6 decimal digits of reliable storage.
The minimum number of bits needed to meet the C90 constraints
on the range and precision of double, is 43.

--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      08-28-2007
On Aug 28, 3:36 pm, Jack Klein <(E-Mail Removed)> wrote:
> On Tue, 28 Aug 2007 03:09:37 -0000, Steven Woody
>
> > j = ( long )d;

>
> The cast is completely unnecessary, and completely useless.


It does have some use: to document that the writer
intended to possibly lose precision in the value.

(Not that I approve of such use, but others do).

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Having compilation error: no match for call to (const __gnu_cxx::hash<long long int>) (const long long int&) veryhotsausage C++ 1 07-04-2008 05:41 PM
unsigned long long int to long double Daniel Rudy C Programming 5 09-20-2005 02:37 AM
cannot convert parameter from 'double (double)' to 'double (__cdecl *)(double)' error Sydex C++ 12 02-17-2005 06:30 PM
float, double, long double JKop C++ 4 08-08-2004 07:12 PM
Cast from (long double*) to (const double*) ferran C++ 9 04-12-2004 05:05 PM



Advertisments