Portable Doubles

**esbo** · 08-30-2006

Actually if you convert the numbers into hexidecimal you probably won't notice the difference!!
You don't have to use a zip file, as I said if you write your own conversion programs, there should be little
or no redundancy in the system. Some of the C wizards may be able to suggest a better way though

**SlyMaelstrom** · 08-30-2006

Originally Posted by esbo

Actually if you convert the numbers into hexidecimal you probably won't notice the difference!!
You don't have to use a zip file, as I said if you write your own conversion programs, there should be little
or no redundancy in the system. Some of the C wizards may be able to suggest a better way though

Convert it to hexidecimal? If the system stores things as binary, it's going to store it as binary no matter how you wish to display it. It's not as if one hex digit fits in one binary digit therefor you can just convert everything to hex and save space. I don't think they're looking to just store a string directly, I think they want to maintain the same exact bytes. I'm honestly not sure what floating point looks like in hex, but I have a feeling it's representation would be only slightly shorter than just the decimal representation of the string.

EDIT: For strings -- here is double precision in decimal vs hex

Code:

3.1415926535897930
400921FB54442D18

So two bytes. I suppose it shrinks it a bit, but I don't think it's small enough for what the OP wants.

EDIT 2: ...and lastly, which I probably should have thought of first, isn't converting to hex on one comp and back on another subject to the same rounding errors as just sending the double directly would have?

**quzah** · 08-30-2006

Maybe if you zipped the hexidecimal!

/mock

Quzah.

**Dave_Sinkula** · 08-30-2006

Originally Posted by EvilGuru

I am trying to transfer double-width floating point numbers between two computers, whose floating point format is different.

Perhaps it might be beneficial to mention the formats?

**esbo** · 08-30-2006

Originally Posted by SlyMaelstrom

Convert it to hexidecimal? If the system stores things as binary, it's going to store it as binary no matter how you wish to display it. It's not as if one hex digit fits in one binary digit therefor you can just convert everything to hex and save space. I don't think they're looking to just store a string directly, I think they want to maintain the same exact bytes. I'm honestly not sure what floating point looks like in hex, but I have a feeling it's representation would be only slightly shorter than just the decimal representation of the string.

EDIT: For strings -- here is double precision in decimal vs hex

Code:

3.1415926535897930
400921FB54442D18

So two bytes. I suppose it shrinks it a bit, but I don't think it's small enough for what the OP wants.

EDIT 2: ...and lastly, which I probably should have thought of first, isn't converting to hex on one comp and back on another subject to the same rounding errors as just sending the double directly would have?

Actually 3.1415926535897930 as a character string will compress considerably more than you indicate, if each character is stored in an eight bit byte, there are 255 possibilities that could be used, however only 10 are being used, (0-9), so there is considerable reduncancy there. If you encode each character in 4 bits rather than 8, which you could you would halve the data length at a stroke. The character string 3.1415926535897930 would use 18 bytes the hexidecimal number 400921FB54442D18 only uses 8, so you have more than halved the transmission time, (44%).
(I was programming im hexidecimal well before your were born!!, seriously, I started programming in machine code, you lot don't know you are born!!)

**esbo** · 08-30-2006

Ask me what C9 means in Z80 machine code!!
(lol - don't bother the answer is ret (return))

**SlyMaelstrom** · 08-30-2006

Originally Posted by esbo

Ask me what C9 means in Z80 machine code!!
(lol - don't bother the answer is ret (return))

Cool, I got'st the internet, too!

**psychopath** · 08-30-2006

Originally Posted by esbo

I was programming im hexidecimal well before your were born!!, seriously, I started programming in machine code, you lot don't know you are born!!

hahaha omg lolz!!!!!1 ur so l33t!

**EvilGuru** · 08-31-2006

Originally Posted by Dave_Sinkula

Perhaps it might be beneficial to mention the formats?

Well, to be honest I am not totally sure on the formats to tell you the truth. The system it will be running on is an embedded system (Gumstix), which uses an ARM processor. I am not sure if it has an FPU or not, it may well be using a software library of some kind.

The other computer (well application) is written in Java (please don't hurt me!), which is friendly enough to use a standardised format for floats and doubles (DataInputStrem).

So I guess the real question is how can I split up the parts of a systems/arch's double and re-arrange it so that it is in the same order/format as the doubles used by Java, which I am told uses the IEEE 754 floating point format in Big endian form.

I am aware the different systems and implementations may have different sizes for various parts of a floating point number, and so a loss of precision may result.

Of-course if anyone has a better suggestion/way to do it, I am anxious to know!

Regards, Freddie.

**Salem** · 08-31-2006

If you're feeling lucky, try assuming that the other end is IEEE 754 in little endian format.
In which case, it's a simple byte-swapping exercise.

Try sending known floats (like 1.0) and seeing how they're represented on both sides as just arrays of bytes.

**dwks** · 08-31-2006

Originally Posted by esbo

If you encode each character in 4 bits rather than 8, which you could you would halve the data length at a stroke.

I said that already.

It was the first reply.

**EvilGuru** · 08-31-2006

Originally Posted by Salem

If you're feeling lucky, try assuming that the other end is IEEE 754 in little endian format.
In which case, it's a simple byte-swapping exercise.

Try sending known floats (like 1.0) and seeing how they're represented on both sides as just arrays of bytes.

Well, I felt luck, and it worked! Question is, does anyone known of a smarter method to swap the bytes than this:

Code:

void my_htond (double *out, double in)
{
    unsigned char *bin = (unsigned char *) &in;
    unsigned char *bot = (unsigned char *) out;
    int j;
    for (j = 0; j < sizeof(double); j++) bout[j] = bin[(sizeof(double) - 1) - j];
}

**dwks** · 08-31-2006

You could try searching the board for "reverse bytes". One such hit is http://cboard.cprogramming.com/showt...=reverse+bytes

**esbo** · 08-31-2006

Originally Posted by dwks

I said that already.

It was the first reply.

I didn't notice that part of your reply I just noticed the bit about converting into a character string, then people saying that wouuld not be efficient ect....., it would be efficient enough!