Hacker's Delight gives a formula equivalent to this one on page 27: ((x ^ r) & (y ^ r)) < 0
Having said that, I think Florian's assertion that such a rewrite will be faster needs proof. In the original form... (x ^ r) < 0 && (x ^ y) >= 0 ...the first condition will be false half the time for random inputs and (hand-waving) probably a lot more than half the time for typical inputs. To the extent that the difference is measurable at all, I would not like to have to bet on which alternative is faster, and the original form is definitely easier to read as "both arguments have the same sign and the result has the opposite sign." Éamonn On 3 February 2012 09:07, Joe Darcy <joe.da...@oracle.com> wrote: > On 02/03/2012 06:44 AM, Florian Weimer wrote: > >> * Roger Riggs: >> >> The boolean expression can be refactored. (Only bit-31 is significant). >>> But it becomes pretty inscrutable. >>> >>> (x ^ r)< 0&& (x ^ y)>= 0 becomes >>> >>> (x ^ r)< 0&& (~(x ^ y))< 0 becomes >>> >>> ((x ^ r)& ~(x ^ y))< 0 >>> >> That's what I got in my second attempt, too. It doesn't result in a >> longer dependency chain because the left side of the& is two operations >> >> deep, too. Therefore, this version should be faster (at least after >> compilation), independent of the input arguments. >> >> > These sorts of concerns and lovingly (and laboriously!) detailed to Hank > Warren's bit-twiddling tome "Hacker's Delight" (http://www.hackersdelight. > **org/ <http://www.hackersdelight.org/>). > > Roger's initial code used one of the recommend idioms from that source. > We should stick with those idioms unless there is a good reason not to. > > -Joe >
