this post was submitted on 22 Feb 2024
695 points (96.5% liked)
Programmer Humor
32174 readers
78 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Is this the same person who coded the odd/even function?
I have a better odd/even function:
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:
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:
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:
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.
Markup languages.
Which were done as such to allow people to write a sentence on each line in their editor, remember notepad etc. doesn't wrap lines so you've got to scroll all the way over to read your lines.
This became the de-facto way of formatting most things, and it's easier to do newlines like that than using a br tag (and html tags generally) which are cringe af
Note you can also do a smaller newline with two spaces at the end of the preceding line
Notepad has had View->Word Wrap for a long time if you want soft word wrap instead of having to use a hard one.
I didn't know you could add two spaces to get a single newline to work though. Is that part of html or the formatting for this site?
Formatting for pretty much any forum...
The place the question is coming from is that I've implemented forum commenting from scratch before and it was trivial to get newlines behaving the same way in the edit box and when they are displayed and I've never seen the benefit of leaving it the way it is other than the case where a user uses hard newlines for word wrap instead of the soft wrap built into pretty much every browser's edit box.
Yeah, in fact it's actually easier, but it's also just not desired behaviour.
If you want a wysiwyg editor, feel free to implement it as an alternative setting, or it may even already exist, but forums populated by nerds have markdown for a very long time because it works well, is faster and more convenient once you know what you're doing with it and above all else the nerds (frankly rightly) they get mad when you take it away, see how much hate Confluence gets for example.
I'm still mostly just confused as to what the use case is for that newline thing specifically. I get the idea behind a plaintext editor that can handle more complex text formatting (and get frustrated a lot with editors that try to guess what formatting I want as a type), but I don't get why anyone would champion "I want to be able to hit enter as I'm inputting text without that showing up in the final output". Is that just the way it behaves because that's how it behaved in the past and people are used to it or is there a use case (or set of use cases) where this behaviour is desirable?
Markup languages.
Which were done as such to allow people to write a sentence on each line in their editor, remember notepad etc. doesn't wrap lines so you've got to scroll all the way over to read your lines.
This became the de-facto way of formatting most things, and it's easier to do newlines like that than using a br tag (and html tags generally) which are cringe af
Note you can also do a smaller newline with two spaces at the end of the preceding line