"John F. Woods" sez:
/*
 * I could easily see what is "horrific" about code that requires several
 * programmers tens of minutes to decode, but I fail entirely to see what
 * is "horrific" about code which can be easily understood and maintained.

Point taken as long as the performance degradation is truly acceptable
("cheapness of disk space, processor speed and core do not justify
 shoddy programming" where "shoddy" == "uses more resources than
 necessary") and/or negligible (as you seem to have shown):

 * 
 * Which, by the way, on my 486 appears not to be noticably slower than
 * the so-called "quick" version:  in a quick test program, running 10,000,000
 * loops of ten tests each (unoptimized), the difference in runtime is about
 * 1 second (I'd have to drop into single user mode to get good, repeatable
 * numbers) or about 10 nanoseconds each.  Which is very curious, since I don't
 * have a 100MHz clock.  I seriously doubt that I have run atan2() frequently
 * enough that the difference would have added up to as much time as people
 * spent tracking this down and fixing it -- and I have run a LOT of SPICE
 * jobs.
 */

Hey, if it works and doesn't overly gum up the works, great.

I sure couldn't take that attitude with the kernel, though
(it's already causing problems with the sun4c serial ports).



				--*greywolf;
--
"Your chief has even inscribed his name on the sole of my boot."