Re: g_strcase_hash & G_GET_DOUBLE_LE suggestion

[Michael Meeks <michael imaginator com>]

On Mon, 16 Aug 1999, Tim Janik wrote:
> 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:

	Great :-) There are several issues that concern me however.

	* I don't understand why you include the unions ? do you propose
to use these in the API or internaly ? I wasn't clear on that.

	* endianness plays a large part in the ordering of the byte
array's mapping onto the 0-31 / 0-63 bits of the floating point number,
and these routines would only read from a LE arrangement.

	* I am worried about the large performance drop on LE machines
where these types can be arbitrarily aligned ( eg. intel :-). The kind of
code to write generic safe routines to do 64bit double reads become very
FPU intensive, maybe two orders of magnitude slower than a straight
pointer cast.

	* I don't know how useful access to individual fields of the IEEE
number will be ? it would be nice not to have to solve a problem that
doesn't exist :-) My application has no use for this, do you have
something in mind ?

	So, after resolving all these issues shall I hack something up ?
and what was the concensus on committing the strcase_hash ? ( for hashing
a load of strings whose case we wish to preserve )
	
> 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.

	Sure. Having played with autoconf some more, I'm beggining to
think it would be possible to write a nice macro to test for arbitary
double / float alignment but its a fair bit of work I don't want to
duplicate by accident.

	Thanks,

		Michael.

-- 
 michael@imaginator.com  <><, Pseudo Engineer, itinerant idiot