Forums Feature Suggestions isodd :: iseven

*scratches head*

No one ever said "custom identifiers" until you brought it up.. what are you even talking about?

Why do you think you'd need to check all of those methods if the identifier is built-in? That makes no sense whatsoever.

As starbucks_mafia stated, there's no reason why a built in method would check all of those. Each of those *by itself* would show whether it's even or odd. The built in method would just use one of those ... whichever is fastest, I'd imagine.

Basically I was saying there are too many different multiple ways of checking for something like $isodd.

If cutting the number in half includes a . in it.

If the last digit is isin 13579.

Etc.

So if Khaled made a built-in $isodd identifier, wouldn't there be more than 1 algorithm?

I guess the question is, which method is the fastest.

If you combined them, then I think a built-in 1 would be slower than a simpler if statement/custom identifier.

So I think the only way you can know if a simpler custom identifier is faster than a built-in 1 is to see the code of the built-in, and if the built-in is, twice as long as a custom 1 you can make, *shrug.* Only Khaled can bench compare the 2.

Well, truth be told, benchmarking isn't needed. the bitwise operator would be fastest

if (x & 1) /* In C of course */

because that's probably one of the quickest cpu instructions out there: AND AL, 0x1

Not surprisingly, that's already what if (%x & 1) in mIRC does-- which is further reason why an "iseven" isn't needed.. the addition would be purely for readability purpose..that doesn't sell me, anyway.

lol interesting argument... well i still don't know what a bitwise comparison (&) so i still support is-odd:is-even because its helpful even if u know other ways, its just faster because theres less writing involved and all of what you guys said

Ok, quick ramble for foshizzle. This is all binary stuff, so hopefully knowing that will make this easier to understand.

A bitwise operator takes these binary values and does an operation on it using standard logic gates. At their simplest, you've got the AND, OR and XOR (exclusive OR).

AND as a bitwise operator in most programming langauges is represented as a single &.

AND does a simple comparison to see if there are commonalities with the two values. Take this for instance:


As a binary comparison in 8 bits, you are comparing:

5 -> 00000101
to
1 -> 00000001

The result of this is 1 (00000001); that trailing 1 being the only bit in common turned on.

In the context of this thread, seeing if that trailing bit is on is enought to tell if it is an odd or even number. All odd's will have that bit turned on. All even's will not have it turned on.

Just to clarify one thing however, all numbers are represented in binary anyway, and these operations are done at the binary level in the processor. There's no string comparison or anything like that. Also note that your computer is running in (at minimum these days) 32bit mode. In otherwords, this takes something like one CPU cycle at it's root (ignoring programming overhead).

It should also be noted that binary is base 2, means counting in binary is something like:

001 = 1
010 = 2
011 = 3
100 = 4
101 = 5
...

see the pattern? This is why an AND with the number 001 will properly test if the number is odd. You can extend this to any number of bits... if the last bit is 1, it is an odd number.

And as Bekar said, dealing with bits is what a processor was made to do, so the and operation is a basic building block for not only processor instruction sets, but all digital circuit theory as well.

thx, ill read it later so i can figure it out...