I shit you not but one coworker I had dared call himself a data scientist and did something really similar to this but in Python and in production code. He should never have been hired. Coding in python was a requirement. I spent a good year sorting out through his spaghetti code and eventually rebuilt everything he had been working on because it was so bad that it only worked on his computer and he always pip freezes all requirements, and since he never used a virtual environment that meant we got a list of ALL packages he had installed on pip for a project. Out of those 100, only about 20 were relevant to the project.
Code reviews mean fuck all when the "senior" developer doing the review is someone who implements an entire API endpoint group in one single thousand-something lines magic function that is impossible to decipher for mere humans.
A few members of my team were reviewing codes but lots of PRs could be merged without tests or checks passing and only about 2 people before I joined understood what cicd is, no one else believed in its importance. They thought doing otherwise would "slow down the work precess and waste time, we know what we're doing anyway!".
I learned a lot from having to implement best practices and introduce tests in teams that don't give a fuck or were never required to do it. I'm amazed at the industry standards and fully understand why job ads keep listing git as a requirement.
Just print True all the time. Half the time it will be correct and the client will be happy, and the other half the time, they will open a ticket that will be marked as duplicate and closed.
Reminds me of the fake thermometers being sold during the peak of COVID that weren't actually thermometers but just displayed numbers to make people think they were.
def is_even(n: int):
import math
return sum(math.floor(abs(math.cos(math.pi/2 * n/i))) for i in range(1, 2 ** 63)) > 0
spoiler
i can't imagine how long it'll take to run, my computer took over 3 minutes to compute one value when the upper bound was replaced with 230. but hey, at least it's O(1).
Don't use recursion. Each call will need to allocate a new stack frame which leads to a slower runtime than an iterative approach in pretty much any language.
You have to make it easy on yourself and just use a switch with default true for evens, then handle all the odd numbers in individual cases. There, cut your workload in half.
You know, shortly after posting this I did think about whether it's still working if I just pass the underflow that will happen at some point or if I have to fix something in that case (like subtract 1 after the underflow). I deemed it "too complicated" and would just issue a warning that my code is only tested on positive numbers, but I think it will still work.
Every bit aside for the ones bit is even. All you have to do is get the ones bit(the far right) for it being a 1 or 0. Which is the fastest and least amount of code needed.
use bitwise &
// n&1 is true, then odd, or !n&1 is true for even
return (!(n & 1));
Looking at their code, it's really just a bunch of checks to make sure the variable passed is actually an integer that it can work with, followed by the solution:
return (n % 2) === 1;
I can't think of a more efficient way to get the answer. It does seem like it'd take more time to download the package than to just write the function yourself, though.
as division is complicated and expensive depending on the size of the numbers you'd usually receive as an input, this could be the most efficient solution. Certainly could have the best worst case if we imagine some 128bit shenanigans.
(Quietly implements a modulo check but only for a range between the current endpoint of the if branches and the highest value I expect the product to ever encounter)
On a sidenote, the completely non-shitposty version would be:
return !(var & 1);
Notice the single &, which should be bitwise AND. Fun thing: negative numbers in two's complement also have 1 for their LSB when odd. C definitely supports bitwise operators, and it appears C# does as well.
If the language you are using uses "real" integers, using a bit mask to get the least significant bit is probably a lot faster - assuming the compiler doesn't replace the operation for you, in which case it doesn't matter.
For another convoluted impl you could do some kind of string format print into a string. Then do your if/else comparing that string containing the last digit. Maybe create a hash set collection of all single digit even strings, then you’ve got O(1) performance using a contains() method.
Explanation: the percent is modulus. Basically it's just divide the first number by the second and return the remainder. If you do number % 2, it will return 1 if it is odd and 0 if it is even.
For example 4/2 has a remainder of 0 and therefore is even. 3/2 has a remainder of 1, and therefore is odd.
So what? It works and it's better than precompiling a list of all known even and odd numbers, and expecting a computer to iterate through a whole list every time it wants to check the value of something.
The stupid trig tables are just as problematic and it's why graphics chips use other geometric functions instead. It's just better to use a modulus.