From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: NO NUMBERS! (or even SHORT INTS!)
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Wed, 7 Oct 1992 05:05:08 GMT

Replies to three unrelated articles in this thread...

In article <1992Oct3.173435.417@mnemosyne.cs.du.edu> jcastner@nyx.cs.du.edu (John Castner) writes:
>In article <kaufman.718082916@Xenon.Stanford.EDU> kaufman@CS.Stanford.EDU writes:
>>GMST = 24110.54841 + (8640184.812866 + (0.093104 - 6.2e-6 * Tu) * Tu) * Tu;
>>which is the equation for the relationship between Greenwich mean sidereal
>>time and Universal time. (or was in 1985).  I could also post the equation
>>for the nutation of the Moon, which has 19 terms.  Surely you don't expect
>>someone to define constants for each of them...
>
>I would guess that if you were writing a program with this expression, you
>would be likely to need these numbers again.  Even if you didn't need
>them anywhere else, constants would be nice.  Or better yet, since these
>numbers had to come from some equation, probably other than this one,

I have to agree with Mr. Castner.  In fact, he even gave another example
to help prove it, but forgot to remark on it:
>|jcastner@nyx.cs.du.edu                        |
>|  186,000 miles per second:                   |
>|    It's not just a good idea; it's the law.  |

Someday someone might want to change this constant to a more accurate
value, right?  Wouldn't it be nice if the constant were specified once
in a location more suitable for constant specifications?

In article <1ao349INNbb2@uwm.edu> markh@csd4.csd.uwm.edu (Mark) writes:
>In article <mcdonald.355@aries.scs.uiuc.edu> mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
>>OK look at this, which, like the nutation of the moon, is a better example
>
>It's a mistake precomputing all the 85 magic numbers in the calculations of
>this routine -- that's what the computer is for.  Likewise, it's a mistake to
>use a source the precomputes those numbers
>
>There's no reason not to step back to the perturbation theory itself and
>write the program directly on the basis of that, integrating the necessary
>Fourier Series calculations right into the software itself.  You don't need
>to precompute Fourier coefficients any more.

I have to agree with Mark too.  After all, look at this:
>#include <math.h>
>#include <float.h>
>typedef struct { double X, Y; } Vector;
[...]
>#define R 6378000.0
>#define PI 3.1415926

It's a mistake to precompute this too, especially when 3.1415927 would be
slightly more accurate than 3.1415926.  Shouldn't you include code to
compute PI as accurately as possible?

>   tR = atan2(r.Y, r.X)*180.0/PI; mR = sqrt(r.X*r.X + r.Y*r.Y);

Or better yet, to compute 180.0/PI as accurately as possible?

In article <1992Oct4.220604.989@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:
>Hmm... perhaps it was in _Elements of Programming Style_?
>Anyway, it said it was appropriate to have exactly 3 numbers in your program:
>zero, one, and many.                              ---
                                                   ---
Exactly how many numbers, did you say?  Uh, suppose I want to write a program
to read your program and check on how many numbers your program has?  :-)
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."