replace values

[Hrvoje Voda]

I'm using 2 integer numbers X and Y.
I would like to replace there values(Y=X, X=Y) but without using any other
variables or functions.

Hrcko

 

[Jon Skeet [C# MVP]]

I'm using 2 integer numbers X and Y.
I would like to replace there values(Y=X, X=Y) but without using any other
variables or functions.

There's a very hacky way of doing it, but using a temporary variable
would certainly be simpler and more readable.

Can I ask *why* you don't want to use any other variables or methods?

Jon

 

[Hrvoje Voda]

Because it's a test question that I have to solve for a job.

Hrcko

 

[Graeme Bradbury]

x = x ^ y;
y = y ^ x;
x = x ^ y;

Graeme
"Doing his bit to rid the world of idiotic aha! interview questions"

 

[Jon Skeet [C# MVP]]

Because it's a test question that I have to solve for a job.

Does your potential employer know that you're asking for help online?
Are they comfortable with that?

Jon

 

[marss]

I'm using 2 integer numbers X and Y.
I would like to replace there values(Y=X, X=Y) but without using any other
variables or functions.

Hrcko

You may use System.Threading.Interlocked to do it:

int var1 = 5;
int var2 = 10;
var1 = System.Threading.Interlocked.Exchange(ref var2, var1);

But, maybe, you are tested not on knowing of hacks but on ability to
write understandable code?

Regards,
Mykola
http://marss.co.ua

 

[Michael S]

You may use System.Threading.Interlocked to do it:

int var1 = 5;
int var2 = 10;
var1 = System.Threading.Interlocked.Exchange(ref var2, var1);

LOL!
Excellent solution.
Playing around with bits are sooo oldschool

- Michael Starberg

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

LOL!
Excellent solution.
Playing around with bits are sooo oldschool

- Michael Starberg

You don't have to play around with bits. It works just fine with
addition and subtraction:

var1 -= var2
var2 += var1
var1 = var2 - var1

 

[marss]

You don't have to play around with bits. It works just fine with
addition and subtraction:

var1 -= var2
var2 += var1
var1 = var2 - var1

Not so reliable as Graeme's solution. What about stack overflow?

Regards,
Mykola
http://marss.co.ua

 

[Jon Skeet [C# MVP]]

Not so reliable as Graeme's solution. What about stack overflow?

I can't see how the stack would overflow. You might get *numeric*
overflow, but that would just wrap round - shouldn't be a problem.

 

[Michael Starberg]

Not so reliable as Graeme's solution. What about stack overflow?

I can't see how the stack would overflow. You might get *numeric*
overflow, but that would just wrap round - shouldn't be a problem.

--
Jon Skeet - <[email protected]>

I thought it was obvious marss ment numeric overflow.
But you are right, syntax is not semantics, and correction
is needed in this forum.

But I still think that marss has the best solution,
as it is totally OO and does it with one understandable line of code.

I bet it also has better performance, as while we have no idea,
the call to .Exchange() could be optimized by the jitter
understanding there is no need for interlocking anything,
and then just shift two registers...by using a third register...
Oh, wait a minute! That's a temp-register, no?!

That would be cheating! =)

- Michael Starberg

 

[Peter Duniho]

I can't see how the stack would overflow. You might get *numeric*
overflow, but that would just wrap round - shouldn't be a problem.

I guess it depends on the implementation. You could easily imagine a
type that does some range-checking on arithmetic and either throws an
exception or pins the value or some such thing. The original question
did not actually assume or demand a C# int-specific implementation.
Just that the values are integers.

Of course, if that type doesn't implement a bit-wise XOR or similar
alternative, you're kind of out-of-luck anyway. But still.

And of course, the real-world bottom line here is that there's really no
reason to try to swap the variables without a temp anyway.

Pete

 

[marss]

Of course, shame on me

I am surprised but you are right - that is not a problem?!!! I made a
test example (VS 2005):

int var1 = 2000000000;
int var2 = -2000000001;

var1 -= var2; //-294967295 = result is truncated
var2 += var1; //2000000000
var1 = var2 - var1; //-2000000001

Why this happens?

Regards,
Mykola
http://marss.co.ua

 

[marss]

Why this happens?

I mean, why it returns a correct result even though one of the values
is truncated? Can anyone explain?

Mykola

 

[Peter Duniho]

[...]
int var1 = 2000000000;
int var2 = -2000000001;

var1 -= var2; //-294967295 = result is truncated
var2 += var1; //2000000000
var1 = var2 - var1; //-2000000001

Why this happens?

Well, first, the result isn't "truncated". It overflowed.

As for why it works okay, it's because the overflow isn't actually a
problem unless you care about the intermediate value. And in this case
you don't. All that you lose in the overflow is the bit that would have
been carried; all of the other bits are just as they should be. And the
carry bit isn't required for the subsequent operations that restore the
original value to wind up correct (you get more overflow, and again the
carry bit is irrelevant).

Another way of looking at it is that you've got a bit circular number
line, where the circle connects at the minimum and maximum values for
the type. The addition and subtraction operations shift your position
around on the number line and may in fact cross that place on the number
line where the min and max meet, but wrapping around doesn't hurt, as it
simply gets offset in the subsequent operation back into the correct
range of values.


As long as you're dealing with a type that allows this overflow to occur
undetected and uncorrected, there's no problem.

Pete

 

[Jon Skeet [C# MVP]]

Of course, shame on me


I am surprised but you are right - that is not a problem?!!! I made a
test example (VS 2005):

int var1 = 2000000000;
int var2 = -2000000001;

var1 -= var2; //-294967295 = result is truncated
var2 += var1; //2000000000
var1 = var2 - var1; //-2000000001

Why this happens?

The result isn't truncated - it just wrapped round.
Int.MaxValue+1=Int.MinValue. You lose the information that you *have*
wrapped round, but nothing else. As your code then reverses the
operation, you end up with the right answer.

 

[Michael S]

Another way of looking at it is that you've got a bit circular number
line, where the circle connects at the minimum and maximum values for the
type. The addition and subtraction operations shift your position around
on the number line and may in fact cross that place on the number line
where the min and max meet, but wrapping around doesn't hurt, as it simply
gets offset in the subsequent operation back into the correct range of
values.

Nice analogy. I remember that one.

- Michael Starberg

 

[marss]

Thanks for answers.
This is one more candidate for "aha!" interview questions, is not
it?

Mykola
http://marss.co.ua

 

[Michael Starberg]

Thanks for answers.
This is one more candidate for "aha!" interview questions, is not
it?

Nah, Mykola.
You created echos at my work and in other forums.
This is one snippet of text that from someone not impressed.

<q>
Of course, anyone can write a function to swap two values.

And x86 assembler has had XCHG for a long time already, and that is
locked as well. Nothing new. Next!
<q/>

But I am impressed.
I hope Hrvoja Voda sends your solution to his future employer.
Also, I feel sorry for the employer if they hire the cheater.

Mykola
http://marss.co.ua

My I ask: Did you come up with it yourself, or read it somewhere?

- Michael Starberg

 

[marss]

But I am impressed.
I hope Hrvoja Voda sends your solution to his future employer.
Also, I feel sorry for the employer if they hire the cheater.

Thanks for kind words.
I do not think that you should feel sorry for the employer who based
his decision on solving puzzles only, he cheats with questions, Hrvoja
Voda cheats with answers - fair play

My I ask: Did you come up with it yourself, or read it somewhere?

I read it in CLR via C# by Jeffrey Richter.

Regards,
Mykola
http://marss.co.ua