Path: utzoo!attcan!uunet!tank!shamash!nic.MR.NET!csd4.milw.wisc.edu!mailrus!tut.cis.ohio-state.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Playing with the bits of floats
Message-ID: <9404@smoke.BRL.MIL>
Date: 17 Jan 89 16:29:24 GMT
References: <MAX.89Jan13163256@george.lbl.gov> <1825@dataio.Data-IO.COM> <1096@l.cc.purdue.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: comp
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <1096@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>> In article <MAX.89Jan13163256@george.lbl.gov> max@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.

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.