1. ## Divisible by 2

Hello.

Is there a better way to know if a number is even or odd than checking if it is divisible by two?

ThankS

2. Yes, there is another way, but I'm not sure if it's better. In fact, I suppose it may not be entirely portable.

3. What would be this other method?

4. if(number & 1)

Its faster because it only checks if the 1s bit is set, but can have endian problems maybe. Not that I have experienced any with it as of yet.

5. Originally Posted by mike_g
if(number & 1)

Its faster because it only checks if the 1s bit is set, but can have endian problems maybe. Not that I have experienced any with it as of yet.
Is there a machine where integer variables and integer constants have different endianness? I can't see how that's possible.

6. Tbh I don't know, and I guess you are probably right. I thought I had read that somewhere on this forum, but like I said I never experienced a problem with it myself.

7. Thanks!

8. As was discussed not long time ago use portable way

if(number &#37; 2)

and leave this optimization to compiler, when it is suitable - it will replace it by &1 byhimself

9. These days compilers optimize a lot of things, you are better off sticking to the normal way of checking if a number is divisible by 2.

10. Originally Posted by mike_g
if(number & 1)

Its faster because it only checks if the 1s bit is set, but can have endian problems maybe. Not that I have experienced any with it as of yet.
On the list of unsafe things that's pretty low. I suppose it's a premature optimization, but I'm guilty of doing it all the time. I don't use it because it's "optimal" but because I understand what it means -- if the 1 bit is set, the number is odd. Just a basic fact, really.

11. Originally Posted by brewbuck
if the 1 bit is set, the number is odd. Just a basic fact, really.
While the number is unsigned integer type

12. Originally Posted by brewbuck
On the list of unsafe things that's pretty low. I suppose it's a premature optimization, but I'm guilty of doing it all the time. I don't use it because it's "optimal" but because I understand what it means -- if the 1 bit is set, the number is odd. Just a basic fact, really.
It works on all machines that use two's complement for negative numbers, but if your -1 value is 1111....1110 then the and with 1 will produce zero for -1, which is of course incorrect.

If all numbers are positive [and that's quite commonly the case in these sort of situations], then you should be fine even for ones-complement machines.

--
Mats

13. Originally Posted by tabstop
Is there a machine where integer variables and integer constants have different endianness? I can't see how that's possible.
Yes, it is. Custom architectures, for example. Nintendo 64 used low endian type I think, not sure. But the whole endianess story is because the processor really doesn't care. It doesn't matter if what way the bytes are stored because it works on bits only. So it can have one big complex mess of storing numbers, yet the processor can do its work just fine.

So it might not seem feasible, but it is indeed so.

14. Originally Posted by tabstop
Is there a machine where integer variables and integer constants have different endianness? I can't see how that's possible.
It wouldn't work very well, because MOST variables derive their current value from a constant in some way or another. So the constant and the variable must use the same bit & byte-order.

Note also that byte-order doesn't change the bit-order of a number. Bit 0 is still the lowest bit, whether that's the byte stored to the left, right or up or down from the higher byte.

It would make a difference if you do:
Code:
```int x;
char *p = (char *)&x;
if (*p & 1) ...```
This assumes the first byte is the low byte. (Little endian)

Even processors that allow endian-switching (e.g. 29K, Mips), the internal order of bits in a register remains the same, the only difference is when the data is stored to memory, it will either store the bytes as 31:24, 23:16, 15:8, 7:0 or 7:0, 15:8, 23:16, 31:24.

--
Mats

--
Mats

15. Originally Posted by vart
While the number is unsigned integer type
Why would it be any different for signed numbers?