A way to bitwise AND two int's

[Henry Padilla]

I'm writing a map generator and I'm looking for a way to keep track of the
various terrain. I had a thought of using bitboards but I can't find a way
to bitwise AND two int's together and get a bool.

How do I get the proper response from:
IF (0x01 & 0x05)

My only recourse so far is to use the full if syntax:
IF ((0x01 & 0x05) > 0)

Is that any faster or slower than the first way?
Is this really the only way to do this?

Thanks for the help,
Tom P.

 

[Larry Lard]

I'm writing a map generator and I'm looking for a way to keep track of the
various terrain. I had a thought of using bitboards but I can't find a way
to bitwise AND two int's together and get a bool.

How do I get the proper response from:
IF (0x01 & 0x05)

What's "the proper response" ? If you bitwise AND two int's, you get an
int. Which ints do you want to count as 'true' ?

My only recourse so far is to use the full if syntax:
IF ((0x01 & 0x05) > 0)

Oh, you want positive ints to count as true. Well, you seem to have
solved your problem!

Is that any faster or slower than the first way?

The first way doesn't compile, so is infinitely slow.

Is this really the only way to do this?

There are usually many ways to do things in C#. But if you want to see
if two ints have any set bits in common, this seems the obvious way.

 

[Guest]

I'm writing a map generator and I'm looking for a way to keep track of the
various terrain. I had a thought of using bitboards but I can't find a way
to bitwise AND two int's together and get a bool.

How do I get the proper response from:
IF (0x01 & 0x05)

My only recourse so far is to use the full if syntax:
IF ((0x01 & 0x05) > 0)

Is that any faster or slower than the first way?
Is this really the only way to do this?

C# enforces stricter typing than C/C++ do, the first won't compile because
bools and ints are diffrent types. Did you try casting the result?

if ((bool)(0x01 & 0x05))

Don't know if it'll be allowed or not. IF not you'll have to do some
variant of the 2nd.

PS despite the C syntax, c# casting is typesafe.

 

[Henry Padilla]

What's "the proper response" ? If you bitwise AND two int's, you get an
int. Which ints do you want to count as 'true' ?

As defined by Kernighan and Ritchie (in 1970 or so) any non-zero is true. I
thought this was pretty well accepted in the programming community at large,
are you being snide and obtuse for a reason? Or do you not know how to use
a simple bitmask and are taking it out on me?

Oh, you want positive ints to count as true. Well, you seem to have
solved your problem!

Yet yours seems to linger. If you read the second sentence in my post you
will see I am trying to get a bool. The part that says "bitwise AND two
int's together and get a bool" was a dead giveaway. This is quite a simple
opperation in C/C++And don't see why it needs to be complicated.

The first way doesn't compile, so is infinitely slow.

This does not address the question of any ways faster than this. Nor why
you insist on these side quests to deride a simple question. Do you just
not know the answer?

There are usually many ways to do things in C#. But if you want to see
if two ints have any set bits in common, this seems the obvious way.

And you had to go through all that to tell me this? Man, it's a good thing
I didn't ask a difficult question, it would have taken months of side notes.

In as much as you have helped not at all, thank you. In the future, if this
is the best you can do please keep your misguided attempts at comedy to
yourself. You are, in point of fact, not good at it.

Tom P.

 

[Henry Padilla]

C# enforces stricter typing than C/C++ do, the first won't compile because
bools and ints are diffrent types. Did you try casting the result?

if ((bool)(0x01 & 0x05))

Yes, it still won't do it. I finally found, after searching the depths of
the unhelpful file, that C# does not support "non-zero true".

The only way to do it is the 2nd way I described.

Don't know if it'll be allowed or not. IF not you'll have to do some
variant of the 2nd.

PS despite the C syntax, c# casting is typesafe.

Thanks again for the help.
Tom P.

 

[Jesse McGrew]

Yes, it still won't do it. I finally found, after searching the depths of
the unhelpful file, that C# does not support "non-zero true".

One pleasant side effect of this rule is that most errors of this form
won't compile:

if (value = 15) { ... }

Jesse

 

[Marc Gravell]

Ignoring the "humour" (sorry Henry, but despite your protestations Larry's
comments did raise a chuckle), your "solution" is not quite correct to the
pedant:

you've written:

"if ((0x01 & 0x05) > 0) {}"

and complained that

"As defined by Kernighan and Ritchie (in 1970 or so) any non-zero is true."

That being the case, you should probably be testing with !=0

Marc

 

[Larry Lard]

As defined by Kernighan and Ritchie (in 1970 or so) any non-zero is true. I
thought this was pretty well accepted in the programming community at large,
are you being snide and obtuse for a reason?

I must apologise for the excessive snideness, it's been a trying day. I
am usually much less snide (some, but not so much). And I try to avoid
all snideness when, unlike here, actual education is in order. You
clearly know what you are doing, so I went without the didacticism in
favour of a more jocular approach.

I will restrict myself to one final observation: K&R were talking about
C. C# is not C, and one of the differences is that implicit narrowing
conversions (such as from int to bool) are not allowed (compiler error
CS0029, if you want to look it up). Now, that last sentence would
probably have sufficed as an initial response. But it wouldn't have
been half so much fun.

Tom P.

And what have you done with Henry!?

 

[Henry Padilla]

I must apologise for the excessive snideness, it's been a trying day. I
am usually much less snide (some, but not so much). And I try to avoid
all snideness when, unlike here, actual education is in order. You
clearly know what you are doing, so I went without the didacticism in
favour of a more jocular approach.

I will restrict myself to one final observation: K&R were talking about
C. C# is not C, and one of the differences is that implicit narrowing
conversions (such as from int to bool) are not allowed (compiler error
CS0029, if you want to look it up). Now, that last sentence would
probably have sufficed as an initial response. But it wouldn't have
been half so much fun.


And what have you done with Henry!?

Henry Thomas Padilla

And thank you for the apology. With 4-8 inches of snow and a 34 mi drive
home I can definitely sympathize with the "hard day".

I hope it gets better.
Tom P.

 

[Henry Padilla]

Ignoring the "humour" (sorry Henry, but despite your protestations Larry's
comments did raise a chuckle), your "solution" is not quite correct to the
pedant:

you've written:

"if ((0x01 & 0x05) > 0) {}"

and complained that

"As defined by Kernighan and Ritchie (in 1970 or so) any non-zero is
true."

That being the case, you should probably be testing with !=0

Marc

Touché (with a little mark above the "e". I can never get those marks to
work right... Hey, the spell checker did it for me, cool.)

Anyway, you are absolutely correct and thank you for the observation.
Indeed if the high order bit is set this would result in a negative number
to the compiler but not result in a "true" condition. Since this situation
is in deference to bitmasking the high-order bit is just that, another bit.
Sign is insignificant.

That may well have driven me nuts for an hour or so. Thank you.

Tom P.

P.S. Knowing the comments were made in a "bad-day jocular" manner I can see
the humor. I'm sorry I was taken by surprise at first.

 

[Jon Skeet [C# MVP]]

As defined by Kernighan and Ritchie (in 1970 or so) any non-zero is true. I
thought this was pretty well accepted in the programming community at large,
are you being snide and obtuse for a reason? Or do you not know how to use
a simple bitmask and are taking it out on me?

I think Larry was trying to point out that C# *doesn't* take the
horrible step of treating ints as booleans. Instead, there's a separate
boolean type. This makes code much clearer, and prevents the sort of:

if (x=5) // Oops, assignment, not comparison!

problem that plagues C and causes people to write in a safer but less
readable fashion.

Yet yours seems to linger. If you read the second sentence in my post you
will see I am trying to get a bool. The part that says "bitwise AND two
int's together and get a bool" was a dead giveaway. This is quite a simple
opperation in C/C++And don't see why it needs to be complicated.

Because you need to be explicit in wanting to get a bool. Note that
what you've written isn't the same as you described - if the result
(using different numbers) is *negative*, the above is false, but
according to your description (non-zero) it should be true. How would
the C# compiler know what you want?

And you had to go through all that to tell me this? Man, it's a good thing
I didn't ask a difficult question, it would have taken months of side notes.

In as much as you have helped not at all, thank you. In the future, if this
is the best you can do please keep your misguided attempts at comedy to
yourself. You are, in point of fact, not good at it.

Unfortunately, it seems you aren't interested in trying to learn the
reason behind C#'s decision about how to handle this, which if you'd
looked at Larry's post in a constructive light, you might have seen.

 

[Marc Gravell]

No problem - and I accept that (in a way) this kinda supports your argement:
by making the programmer do this themselves, you are introducing the risk of
error. But then again, most of everything we type has that caveat.

Anway, seasons regards etc (since this is my last day before the hols ;-p))

Marc

 

[Henry Padilla]

I think Larry was trying to point out that C# *doesn't* take the
horrible step of treating ints as booleans. Instead, there's a separate
boolean type. This makes code much clearer, and prevents the sort of:

if (x=5) // Oops, assignment, not comparison!

problem that plagues C and causes people to write in a safer but less
readable fashion.


Because you need to be explicit in wanting to get a bool. Note that
what you've written isn't the same as you described - if the result
(using different numbers) is *negative*, the above is false, but
according to your description (non-zero) it should be true. How would
the C# compiler know what you want?


Unfortunately, it seems you aren't interested in trying to learn the
reason behind C#'s decision about how to handle this, which if you'd
looked at Larry's post in a constructive light, you might have seen.

I never meant to suggest that this was good, bad, or indifferent. There is
no reason to get defensive, I'm not attacking anything.

Larry himself has apologized for the tone of the post and was quite helpful
afterwards. I am asking questions TO learn. There was a particular manner
that I had done things and was trying to discover how that was accomplished
in C#. Just because I mentioned C/C++ doesn't make this an attack on C#'s
ability to accomplish my task. It establishes a basis for prior knowledge
and allows people like "Marc Gravell" (see above) to help from a common
ground. (he pointed out the same "!=0" bug you did but with much less
attitude and with an understanding that, as a bitmask the high-order bit has
every possibility of being set)

I did look at Larry's post in a constructive light and did, indeed, come to
understand what the reasoning might be behind a decision like this. I also,
being the subject of his ire at the time, felt the sting of comments made to
hurt. Why are you not more sensitive to this aspect of his post?

And, in point of fact, no - I was not interested in "WHY" C# wishes to do
this. It's the syntax of the language and that's what I am using. There's
no need for me to dissertate on what may or may not have been going on that
made a decision final. It will not help me in the least and does nothing
for my situation. The hard fact is that C# acts like this, period. If I
don't can't get around this I'm not much of a programmer and need to find a
different language. (I do wish they would use a bit for a data type that
only has a bits worth of data in it but I'm sure there's a reason for that
too)

I'm sorry to have obviously offended you.

Tom P.

 

[Bruce Wood]

Going back to your original post, do you realize that C# has an
alternate method for handling bit flags in a more readable manner? I,
too, am an ex-C programmer, and spent years writing this:

if ((qualities & 0x04) != 0)

(and yes, I did write the != 0, because I'm a pendatic sort of guy).
C#, however, provides bit flags:

[Flags]
public enum ProductQualities
{
Taxable = 0x01,
Imported = 0x02,
ShrinkWrapped = 0x04
}

ProductQualities qualities = ProductQualities.Taxable |
ProductQualities.Imported;
if ((qualities & ProductQualities.Taxable) != 0) ...

Same code generated (I believe), but much easier on the eyes. The
[Flags] attribute, by the way, is what indicates that you can combine
multiple "enum" values into a compound value, as shown above.

 

[Jon Skeet [C# MVP]]

I never meant to suggest that this was good, bad, or indifferent. There is
no reason to get defensive, I'm not attacking anything.

Well, look at your previous posts and you might see why I was under
that impression. Things like:

<quote>
I thought this was pretty well accepted in the programming community at
large
</quote>

and

<quote>
This is quite a simple opperation in C/C++And don't see why it needs to
be complicated.
</quote>

suggested to me that you preferred the C/C++ way of doing things, and
hadn't understood the problem with it.

Larry himself has apologized for the tone of the post and was quite helpful
afterwards. I am asking questions TO learn. There was a particular manner
that I had done things and was trying to discover how that was accomplished
in C#. Just because I mentioned C/C++ doesn't make this an attack on C#'s
ability to accomplish my task. It establishes a basis for prior knowledge
and allows people like "Marc Gravell" (see above) to help from a common
ground. (he pointed out the same "!=0" bug you did but with much less
attitude and with an understanding that, as a bitmask the high-order bit has
every possibility of being set)

Whether it's being used as a bit-mask is irrelevant, IMO. If an int is
going to be treated as a boolean, it should be treated in the same way
whether it's a bitmask or the result of any other operation.

I did look at Larry's post in a constructive light and did, indeed, come to
understand what the reasoning might be behind a decision like this. I also,
being the subject of his ire at the time, felt the sting of comments made to
hurt. Why are you not more sensitive to this aspect of his post?

I've just reread both Larry's post and your reply to it - I still think
yours is the ruder one. I suggest you reread both and see if you
disagree. You are much more personally aggressive in yours.

And, in point of fact, no - I was not interested in "WHY" C# wishes to do
this. It's the syntax of the language and that's what I am using. There's
no need for me to dissertate on what may or may not have been going on that
made a decision final. It will not help me in the least and does nothing
for my situation.

I'm sorry you feel that way. I always find that if you try to
understand why a language designer made a decision in one particular
situation, that makes it easier to understand the general emphasis of
the language, and helps you to pick up the rest of the points of the
language. For instance, understanding that C# doesn't want you to make
the kind of mistakes which are often made in C/C++ might help you to
guess (and then check) that when you try to fall through from one bit
of code in a switch statement to the next switch case and the compiler
stops you from doing it, that's a deliberate choice and not just a typo
on your part. It might help you to guess that instance and class
variables which have not been explicitly initialised have a specified
default value rather than just getting potentially random garbage. It
might help you to understand why you can't use uninitialised local
variables. It's a bit like using foreign culture to help you pick up a
foreign language - the more you think in the language, the easier it is
to learn (whether a computer language or a natural language).

The hard fact is that C# acts like this, period. If I
don't can't get around this I'm not much of a programmer and need to find a
different language. (I do wish they would use a bit for a data type that
only has a bits worth of data in it but I'm sure there's a reason for that
too)

I'm sorry to have obviously offended you.

What offends me is people being rude to others who are trying to help
them. I've seen it time and time again on the newsgroups - admittedly
often with even less provocation than in this case.

 

[Henry Padilla]

Well, look at your previous posts and you might see why I was under
that impression. Things like:

<quote>
I thought this was pretty well accepted in the programming community at
large
</quote>

and

<quote>
This is quite a simple opperation in C/C++And don't see why it needs to
be complicated.
</quote>

suggested to me that you preferred the C/C++ way of doing things, and
hadn't understood the problem with it.

Having used C/C++ for the number of years that I have, I've become
desensetised to the "problem" with it. In fact I don't view it as a
problem, like I said, it's just the way the language is. Learn the
language.

I've just reread both Larry's post and your reply to it - I still think
yours is the ruder one. I suggest you reread both and see if you
disagree. You are much more personally aggressive in yours.

This I will grant you. However I WAS the one being attacked and therefore
had every right to respond severely.

I'm sorry you feel that way. I always find that if you try to
understand why a language designer made a decision in one particular
situation, that makes it easier to understand the general emphasis of
the language, and helps you to pick up the rest of the points of the
language. For instance, understanding that C# doesn't want you to make
the kind of mistakes which are often made in C/C++ might help you to
guess (and then check) that when you try to fall through from one bit
of code in a switch statement to the next switch case and the compiler
stops you from doing it, that's a deliberate choice and not just a typo
on your part. It might help you to guess that instance and class
variables which have not been explicitly initialised have a specified
default value rather than just getting potentially random garbage. It
might help you to understand why you can't use uninitialised local
variables. It's a bit like using foreign culture to help you pick up a
foreign language - the more you think in the language, the easier it is
to learn (whether a computer language or a natural language).

Any given situation can be seen as a plus or minus under the right
circumstances. What you may see as keeping you from making mistakes I may
see as keeping me from doing something usefull to me.

I apreciate your outlook, but I can't share it. Ian't get that invested in
a language, they change too often.

What offends me is people being rude to others who are trying to help
them. I've seen it time and time again on the newsgroups - admittedly
often with even less provocation than in this case.

Larry was, admittedly, not trying to help me. He has since apologized, but
he was not trying to help. What is the problem with being rude to someone
that is being rude to you? I suppose you have a point in that I should have
ignored him, but he should not have posted either. So I see no center for
blame.

Tom P.

 

[Henry Padilla]

Going back to your original post, do you realize that C# has an
alternate method for handling bit flags in a more readable manner? I,
too, am an ex-C programmer, and spent years writing this:

if ((qualities & 0x04) != 0)

(and yes, I did write the != 0, because I'm a pendatic sort of guy).
C#, however, provides bit flags:

[Flags]
public enum ProductQualities
{
Taxable = 0x01,
Imported = 0x02,
ShrinkWrapped = 0x04
}

ProductQualities qualities = ProductQualities.Taxable |
ProductQualities.Imported;
if ((qualities & ProductQualities.Taxable) != 0) ...

Same code generated (I believe), but much easier on the eyes. The
[Flags] attribute, by the way, is what indicates that you can combine
multiple "enum" values into a compound value, as shown above.

Thank you. I'll see what I can do with this.

Thanks.
Tom P.

 

[Bruce Wood]

I think that you'll find this newsgroup very civilized, and the people
here very helpful, even to newbies. I, too, found your original post
provocative, with a sort of "What the hell's wrong with this stupid
language?" attitude. Nonetheless, you have to admit that people
eventually responded to your question in a constructive manner.

Jon's one of the most helpful people here, by the way. If you stick
around I think that after a short while you'll agree with me on that.

Just for comparison, try going into the C newsgroups like comp.lang.c
and post something like, "In C# the compiler warns me if I do something
stupid like a variable assignment within an 'if' condition... why can't
C compilers do that, too?" and watch the fur fly. The guys who post to
that newsgroup are downright unforgiving, in my experience.

When I started posting here I was pleasantly surprised. Even total
newbies with very, very basic questions receive civilized replies, as
opposed to being shredded and charbroiled as they would be in other
NGs. Kudos to everyone here for making this a civilized, professional
place where anyone can come for help.

 

[Jon Skeet [C# MVP]]

Having used C/C++ for the number of years that I have, I've become
desensetised to the "problem" with it. In fact I don't view it as a
problem, like I said, it's just the way the language is. Learn the
language.

And choose between having to be perfect with respect to typos or use a
less readable comparison form? Sorry, but that choice still seems to be
a problem to me. However, whether it's actually a problem or not is
irrelevant to the main point of me quoting your post - which was to
show why I thought your post really *was* criticising C# for its
choice. I hope you can at least see where I was coming from in that
respect.

This I will grant you. However I WAS the one being attacked and therefore
had every right to respond severely.

Well, you were being "attacked" fairly light-heartedly in my reading of
it, and overreacted by a large margin.

Any given situation can be seen as a plus or minus under the right
circumstances. What you may see as keeping you from making mistakes I may
see as keeping me from doing something usefull to me.

I apreciate your outlook, but I can't share it. Ian't get that invested in
a language, they change too often.

It really doesn't take that much investment, and I believe it makes it
significantly quicker to learn the language as a whole. It's like
saying it's not worth learning the patterns of how to conjugate verbs,
preferring to learn how to conjugate each one individually. Learning
the patterns is a larger "up front" investment, but it pays huge
dividends.

Larry was, admittedly, not trying to help me. He has since apologized, but
he was not trying to help.

I don't think he "admitted" that. Indeed, he *did* help you - his last
sentence (out of only 7 - it wasn't exactly a post you had to pick
apart for ages to find the answer) gave the answer perfectly easily. In
my view the first two sentences are also helpful - they should have got
you to ask the question of yourself in a deeper way than your "Well,
K&R decided to do it that way, so every language should follow what
they did" response.

What is the problem with being rude to someone that is being rude to
you? I suppose you have a point in that I should have ignored him,
but he should not have posted either. So I see no center for blame.

Well, I still don't think he was being that rude to you, personally. If
you're going to react that way when people are only that "rude" to you,
you're likely to come apart at the seams if you hang around newsgroups
for a while. People can be an awful lot ruder than that.

 

[Tom Padilla]

I'm sorry to have impugned whomever I did to get on the short list.

I've been a programmer for too long in too many languages to favor one over
the other. I've been in situations where each language had a benefit and a
restriction - it has never occurred to me that a syntax could be attacked.
I'm sorry if this was how my post was received.

There have been helpful responses, and "thank you" to those that did help.
I don't think trying to talk me into thinking Larry's first post was sweet
and helpful is useful. This is something Jon is apparently looking for. I
don't know, I've tried to explain why I used C/C++ as a base for
understanding. I've tried to apologize for offending him. And still he
tries to get me to admit that Larry's first post was not the least bit out
of line, when Larry himself admits he responded with an attitude because he
had a bad day.

Admittedly I have posted in other NG (just 'cause I've used C/C++ for years
doesn't mean I'm any good at it) and been upbraided much worse than this.
I've also apologized and had it accepted much easier than this. You've
dealt with Jon before - What does it take for the guy to accept your
apology?

What does he want from me? "Cat's rule and dogs drool"? I give up.

Tom P.