Quickest way for even numbers

[Darksun4]

Hi all!
I want to check whether a number is odd or even. I've made an algorithm
but I believe there should be a faster one ( maybe a macro ).
Here it goes :

int iseven ( int number )
{
int first;
int tempnum;

tempnum = number;

first = number >> 1;
number = first << 1;

if ( tempnum == number )
return 0;

return 1;
}
Thanks in advance

[Christian Haselbach]

Darksun4 <da*******@yaho o.gr> wrote:

I want to check whether a number is odd or even. I've made an algorithm
but I believe there should be a faster one ( maybe a macro ).
Here it goes :

int iseven ( int number )
{ return !(number % 2); }

Alternatively: return (number & 1)^1

Ciao Chriss

[Emmanuel Delahaye]

Darksun4 a exprimé avec précision :

I want to check whether a number is odd or even. I've made an algorithm
but I believe there should be a faster one ( maybe a macro ).
Here it goes :

int iseven ( int number )
Identifiers beginning with is followed by lowercases are reserved for
future language extensions.

is_even() is fine (and additionally, readable).
{
int first;
int tempnum;

tempnum = number;

first = number >> 1;
Bitwise operators only work portably with unsigned integers.
number = first << 1;
DOn't shift anything if you want to go fast.
if ( tempnum == number )
return 0;

return 1;
}
Thanks in advance

What about

int is_even (long number)
{
return ((unsigned long) number & 0x1ul) == 0:
}

or

inline int is_even (long long number)
{
return (number & 0x1ull) == 0:
}

if you have C99.

Also consider an unsigned version of the functions

int is_even_ul (unsigned long number)

etc.

--
Emmanuel

[Emmanuel Delahaye]

Emmanuel Delahaye avait prétendu :

inline int is_even (long long number)
{
return (number & 0x1ull) == 0:
return ((unsigned long long) number & 0x1ull) == 0:
}

--
Emmanuel

[Christopher Benson-Manica]

Darksun4 <da*******@yaho o.gr> spoke thus:

I want to check whether a number is odd or even. I've made an algorithm
but I believe there should be a faster one ( maybe a macro ).
I suspect that you're not gaining much performance advantage over

!(number%2)

at the expense of quite a bit of clarity (IMHO). The overhead of the
function call probably more than offsets the possible penalty of using
the modulo operator.
int iseven ( int number )
{
int first;
int tempnum; tempnum = number; first = number >> 1;
If number happens to be negative, the results of this shift operation
are implmentation-defined.
number = first << 1; if ( tempnum == number )
return 0; return 1;
}

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Christopher Benson-Manica]

Emmanuel Delahaye <em***@yourbran oos.fr> spoke thus:

Bitwise operators only work portably with unsigned integers.

According to my reading of K&R2, the result is also portable for
signed integers with positive values.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Eric Sosman]

Emmanuel Delahaye wrote:

Darksun4 a exprimé avec précision :

I want to check whether a number is odd or even. [...]

What about

int is_even (long number)
{
return ((unsigned long) number & 0x1ul) == 0:
}

or

inline int is_even (long long number)
{
return (number & 0x1ull) == 0:
}

if you have C99.

"Premature optimization is the root of all evil," but
why not

inline int is_even(long long number) {
return ((unsigned int /* yes, int */) number & 1u) == 0;
}

... on the assumption that operations on `int'-sized data
may well be faster than on wider types.

--
Er*********@sun .com

[Dan Pop]

In <40************ **@sun.com> Eric Sosman <Er*********@su n.com> writes:

Emmanuel Delahaye wrote:

Darksun4 a exprim=E9 avec pr=E9cision :
=20

I want to check whether a number is odd or even. [...]

=20
=20
What about
=20
int is_even (long number)
{
return ((unsigned long) number & 0x1ul) =3D=3D 0:
}
=20
or
=20
inline int is_even (long long number)
{
return (number & 0x1ull) =3D=3D 0:
}
=20
if you have C99.

"Premature optimization is the root of all evil," but
why not

inline int is_even(long long number) {
return ((unsigned int /* yes, int */) number & 1u) =3D=3D 0;
}

=2E.. on the assumption that operations on `int'-sized data
may well be faster than on wider types.

Both are going to be unnecessarily slow on machines using
sign-magnitude, where the conversion from negative values to unsigned
values is actually changing representation. Unless the compiler is
smart enough to figure out the obfuscated intent, of course.

How about "return number % 2 == 0"; and letting the compiler choose the
best machine code sequence? We're no longer in the dark seventies, when
compilers had to fit into 64 KB and run on pathetically slow hardware...

The code generated from my version by gcc on x86, for a long int
parameter, is:

xorl %eax, %eax
testb $1, 4(%esp)
sete %al
ret

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Old Wolf]

Emmanuel Delahaye <em***@YOURBRAn oos.fr> wrote:

Emmanuel Delahaye avait prétendu :

inline int is_even (long long number)
{
return (number & 0x1ull) == 0:

return ((unsigned long long) number & 0x1ull) == 0:

}

Why would you do that? Since one operand of the '&' is unsigned
long long, the other will be promoted to it without a cast.

More readable, would be:

return (number & 1) == 0;

or !(number & 1) if you prefer, as then the 1 (1 decimal = 1 hex)
will be promoted to match 'number'. I would even go for
'int' instead of 'long long' since I don't care about any
bits other than the least-significant one.

[Mark A. Odell]

Da*****@cern.ch (Dan Pop) wrote in news:cd******** **@sunnews.cern .ch:

The code generated from my version by gcc on x86, for a long int
parameter, is:

xorl %eax, %eax
testb $1, 4(%esp)
sete %al
ret

Pretty tight, with return (number % 2) == 0 I get

srawi r0,r3,1
addze r0,r0
mulli r0,r0,2
subf r12,r0,r3
cntlzw r3,r12
rlwinm r3,r3,27,5,31
blr

and with return (number & 1U) == 0;
rlwinm r12,r3,0,31,31
cntlzw r3,r12
rlwinm r3,r3,27,5,31
blr

with Diab 5.0.3. I guess Diab's not as smart as it could be. The var.
'number' is in r3 of course.

--
- Mark ->
--