J
Jeff Higgins
void curve4_div::recursive_bezier
Oops, attribution; sorry
<http://www.antigrain.com/__code/src/agg_curves.cpp.html>
void curve4_div::recursive_bezier
Hmm, some of the Wikipedia-pages you gave us were quite explicit that
these things were rather a matter of typography than of orthography.
Jeff said:Yes, the nested if/else seems more clear in the above short example.
Now I wonder about the original author's motivation for
the use of switch statement. Code clarity, optimization, idiomatics?
Michael Wojcik said:It's unlikely a Java implementation will benefit detectably from
anything other than the straightforward cascading-if-else design.
Certainly that would be the one to start with, and only investigate
alternatives if performance is a problem and profiling indicates this
is a useful target for optimization.
And that shows why context is often important in a question of coding
style. Your short example contained nothing that could justify the odd
use of the switch statement. (And your Java version made even less
sense, since it lost the C++ boolean-int conversions and symmetry.)
It looks to me like the C++ code may have been based on a C
implementation of the algorithm, which would have been a bit simpler,
since the int casts would have been unnecessary:
switch (((d2> curve_collinearity_epsilon)<< 1) +
(d3> curve_collinearity_epsilon)) {
I would have preferred binary-or there rather than addition, for
clarity, but either works.
And that, in turn, may have come from a description of the algorithm
that treated the two tests for inner-point collinearity as a pair of
bits (which is what this code is doing). Or it may have originally
been implemented on a processor where {test, test, shift, add,
computed-goto} was a faster sequence than {test, branch, test,
branch}. Bezier-curve rendering is a plausible target for optimization.
Or it may just be idiosyncrasy, particularly since this is a directly
recursive implementation, which seems likely to dwarf any savings from
fooling with the collinearity tests.
It's unlikely a Java implementation will benefit detectably from
anything other than the straightforward cascading-if-else design.
Certainly that would be the one to start with, and only investigate
alternatives if performance is a problem and profiling indicates this
is a useful target for optimization.
switch (((d2 > curve_collinearity_epsilon) << 1) +
(d3 > curve_collinearity_epsilon)) {
I would have preferred binary-or there rather than addition, for
clarity, but either works.
Lawrence said:Using the bitwise operator allows you to remove some parentheses.
Jeff said:Roedy Green sparked my interest in this subject in a recent cljh post.
My original question was: Will the AGG algo produce a 'nicer' curve
than Java's FlatteningPathIterator? The answer so far is yes and no.
My interest has now expanded. Starting here, I've a ways to go.
<http://www3.villanova.edu/maple/misc/history_of_curvature/index.htm>
Whether that makes the overall expression easier to read is a subjective
question, but I'd probably go with removing the unnecessary parentheses,
particularly with the two subexpressions on separate lines (assuming
we keep the formatting).
switch
(
(d2> curve_collinearity_epsilon)<< 1
|
(d3> curve_collinearity_epsilon)
)
For my own future reference:Roedy Green sparked my interest in this subject in a recent cljh post.
My original question was: Will the AGG algo produce a 'nicer' curve
than Java's FlatteningPathIterator? The answer so far is yes and no.
My interest has now expanded. Starting here, I've a ways to go.
<http://www3.villanova.edu/maple/misc/history_of_curvature/index.htm>
For my own future reference:
<http://home.comcast.net/~k9dci/site/?/page/Piecewise_Polynomial_Interpolation/>
Some help with curves for those of us with severe mathematical disabilities.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.