Re: g_strcase_hash & G_GET_DOUBLE_LE suggestion

[Tim Janik <timj gtk org>]

On Sun, 15 Aug 1999, Michael Meeks wrote:

>         Secondly, we use a routine that will convert an array of 8 guint8s
> into a double a lot. [ this double written by an x86 eg. as output by
> Excel, Lotus123, DBase etc. ]. Possibly this has a wider application, so I
> have hacked up a second patch implementing a get/set interface for this.
> Unfortunately this is horribly processor specific :-) My current
> reservations are:
> 
>         It will only work on machines that can cope with arbitarily
> aligned double pointers.
>         It assumes that machines write a double as 8 consecutive bytes in
> an endianness comparable to their word writing endianness ( apparently not
> true of the ARM in some cases (?) ).
> 
>         I think neither of these are insuperable, since it is clearly
> possible to write more generic routines for these processors. Arguably the
> generic routines should always be used, but this would create an immense
> performance drop off for most processors. Also much as I love m4 I don't
> know how to hack up an autoconf test for such things.
> 
>         So could these go in glib ? is this the right place ? am I wasting
> my time ?

hi michael,

i remeber us actually discussing this a little on #gnome. back then we
already suggested to provide conversion routines for the ieee754 floating
point formats. after a little investigation (on
http://twister.ou.edu/workshop.docs/common-tools/numerical_comp_guide/ncg_math.doc.html
and reading portions of libm's sources), it actually turns out that intel,
ppc and sparc all use the ieee754 storage format for doubles, so i think
we should add something along the following to glib 1.3:


/* IEEE Standard 754 Single Precision Storage Format (gfloat):
 *
 *        31 30           23 22            0
 * +--------+---------------+---------------+
 * | s 1bit | e[30:23] 8bit | f[22:0] 23bit |
 * +--------+---------------+---------------+
 * B0------------------->B1------->B2-->B3-->
 *
 * IEEE Standard 754 Double Precision Storage Format (gdouble):
 *
 *        63 62            52 51            32   31            0
 * +--------+----------------+----------------+ +---------------+
 * | s 1bit | e[62:52] 11bit | f[51:32] 20bit | | f[31:0] 32bit |
 * +--------+----------------+----------------+ +---------------+
 * B0--------------->B1---------->B2--->B3---->  B4->B5->B6->B7->
 */

#if G_BYTE_ORDER == G_LITTLE_ENDIAN
union GFloatIEEE754
{
  gfloat v_float;
  struct {
    guint mantissa : 23;
    guint exponent : 8;
    guint sign : 1;
  } mpn;
};
union GDoubleIEEE754
{
  gdouble v_double;
  struct {
    guint mantissa_low : 32;
    guint mantissa_high : 20;
    guint exponent : 11;
    guint sign : 1;
  } mpn;
};
#elif G_BYTE_ORDER == G_BIG_ENDIAN
union GFloatIEEE754
{
  gfloat v_float;
  struct {
    guint sign : 1;
    guint exponent : 8;
    guint mantissa : 23;
  } mpn;
};
union GDoubleIEEE754
{
  gdouble v_double;
  struct {
    guint sign : 1;
    guint exponent : 11;
    guint mantissa_high : 20;
    guint mantissa_low : 32;
  } mpn;
};
#else /* !G_LITTLE_ENDIAN && !G_BIG_ENDIAN */
#error unknown ENDIAN type
#endif /* !G_LITTLE_ENDIAN && !G_BIG_ENDIAN */

/* floating point to/from multiple precision number
 */
void    g_ieee_double2mpn (gdouble   v_double,
			   gboolean *sign,
			   gint     *exponent,
			   gint64   *mantissa);
gdouble g_ieee_mpn2double (gboolean  sign,
			   gint      exponent,
			   gint64    mantissa);
void    g_ieee_float2mpn  (gfloat    v_float,
			   gboolean *sign,
			   gint     *exponent,
			   gint     *mantissa);
gfloat  g_ieee_mpn2float  (gboolean  sign,
			   gint      exponent,
			   gint      mantissa);

/* floating point to/from guint8 array (msb)
 */
void    g_ieee_double2buf (gdouble v_double,
			   guint8  buffer[8]);
void    g_ieee_float2buf  (gfloat  v_float,
			   guint8  buffer[4]);
gdouble g_ieee_buf2double (guint8  buffer[8]);
gfloat  g_ieee_buf2float  (guint8  buffer[4]);


if we then actually encounter platforms that don't store their floats and
doubles in ieee format, we can still provide platform dependant conversion
routines.


> 
> 		Michael Meeks.
> 

---
ciaoTJ