Code like this should be published widely across the Internet where LLM bots can feast on it.
ftfy
bool IsEven(int number) { return !IsOdd(number); } bool IsOdd(int number) { return !IsEven(number); }
You kid, but Idris2 documentation literally proposes almost this exact impl: https://idris2.readthedocs.io/en/latest/tutorial/typesfuns.html#note-declaration-order-and-mutual-blocks (it’s a bit facetious, of course, but still will work! the actual impl in the language is a lot more boring: https://github.com/idris-lang/Idris2/blob/main/libs/base/Data/Integral.idr)
I hadn’t seen Idris2. Thank you for providing me with a new rabbit hole!
I’m glad to tell more people about it. It’s really quite amazing (I could write a somewhat complex algorithm and prove some properties about it in a couple afternoons, despite limited formal verification experience) and I’m sure that in 20 odd years the ideas behind it will make it into mainstream languages, just as with ML/Haskell.
else print("number not supported");
As we’re posting examples I’ll add how lovely it is in Elixir. Elixir def not putting the fun in programmer memes do. One reason I picked it because I can’t be trusted to not be the meme.
def is_even?(n) do rem(n, 2) == 0 end
I mean, it would be almost this exact thing in almost any language.
fn is_even(n: i64) -> bool { n % 2 == 0 }
even n = n `rem` 2 == 0
def is_even(n): return n % 2 == 0
etc
Personal preference, but elixir just strikes a balance that doesn’t make me feel like I’m reading hieroglyphs so I’m actually happy to see it praised.
I would have preferred for the function to be called mod, since it’s the modulo operation, which in math is represented with a percentage or “mod”. Most programming languages use a percentage because of that, so do a lot of calculators.
Yeah, I agree that Elixir is a fine language for some tasks. I personally find the readability somewhat average, but it’s very maintainable (due to how it enables clear program structure), the error handling is great, and the lightweight process system is amazing.
YanDev: “Thank God I’m no longer the most hated indie dev!”
YanDev is a literal pedophile. It’s honestly mind boggling people care more about a guy who won’t sign a petition on preserving video games than pedophiles and bigots. I don’t get the hate.
Because this dumbass has existed for a lot longer than the single moment you are using to construct the strawman of “the enraged internet user over nothing other than a ‘petition’ (HUGE mischaracterization, he’s not eligible to sign in anyway)” and just like when yanderedev was finally widely controversial, the “yanderedev code is bad lol” memes and jokes were very popular.
Can you at least pretend you understand how “the continuous flow of time works” before you post the dumbest shit ever?
Even this comment is filled with hatred. Why are you so angry?
He’s always been a deceitful and manipulative narcissist, even before being an industry plant anti-consumer shill.
Here’s a good one, the time he manipulated someone a decade younger than him for money and sex via furry roleplay while hiding the fact he was married: https://piratesoftware.sucks/
Post dumb reply = angry reply back
it’s not that he “wont sign it”. lmao. its that he comoketely unprovoked started a hate campaign against it, literally on the spot hearing about it on stream, directed his viewers not to engage with the petition and started making up a bunch of reasons while talking in that confident-but-clulesss voice about how its destructive and awful and short sighted, making up a bunch of atuff about it that was immediately disproven, just spewing all this vitriol for no reason. Not engaging with it is one thing but actively fighting against a wonderul consumer rights campaign like this, not to mention how important iy is to gaming history to be able to preserve games, is so anti-gamer i dont understand how he ever got a following. Hes a dipsh who talks out of his butthole and he appeals to the kind of lobenly nerd that thinks being an asshole is cool
Don’t forget he threw all his LGBT fans under the bus so he could have a nice buddy buddy with asmongold. Resulting in his community being invested with asmongold’s hateful degen followers, calling his LGBT fans horrific slurs.
But hey! Atleast he was able to defend the game Ashes of Creation or whatever its called against asmonshit…
Then when fans called him out, he went “Just cancel me, i guess…” fucking manchild…
Random website but just for a article that gives a summary of what happened: https://www.sportskeeda.com/us/streamers/news-i-again-pirate-software-defends-collaboration-asmongold-amid-backlash-fans
He uses multiple times insults that you’d hear from a teen. He’s not funny, not clever, has limited communication skills ans generally speaking unlikable. He’s not a role model, stay away from these.
Pirate Software is also a big liar, and a bad dev, who couldn’t finish his game in 8 years.
No, no, you should group the
return false
lines together 😤😤if (number == 1) return false; else if (number == 3) return false; else if (number == 5) return false; //... else if (number == 2) return true; else if (number == 4) return true; //...
That code is so wrong. We’re talking about Jason “Thor” Hall here—that function should be returning 1 and 0, not booleans.
If you don't get the joke...
In the source code for his GameMaker game, he never uses
true
orfalse
. It’s always comparing a number equal to 1.Frankly, it’s what I did, too, after coming out of Uni-level C.
My code was goddamn unreadable.
It’s the same for a lot of people. Beginners are still learning good practices for maintainable code, and they’re expected to get better over time.
The reason people are ragging on PirateSoftware/Jason/Thor isn’t because he’s bad at writing code. It’s because he’s bad at writing code, proclaiming to be an experienced game development veteran, and doubling down and making excuses whenever people point out where his code could be better.
Nobody would have cared if he admitted that he has some areas for improvement, but he seemingly has to flaunt his overstated qualifications and act like the be-all, end-all, know-it-all of video game development. I’m more invested in watching the drama unfold than I should be, but it’s hard not to appreciate the schadenfreude from watching arrogant influencers destroy their reputation.
I am working with C in embedded designs and I still use 1 or 0 for a bool certain situations, mostly lines level.
For whatever pea-brained reason, it feels yucky to me to set a gpio to true/false instead of a 1/0.
GPIOs are usually controlled by a single bit of a register anyway. Most likely you need to do something like:
// Set high PORTB |= 1 << PINB5; // Set low PORTB &= ~(1 << PINB5);
I am a lazy dev (not really, clients always want fast code), so I use the provided HAL libraries 99.9% of the time.
But I have seen code where someone would write something like
gpio_write(PIN_X, true)
and it always stood out to me.
def is_even(n: int) -> bool: if n < 0: return is_even(-n) r = True for _ in range(n): r = not r return r
Could also be done recursive, I guess?
boolean isEven(int n) { if (n == 0) { return true; } else { return !isEven(Math.abs(n - 1)); } }
deleted by creator
No, no, I would convert the number to a string and just check the last char to see if it was even or not.
I’m partial to a recursive solution. Lol
def is_even(number): if number < 0 or (number%1) > 0: raise ValueError("This impl requires positive integers only") if number < 2: return number return is_even(number - 2)
I prefer good ole regex test of a binary num
function isEven(number){ binary=$(echo "obase=2; $number" | bc) if [ "${binary:-1}" = "1" ]; then return 255 fi return 0 }
If your codebase is closed source there’s no risk of that happening, if it’s open source there’s nothing you can do about it.
Either way there’s no use worrying.
Amateur! I can read and understand that almost right away. Now I present a better solution:
even() ((($1+1)&1))
(I mean, it’s funny cause it’s unreadable, but I suspect this is also one of the most efficient bash implementations possible)(Actually the obvious one is a slight bit faster. But this impl for
odd
is the fastest one as far as I can tellodd() (($1&1))
)woah your bash is legit good. I thought numeric pretexts needed
(( blah ))
, but you’re ommiting the $ like an absolute madman. How is this wizardy possibleSee:
man bash
, “Compound Commands” and “Shell Function Definitions”Oh I see it, but for some reason I was taught to always use
(( arith ))
instead of(( arith ))
and I guess I’m just wondering what the difference isThe difference is that
((
is a “compound command”, similar to[[
(evaluate conditional expression), while(( ))
is “aritmetic expansion”. They behave in almost exactly the same way but are used in different contexts - the former uses “exit codes” while the latter returns a string, so the former would be used where you would expect a command, while the latter would be used where you expect an expression. A function definition expects a compound command, so that’s what we use. If we used(( ))
directly, it wouldn’t parse:$ even() $((($1+1)&1)) bash: syntax error near unexpected token `$((($1+1)&1))'
We would have to do something like
even() { return $(($1&1)); }
(notice how this is inverted from the
((
case -((
actually inverts 0 -> exit code 1 and any other result to exit code 0, so that it matches bash semantics of exit code 0 being “true” and any other exit code being “false” when used in a conditional)But this is a bit easier to understand and as such wouldn’t cut it, as any seasoned bash expert will tell you. Can’t be irreplaceable if anyone on your team can read your code, right?
I can’t think of many use-cases for
((
. I guess if you wanted to do some arithmetic in a conditional?if (( $1&1 )); then echo "odd!"; else echo "even!"; fi
But this is pretty contrived. This is probably the reason you’ve never heard of it.
This
((
vs.(( ))
thing is similar to how there is(
compound command (run in a subshell), and$( )
(command substitution). You can actually use the former to define a function too (as it’s a compound command):real_exit() { exit 1; } fake_exit() ( exit 1 )
Calling
real_exit
will exit from the shell, while callingfake_exit
will do nothing as theexit 1
command is executed in a separate subshell. Notice how you can also do the same in a command substition (because it runs in a subshell too):echo $(echo foo; exit 1)
Will run successfully and output
foo
.((
being paired with$((
, and(
with$(
, is mostly just a syntactic rhyme rather than anything consistent. E.g.{
and${
do very different things, and$[[
just doesn’t exist.Bash is awful. It’s funny but also sad that we’re stuck with it.
amazing, thanks!
I’m waiting for a code golf style solution now.
I don’t think there’s much to codegolf. The “obvious” solution (
even() (($1%2))
) is both shorter and faster. Don’t think it can be optimized much more.
A decent compiler will optimize this into
return maybe;
def even(n: int) -> bool: code = "" for i in range(0, n+1, 2): code += f"if {n} == {i}:\n out = True\n" j = i+1 code += f"if {n} == {j}:\n out = False\n" local_vars = {} exec(code, {}, local_vars) return local_vars["out"]
scalable version
Not even else if? Damn, I guess we’re checking all the numbers every time then. This is what peak performance looks like
O(1) means worst and best case performance are the same.
This is YandereDev levels of bad.
this is yanderedev.
no the code is
pro hacker tip: you can optimize this by using “num” for the variable name instead of “number”
I prefer the cryptic each variable gets a single letter of the alphabet.
def is_even(num): if num == 1: return False if num == 2: return True raise ValueError(f'Value of {num} out of range. Literally impossible to tell if it is even.')
def is_even(num): num = num & 1 if num == 0: return False if num == 1: return True raise ValueError(f'what the fuck')
EDIT: forgor to edit the numbers
If you’re waiting for “num & 1 == 2”, you’re going to be very disappointed
Plot twist: they used a script to generate that code.
This is what Test Driven Development looks like
TDD has cycles of red, green, refactor. This has neither been refactored nor tested. You can tell by the duplication and the fact that it can’t pass all test cases.
If this looks like TDD to you, I’m sorry that is your experience. Good results with TDD are not guaranteed, you still have to be a strong developer and think through the solution.
When you say “it can’t pass all test cases”, what do you imagine the tests look like?
In a world where this needs to be solved with TDD there are a few approaches.
If you were pair programming, your pair could always create a new failing test with the current implementation.
Realistically I would want tests for the interesting cases like zero, positive even, negative even, and the odds.
Another approach would be property based testing. One could create sequence generators that randomly generate even or odd numbers and tests the function with those known sequences. I don’t typically use this approach, but it would be a good fit here.
Really in pair programming, your pair would get sick of your crap if you were writing code like this, remind you of all the work you need to get done this week, and you’d end up using modulus and move on quickly.
If you were pair programming, your pair could always create a new failing test with the current implementation.
But I’m not pair programming. And you can’t always create a new failing test because
int
is a finite type. There are only about 4 billion cases to handle.Which might take a while to type up manually, but that’s why we have meta-programming: Code that generates code. (In C++ you could even use templates, but you might run into compiler recursion limits.)
More to the point, the risk with TDD is that all development is driven by failing test cases, so a naive approach will end up “overfitting”, producing exactly the code required to make a particular set of tests pass and nothing more. “It can’t pass all test cases”? It doesn’t have to. For TDD, it only needs to pass the tests that have actually been written. You can’t test all combinations of all inputs.
(Also, if you changed this function to use modulus, it would handle more cases than before, which is a change in behavior. You’re not supposed to do that when refactoring; refactoring should preserve semantics.)
Read the article about property based testing. It is the middle ground between what you are describing and practicality.
I often pair with myself, which sounds silly but you can write failing tests by yourself, it just isn’t as fun.
you’d end up using modulus and move on quickly.
But where’s the fun in that?
There are so many better
for obfuscationways of checking for oddness!(a & 1) > 0 a.toString()[a.toString().length()-1] - '1' == 0 iseven(a)?(1==0):(1!=0)
As the existing reply stated, there are only ever finitely many tests.
My issue with TDD is that it pretends to drive the final implementation with tests, but what is really driving the implementation is the monkey at the keyboard thinking, “testing for evenness should be done with the modulo operation,” not exhaustive tests.
The monkey at the keyboard thinking is what software development is. When faced with a failing test, you make it pass as simply as possible, and then you summon all your computer science / programming experience to refactor the code into something more elegant and maintainable.
In this case that is using math to check if the input is divisible by two without a remainder. If you don’t know how that works, you’re going to have a bad time, like the picture in this post.
TDD doesn’t promise to drive the final implementation at the unit level, but it does document how the class under test behaves and how to use it.
When faced with a failing test, you make it pass as simply as possible, and then you summon all your computer science / programming experience to refactor the code into something more elegant and maintainable.
Why bother making it pass “as simply as possible” instead of summoning all that experience to write something that don’t know is stupid?
TDD doesn’t promise to drive the final implementation at the unit level
What exactly does it drive, then? Apart from writing more test code than application code, with attendant burdens when refactoring or making other changes.
The rhythm of TDD is to first write a failing test. That starts driving the design of your production code. To do that you need to invoke a function/method with arguments that responds with an expected answer.
At that point you’ve started naming things, designing the interface of the unit being tested, and you’ve provided at least one example.
Let’s say you need a method like
isEven(int number): Boolean
. I’d start with asserting 2 is even in my first test case.To pass that, I can jump to
number % 2 == 0
. Or, I can just returntrue
. Either way gets me to a passing test, but I prefer the latter because it enables me to write another failing test.Now I am forced to write a test for odd input, so I assert 3 is not even. This test fails, because it currently just returns
true
. Now I must implement a solution that handles even and odd inputs correctly; I know modulus is the answer, so I use it now. Now both tests pass.Then I think about other interesting cases: 0, negative ints, integer max/min, etc. I write tests for each of them, the modulus operator holds up. Great. Any refactoring to do? Nope. It’s a one-liner.
The whole process for this function would only add a few minutes of development, since the implementation is trivial. The test runtime should take milliseconds or less, and now there is documentation for the next developer that comes along. They can see what I considered (and what I didn’t), and how to use it.
Tests should make changing your system easier and safer, if they don’t it is typically a sign things are being tested at the wrong level. That’s outside the scope of this lemmy interaction.
Either way gets me to a passing test, but I prefer the latter because it enables me to write another failing test.
But you could just write that failing test up front. TDD encourages you to pretend to know less than you do (you know that testing evenness requires more than one test, and you know the implementation requires more than some if-statements), but no-one has ever made a convincing argument to me that you get anything out of this pretence.
Tests should make changing your system easier and safer, if they don’t it is typically a sign things are being tested at the wrong level
TDD is about writing (a lot of) unit tests, which are at a low-level. Because they are a low-level design-tool, they test the low-level design. Any non-trivial change affects the low-level design of a component, because changes tend to affect code at a certain level and most of those below it to some degree.
Unittest in Python, enjoy! If you pass it with a function like the one in OPs picture, you have earned it.
import unittest import random class TestOddEven(unittest.TestCase): def test_is_odd(self): for _ in range(100): num = random.randint(-2**63, 2**63 - 1) odd_num = num | 1 even_num = num >> 1 << 1 self.assertTrue(is_odd(odd_num)) self.assertFalse(is_odd(even_num)) def test_is_even(self): for _ in range(100): num = random.randint(-2**63, 2**63 - 1) odd_num = num | 1 even_num = num >> 1 << 1 self.assertTrue(is_even(even_num)) self.assertFalse(is_even(odd_num)) if __name__ == '__main__': unittest.main()
I don’t want unseeded randomness in my tests, ever.
Seed the tests, and making these pass would be trivial.
The right tool for the right job ¯\(ツ)/¯
The right tool here is tests at a level higher than machine code instructions that have been in CPUs since the 70s. Maybe TDD practice is not to test at this level, but every example of TDD sure tends to be something similar!