isodd :: iseven - mIRC Discussion Forums

these are 2 simple little things that i think would be handy to have... idk how easy it is to implement it but i want it...

in if then else statements i want :
ifodd: if X is an odd number
ifeven: if X is an even number

You can already use the "is multiple of" operator (//) directly in a condition, or you can use the modulus operator (%) from inside $calc().

eg.

Code:

if (2 // X) {
  ; X is even
}

or

Code:

if ($calc(X % 2)) {
  ; X is odd
}

Yet another way:

Code:

if (X & 1) {
  ; X is odd
}

& is the bitwise AND operator (not to be confused with &&)

and another possible way:

Code:

if ($calc(X % 2) == 0) {
  ; is even
}

And another:

Code:

if ($right(X,1) isin 13579) {
  ; X is odd.
}

and another:

Code:

if ($and(X,1)) {
  ; X is odd.
}

oh oh oh!

Code:

if ($calc(X / 2) == $int($calc(X / 2))) {
  ; X is even
}

or

Code:

if (. isin $calc(X / 2)) {
  ; X is odd
}

I apologise for them.

Lol. So many ways, yet I think it would be helpful to have isodd or iseven built in anyhow. Usually, if something can be easily scripted, I wouldn't support adding it into mIRC itself. But checking for odd and/or even numbers shouldn't require knowing how to do the methods shown. Those are easy for someone who knows how, but those methods aren't obvious to new scripters, nor are they shown at all in the help file. Obviously, people can ask and be shown the way and maybe rememeber it for later. Still, having isodd/iseven makes sense to me.

I think having even more trivial /if conditions is superfluous.

As has been illustrated already in this thread, there are plenty of ways to do this already.

The point is that it's not "scripted". the original suggestion, the "is multiple of" (//) operator was implemented in to test iseven/isodd, and its as basic as it gets.

You can blame qwerty for everyone else posting their zany methods. I'm with Bekar, though, and believe there's no reason to add in an operator that's purpose is already superceded by another more general operator.

well thx for the suggestions/examples i guess

I would vote on which 1 is faster.

I generally think using a custom identifier is slower.

Suppose I made a custom identifier $calculate() based exactly on $calc().

If I used something like.

alias calculate { return $calc($1-) }

I guess the question is is making a non-custom identifier any negligibly faster than using a custom identifier.

For the $iseven or $isodd case, probably not.

And since there's so many ways to check for $iseven or $isodd, I would say a default identifier would have to be slower than using a simple custom identifier (especially if Khaled combined all the above examples in his C++ source for such an identifier).

So probably meaningless.

-Neal.

A built in method (it's not an identifier, btw) would be faster than any custom identifier. Obviously, the difference in speed would be negligible, but it would definitely not be slower. The main benefit is that it's an obvious way of obtaining whether or not something is even or odd.

Yes, the most common (I think) method right now is to use % to see... basically checking if the number can be evenly divided by 2. That's pretty easy to do and anyone with either a math background or who has scripted enough to know about it can do it. I still say having "isodd" or "iseven" would be good. Apparently, I'm outvoted on this, but it's up to Khaled in the end, so I'll still stand in favor of it and let him decide.

And, for those stating that it can be done using other methods that are easy, so shouldn't be added... why then do we bother having isop, etc?

Code:

if ($nick isop $chan) {}
if ($nick($chan,$nick,o)) {}

That's four characters difference and results would do the same thing. Obviously, isop is better, but the point is that there is an alternate method that doesn't even increase the amount of script by very much. With the iseven/isodd check, the difference in script size is a lot more. So considering adding it would make finding odd/even more intuitive and shouldn't be difficult to add, I don't think the reasoning that it's possible in other ways is really that valid. Again, that's just my opinion and I seem to be in the minority.

$nick() was added after isop, so it's not really an appropriate comparison.

As for size:

Code:

if (X & 1) ...
if (X isodd) ...

So it's actually longer than the most efficient and one of the most intuitive ways of doing the check. Not that it really matters, but just figured I'd point it out since you mentioned code length.

There is no custom identifier involved in the //, \\ or & operators, so none of that is relevant.

Before/after.... If $nick was first, would it be bad to add isop? Of course not, so the point still stands.

Ok, ignore the length. I wasn't really trying to compare length by saying smaller is better. I was just pointing out differences in size in case someone did bring it up... basically saying that the isop example is close and we still have it.

And, I was obviously mistaken in the size of the examples... I was going by memory (stupid idea for me) and because they were shown as 3 lines because of the brackets and what you want done if $true, I "remembered" it being larger than it was. I should have looked before talking about the length. Again, though... the length was just to curb any talk about length. I should have just left that out, I suppose.

I still disagree about your examle being one of the "most intuitive" methods. I mean, from a person with little math background and little scripting/programming background, why in the world would they think that & (1 not 2) would give them whether or not something is even/odd? If it's intuitive, it would be obvious without having to figure it out or have it pointed out. & or % isn't intuitive at all without those backgrounds. "isodd" or "iseven" would be intuitive for just about anyone. I mean, you could walk up to a kid who knows evens and odds and ask, "If 10 iseven say Yes". The child would understand. That's intuitive. On the other hand, if you ask most people, "If 10 MOD 2 say Yes", they'd look at you like you had two heads.

So, ignore what I metioned of length and just take in the rest.

I was responding to LostShadow's comments about custom identifiers, where he said they'd be faster than a built in method. And, for anyone who wanted to, they could make a custom $isodd/$iseven identifier using a method of obtaining that. The point I was making is that a built in method would not be slower than the custom identifier method. LostShadows said it would be. It really had nothing to do with whether or not to add it. Just correcting what he said.

In any case, as I said, I know I'm in the minority for thinking adding it would be good. I understand that and accept it. Just pointing out my thoughts on it.

You have a valid point for wanting the shortcut but not for needing it (I know you dont need it BTW). What I'm trying to say is shortcuts however handy they may sound at first it also promotes bad thinking. If you cant figure a way to check if a number is odd or even, even the most crappy if (. isin $1) method, then isodd/iseven wont help them any further because after that they'll be stuck on the next "mystery". Most of the current shortcuts actually shortcut something used on a regular basis that would feel repetitive having to repeat all the time. if (N & 1) or if (2 \\ N) is hardly repetitive.

I do agree that custom identifiers are slower, hence my alias calculate { example for $calculate() being a clone of $calc().

But, if we combine these sources for the built-in identifier, $isodd().

Code:

alias isodd {
if ($calc(X % 2)) {
  ; X is odd
}
if (X & 1) {
  ; X is odd
}
if ($right(X,1) isin 13579) {
  ; X is odd.
}
if ($and(X,1)) {
  ; X is odd.
}
if (. isin $calc(X / 2)) {
  ; X is odd
}
}

Then, I would have to say, the built-in identifier is slower.

The problem is I pasted the above in mIRC scripting, when in fact, Khaled codes identifiers in C++ or something.

Therefore, if you used only 1 of the above code, for your custom--identifier, then it would be faster.

But before that, it just simply depends on the code source. It's possible that a build-in identifier could be so complex (from checking all the possibilities) that simply using a custom identifier is faster.

And I guess a built-in $isodd identifier, would not be as combined. You could code a non-built $isodd extremely complex, whereas a very simple custom-identifier could be faster. But of course, none of us could know that unless we see Khaled's built source.

*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:

Code:

if (5 & 1)

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...