←back to thread

108 points BerislavLopac | 1 comments | | HN request time: 0.301s | 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 #
MattPalmer1086 ◴[] No.43714328[source]
You find Big O notation useless for real world problems?

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?

replies(2): >>43714361 #>>43714455 #
Sankozi ◴[] No.43714455[source]
Better - estimate complexity so things like "this algorithm will take 1234 + 2n + 500m operations " for our use case

Much better - research (not always possible)

Best - benchmark it using realistic data from your use case

replies(1): >>43714551 #
1. bawolff ◴[] No.43714551[source]
> Better - estimate complexity so things like "this algorithm will take 1234 + 2n + 500m operations " for our 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.