Could be easily made 50% space saving by only iffin all odds and return even on else. Maybe one if before to handle overflow to avoid wrong even if over the last if.
The problem with if is the answer comes from user. There’s no mathematical reason or scientific explanation, only programmer who thinks the answer should include the subject.
But even on a more metaphorical level, every single thing that has or will happen in this universe, down to even the smallest quantum fluctuations could be encapsulated into IF statements as long as you had enough of them.
As a side note, the program is amazingly performant. For small numbers the results are instantaneous and for the large number close to the 2^32 limit the result is still returned in around 10 seconds.
For a long time I’ve been of the opinion that you should only ever optimize for the next sucker colleague who might need to read and edit your code. If you ever optimize for speed, it needs to be done with massive benchmarking / profiling support to ensure that the changes you make are worth it. This is especially true with modern compilers / interpreters that try to use clever techniques to optimize your code either on the fly, or before making the executable.
I do feel like it’s good, though, when libraries optimize. Ideally, they don’t have much else to do than one thing really well anyways.
And with how many libraries modern applications pull in, you do eventually notice whether you’re in the Python ecosystem, where most libraries don’t care, or in the Rust ecosystem, where many libraries definitely overdo it. Because well, they also kind of don’t overdo it, since as a user of the library, you don’t see any of it, except the culmulative performance benefits.
Libraries are also written and maintained by humans.
It’s fine to optimize if you can truly justify it, but that’s going to be even harder in libraries that are going to be used on multiple different architectures, etc.
I’m still mad he didn’t use the size of the number to tell the system which block to read first. I feel like that would be a great use for division or maybe modulus?
SQL is run on the server to communicate with a database. The screenshot is jsx, which is a front-end, UI templating language. Writing SQL this way is cursed
That, right there, is a perfect example of why folks need to stop trying to shoehorn web apps everywhere they don’t belong. It’s a use-case for a proper native mobile app if ever there was one.
That’s why you should’ve just handled arbitrary rotations instead of inventing a finite predefined set of orientation “modes” in the first place.
Things get a lot easier in the long run if you aggressively look for commonalities and genericize the code that handles them instead of writing bunches of one-off special cases.
No one does this kind of stuff because someone asked them to do it. This is the kind of useless, insane stuff you do for the lulz, or because someone dared you.
Rotating the display by a custom angle is possible through xrandr on X.org.
There’s no Wayland protocol for custom angle rotation, and I don’t expect anyone to create a protocol extension without a use-case.
My wild guess: Theoretically it should be possible for a compositor to support similar custom rotation, as applications simply draw to their surface (window), without knowing how and where it is displayed on the viewport (display).
But it might require quite a bit of work, depending on the project, so I don’t expect to ever see custom rotation on anything besides smaller/niche compositors.
There’s no Wayland protocol for custom angle rotation, and I don’t expect anyone to create a protocol extension without a use-case.
Puh-lease. It’s Wayland; the devs fully and honestly expect every app developer (eg.: calc, Libreoffice, notepad.exe) to implement custom angle rotation on their own.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.