On Mon, Jul 02, 2012 at 11:18:21PM -0400, David Higgs wrote: > On Mon, Jul 2, 2012 at 10:49 PM, Michael W. Bombardieri <m...@ii.net> wrote: > > On Tue, Jul 03, 2012 at 02:03:39AM +0000, Dave Hart wrote: > >> On Tue, Jul 3, 2012 at 01:49 UTC, Michael W. Bombardieri <m...@ii.net> > >> wrote: > >> > Sorry, my fault. The intent was bitwise-and not bitwise-or. > >> > Third version of the diff follows. > >> > In regards to hand optimisations, we could be even worse > >> > and do something like add rn_id values, subtract rn_len, check > >> > if zero. :) > >> > >> I don't understand why you don't simply write the obvious comparison > >> of each to 1 for equality, anding them together logically, and let the > >> compiler play the bit-twiddling games. Bitwise and will be correct, I > >> believe, but obfuscated in a place where micro-optimization seems > >> pointless. The same goes for the add then subtract alternative. > > > > I automatically typed the bitwise code, either because it seems somehow > > simpler, or because it's marginally less typing. Something like the > > following might be easier for people to read. I don't have a strong > > opinion on this in any case. > > > > #define RCSNUM_ISDEFBRANCH(n) \ > > ((n)->rn_len == 3 && (n)->rn_id[0] == 1 \ > > && (n)->rn_id[1] == 1 && (n)->rn_id[2] == 1) > > Um... Bitwise-or, bitwise-and, summing, and the triple equality test > are not equivalent. Unless you intend to match things other than > 1.1.1, only the latter is correct. Please refrain from optimizing > until you understand why.
Noted. I will go back to my corner. > > --david
