p_davis@epik.enet.dec.com (Peter Davis) (09/05/90)
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? Thanks. -pd
p_davis@epik.enet.dec.com (Peter Davis) (09/06/90)
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 . . .
roger@everexn.uucp (Roger House) (09/08/90)
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