luj@gus16.ecn.purdue.edu (Jun Lu) (11/26/90)
Is there a quick/neat way to passing floats in inet socket-based IPC, just like we "routinely" do for passing ints on "popoular" architectures( with just some hton or ntoh conversions) ? The two processes, as indicated by "inet", may run on two different plateforms. One very portable and safe way for passing floats is, as I can see, is to convert floats to ascii representations before sending them across the network and on the other end convert the ascii strings back to floats using strtod(). But the disadvantages are that this consumes more message space than necessary and also incurs the overhead of converisons between ascii and floats. Are the any better alternatives ? Thanks for any info/pointers in advance. -- -- Jun Lu Internet:luj@ecn.purdue.edu -- -- Aeronautics & Astronautics Bitnet: luj%ecn.purdue.edu@purccvm -- -- Purdue University UUCP: pur-ee!luj -- -- W. Lafayette, IN 47907 Phone:317-494-9410 Fax:317-494-0307 --
henry@zoo.toronto.edu (Henry Spencer) (11/30/90)
In article <1990Nov26.164122.6152@noose.ecn.purdue.edu> luj@delta.ecn.purdue.edu (Jun Lu) writes: >Is there a quick/neat way to passing floats in inet socket-based IPC, just >like we "routinely" do for passing ints on "popular" architectures( with >just some hton or ntoh conversions) ? In a word, no. There is too much diversity in floating-point formats to admit of any graceful general solution that's also quick and simple. About the best you can do is convert to IEEE format, since that conversion is a no-op on increasingly many machines, and then deal with the byte order in much the same way as for integers. However, conversions to and from IEEE format can be costly on non-IEEE machines. ASCII is probably simpler unless you've got pre-canned IEEE conversions (which I believe XDR does). -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry
gwyn@smoke.brl.mil (Doug Gwyn) (11/30/90)
In article <1990Nov29.224651.26522@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1990Nov26.164122.6152@noose.ecn.purdue.edu> luj@delta.ecn.purdue.edu (Jun Lu) writes: >>Is there a quick/neat way to passing floats in inet socket-based IPC, just >>like we "routinely" do for passing ints on "popular" architectures( with >>just some hton or ntoh conversions) ? >In a word, no. There is too much diversity in floating-point formats to >admit of any graceful general solution that's also quick and simple. What I do is to split the float into integral exponent and significand, using the UNIX library functions that support that (frexp et al.). There are some details to be considered but that's the essence.
jim@segue.segue.com (Jim Balter) (12/01/90)
In article <1990Nov29.224651.26522@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1990Nov26.164122.6152@noose.ecn.purdue.edu> luj@delta.ecn.purdue.edu (Jun Lu) writes: >>Is there a quick/neat way to passing floats in inet socket-based IPC, just >>like we "routinely" do for passing ints on "popular" architectures( with >>just some hton or ntoh conversions) ? > >In a word, no. There is too much diversity in floating-point formats to >admit of any graceful general solution that's also quick and simple. It wouldn't be hard to put together routines that convert to/from a canonical bit representation from/to the native architecture. The bits would be packed into bytes (either hi bit first or lo bit first, pick the convention). A simple representation for floating point would consist of an exponent sign, a variable length exponent, a mantissa sign, and a variable length mantissa. If numbers are restricted to normalized form, the high-order bit of the mantissa can be suppressed ("hidden" in the usual terminology). A simple way to encode variable length bit sequences is to add a 0 after any occurrence of 11 and terminate the sequence with 111. The conversion is certainly slower than swapping bytes, but beats the heck out of ASCII, and is much more compact (in fact, many numbers are smaller than their fixed-width representations). Base-10 ASCII is the worst possible representation because conversion between base 10 and base 2 floats is either very expensive and loses precision, or mind-bogglingly expensive and doesn't (arbitrary base 10 can't be converted intact to base 2, but of course those that already represent base 2 values can, but it requires multi-precision multiply, and the base 10 ASCII strings can be rather long).