# Thread: Even/Odd Number without % or /

1. ## Even/Odd Number without % or /

Hi all,

I'm new over here n want some help. What will be the solution, if we want to find out even/odd number without using divsion or modulus operator?

Best Regards.

2. Use subtraction

3. Consider the binary layout of an integer and look up the bitwise & (and) operator.

4. You can read the number into a string stream, and then using a switch() statement if myStr[myStr.length() - 1] is equal to '1', '3', '5', '7', or '9', then the number is odd. If the number's not odd, then it's even.

5. Sure, but don't you think that uses the % operator?

Use two mutually recursive functions!

6. Sure, but don't you think that uses the % operator?
I know that it does not.

7. Originally Posted by anonytmouse
Consider the binary layout of an integer and look up the bitwise & (and) operator.
Yes, do it the way everyone else does it:
Code:
```if (x & 1)
{
cout << "OMFG x is ODD!!!" << endl;
}
else
{
cout << "OMFG x is EVEN!!!" << endl;
}```

8. Not quite as efficient as x&1, but guaranteed to work regardless of how an int is represented;
Code:
```int IsOdd(int x)
{
while (x > 0)  x -= 2;
while (x < 0) x += 2;
return x;
}

int IsEven(int x)
{
return !IsOdd(x);
}```

9. Originally Posted by grumpy
Not quite as efficient as x&1, but guaranteed to work regardless of how an int is represented;
You say that as if x&1 won't work with all integers, but it surely will. &1 test for the 1st bit being 1, which for all odd integers this will be the case regardless of sign or type of integer.

And since you brought up efficiency, if yours is passed a very large integer, how slow is that going to be? I would guess to slow for most practical purposes.

10. And since you brought up efficiency, if yours is passed a very large integer, how slow is that going to be? I would guess to slow for most practical purposes.
Of course, in practice if one suspects that x&1 might not work unless some circumstance, one would just choose x%2... but oranges isnt asking for something that will necessarily be used in practice.

11. Originally Posted by Darryl
You say that as if x&1 won't work with all integers, but it surely will. &1 test for the 1st bit being 1, which for all odd integers this will be the case regardless of sign or type of integer.
For unsigned integers, x&1 will be the same as x%2. This is also true for positive values of signed integers, whether ones' complement, twos' complement, or sign-and-magnitude is the underlying representation. But negative ones' complement values will produce different results. I think that may have been what grumpy may have meant.

12. Originally Posted by laserlight
Of course, in practice if one suspects that x&1 might not work under some circumstance, one would just choose x%2... but oranges isn't asking for something that will necessarily be used in practice.
Ok even in theory, I think it's a bad solution :

Code:
```bool isOdd(int n) {return n&1;}
bool isOdd(int n) {return n << (8*sizeof(int)-1) ;}
bool isOdd(int n) { bitset<sizeof(int)> b(n); return b.test(0);}
and for one's complement systems
bool isOdd(int n) { return abs(n)&1;}```

13. Rethink this one too for ones' complement, and for CHAR_BIT != 8, and for padded integers (or is that one just a C possibility?).
Code:
`bool isOdd(int n) {return n << (8*sizeof(int)-1) ;}`

14. Originally Posted by Dave_Sinkula
For unsigned integers, x&1 will be the same as x%2. This is also true for positive values of signed integers, whether ones' complement, twos' complement, or sign-and-magnitude is the underlying representation. But negative ones' complement values will produce different results. I think that may have been what grumpy may have meant.
You've earned the cigar. If our integer type uses ones-complement notation, x&1 will not detect that negative values of x are odd.

15. Originally Posted by 7stud
I know that it does not.
You have knowledge of the inner workings of every STL implementation? Okay...

At least in the STL implementation that gcc uses, the modulo operator is in fact used.
http://gcc.gnu.org/onlinedocs/libstd...ce.html#l00883