Path: csiph.com!x330-a1.tempe.blueboxinc.net!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Jeff Higgins Newsgroups: comp.lang.java.programmer Subject: Re: boolean to int : was char to decimal Date: Mon, 09 May 2011 20:51:55 -0400 Organization: A noiseless patient Spider Lines: 59 Message-ID: References: <92ea64F3avU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 10 May 2011 00:49:44 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="66+B4XK2fUYI7mQKoMaOgA"; logging-data="10597"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX197eUyDsOr5y3QJvDc41PPnBcs9qSQbddo=" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:z5C2W6WokTdQmU/iO0x/aEo4p9o= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3883 On 05/09/2011 12:51 PM, Michael Wojcik wrote: > Jeff Higgins wrote: >> Yes, the nested if/else seems more clear in the above short example. > > 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.) Yes, a hasty post. >> Now I wonder about the original author's motivation for >> the use of switch statement. Code clarity, optimization, idiomatics? > > 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. Yes. I believe that if I had spent even a few more moments studying I would have come up with markspace's one line solution. Nigel Wade's one liner would have likely escaped me. Very nice. Thanks to both. > 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. My translation of Maxim Shemanarev's code seems to run without a hitch in an interactive Swing panel. 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. Thanks for the discussion, much appreciated.