Path: utzoo!mnetor!uunet!husc6!bbn!rochester!PT.CS.CMU.EDU!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.lang.c
Subject: Re: How not to write a loop
Message-ID: <1192@PT.CS.CMU.EDU>
Date: 22 Mar 88 15:01:59 GMT
References: <296@draken.nada.kth.se> <64400004@convex> <7409@brl-smoke.ARPA> <947@micomvax.UUCP>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 29

> >
> >This is of course wrong.  Floating-point imprecision is not due
> >simply to float<->double conversion, but is inherent in the
> >whole approach.
> 
> Yup.  Interestingly, this is one of the very first things I can remember
> being taught in "computer science" - NEVER test "reals" against absolute
> values - choose a precision and test against values +/- that precision.

One of the "tricks" I do when optimizing code is handling typical cases
different from the general case.  In particular, I do alot with
3-d geomety and 3-d rotations.  The typical transform case has zero roll and
pitch angular rotations (x and y axis rotations).  Its to my benefit
to test for this situation and handle it differently.  The test
I use is a direct equality test to see if the roll and pitch angles
are zero and if so only perform a rotation about the z-axis.
I have no problems with this on my Sun.  Profiling has shown that this
test does decrease the time spent in the routine that performs
the rotation.  I'm hesitant to use an approximately equal test
because it is more expensive to execute. Besides if the test fails
because of numerical imprecision when it actually should have succeeded
I still get the same result, it just takes a few more instructions to
calculate it.  So the point being made, well, NEVER SAY NEVER. :-)

BTW I don't use homogeneous transforms because the transform parameters
have covariances associated with them.
-- 

Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu