Playing with the bits of floats

[Herman Rubin]

In article <9404 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn ) writes:
> In article <1096 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
> >> In article <MAX.89Jan13163256 at george.lbl.gov> max at george.lbl.gov (Max Rible) writes:
> >> >I'm trying to do deal with floating point numbers as if they're ints.
> >< <Things like "if(((3.1 - 3.14) & 0x7FFFFFF) <= 0.1)"--- lousy
> >< <programming style, I know, but I'm interested in speed, not
> >< <portability for this application.
> >I agree that every language should make it easy for the knowledgeable
> >programmer to do these things, but I am afraid the movement is in the
> >opposite direction.
> 
> I utterly disagree.  Generating efficient code for routine floating-point
> operations is the job of the compiler, not the high-level programmer.
> There is no reason why, if the suggested replacement test represents the
> most efficient code for the test, that the compiler should not generate
> it in the first place.

Clearly the compiler writers and language designers did not think that the
operations Max wants to use are routine.  I am not even sure that Max thinks
they are routine, but he wants to use them.  I find myself in this position
often, and I have so stated.  There are routine operations on both bit patterns
and floating-point numbers which are not in many languages; remember the
discussion in this group about the power OPERATOR.

Also, the particular situation may be highly non-portable.  Note that Max 
has stated that he wants speed, and not necessarily portability.

> There are a few cases, such as dealing with IEEE-754 NaNs, where bit
> patterns are necessary.  C vendors on such systems have, quite properly,
> provided the necessary support as macros or functions, so the programmer
> still need not concern himself with bit-twiddling.

Macros can be so clumsy as to be almost useless.  I do not see how to treat
a double float in registers as a pair of integers by anything provided in 
the C language.  Function calls can be quite slow, and usually are, and can
even take more space than inlining.  As I see the application cited, the
cost of the procedure inlined is less than the cost of moving the arguments
for processing by the function and moving the result back.

Max wants to do in one or two instructions what the has not been provided
for in the language.  As I read Doug's remarks, he feels that this is
inappropriate.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (Internet, bitnet, UUCP)