Yes, lots of these problems assume fantasy infinite world.
Big O notation also suffers from this - it's almost useless for real world problems.
Big O notation also suffers from this - it's almost useless for real world problems.
This is quite a bold claim. Yeah "in the real world" you often need to take into consideration the constant factors... but to go this far to say that Big O is useless? It's very useful to figure out what would likely work (or not) for your problem, given that you know the data size - I used it for exactly that, many many times.
Big O says how fast complexity grows, but it doesn't say what that complexity exactly is.
Does something like that happens in real world? Yes, but of course not in such drastic ways.
If you need to pull an example from fantasy world to illustrate your point about Big-O notation not being useful "in the real world" you're probably committing the same alleged mistakes as computational theorists...
You don't really know how this works, do you? I can guarantee that thera are more than 1M particles in the universe. And if you iterate 2^1M times, doing nothing, on a current computer... that's basically indistinguishable from an infinite loop.
I find it useful to characterise algorithmic performance, e.g. O(1), O(n) O(n^2), etc.
What do you find useless about it - and do you know of something that works better?
Small N right?
This mentality is how we ended up with cpu and memory hogging Electron apps...
For example, it is common in sorting algorithms to do an n² algorithm like bubble sort when the list to sort is small (e.g. <50), whereas when it's larger, we do an n log n algorithm like merge sort.
The issue is that merge sort does recursion, which comes with some extra cost, so that an n² algorithm beats an n log n algorithm, provided n is small.
It has nothing with your criticism to do.
For arrays smaller than the threshold, insertion is faster than bubble sort. And if you really don't want recursion for large arrays to begin with, you have heapsort or Shell sort.
I don't think there is any practical case where using bubble sort makes sense, except "efficiency doesn't matter for my use case and this is the code I already have".
a) isn’t really slow for what it does
b) introduces many layers of abstraction, leading to larger memory consumption compared to „native“ apps
c) is certainly not algorithmically unoptimized, it runs on a software stack that has been tuned like few others using billions of dollars
You just loosely associated words and concepts that occupy a similar emotional niche.
Much better - research (not always possible)
Best - benchmark it using realistic data from your use case
I feel like that is never the level of detail you want.
Either that is way too much detail and big-oh notation abstracts away the meaningless stuff.
Or, if this level of detail matters, then you really need to go much further. Think about cache hit ratios, memory layout issues, different speed of different operations, etc.
Calculating number of operations is a weird middle ground that seems pretty useless.
It's not the only way to optimize things but there's a reason no one sorts with bubble sort.
Complexity estimations or just benchmarks are much better at that.
You should never limit yourself to big O notation when comparing algorithms.
Sure, but it's still an incredibly useful tool for considering how your algo will scale.
In other news, there's a reason no BLAS implementation multiplies matrices with Strassen's algorithm, and it's not that the people writing those are too dumb.