Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!randvax!segue!jim
From: jim@segue.segue.com (Jim Balter)
Newsgroups: comp.unix.questions
Subject: Re: passing floats in inet socket-based IPC
Message-ID: <4903@segue.segue.com>
Date: 1 Dec 90 14:32:24 GMT
References: <1990Nov26.164122.6152@noose.ecn.purdue.edu> <1990Nov29.224651.26522@zoo.toronto.edu>
Reply-To: jim@segue.segue.com (Jim Balter)
Organization: Segue Software, Inc. - Santa Monica, CA. +1-213-453-2161
Lines: 26

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).