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

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

What would be this other method?

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.

Quote:

---

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.

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.

Thanks!

As was discussed not long time ago use portable way

if(number % 2)

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

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.

Quote:

---

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.

Quote:

---

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

Quote:

---

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

Quote:

---

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.

Quote:

---

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

Quote:

---

Originally Posted by vart

While the number is unsigned integer type

---

Why would it be any different for signed numbers?

Quote:

---

Originally Posted by cpjust

Why would it be any different for signed numbers?

---

As was already stated, if 11111110 is -1 for a byte, this will be read as an even number.

It will work on signed numbers if 2's complement is used.

Quote:

---

Originally Posted by cpjust

Why would it be any different for signed numbers?

---

If it's a ones complement, negative numbers will be "even when they are odd". Of course the machines that use ones complement also have a "negative zero" value, and I haven't ever worked on a machine with ones complement for negative numbers.

--
Mats

Seeing as bit 0 is the sign bit, perhaps the bit will be shifted to the 3rd position instead?
I don't know, but it sounds logical.

Quote:

---

Originally Posted by Elysia

Seeing as bit 0 is the sign bit, perhaps the bit will be shifted to the 3rd position instead?
I don't know, but it sounds logical.

---

I'm confused again. I thought bit 31 (on a 4-byte integer) was usually the sign bit. And, why does that matter? And ... 3rd position? And ... shifting? Why are we shifting?

Quote:

---

Originally Posted by Elysia

Seeing as bit 0 is the sign bit, perhaps the bit will be shifted to the 3rd position instead?
I don't know, but it sounds logical.

---

Huh? Bit zero isn't the sign bit in any type of integers that I'm aware of. Ones complement still use the top bit for sign, but it uses a direct "inverse" of the positive number, instead of "inverse+1" as two's complement use.

--
Mats

My bad. It's the last bit (31th for 4 bytes), not the first (bit 0).

Quote:

---

Originally Posted by MacGyver

As was already stated, if 11111110 is -1 for a byte, this will be read as an even number.

It will work on signed numbers if 2's complement is used.

---

Oh crap, I think you're right. I don't know much about those 1's vs 2's complement numbers, but I've only worked on machines that use 11111111 as -1.
What platforms use the other complement for numbers?

Quote:

---

Originally Posted by matsp

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.

---

Yeah, things get more confusing with negative values. But even the mod operator '%' can be confusing when applied to negative quantities.