Xor

[Jay1b]

Could someone please tell me how this works?

 

msgbox(Asc("A") Xor 50)
'This returns 115

 

I thought that the logic for Xor was:

True+False=True

False+False=False

False+True=True

True+True=False

 

How on earth does it act like a + sign?

 

Thanks

[Wile]

I thought that the logic for Xor was:

True+False=True

False+False=False

False+True=True

True+True=False

 

I'm gonna guess that instead of a logical Xor (like you described above) it is doing a bitwise Xor.

So something like:

result = A Xor B;

where:

bit 0 of A is Xor-ed with bit 0 of B (using logical Xor rules)

bit 1 of A is Xor-ed with bit 1 of B

etc.

until you get result. Asc(A) returns 65, Xor with 50 with the those bitwise rules above does give 115 if my use of the windows calculator is correct ;).

[PlausiblyDamp]

Pure luck 65 in binary XOR 50 in binary is

1000001  = 65
0110010  = 50
XOR Gives:
1110011  = 115

 

Would love to see the rest of the code though as this wouldn't work on many numbers (or letters) try it with "B" for example it returns 112)

 

I get the feeling this could be someone optimising their code to the point of being unmaintainable...

Edited March 7, 2005 by PlausiblyDamp

[Jay1b]

Thanks guys.

 

Within the program I tried A Xor 49 and got 114. Also B with 50 and got 116.

 

Looking at the logic:

1000010=66 (B)

0110010=50

Xor would logically give:

1110000=112

But you use add them together:

1110100=116 - So i assume it must be doing this.

 

I think i will have to dig out my old uni notes on binary.

[mskeel]

I get the feeling this could be someone optimising their coed to the point of being unmaintainable...

 

As a C programmer long converted, I would just like to take a moment to say that there is nothing wrong with the use of Xor -- every tool has its place. The trick wehn using Xor or any other low level tool like this (of which few exist in C# and VB .Net) is to abstract the low level stuff from your code as much as possible.

 

So, while overall it is more difficult to maintain bitwise operations you can make it bearable and proper by isolating your low level code away from the rest of your program. Hide it in a method and use that method (named something high level, not getXor(int) ) -- the rest of your program should have absolutely no idea that the Xor operator is ever used and this method should be the only place that it is used in that particular way.

 

The only example I can think of right now is if you are using Xor and other bit-wise operators to pull specific bit values from an message stored as an integer. Something liek using the first two bits to represent the id, the next four to represent the source, the next 4 to represent the mode, and the next two to represent the priority. You would create public methods GetID(), GetSource(), GetMode(), GetPriority() and your would probably have a private ReadMessage() method called when you get one of these special messages in the form of an integer or something like that -- you may just store the message and interpret it on the fly.

 

You should not be afraid to use bit-wise operations just becuase modern computers have plenty of space and speed. There is a place and time for everything. There are still places where space and speed need every drop of boost they can get. The crucial thing is to know how to use bit-wise operators and how to design a class or program around them to make the best use of them as possible.

[PlausiblyDamp]

Mskeel - I wasn't suggesting that using any function or operator in itself was a bad thing, however when using something in a really non-intuitive way because is can save a clock cycle or two, but needs several minutes / hours of debugging to figure out what it is supposed to do is not a good thing. At the very least this kind of thing demands comments explaining why this method was chosen and acceptable ranges etc.

Just how slow was the + operator that using XOR gave any performance benefits. Also take into account the fact that it doesn't seem to be doing an XOR anyway - XOR the ASCII bit pattern for B and then use the above code with a B and compare the results. This has got to make you wonder if this has ever been properly tested or thought through - did somebody try this with the letter A and it worked? Knowing that XOR is faster did they realise that they had hit on a wonderful optimisation and not even try another letter to prove their theory?

 

Sometimes developers 'being clever' can cause a lot more problems than they fix and using odd tricks in a language can seriously hurt if you need to port to another language or these issues are resolved in a later version...

[mskeel]

PD- I aggree with you whole heartedly. Often times clever will get you in trouble.

 

The bigger issue here is the trend of moving to higher level languages at the sacrifice of lower level power. But that is probably a topic for another thread...

 

Jay1B should be able to use as much power as he wants and not be discouraged to do so -- the ultimate decesion will be dictated by the needs of the application. It is our responsiblity as a community to raise several points that should be considered. Points raised so far in this thread include:

 

- maintainabilty

- time spent/speed gained (and other) trade-offs

- proper design

- good documentation

- adequate testing

 

So long as all of these points are carefully considered by Jay1B, he should feel free to do what he thinks is best. Knowing about these lower level operations, how they work, and how to exploit them will only make you a better programmer in the end.

 

More on topic -- for any math operation you can think of, you can use a series of bitwise operations to preform the math. A link that goes into some more depth about what you have discovered... Adding Binary Numbers

[mskeel]

Oh yeah, and the main point I was trying to make is that you can use these operators (and sometimes should) and still keep your code maintainable. You just have to be careful and think things through.

[snarfblam]

Um... it should be noted that without more of the code from where the original excerpt above came from, it can not be concluded that the coder necessarily intended to use the xor operator for the purpose of addition. Jay1b did ask how it acts like a + operator, but apparently only because he realized that the result yielded by both operators was equal.

 

Anyways, a note on optimization...

The bigger issue here is the trend of moving to higher level languages at the sacrifice of lower level power.

Jay1B should be able to use as much power as he wants and not be discouraged to do so

I am not sure if you are trying to encourage use of code like that posted at the top of the thread, but to paraphrase something written by microsoft, i believe, micro-optimizing every line of code is a terrible waste of effort. Yes, 65 xor 50 is faster than 65 + 50, but to try to maximize power and speed on every line of code is a terrible waste of effort. Don't try to take advantage of every micro-optimization you know of. The speed difference will be negligible. You really need only focus on optimizing bottlenecks, places where large amounts of code or large loops are processed at once. If you are showing a message box it is quite pointless to try to save the user one nanosecond of his time by using an xor instead of a +. I highly discourage anyone from using xor instead of + or any other "tricks" like that unless he runs into a situation where he really needs speed.

[Jay1b]

I just saw it mentioned in a book, and wondered how it worked.

 

From reading the posts in the thread i would conclude that if there was a one off line of code then "A" + 50 would be easier to read and therefore advantageous. However if, as in the example in the book it was some type of primitive encoding, which scrolls through each character in a document, then this could be looped 10,000+ times easily - therefore any optimisation would be worthwhile. Although on modern computers that would probably only save 0.01 seconds.

[mskeel]

This is really getting off subject but...

 

I am not sure if you are trying to encourage use of code like that posted at the top of the thread...

I neither encourage nor discourage. I say right tools for right job.

 

The bigger issue here is the trend of moving to higher level languages at the sacrifice of lower level power.

I just fear that one day those tools might not exist anymore.

 

If you really wanted a hum dinger argument you would have pointed out that code doesn't compile the same way in .Net (il is not assembly) and the .Net compiler optimizes the piss out of everything so such a tactic would have little to no impact, unlike other compilers such as gcc. (as a side note, what about the c++ .Net compiler?) But, as I stated before, it is always good to know about low level things like caching, byte ordering, etc. so you can take advantage of those things when needed.

 

You really need only focus on optimizing bottlenecks

True. But that's really the definition of optimization, yes? decreasing bottlenecks...

 

I state two points that I would like you all to hear very well.

1. Sometimes you will need to use binary operations so don't just dismiss them outright.

2. If you decide to use binary operations, you have to do it right so as to minimize their consequences in your code.

 

Look at the example in post #5. That is a real world example of something that I am working on. I use C++ .Net for that. I have to deal with bytestreams of data. I am handed a sereis of words and have to determine what they mean at a bit level basis. Why so bizarre? Becuase I am faced with real world space and speed restraints. How do I deal with it? By encapsulating the low level code as best as I can.

 

All I'm saying is that binary operators aren't a dirty word. Just understand when and how to use them. Further, a little practice never hurt anyone.

 

And it may be a nearly negligible speed boost, but it is a speed boost. Sometimes you need that. Which is faster, 10 or 9.9 ? I say, if you've identified a need (and it should be a big need) and properly code it, who cares?

 

I highly discourage anyone from using xor instead of + or any other "tricks" like that unless he runs into a situation where he really needs speed.

 

bool iAgree = 0 ^ 1;

[snarfblam]

There is a difference between nearly negligible and negligible. A good optimizer recognizes this difference. And binary operators aren�t going anywhere. I am working on a program right now that has hundred of lines of binary operations performed on bytes in arrays. So of course I am aware of their importance, and would never dismiss them for their intended purpose. My only point was that swapping an xor for addition when the operation consumes essentially none of the cpu time either way is ridiculous. I highly discourage anyone from using xor instead of + or any other "tricks" like that unless he runs into a situation where he really needs speed.

[thenerd]

Actually I think he's using it as some sort of encryption method where only xor will work, not to microoptimize. It allows you to easily reverse your encryption.

 

(No, I'm not a mind reader, I've just read the book that he got it from ;))