• Advertisement
Sign in to follow this  

why!? why!? WHY!?!? bitwise hell

This topic is 4172 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

int _tmain(int argc, _TCHAR* argv[])
{
	int index = 85, up = -16, yay = 2;
	int temp = index + up * yay;
	int temp2 = temp & 0x88;
	if((index + up * yay) & 0x88 != 0)
	{
			bool ok = false;
	}
	return 0;
}

This is based on a problem I am having with my program. Go through it in the debug. temp = 53. ok temp2 = 0. ok but the if statement carrys through WHY WHY WHY WHY AHGHRHGHA AHGAGHA RARHGHGHGHGHA ARGHGHGHGHGH

Share this post


Link to post
Share on other sites
Advertisement
53 & 0x88 is best done after we convert to binary, correct? So lets do that first. 53 in binary is 00110101, 0x88 in binary is 10001000 (if memory serves...been a while since I've done hex to binary conversions). Performing an & operation on these two numbers results in

00110101
& 10001000
----------
00000000

Are you saying this if check is returning true (therefore entering the following body)? If that's the case you have me stumped. When you say the if statement carries through, do you mean to say it is being evaluated to true?

EDIT: for some reason I can't get my binary numbers to line up in the operation above, sorry for any confusion. The leading values should line up with one another.

Share this post


Link to post
Share on other sites
Ahh, now that makes sense. because the != has higher precedence, the 0x88 != 0 is evaluated first. This will return to us true or 1. if we do the & operation on 53 and 1 we get

00110101
& 00000001
----------
00000001

which is non-zero, therefore true.

Share this post


Link to post
Share on other sites
EDIT: Oops! I should refresh the page before answering... I thought that I had the first reply :D

This should do the trick:

if(((index + up * yay) & 0x88) != 0)

Actually, I agree with you, IIRC the bitwise and should be done before the inequallity operator...

I'll go back to study C++ again...

Share this post


Link to post
Share on other sites
Why? At some point a choice must be made; just because you don't like it because it caused you a problem doesn't make it stupid. You could make valid cases for either option. Just deal with it.

Share this post


Link to post
Share on other sites
Sorry, you just have NO idea how long I spent trying to figure this out ;P It just seems a bit counter-intuitive to me.

Share this post


Link to post
Share on other sites
operator precedence doesn't really have to do with intuition. The order could just as easily be the other way around. It is arbitrary (as far as I know) and only exists because it has to. The language requires standards such as this, otherwise it wouldn't work.

I doubt you really spent that long on this problem relative to some of the other more complex issues you'll run into in game development or programming in general. When you've spent 4 days debugging your octree implementation, then we'll talk :)

Just be aware of the language intricacies. They don't always make sense immediately but they exist for a reason, without these rules, the language itself would fall apart.

Share this post


Link to post
Share on other sites
Quote:
Original post by Morpheus011
It is arbitrary (as far as I know) and only exists because it has to.


Actually it isnt. Its based on math.

You probrably already know this from grade 10 math, but lets look at some simple math equations.

1 x 3 + 5 = 8
Resolves to
(1 x 3) + 5 = 8
..to...
(3) + 5 = 8

So, in math, multiplication has a higher precedence then addition.

Or

1 x 2 + 6 / 3 = 4
==
(1x2) + (6/3) = 4
==
(2) + (2) = 4

Notice how in both equations I used () to denote things that come first. Thats because, like in math, () give you the option of raising operator precedence.

So, for example:
(3+6) X 2 = 18
--
(9) X 2 = 18

Then, you can nest paranthesis, such as
(3 x ( 3+2))/2 = 7.5
==
(3 x (5))/2 = 7.5
==
(15)/2 = 7.5
==
15/2 = 7.5


It just so happens that since bitwise math is as "basic" math as computers get, they have the highest precedence ( are evaluated first ), unless over ridden by ( ) markers.


There is actual logic behind how languages implement operator precedence.

Share this post


Link to post
Share on other sites
I understand the operator precedence for mathematical operators such as +, -, etc. but the operators we were referring to such as & or != seem to be more abstract then your everyday mathematical operations. Logical operations such as these don't borrow rules from mathematics (except possibly from discrete mathematics, but these again seem to me to be just as arbitrary).

Thank you for clarifying that though, if someone could maybe shed some light on why the other (i.e. non-arithmetic operators such as &, |, etc.) are given precedence such as they are that would be cool.

Thanks

Share this post


Link to post
Share on other sites
The choice (like many in software/computers/etc) was probably based on existing system when C was developed. Another possibility is they didnt want to seperate logical AND/OR from the bitwise AND/OR hence they both have lower precedence than comparision.

Share this post


Link to post
Share on other sites
Quote:
Original post by Illumini
The choice (like many in software/computers/etc) was probably based on existing system when C was developed. Another possibility is they didnt want to seperate logical AND/OR from the bitwise AND/OR hence they both have lower precedence than comparision.


Logical operators are evaluated much latter then bitwise operators.

If I was to venture a guess, it would stem from assembly and pre-assembly programming, in which bitwise operators are about as "base" as you can get. Then again, thats just a guess.


To people a bit blurry on operator precedence, this might be helpful
http://www.cppreference.com/operator_precedence.html

Share this post


Link to post
Share on other sites
I guess your open to your own definition of "much later", but the page you just linked shows them at the next lowest precedence (ie directly after, there are no other operators in between them).

Share this post


Link to post
Share on other sites
Quote:
Original post by Serapth
It just so happens that since bitwise math is as "basic" math as computers get, they have the highest precedence ( are evaluated first ), unless over ridden by ( ) markers.


But that's sort of the point... they AREN'T evaluated first. The != is.

Share this post


Link to post
Share on other sites
Quote:
Original post by Morpheus011
I understand the operator precedence for mathematical operators such as +, -, etc. but the operators we were referring to such as & or != seem to be more abstract then your everyday mathematical operations. Logical operations such as these don't borrow rules from mathematics (except possibly from discrete mathematics, but these again seem to me to be just as arbitrary).

Thank you for clarifying that though, if someone could maybe shed some light on why the other (i.e. non-arithmetic operators such as &, |, etc.) are given precedence such as they are that would be cool.

Thanks


Actually comparing if two things are the same is even more basic than adding or subtracting them. Also And and OR and all that stuff is everyday mathematics or something even more basic - logic. Bitwise is more basic than logical since it is simply a boolean operation on the hardware representation of the bits themselves (not very abstract at all), while logical are more highlevel and akin to the everyday notion of boolean logic.

Anyways to wrap up &&, || , ! all 'borrow' rules from a 2000 year old subject called logic.

Share this post


Link to post
Share on other sites
Quote:
Original post by Illumini
I guess your open to your own definition of "much later", but the page you just linked shows them at the next lowest precedence (ie directly after, there are no other operators in between them).


Yes, I suppose much might be a bit much :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Daerax

Actually comparing if two things are the same is even more basic than adding or subtracting them. Also And and OR and all that stuff is everyday mathematics or something even more basic - logic. Bitwise is more basic than logical since it is simply a boolean operation on the hardware representation of the bits themselves (not very abstract at all), while logical are more highlevel and akin to the everyday notion of boolean logic.

Anyways to wrap up &&, || , ! all 'borrow' rules from a 2000 year old subject called logic.


Right, that's why I referenced them as being borrowed from discrete mathematics. Claiming that performing boolean operations on hardware representations of bits isn't an abstract concept (imagine explaining that to someone who doesn't program) seems to only validate, in my mind, that it is all somewhat arbitrary, i.e. up to the discretion of the observer (or in this case, the developer). I understand these are rules that govern all human and mathematical logic, but IMO it seems that these things could just as easily be flipped around (perhaps in an alternate universe the logic works completely differently then in ours :D)

Although I see that that's a pointless thing to ponder, as it _is_ this way, and for good reason. Hell, we can't just go and defy the core logic of our universe, can we?

Share this post


Link to post
Share on other sites
Quote:
Original post by Morpheus011
Quote:
Original post by Daerax

Actually comparing if two things are the same is even more basic than adding or subtracting them. Also And and OR and all that stuff is everyday mathematics or something even more basic - logic. Bitwise is more basic than logical since it is simply a boolean operation on the hardware representation of the bits themselves (not very abstract at all), while logical are more highlevel and akin to the everyday notion of boolean logic.

Anyways to wrap up &&, || , ! all 'borrow' rules from a 2000 year old subject called logic.


Right, that's why I referenced them as being borrowed from discrete mathematics. Claiming that performing boolean operations on hardware representations of bits isn't an abstract concept (imagine explaining that to someone who doesn't program) seems to only validate, in my mind, that it is all somewhat arbitrary, i.e. up to the discretion of the observer (or in this case, the developer). I understand these are rules that govern all human and mathematical logic, but IMO it seems that these things could just as easily be flipped around (perhaps in an alternate universe the logic works completely differently then in ours :D)

Although I see that that's a pointless thing to ponder, as it _is_ this way, and for good reason. Hell, we can't just go and defy the core logic of our universe, can we?


Ahh philosophy, my favourite topic. But very much off topic (ah cant help but say this much, what you say has been and is studied but nonetheless there is a class of necessary truths true across all universes of discourse whose otherwise existance would not be). Just a few corrections. Perhaps it is because it hits close to home but I must emphasize that a distinction be made between logic and discrete mathematics, just because discrete math uses some techniques from logic does not mean that it is. That is like saying chemistry or economics is the same as mathematics. I am sure the mathematician would be offended :).

As for absract, here it is meant that no direct physical representation, the bits of a computer certainly do have a physical existance and there is nothing abstract about flipping their state,surely much less abstract than the logical operations. Be assured that the concept of switching from on to off and in terms of logical notions of AND and OR is easily done. And to children as well. Do not underestimate the general public.

Share this post


Link to post
Share on other sites
Lesson for the day: Make sure you set level 4 warnings in the Code Generation tab of project properties

This error would have been picked up immediately if you had done so (through a compiler warning "warning C4554: '&' : check operator precedence for possible error; use parentheses to clarify precedence".

Share this post


Link to post
Share on other sites
Forget the philosophy for a second - at some point someONE must have sat down and decided, when making the compiler, which were given precedence.

Take a look at this

2 + 6 & 3 = 4

6 & 3 = 2, 2 + 2 = 4

Makes sense to me.

But what you are telling me is the & takes priority over the =? Or the = takes priority over the &? Or what? I just don't understand what and why.

Share this post


Link to post
Share on other sites
Quote:
Original post by CzarKirk
Forget the philosophy for a second - at some point someONE must have sat down and decided, when making the compiler, which were given precedence.

Take a look at this

2 + 6 & 3 = 4

6 & 3 = 2, 2 + 2 = 4

Makes sense to me.

But what you are telling me is the & takes priority over the =? Or the = takes priority over the &? Or what? I just don't understand what and why.


I'm changing the = to an ==, because that seems to be what you were going for (and the other wouldn't compile). Due to operator precedence, it becomes

(2 + 6) & (3 == 4)

The & is the lowest operator there.

Share this post


Link to post
Share on other sites
Well I was just talking general maths which is why I used single =

I don't understand that. "3 == 4" How is that ever supposed to be something useful?

Share this post


Link to post
Share on other sites
Quote:
Original post by CzarKirk
Well I was just talking general maths which is why I used single =

I don't understand that. "3 == 4" How is that ever supposed to be something useful?


Change it to a == b. You had assignment operators before. You cannot assign a literal to a literal.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement