Basic bits operation

[philbo30]

Simple question, I think:

I have a known byte, "byte 1":

0000 0100

and a known portion of an unknown byte, "byte 2":

bbbb 0100

I need to compare the lower 4 bits (0100) of each and determine if
"byte 1, lower 4" == "byte 2, lower 4".


What's the most efficient way?

 

[Ian Collins]

Simple question, I think:

I have a known byte, "byte 1":

0000 0100

and a known portion of an unknown byte, "byte 2":

bbbb 0100

I need to compare the lower 4 bits (0100) of each and determine if
"byte 1, lower 4" == "byte 2, lower 4".


What's the most efficient way?

(a&0x0f) == (b&x0f)

 

[Ian Collins]

(a&0x0f) == (b&x0f)

Oops, (a&0x0f) == (b&0x0f)

 

[Army1987]

Simple question, I think:

I have a known byte, "byte 1":

0000 0100

and a known portion of an unknown byte, "byte 2":

bbbb 0100

I need to compare the lower 4 bits (0100) of each and determine if
"byte 1, lower 4" == "byte 2, lower 4".


What's the most efficient way?

Use byte2 & 15 (or equivalently byte2 % 16, in this case) to
isolate the lower four bits. Then compare the lower four bits of
byte2 with the lower four bits of byte1 (remember that == binds
more tightly than &, so make sure you have enough parentheses), or
directly with 8 if you know that byte1 is always 8.

 

[CBFalconer]

I have a known byte, "byte 1": and a known portion of an unknown
byte, "byte 2":

I need to compare the lower 4 bits (0100) of each and determine
if "byte 1, lower 4" == "byte 2, lower 4".

What's the most efficient way?

if ((b1 ^ b2) & 0x0f) /* bit fields unequal */ ;
else /* bit fields equal */ ;

 

[Dan Henry]

Oops, (a&0x0f) == (b&0x0f)

!((a ^ b) & 0xF)

Will also work. Efficiency is architecture dependent, so test for it.

 

[Coos Haak]

Op Sun, 12 Aug 2007 01:18:29 +0200 schreef Army1987:

Use byte2 & 15 (or equivalently byte2 % 16, in this case) to
isolate the lower four bits. Then compare the lower four bits of
byte2 with the lower four bits of byte1 (remember that == binds
more tightly than &, so make sure you have enough parentheses), or
directly with 8 if you know that byte1 is always 8.

The byte maybe a signed char. If it holds a negative value, the remainder
after % is negative too ;-) Better use & here.

 

[Richard Bos]

!((a ^ b) & 0xF)

Will also work. Efficiency is architecture dependent, so test for it.

I'd never use that code unless it were shown with absolute certainty to
be a bottleneck. It's highly unclear compared Ian's. _If_ you can show
that the program is unacceptably slow with Ian's version, and fast
enough with yours, then I'd still first look for a better algorithm; and
only if that cannot be found, I'd use your version, and add a big
comment explaining why I didn't use the obvious code.

Richard

 

[CBFalconer]

I'd never use that code unless it were shown with absolute
certainty to be a bottleneck. It's highly unclear compared Ian's.
_If_ you can show that the program is unacceptably slow with
Ian's version, and fast enough with yours, then I'd still first
look for a better algorithm; and only if that cannot be found,
I'd use your version, and add a big comment explaining why I
didn't use the obvious code.

What's unclear? The xor isolates the different bits (if any), and
the mask constrains the consideration to the lower 4 bits. It
avoids the non-vanishing probability of the compiler masking both
operands separately. I believe the original post specified that
speed was important.

 

[Dan Henry]

I'd never use that code unless it were shown with absolute certainty to
be a bottleneck.

Me either and then I would. The OP asked for efficiency. I posted an
alternative expression to Ian's. I don't know the OP's architecture
or toolchain. If the OP is concerned about efficiency, let the OP
test it.

It's highly unclear compared Ian's.

Yes, oh dear, highly obscure, yet it was clear enough for my feeble
brain to recognize as an alternative. Strength in clarity compared to
Ian's was not a consideration for me.

_If_ you can show
that the program is unacceptably slow with Ian's version, and fast
enough with yours, then I'd still first look for a better algorithm; and
only if that cannot be found, I'd use your version, and add a big
comment explaining why I didn't use the obvious code.

I cannot do that for you and am not particularly motivated to do so. I
don't know the OP's architecture or toolchain. Was that tiny
expression obfuscated to the point of being incomprehensible at a
casual glance? I'd guess that you have run across the '&' operator
before, so was it the '^' (exclusive-or) operator that threw you?

I certainly have no investment in what I posted and simply supplied an
alternative expression. Is that not allowed here? I was kind of
C-like, after all.

 

[Dan Henry]

I'd never use that code unless it were shown with absolute certainty to
be a bottleneck.

The OP asked "What's the most efficient way?". This alternate way
might be more efficient on some architectures and should be tested to
see.

It's highly unclear compared Ian's.

It might be unclear to yet-another-general-ledger application writers,
but to folks that work close to the hardware, it is an instantly
recognizable and commonly used expression that certainly does not
merit a "big comment". We use bitwise operators all the time.

_If_ you can show
that the program is unacceptably slow with Ian's version, and fast
enough with yours, then I'd still first look for a better algorithm; and
only if that cannot be found, I'd use your version, and add a big
comment explaining why I didn't use the obvious code.

Right, you don't like it. I can tell. We travel in different
circles.

 

[Richard Bos]

I cannot do that for you and am not particularly motivated to do so.

You can't do it for anyone but yourself.

I don't know the OP's architecture or toolchain. Was that tiny
expression obfuscated to the point of being incomprehensible at a
casual glance? I'd guess that you have run across the '&' operator
before, so was it the '^' (exclusive-or) operator that threw you?

Let's put it this way. Your line was immediately obvious at a moment's
thought. Ian's line was immediately obvious _without_ having to think
about it. Unless there is clear evidence that your version is more
efficient in a particular situation, I'd prefer not having to think
about individual lines of code, so I can focus my thought on what the
program actually does.

Richard

 

[Dan Henry]

Let's put it this way. Your line was immediately obvious at a moment's
thought. Ian's line was immediately obvious _without_ having to think
about it.

Too bad for me that the patent period has expired without my having
taken advantage of this (by my 30-year observation) most common form
of I/O port change detection logic. I and those around me *instantly*
recognize the expression (i.e., *without* a moment's thought).

"I pray Thee Lord, from this point forward, I promise to try to be
more tolerant of those who, through no particular fault of their own,
might take pause 'to think about it' when seeing 'my line'. I pray
that you give me strength when seeing 'my line' promulgated
world-wide, but without my benefit. I will strive to keep my wits and
mental balance despite the intolerable anguish of realizing my lost
opportunity by not legitimately claiming it as 'my own'. You tested
Job, now test me. I pray that I remain worthy."

Amen

 

[Richard Bos]

Amen

*Plonk*

Richard

 

[Richard]

*Plonk*

Richard

All the guy did, with an explanation, was to explain why he gave the
alternate expression.

 

[Dan Henry]

All the guy did, with an explanation, was to explain why he gave the
alternate expression.

Alternate expressions seem to be allowed in c.l.c. It could have been
that obscure exclusive-or operator that derailed him. No wait -- I
see that mere moments apart CBFalconer and I both used the offensive
exclusive-or operator, yet CBF got away with it scot-free. Methinks
there is some mighty fishy selective tolerance going on here!

Seriously though, no worries. I think Mr. Bos is better off no longer
reading my posts. My day-to-day use of C for working directly with
hardware exposes me to the kinds of expressions and usage patterns
that he apparently finds to be uncommon. If he were to read my future
posts, we'd likely have similar silly exchanges again. His killfiling
me now will avoid that, so I'm content with the quick action he has
taken.

 

[Richard Heathfield]

Dan Henry said:

Alternate expressions seem to be allowed in c.l.c.

Indeed they are.

It could have been
that obscure exclusive-or operator that derailed him.

It will take more than an XOR to derail Richard Bos.

No wait -- I
see that mere moments apart CBFalconer and I both used the offensive
exclusive-or operator, yet CBF got away with it scot-free. Methinks
there is some mighty fishy selective tolerance going on here!

FWIW I had no problem reading your expression (although I must admit I
prefer foo == 0 to !foo). Nor did Richard Bos - you can be sure of
that. He rightly enjoys a great deal of respect in this newsgroup for
his C knowledge, and would have had no trouble working out what your
code means. He just didn't think it was as self-evident as the code
that preceded it in the thread. But Richard Bos doesn't have a monopoly
on what is considered good code. It is purely a style issue, and
opinions on style vary widely within this group.

Seriously though, no worries. I think Mr. Bos is better off no longer
reading my posts.

He plonked you not for your code but for your ill-considered "prayer"
response, which seemed to suggest that you were more interested in
mockery than in thought. I hope that that response was merely a
temporary aberration.

<snip>

 

[pete]

Alternate expressions seem to be allowed in c.l.c.

I liked your ^ expresssion good enough.
It had a thoughtful comment about speed to go with it.
I don't consider ^ to be much more cryptic than &.
The thread subject was "Basic bits operation";
I wouldn't expect that to mean "& and nothing else"

But like Mr. Heathfield said,
I think it was your witty sarcasm that got the plonk.

I've indulged in witty sarcasm a lot on this newsgroup,
but I know that it's not good to do.

 

[Richard Heathfield]

pete said:

I've indulged in witty sarcasm a lot on this newsgroup,

Well, half-witty, anyway.

And having failed to resist writing this reply, I will now try very hard
to resist posting it.

 

[pete]

pete said:



Well, half-witty, anyway.

And having failed to resist writing this reply,
I will now try very hard to resist posting it.

My posts that I *have* discarded before sending, oh boy, oh boy...