>This is just flatly false. Of course blindly executing the code is one thing a literal computer can do when faced with it, but there are others
I am talking about a programmable computer. And I said the program is meant to be executed. It does NOT lead to an endless loop, as it can be halted or left or transcended uncomputationally. That is the whole point of the argument. The brand new internal computer system you use to execute it can be halted uncomputationally.
That is really an important information, otherwise this is rather confusing right there, it might get someone rather confused if you miss that crucial point.
If you ignore the instruction that the program is to be executed the demonstration does not work, and the whole reasoning around it does not work either, as it is in the context of that instruction.
>The OP promised, in so many words, “a clearly structured argument”, but it does not contain a clearly structured argument.
This is unfortunately 100% true. The commentary I hope is somewhat clearly structured (hence bolding etc), but the post itself is not an argument. It is meant as a demonstration.
Meaning it is meant to demonstrate something that is already the case. It is meant to be valid and true, not to be “convincing”. There is not need to convince anyone of this, and attempting to do so will just lead to tie my head up in knots and possibly others too😅.
I edited my post appropriately, my bad. Thank a lot for pointing it out!
Again just for clarity you can execute and halt the following loop by reading it:
START: START COMMENT This kind of loop cannot be left computationally-deterministically but it can be left or halted deterministically-uncomputably or chaotically-randomly². END COMMENT GOTO START
Maybe that is a much better demonstration? As it leaves the whole meta and trans-computational stuff aside.
²which is not computationally either (not talking about classical chaos or pseudo-randomness here, as that can be computed in principle—although not in practice, but uncomputational chaos, whether deterministic or stochstically-deterministically, meaning with a quantifiable probability or in an i n d e t e r m i n s t i c way that is not stochastically quantifiable)
I think the difference between computational loop and uncomputational loop can be explained by a computational loop being at the very least a loop between two states. An uncomputational loop is just a loop going around and back to a single state.
As for a program you need at least two states (For example S start and E end).
The mere state “loop” is not a program, it is just a loop. O
♾
An instruction can be open ended: S start. That is not a computer program. It cannot be computed, as it is open-ended. You cannot tell a computer just start, and do nothing else. That is just a start of some kind, not a computer program, haha. Maybe in this case the start into a new future of clear reasoning about uncomputability, who knows?
It seems to me in many ways illustrations would be more useful for this than words. As in a certain way, it seems the structure becomes more clear by way of illustration than verbal elucidation. So again, also thanks for giving me some reason that maybe the structure can be made clearer!
I feel I am a bit too serious about this. I used to think computers will solve a lot of my problems too and even perhaps digitally revive me after I am dead😅. They do solve MANY problems, but not as many as I thought.
I think this past belief still haunts me a bit, so that I take this whole thing more heavily than it needs to be. Computers work great. My brain works, at least somewhat okayishly, enough to write this to you. Heavy is heavy illness or heavy conflict. Not really this kind of question or conversation🙏.
I believe that insight will at some point gain more popularity in AI culture, as it just becomes clear that computers do not fulfill all of our expectations, and that there are some false assumptions about what the brain and the mind are going around (Penrose addresses those things quite well lately, as he now tends to leave aside the OR stuff more that seems a bit questionable).
You say that the program is meant to be executed. But then you say it is meant to be “halted or left or transcended”. If you do those things then you are not executing the program any more. You might be doing something _better_ than executing it, but in any case you are doing something _different_.
It seems like you are saying (1) that a human being can execute the program but then halt/leave/transcend it, and (2) that a computer cannot. But this is only true if you (1) allow “execute” to be used in a metaphorical sense when talking about what the human being does but (2) don’t allow it to be so used when talking about what the computer does.
It is perfectly possible for a computer to “execute” code in a way that allows it to stop when (for instance) it notices certain kinds of lack of progress. I gave a simple example elsewhere in this thread. So it isn’t at all true that humans can execute code while retaining some ability to stop doing so but computers can’t; computers can do that too.
Computers can’t (at present) execute code while understanding what English-language comments in the code say and acting accordingly because computers don’t yet understand English very well. It could turn out that this is because for some reason understanding human language is impossible for merely-computational systems, but I see no reason to think so and you haven’t offered any.
Of course if you take your code, turn it into an executable program, and make that the program the computer is executing then it will loop for ever. A human being won’t do that because you don’t have any way to make a program the program the human is executing. (Fortunately, perhaps.) This isn’t a difference between what humans can do and what computers can do, it’s a difference between how you use the term “execute” when talking about humans and when talking about computers.
Your “much better demonstration” still does not demonstrate anything, at least not in the sense of conveying anything useful to my mind.
I am not sure exactly what you mean by “state”, but a machine-language program consisting of a single instruction saying “branch to the same address this instruction is at” doesn’t loop “between two states” in any useful sense. When executing this loop, the computer’s program counter always has the same value, all its registers keep the same value, and the contents of memory do not change.
>This is just flatly false. Of course blindly executing the code is one thing a literal computer can do when faced with it, but there are others
I am talking about a programmable computer. And I said the program is meant to be executed. It does NOT lead to an endless loop, as it can be halted or left or transcended uncomputationally. That is the whole point of the argument. The brand new internal computer system you use to execute it can be halted uncomputationally.
That is really an important information, otherwise this is rather confusing right there, it might get someone rather confused if you miss that crucial point.
If you ignore the instruction that the program is to be executed the demonstration does not work, and the whole reasoning around it does not work either, as it is in the context of that instruction.
>The OP promised, in so many words, “a clearly structured argument”, but it does not contain a clearly structured argument.
This is unfortunately 100% true. The commentary I hope is somewhat clearly structured (hence bolding etc), but the post itself is not an argument. It is meant as a demonstration.
Meaning it is meant to demonstrate something that is already the case. It is meant to be valid and true, not to be “convincing”. There is not need to convince anyone of this, and attempting to do so will just lead to tie my head up in knots and possibly others too😅.
I edited my post appropriately, my bad. Thank a lot for pointing it out!
Again just for clarity you can execute and halt the following loop by reading it:
START: START COMMENT This kind of loop cannot be left computationally-deterministically but it can be left or halted deterministically-uncomputably or chaotically-randomly². END COMMENT GOTO START
Maybe that is a much better demonstration? As it leaves the whole meta and trans-computational stuff aside.
²which is not computationally either (not talking about classical chaos or pseudo-randomness here, as that can be computed in principle—although not in practice, but uncomputational chaos, whether deterministic or stochstically-deterministically, meaning with a quantifiable probability or in an i n d e t e r m i n s t i c way that is not stochastically quantifiable)
I think the difference between computational loop and uncomputational loop can be explained by a computational loop being at the very least a loop between two states. An uncomputational loop is just a loop going around and back to a single state.
As for a program you need at least two states (For example S start and E end).
The mere state “loop” is not a program, it is just a loop. O
♾
An instruction can be open ended: S start. That is not a computer program. It cannot be computed, as it is open-ended. You cannot tell a computer just start, and do nothing else. That is just a start of some kind, not a computer program, haha. Maybe in this case the start into a new future of clear reasoning about uncomputability, who knows?
It seems to me in many ways illustrations would be more useful for this than words. As in a certain way, it seems the structure becomes more clear by way of illustration than verbal elucidation. So again, also thanks for giving me some reason that maybe the structure can be made clearer!
I feel I am a bit too serious about this. I used to think computers will solve a lot of my problems too and even perhaps digitally revive me after I am dead😅. They do solve MANY problems, but not as many as I thought.
I think this past belief still haunts me a bit, so that I take this whole thing more heavily than it needs to be. Computers work great. My brain works, at least somewhat okayishly, enough to write this to you. Heavy is heavy illness or heavy conflict. Not really this kind of question or conversation🙏.
I believe that insight will at some point gain more popularity in AI culture, as it just becomes clear that computers do not fulfill all of our expectations, and that there are some false assumptions about what the brain and the mind are going around (Penrose addresses those things quite well lately, as he now tends to leave aside the OR stuff more that seems a bit questionable).
You say that the program is meant to be executed. But then you say it is meant to be “halted or left or transcended”. If you do those things then you are not executing the program any more. You might be doing something _better_ than executing it, but in any case you are doing something _different_.
It seems like you are saying (1) that a human being can execute the program but then halt/leave/transcend it, and (2) that a computer cannot. But this is only true if you (1) allow “execute” to be used in a metaphorical sense when talking about what the human being does but (2) don’t allow it to be so used when talking about what the computer does.
It is perfectly possible for a computer to “execute” code in a way that allows it to stop when (for instance) it notices certain kinds of lack of progress. I gave a simple example elsewhere in this thread. So it isn’t at all true that humans can execute code while retaining some ability to stop doing so but computers can’t; computers can do that too.
Computers can’t (at present) execute code while understanding what English-language comments in the code say and acting accordingly because computers don’t yet understand English very well. It could turn out that this is because for some reason understanding human language is impossible for merely-computational systems, but I see no reason to think so and you haven’t offered any.
Of course if you take your code, turn it into an executable program, and make that the program the computer is executing then it will loop for ever. A human being won’t do that because you don’t have any way to make a program the program the human is executing. (Fortunately, perhaps.) This isn’t a difference between what humans can do and what computers can do, it’s a difference between how you use the term “execute” when talking about humans and when talking about computers.
Your “much better demonstration” still does not demonstrate anything, at least not in the sense of conveying anything useful to my mind.
I am not sure exactly what you mean by “state”, but a machine-language program consisting of a single instruction saying “branch to the same address this instruction is at” doesn’t loop “between two states” in any useful sense. When executing this loop, the computer’s program counter always has the same value, all its registers keep the same value, and the contents of memory do not change.