Portable Doubles

I am trying to transfer double-width floating point numbers between two computers, whose floating point format is different. Does anyone know of any packages/libraries that will convert floats/doubles into something that is not platform or architecture specific so that I can send the values.

Strings are not practical, as I am working over a 300 baud connection, and to serialise the data as a string requires more space than the 8 bytes required to send the type whole.

I have looked into XDR, but does not seem to be what I want. I expected it to do nothing more than do a bit of creative bit-twiddling on doubles/floats, not try and hijack my stream interface!

You could use *printf to get a string representation, and then store each digit in four bits (cutting the size in two), because four bits gives you 16 combinations, more than enough for then digits and a decimal point.

dwk

Seek and ye shall find. quaere et invenies.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

It doesn't really matter how you send it to them. The second you convert it to a double from one machine to another, if they're not handled exactly the same internally, it will just smash them into the new machine's representation.

So it doesn't matter how you transport it over there. Once it gets converted, you're at the mercy of floating point accuracy, on inaccuracy as the case may be.

It doesn't really matter how you send it to them. The second you convert it to a double from one machine to another, if they're not handled exactly the same internally, it will just smash them into the new machine's representation.

So it doesn't matter how you transport it over there. Once it gets converted, you're at the mercy of floating point accuracy, on inaccuracy as the case may be.

Quzah.

Not sure what you mean here. If you send raw bytes to a different system, that system will need to know how to interpret that data. If it's the same OS, you can likely just cast the bytes as the right type. The portable approach is to use a markup language like XML. A psudo-markup language may sufice if you have a slow connection and it's only between two computers.

Last edited by King Mir; 08-30-2006 at 06:07 PM.

It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.

There is no portable approach. Let's say you send it over as a text dump of the number. Pretend it's "123.456789". Now you get to your other machine, and you convert that from text, back into a double. It might represent it differently, and as such, it may not end up being "123.456789", it could be say... "123.45644". Nothing you can do about it. You cannot ensure the number you send over will be the exact same number once it's converted back to an actual floating point number.

Yes, but he doesn't want to send the string "123.456789". Apparently that's too slow for his purposes. What he tried was sending a raw byte copy of his floating point values. This didn't work because the two machines use different representations for floating point. He wants another 8 byte solution.

He would also seemingly prefer to work with a librairy.

It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.

I wasn't telling him to use a string. That was an illustration. I was saying: No matter what you send over, there is no guarintee you'll wind up with the same number you started with once you convert it back.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Fixed point is not floating point. It's integers pretending to be floating point. Furthermore, it's also not accurate, because it's impossible for it to be accurate. You cannot represent all possible floating point values in 32 bits. That's why we approximate with floating point numbers as it stands now. If it were possible, we wouldn't need to guess.

But my point was that if you store a fixed point number, because it is integral, you can be sure of being able to represent the same value on the receiving end (barring overflow).

dwk

Seek and ye shall find. quaere et invenies.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

I wouldn't say fixed point is less accurate than floating point; it's simply accurate in a different way. Fixed point has a fixed accuracy of within whatever the smallest decimal it can store is. The accuracy of a floating point number depends on the magnitude of that number and the size of the significand.

Fixed point is a great solution if all the values are within a certain range and that can be expressed accurately in a single base. This means no irrational numbers. It may be the best solution here, depending what the numbers are.

It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.

I am trying to transfer double-width floating point numbers between two computers, whose floating point format is different. Does anyone know of any packages/libraries that will convert floats/doubles into something that is not platform or architecture specific so that I can send the values.

Strings are not practical, as I am working over a 300 baud connection, and to serialise the data as a string requires more space than the 8 bytes required to send the type whole.

I have looked into XDR, but does not seem to be what I want. I expected it to do nothing more than do a bit of creative bit-twiddling on doubles/floats, not try and hijack my stream interface!

Regards, Freddie.

If, as suggested you convert them to strings and then compress then into a zip file, or whatever, before transmission I doubt you will notice a significant overhead on the transmission side. You might even want to write you own compression and decompresion program!!

The header for a zip file is going to be bigger than the contents. In this case they're worried about sending more than 8 bytes at a time. In WinXP if you write eight bytes to a file, and compress it, it becomes 126 bytes. Not a good solution. The only potential gain you'd see would be if you wrote hundreds of them at a time to a file and transfered that way.