←back to thread

108 points BerislavLopac | 2 comments | | HN request time: 0.574s | source
Show context
graycat ◴[] No.43714234[source]
Well, for a computer that is a finite state machine there are only finitely many states. So, in finite time the machine will either (a) halt or (b) return to an earlier state and, thus, be in an infinite loop. So, in this case can tell if the "program will stop" and, thus, solve "the halting problem".

Uh, we also assume that before we start, we can look at the design of "the machine" and know how many states there can be and from the speed of the machine how many new states are visited each second. So, we will know how long we have to wait before we see either (a) or (b).

replies(6): >>43714273 #>>43714285 #>>43714402 #>>43714513 #>>43714742 #>>43717019 #
Sankozi ◴[] No.43714285[source]
Yes, lots of these problems assume fantasy infinite world.

Big O notation also suffers from this - it's almost useless for real world problems.

replies(5): >>43714298 #>>43714309 #>>43714328 #>>43714554 #>>43718244 #
suddenlybananas ◴[] No.43714298[source]
>Big O notation also suffers from this - it's almost useless for real world problems.

It's not the only way to optimize things but there's a reason no one sorts with bubble sort.

replies(2): >>43714316 #>>43716864 #
1. Sankozi ◴[] No.43714316[source]
Yes bubble sort usually will take more time, but big O notation does not say that quick sort will be better for your real world problem.

Complexity estimations or just benchmarks are much better at that.

You should never limit yourself to big O notation when comparing algorithms.

replies(1): >>43714334 #
2. suddenlybananas ◴[] No.43714334[source]
>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.