Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!pacbell.com!pacbell!barn!everexn!roger
From: roger@everexn.uucp (Roger House)
Newsgroups: comp.graphics
Subject: Re: Graphics Gems: Schneider's FitCurves
Message-ID: <1990Sep8.011536.20449@everexn.uucp>
Date: 8 Sep 90 01:15:36 GMT
References: <1620@shodha.enet.dec.com>
Organization: Everex Systems, Inc.
Lines: 46

In <1620@shodha.enet.dec.com> p_davis@epik.enet.dec.com (Peter Davis) writes:

>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
>            [stuff deleted]


A colleague of mine who develops software as an independent contractor has a
rule which
has saved him from much grief:  Never fix-price a program that will re-
quire more more than 3 lines of code.

A related rule of mine is:  Never write a C program longer than 3 lines with-
out prototyping each and every function, and always use the compiler option
which treats references to non-prototyped functions as errors or warnings.
(If your favorite compiler doesn't have such an option, get another com-
piler.)

						Roger House