Path: utzoo!attcan!uunet!samsung!sdd.hp.com!decwrl!bacchus.pa.dec.com!shodha.enet.dec.com!epik.enet.dec.com!p_davis
From: p_davis@epik.enet.dec.com (Peter Davis)
Newsgroups: comp.graphics
Subject: Re: Graphics Gems: Schneider's FitCurves
Message-ID: <1620@shodha.enet.dec.com>
Date: 6 Sep 90 16:30:02 GMT
Sender: news@shodha.enet.dec.com
Organization: Digital Equipment Corporation
Lines: 43


In article <1608@shodha.enet.dec.com>, p_davis@epik.enet.dec.com (Peter Davis) 
writes...
> 
>Has anyone tried using Philip J. Schneider's FitCurves program, as included 
>Andrew Glassner's Graphics Gems?  I just put a quick hack X and Display 
>PostScript UI on it to try to see if it could be used for automatic smoothing 
>of freehand curves.  However, the curves which this program generates seem
>to be identical to a polyline which simply connects the sample points.  I've
>tried varying the "error" value from 4 to 40000 with no discernable effect.
> 
>Can anyone explain this?
> 

Well, Philip Schneider himself answered me on this, and here is his 
explanation (re-printed without permission ... I hope it's ok, Philip):

===========================================================================

    OK, I've tracked down the bug(s).  The various routines in the 
"GGVecLib" library return all sorts of values, such as double, or
Vector2, or Point2, etc.  However, the header file "GraphicsGems.h"
only defines the data structures and a few "#define" macros, and does
*not* declare the routines.  The result is that (this being C and all :-)
these routines are assumed by the compiler to be of a type that return
integers.  C, of course, lets you do this sort of thing without
complaining.

    So, if you call a routine that has not been previously declared
to return, say "double", the return value is assumed to be an integer.  For
doubles such as, say 6.5, the "integer" interpretation of this is 0 (zero).
(Sorry to sound pedantic here . . . I assume of course that you know this
in general :-)  I found this error in the "ChordLengthParameterize"
routine, where all the inter-point distances were being returned as "0",
which isn't right at all.  I found all the places where routines were
being (incorrectly) assumed to being of sort that returned integers, and
put the proper forward declarations in, so that the routines would be
known to the compiler to be of the sort that returned double (or whatever
was correct).  

    In addition to this problem, "GraphicsGems.h" doesn't include "math.h",
so functions like "sqrt()" were also assumed to be returning integers, with
the same sort of wrong results . . . So, I fixed this, too . . .