• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 252
  • Last Modified:

bitwise operation on double

How can I convert a 8byte number (double) to two 4 bytes (unsigned longs) number ?
ex.   double   d;
       unsigned long   hi;
       unsigned long   lo;
       d = atof("112228383499478777277223");
       hi = first 4 bytes of d
       lo = second 4 bytes of d
0
bsmoam1
Asked:
bsmoam1
  • 5
  • 4
  • 3
  • +5
1 Solution
 
bsmoam1Author Commented:
Edited text of question
0
 
ozoCommented:
hi = ((unsigned long *)&d)[0];
lo = ((unsigned long *)&d)[1];
0
 
snoeglerCommented:
ozo why didn't you post this as an answer? it is absolutely perfect.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
ozoCommented:
Because the operation is implementation defined, and so may not be guaranteed to work on bsmoam1's machine.
And even if it does, I'm not quite sure if this is what bsmoam1 really wants to do.
I await comment.
0
 
elfieCommented:
You have to take into account that the byte order for storing binary types (int, short, long) differs on PC's and most UNIX systems (Sun, HP, ...)

If you have a short that has a value s=1; and you take ozo's algorithm for converting it to char hi=((unsigned char*)&s)[0];


you will find that hi equals 1 on PC, and 0 on HP, Sun, ...
lo has the opposite value.

0
 
snoeglerCommented:
It isn't possible to make a conversion like this machine independent, and the bsmoam1 did
not ask that he wants it to have a special order. So i think the answer ozo gave should be right ... or what?
0
 
elfieCommented:
using htons(3) calls can make it portable among different machines. On most unix systems these calls doesn't do a thing. But on pc systems the should change the byte order pf the passed long, int, short, ... .

0
 
julio011597Commented:
IMO, before discussing the size of int and the endian order issues, it should be noted that bitwise operations on doubles are not very orthodox.

-julio
0
 
halenCommented:
Try this, it always works for me:

hi = (unsigned long)d >> 32;          //  shifts upper 32 bits(4 bytes) to lower 32 bits
                                                   //  zeros are shifted into the upper 32 bits hence
                                                   //  8888 7777 6666 5555 hex becomes
                                                   //  0000 0000 8888 7777 hex which is simply
                                                   //  8888 7777 hex when cast as a unsigned long.

lo = (unsigned long)d & 4294967295;  //  4294967295 decimal = FFFFFFFF hex.
                                                       //  By doing the bitwise AND operation of the
                                                       //  double and FFFFFFFF hex, the upper 32
                                                       //  bits become zero leaving us with the lower
                                                       //  part which is our answer.

To follow this approach it helps to have studied digital design or at least converting
numbers between decimal, hexidecimal and binary.
0
 
snoeglerCommented:
No comment :)
0
 
xyuCommented:
:)
union Hehe {
  double d;
  struct HoHo{
    long l1;
    long l2;
  } _HoHo;
} _Hehe;

:)

0
 
newexpertCommented:
The proper C way of doing so is as follows
union
 {
  double dbv;
  struct { unsigned long lo, hi } ul;
 } D22UL;

D22UL var;
var.dbv = (double) 3.14159;
printf("%ld %ld", var.ul.lo, var.ul.hi);
0
 
newexpertCommented:
Just noticed xyu's answer.  Sorry xyu.  At least I used unsigned long as requested
0
 
ozoCommented:
I wouldn't quite say it's the "proper" C way.
I don't think the ANSI C specifications actually require that to work any more than the pointer cast method.
(On the other hand, I'm not familiar with any implementation in which it wouldn't work, provided that sizeof(double)==2*sizeof(unsigned long))


halen's solution of casting a double to an unsigned long seems very unlikely to be what bsmoam1 was asking for.
0
 
newexpertCommented:
ozo:  There are non-portable features in ANSI compliant C such as
bit_field (which can never be portable).

In the future if a 64 bit machine requires every integer (long included) to be aligned on 64 bit boundary (just like some unix systems nowadays require all char and int to be on 32 bit boundary) then the above example using union would not work.
0
 
ozoCommented:
Even if the hardware does not  require such alignment, the C implementation is still permited to use such algnments in its unions.
0
 
newexpertCommented:
ozo: but not in struct {} !!

struct { char c; int d; } A;
struct { int d1; int d2; } B;

sizeof(A) == sizeof(B) on some machines.
0
 
ozoCommented:
Or on any machine, if the C impementation chooses to make it so.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 5
  • 4
  • 3
  • +5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now