why is eccentricity of zero an error?

[Jim Aanstoos (919) 541-6890]

> With repect to what program is a zero eccentricity or 1/f in error??

I encountered the problem using m.datum.shift (in GRASS 4.1);
however,  after tracing it to some routines in the GRASS gis
library I suspect it may affect other modules that use these
functions as well. 

Upon investigating further, I have discovered that the routine
G_get_ellipsoid_parameters(a,e2) in that library has code
which traps the name 'sphere' and hard-codes its values of
a (radius) and e2 (eccentricity squared, which is set to zero in this
case).  This bypasses the call to G_get_ellipsoid_by_name which
reads spheroid parameters from a table, rejecting any for
which e is less than or equal to zero.  I don't know why this
one  ellipsoid was hard-coded and why the table entries are
rejected if e = 0.  Since some modules (m.datum.shift, for one)
call G_get_ellipsoid_by_name directly, the hard-coding of
'sphere' in G_get_ellipsoid_parameters does not get around
this limitation.  Entering 'sphere' for one of the spheroid
arguments of m.datum.shift causes a "value out of range" error
since the parser uses the entries in the ellipse.table file,
but creating a 'sphere' entry in that file causes another
error if e=0.  Catch-22, n'est-ce pas?

Perhaps I will report it as a bug, but I thought I'd try to
get a handle on what's going on and why first.
 
-- jim A.