Ah thank you, the editor in connect isn’t great and doesn’t have the markdown guide or buttons for the preformatted block, so I couldn’t find the character combo to use it (and never would have guessed that lol). Also it keeps giving an error when I edit, though the edit is going through.
The reply would have been return x % 2 == 0, or if you wanted it to be less readable return !(x&1).
But if you were going for a way that is subtly awful or expensive, just do a regex match on “[02468]$”. You don’t get a stack overflow with larger numbers but I struggle to think of a plausible bit of code that consumes more unnnecessary cycles than that…
The less readable one is faster, though I’d be surprised if the compiler doesn’t generate the same code for both of those options with optimizations enabled.
I like the regex one as another unnecessarily complicated way of doing it. It also involves a string conversion.
The way that was being hinted at before my reply was a large series of if statements: is it 2? 4? 6? 8? And so on. It’s plausible in that I could see a beginner programmer using that method. And honestly, knowing how people can get pigeon holed into looking at a problem from some weird angle but still having the determination to figure it out, most solutions are plausible. Often when they get pointed in a better direction, it’s not so much a case of them learning something new as it is a facepalm kinda moment where they feel embarrassed at not seeing that. I’ve done it myself many times lol.
It’s always funny seeing someone use the wrong tool for the job but still getting the job done, even when it’s me.
Godbolt to the rescue! So gcc 13.2 certainly does produce the same code, though a lot of other versions and compilers do it slightly differently. Surprisingly, clang doesn’t optimise this and uses idiv for the modulo version.
Awesome, thank you for that link. I should have guessed this was a thing but it hadn’t even occurred to me.
And yeah, it is surprising that clang doesn’t treat mod power of 2 as a special case. It looks like I can’t type in code on mobile, does clang handle divide by power of 2 as a idiv or shift?
For large numbers, you might get a stack overflow. Depends on whether the compiler recognizes that it’s a tail recursion and then handles it appropriately.
As for why Lemmy ignores single newlines, that’s because it uses Markdown for its comment syntax, which happens to handle newlines that way. If you want a single newline to display, you have to add two spaces at the end of the line.
Here, you really would have wanted to use a code block, though, which you can create with backticks
```
like
so.
```
Normally, this would display “like so.” in a monospace font and handle newlines as you expected:
Just need to add some code that saves the base stack pointer, detects when the stack is about to run out, then saves the current number, resets the stack to the original pointer but now with the current number as x and continues on to fix the stack overflow issue. You don’t even have to restore the stack when it’s all unwinding!
The integer overflow issue would be more complicated to solve except it isn’t really an issue because chopping off the upper bits doesn’t affect the eveness of a value.
Oh and I thought of a quick way to verify the result of the algorithm. It should give the same result as this expression that you can use in your test suite:
!(x & 1)
Edit: um, new formatting problem… And that amp shows up in the edit box so it might even keep expanding.
Is this the same person who coded the odd/even function?
I have a better odd/even function:
bool isEven( long long x ) { if ( x < 0 ) x = -x; if ( x == 1 ) return false; if ( x == 2 ) return true; return isEven( x - 2 ); }This will work for both negative numbers and arbitrarily large integers. I’ve tested it up to 26 but I’m pretty sure it will work up to infinity.
Though serious question: Why are these forums coded in such a way that they ignore single newlines? How hard is it to replace a newline with a br tag?
Edit: added two spaces, should look much better.
Edit2: just looks a bit better lol
Edit3: better now?
It’s Markdown syntax. You can actually format it nicely in a code block:
bool isEven( long long x ) { if ( x < 0 ) x = -x; if ( x == 1 ) return false; if ( x == 2 ) return true; return isEven( x - 2 ); }You do that by adding ``` above and below it. To force single line breaks, you can terminate your sentences with two spaces, or a backslash.
Ah thank you, the editor in connect isn’t great and doesn’t have the markdown guide or buttons for the preformatted block, so I couldn’t find the character combo to use it (and never would have guessed that lol). Also it keeps giving an error when I edit, though the edit is going through.
Can you put this in a npm package so I can use it in my project, please?
Just copy paste it into each source file, I give you permission to reuse the code.
Is this meant to be a joke or is it intended to be a serious solution?
Asking for someone who lacks a sense of humor.
Ok, fine, I’m asking for me. That person is me.
I want to see how you’d reply if I said it was serious. So let’s go with that. This is the best way to determine if a number is even in c/c++.
The reply would have been
return x % 2 == 0, or if you wanted it to be less readablereturn !(x&1).But if you were going for a way that is subtly awful or expensive, just do a regex match on “[02468]$”. You don’t get a stack overflow with larger numbers but I struggle to think of a plausible bit of code that consumes more unnnecessary cycles than that…
The less readable one is faster, though I’d be surprised if the compiler doesn’t generate the same code for both of those options with optimizations enabled.
I like the regex one as another unnecessarily complicated way of doing it. It also involves a string conversion.
The way that was being hinted at before my reply was a large series of if statements: is it 2? 4? 6? 8? And so on. It’s plausible in that I could see a beginner programmer using that method. And honestly, knowing how people can get pigeon holed into looking at a problem from some weird angle but still having the determination to figure it out, most solutions are plausible. Often when they get pointed in a better direction, it’s not so much a case of them learning something new as it is a facepalm kinda moment where they feel embarrassed at not seeing that. I’ve done it myself many times lol.
It’s always funny seeing someone use the wrong tool for the job but still getting the job done, even when it’s me.
Godbolt to the rescue! So gcc 13.2 certainly does produce the same code, though a lot of other versions and compilers do it slightly differently. Surprisingly, clang doesn’t optimise this and uses
idivfor the modulo version.Awesome, thank you for that link. I should have guessed this was a thing but it hadn’t even occurred to me.
And yeah, it is surprising that clang doesn’t treat mod power of 2 as a special case. It looks like I can’t type in code on mobile, does clang handle divide by power of 2 as a idiv or shift?
I love the use of recursion. Slick.
For large numbers, you might get a stack overflow. Depends on whether the compiler recognizes that it’s a tail recursion and then handles it appropriately.
As for why Lemmy ignores single newlines, that’s because it uses Markdown for its comment syntax, which happens to handle newlines that way. If you want a single newline to display, you have to add two spaces at the end of the line.
Here, you really would have wanted to use a code block, though, which you can create with backticks
```
like
so.
```
Normally, this would display “like so.” in a monospace font and handle newlines as you expected:
like so.Just need to add some code that saves the base stack pointer, detects when the stack is about to run out, then saves the current number, resets the stack to the original pointer but now with the current number as x and continues on to fix the stack overflow issue. You don’t even have to restore the stack when it’s all unwinding!
The integer overflow issue would be more complicated to solve except it isn’t really an issue because chopping off the upper bits doesn’t affect the eveness of a value.
Oh and I thought of a quick way to verify the result of the algorithm. It should give the same result as this expression that you can use in your test suite:
!(x & 1)Edit: um, new formatting problem… And that amp shows up in the edit box so it might even keep expanding.
The ampersand thing is a known bug in Lemmy. It has to do with input sanitation, as I understand.
Yeah looks like it’s sanitizing both on submit and when displaying.
Some quirk of this version of Markdown I think.
Try putting two spaces at the end of a line before your single newline.