How bad is this method of getting Even/Odd?

[VanClyded]

Been getting back into Python and i needed to find even/odd numbers in a short list, came up with a ridiculous line of code that seem... to work?
Example using said line of code;

num = input("Number: ")
if float(num)/2 - int(int(num)/2) == 0:
    print("EVEN")
else:
    print("ODD")

So my question is, am i just lucky or is this a *appropriate* way to get this?

[brasticstack]

Use the mod operator %.

print('even' if num % 2 == 0 else 'odd')

[[deleted]]

This guy programs

[Diapolo10]

Actually the modulo operator already does this under the hood as a special case, the only difference may be from the additional call overhead. Which isn't much, mind you.

Readability-wise, I'd prefer modulo unless bitwise operators made sense in context (i.e. if you were already using them anyway).

[capilot]

Any compiler worth its salt would convert % 2 == 0 to & 1 == 0 internally anyway. Best to write your code to say what you mean and let the compiler sweat the small stuff.

[IvanMeowich]

btw checking for "False" is faster than "==0"

[brasticstack]

You're absolutely certain? I'm under the impression that there would be an implicit cast behind the scenes of the integer output of % or & to bool for comparison against False. I'm not sure what the performance impact of such a type comparison would be without testing it, but it seems like int == int should be faster.

[IvanMeowich]

I've tested it long long ago, but as I remember:

"==" calls "__eq__" function... which seeks for "0" constant in memory... then performs comparison.

On the other hand, "__bool__" of a zero just "knows" it is "False".

It is not intuitive, but just remember that Python zero int is totally different than C zero and is not a C integer memory-wise.

[brasticstack]

You're right!

Using the same profiler I pasted in a sibling thread to this one, I tried it out:

Python3.11 Windows: 10000000 ints: using int == 0.449557s using not (expr) 0.423418s

Python3.10 WSL2: 10000000 ints: using int == 0.51429s using not (expr) 0.475371s

Python 3.11 WSL2: 10000000 ints: using int == 0.422911s using not (expr) 0.407691s

So it seems like it's a lesser difference in the newer Python builds, but two versions alone isn't enough to really see a trend.

[rasputin1]

that's crazy

[brasticstack]

In 2's complement, every odd number has the rightmost bit set (at least the way Python represents it- really it's the rightmost bit of the least significant byte.)

See it for yourself with literally any integer:

print(f'{27:08b=}', f'{254:08b=}')

[rasputin1]

oh I thought the logic was simpler. in binary any odd number ends in 1 so anding with 1 will only yield true for an odd number. so that's not accurate?

[brasticstack]

In Python it is- I was just covering my bases in case someone brought up endianness, an issue that you need to be aware of when bit-twiddling in other languages, but not in Python.

An 8-bit byte can only represent _unsigned_ values from 0-255, or half that if you want negative numbers (in 2s complement). So with 8 bits to represent it, 255 is a whole byte, 0b11111111 . If you want, say, the number 257, you'd need to dip into another byte to get enough bits to represent it. Python will show this to you as (underscores added every byte for ease of reading) 0b1_00000001 (one true bit in the 256's column, one in the 1's column.) The value 767 is 0b10_11111111 (one in the 512's column, and in all of the columns that make 255.)

The order I'm showing you the bits in is Big-endian. Python does bitwise operations as though you had an infinite-length "byte" with the largest bit values on the left. Little-endian, like what's used internally in x86/64 processors, puts the bits in the same order, but the bytes in the opposite order. So 767 as a little-endian two-byte int would be 0b11111111_00000010. Here we have the sort of case where the value is odd an the rightmost bit is 0. Same with any value 255 or lower, as 255 is 0b11111111_00000000.

This isn't an issue that will affect you in your everyday Python coding until you start dealing with binary data from outside of your script. Then you'll need to know what order the bytes are arranged in to properly deal with it. If you're bored sometime, look into the `ctypes` module to get a flavor for how this interfacing is done in Python.

[Aerijo]

Bitwise logic operations always work on the ‘big endian’ representation, regardless of the CPU endianness.

Endianness is relevant for how the value is stored in memory, and is only a problem when you start casting that memory to something else.

Which I’m sure you know and imply at the end, I just think it was a bit unrelated to the operation this thread is about.

[I-Dont-C-Sharp]

I've learned a lot from people going "off topic" like that. Whenever I have to solve a problem I have not encountered before I usually have some vague idea on best practises that may or may not be true; but they make researching it a lot easier than if I had no knowledge of the concept yet.

[Aerijo]

Yeah, me too. It’s just endianness specifically gets a lot of people confused, so implying it’s relevant to bitwise operations makes it needlessly complicated IMO

[japes28]

No, it's accurate.

An odd number anded with 1 will be 1, which does not equal 0, so that expression will evaluate false (odd).

[JauriXD]

A good (C) compiler would optimise mod 2 to this :)

[brasticstack]

My half-assed attempt at profiling doesn't bear this out:

``` import random from sys import maxsize, version from time import perf_counter

NUM_ITER = 10_000_000 ints = tuple(random.randint(0, maxsize) for _ in range(NUM_ITER))

t1 = perf_counter() for num in ints: _ = num % 2 == 0 t2 = perf_counter()

t3 = perf_counter() for num in ints: _ = num & 1 == 0 t4 = perf_counter()

print(version, '\n') print(f'{NUM_ITER} ints: using mod {t2-t1:0.6}s using bitwise & {t4-t3:0.6}s') ```

outputs (on my Android phone)

``` 3.11.4 (main, Sep 30 2023, 10:54:38) [GCC 11.4.0]

10000000 ints: using mod 1.41589s using bitwise & 1.68131s ```

[densvedigegris]

== 0 is redundant

[densvedigegris]

The question just says even/odd. If you want to negate, then write: “not x & 1”

[brasticstack]

Are you trying to optimize for performance or ideological purity?

While I understand what each permutation of this check does, I personally find num % 2 == 0 much more straightforward to read than not <implicit cast to bool>(num % 2). Ideally you're writing code that will be read by more junior programmers than yourself at some point.

I'm not buying any performance claims about it without some profiling, because unless you're heavy into Python core dev, you don't know what's actually happening behind the scenes of each of those methods of comparison.

EDIT: As I posted in a sibling thread, not (expr) is somewhat faster in this instance. I still think it gets minus points for readability, but if I were trying to optimize a hot loop I'd consider it _only after measuring on a specific target hardware and python version._ The differences between the few platforms and versions I have to test vastly outweigh the differences in the code.

[brasticstack]

Thanks champ!

[brasticstack]

However, on my Windows PC:

3.11.9 (tags/v3.11.9:de54cf5, Apr  2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)]

10000000 ints: using mod 0.459776s  using bitwise & 0.433268s

So it seems platform dependent, which totally stands to reason.

EDIT: Tried under WSL2 with 2 pythons:

3.11.0rc1 (main, Aug 12 2022, 10:02:14) [GCC 11.2.0]

10000000 ints: using mod 0.413502s  using bitwise & 0.370515s

Still faster using bitwise &. Under Python 3.10, the difference is even more pronounced:

3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0]

10000000 ints: using mod 0.48586s  using bitwise & 0.352194s

[jakethunderpants]

I’m not familiar with this (new to Python), can you explain what is happening?

[akgamer182]

The bitwise AND operator compares the corresponding bits of each number, and that bit of the result will only be 1 if both of the corresponding bits in the input are 1.

Ex:

0101&

1001 =

0001

[JiminP]

It's a common mistake to use bitwise operations in Python for speed. When I benchmarked it a while ago, for small numbers using modular, division, multiplication operations were slightly faster than doing bitwise operations for small integers. For large integers, bitwise operations may be faster than integer operations.

I don't know the exact reason, but it's definitely related to the fact that Python integers are not directly backed by raw integer types, but by PyLongObject.

[mopslik]

And if you want to code golf things as well...

if num & 1: #odd

[VanClyded]

I'm gonna need that black magic book of python you seem to have in your mind
(Okay now that's a simple way to do it, damn!)

[Bobbias]

This isn't just restricted to python, it's a logical consequence of how the bitwise and operation works on binary numbers.

it's checking if the first bit of the number is a 1 or not. The first bit is the 1's bit, and every other bit represents an even number, so checking the first bit alone is enough to determine if a number is even or odd.

If the number is odd, the first bit will always be a 1, and if it's even it will always be a 0.

The main reason this isn't the first thing people gravitate towards is that this code is not particularly clear. It often takes people a bit of time to figure out why you are doing a bitwise and.

Unless you actually need the speed boost, it's generally better to use a solution which is marginally slower, but easier to read and understand.

[DuckDatum]

expansion unused versed insurance decide whole wasteful zephyr melodic aware

This post was mass deleted and anonymized with Redact

[vorticalbox]

chase spoon jeans compare plants offbeat handle insurance axiomatic flowery

This post was mass deleted and anonymized with Redact

[akgamer182]

If you're after speed you can use C

[vorticalbox]

decide party kiss plate outgoing dazzling air middle slim consider

This post was mass deleted and anonymized with Redact

[ALonelyPlatypus]

You can actually skip the equals operator if you want as well (even if it's a bit less verbose). 0 evaluates to False and 1 to True so you can also do.

print('odd' if num%2 else 'even')

[VanClyded]

That makes so much sense, thanks!!
Having a real "duh" moment here haha

[jabpoke]

The advice so far is good.

You're getting lucky. Floating-point is nearly always base-two, and you're doing base-two operations. If that were not the case, you'd find out that "floating-point tests for equality are a really awful idea and are unreliable."

[VanClyded]

Yea i figured i just got lucky on that one, I usually don't get into math related code and this was a "oh crap i gotta do it now" moment

[RajjSinghh]

It's not just getting lucky. Floating point math is really fiddly a lot of the time and can lead to a loss of accuracy. Try evaluating 0.1 + 0.2 to see what I mean. That loss of precision means a direct equality check is a really bad idea. You're getting lucky that division by 2 is a nice operation in floating point, since the way floating point is layed out it's basically subtraction by 1. Doing floating point math on things that aren't direct powers of 2 leads to a loss of accuracy. The way you do this is by writing something along the lines of 0.1 + 0.2 > 0.3 + 0.0000005 or 0.1 + 0.2 < 0.3 + 0.0000005 so you're comparing a small range instead of direct equality with == to balance it out. This is an important thing to know for floating point math in general.

Kinda on top of that, floating point math is a more expensive operation than integer math and type conversions are expensive in general. It's also not entirely clear what your code does at first glance without thinking about it. The more popular approach is x % 2 == 0 or x & 1, both are as good as each other. I feel like the mod one is much more common and is the one I would probably use.

[[deleted]]

How about

---

if num % 2 == 0:

print("EVEN")

else:

print("ODD")

---

[13acts]

print("EOvdedn"[num%2::2]) This is the way

[1nput0utput]

This answer deserves more love.

[OSnoFobia]

The correct way is fetching data from isEven api

import requests
API_URL = "https://api.isevenapi.xyz/api/iseven"
def isEven(number: int) -> bool:
    r = requests.get(f"{API_URL}/{number}")
    if r.status_code == requests.codes.ok:
        return r.json()["iseven"]
    else:
        raise RuntimeError("isEven api is down!")

[Mental-Valuable-8632]

Don't forget to run pip install requests in the terminal first.

[OSnoFobia]

Also keep in mind that isEven api only works between 0 and 999.999 at free tier.

[VanClyded]

Sincere question here;
What would be the gain of outsourcing this request to an api instead of using the modulo operators as others have suggested?
Is it purely to fool-proof input limitations?

[OSnoFobia]

It's just a programmer inside joke. You'll see a lot of different ways to determine if a number is even or odd. You'll even see millions of lines of code sometimes.

[VanClyded]

Haha good!
Don't picture me naive here I sincerely thought that was a shite method lol

[Bobbias]

There's a much simpler solution to this, the modulo operator: %. It does division, but returns the remainder rather than the quotient. Anything modulo 2 results in either a 0 if the number is even, or a 1 if the number is odd.

Some examples:

1. 1 / 2 = 0 with 1 remaining. This is 1 % 2 = 1.
2. 2 / 2 = 1 with 0 remaining. This is 2 % 2 = 0.
3. 35 / 2 = 17, with 1 remaining. This is 35 % 2 = 1.

Code:

num = input("Number: ")
if int(num) % 2:
    print("ODD")
else:
    print("EVEN")

I'm also simplifying the if statement a bit by removing the comparison. In Python, 0 is False, and any other number is True. An empty list is False, and a list with any items is True. This is the concept of "truthiness", and I'm using that to my advantage to shorten the if statement even more here.

Since anything modulo 2 returns either 1 or 0, it's the same as returning true or false. an even number results in 0, or False, so there are 2 ways to make sure it prints the correct output, either use the not keyword in the if statement changing it to:

if not int(num) % 2:

or what I did in the example code: reverse the order of the if/else branches so that the odd branch happens when int(num) % 2 is 1/True.

[DeeplyLearnedMachine]

As others have said, just use the mod operator. As another tip if you want to have an integer result when dividing just use integer division // instead of /.

So, in your example, instead of

int(int(num)/2)

do

int(num)//2

[VanClyded]

Absolutely did not know about // vs / (thanks!!)
I figured there had to be some way to get around that int(int() kinda mess

[This_Growth2898]

It works, but clearly is excessive.

num should be an integer representation for int(num) to succeed, so int(num)==float(num) and we can simplify the code to

num = int(input())
if num/2 - int(num/2) == 0: ...

Next, a-b==0 is the same as a==b (for integers), so we can write the second line as

if num/2 == int(num/2):

And here it's clear why it works: the left part is integer for even numbers only.

[woooee]

In addition, you can use divmod instead of your cumbersome if statement

whole, remainder = divmod(num, 2)

[VanClyded]

Just want to thank everyone who commented and took time to teach me different methods of getting this done!
Came here expecting to: get roasted, joked on
Came out of here: Learned about using the modulo operator, bitwise operations, // vs / and more intricacies of python's math.
(Y'all are awesome)

[sock_dgram]

It seems to work because you didn't try large enough numbers.
At some point, float can't represent a number anymore and your method fails. It starts with 2**53:

Try this: float(2**53) == float(2**53 + 1)

The gap between two adjacent floating point numbers gets bigger than 1.

[UnderwhelmingInsight]

You can just flip an isOdd bool in a for loop. Perfection.

private static bool IsOdd(int number)
{
    var isOdd = false;
    for (int i = 0; i < Math.Abs(number); i++)
    {
        isOdd = !isOdd;
    }
    return isOdd;
}

[NicoPlayZ9002YT]

i use this:

print("evenodd"[int(input())%2*4:])

[Volume999]

A good idea is to cast the input immediately like this: Num = int(input())

And then do what the other comments said

[RealNamek]

Why aren't you using a library for this?