| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 48:47:47 |
| Calls: | 632 |
| Files: | 1,187 |
| D/L today: |
3 files (4,227K bytes) |
| Messages: | 177,138 |
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do you think
my answer will change if you keep asking it? Please get to the point.
I am not going to ever talk about DD() with you again until
after you totally understand my view of the Linz proof.
Dialogues are a two way street. I respond to your comments and expect
you to respond to mine.
Andr|-
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior >>> as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do you think
my answer will change if you keep asking it? Please get to the point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?
On 2025-10-07 13:38, olcott wrote:
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior >>>> as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >>>> aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do you
think my answer will change if you keep asking it? Please get to the
point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?
No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1]
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1]
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior >>>>> as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >>>>> aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do you
think my answer will change if you keep asking it? Please get to the
point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ? >>
You already agreed to a different wording of that.
On 2025-10-07 14:23, olcott wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1]
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >>>>>> aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do you
think my answer will change if you keep asking it? Please get to
the point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ? >>>
You already agreed to a different wording of that.
No. I did not. I may have agreed to something that you *think* is simply
a different wording of that, but whatever it was that I agreed to was
not something by which I meant "simulated rf?-nrf- rf?-nrf- would never stop running unless aborted", because that is simply false.
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
On 10/7/2025 3:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:23, olcott wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:You already agreed to a different wording of that.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >>>>>>> aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do you
think my answer will change if you keep asking it? Please get to
the point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?
No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1] >>>
No. I did not. I may have agreed to something that you *think* is
simply a different wording of that, but whatever it was that I agreed
to was not something by which I meant "simulated rf?-nrf- rf?-nrf- would never
stop running unless aborted", because that is simply false.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
So the input rf?-nrf- rf?-nrf- to embedded_H would
---
"have the same behavior as -n applied to rf?-nrf- when embedded_H is a UTM" *is equivalent to*
"never stop running"
---
if embedded_H never aborted its simulation?
---
So the input rf?-nrf- rf?-nrf- to embedded_H would
"never stop running"
if embedded_H never aborted its simulation?
---
*is equivalent to*
"simulated rf?-nrf- rf?-nrf- would never stop running unless aborted"
On 10/7/2025 3:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:23, olcott wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior asYes.
-n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >>>>>>> aborted its simulation?
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1]
So the input rf?-nrf- rf?-nrf- to embedded_H would ---
"have the same behavior as -n applied to rf?-nrf- when embedded_H is a UTM" *is equivalent to*
"never stop running"
---
if embedded_H never aborted its simulation?
---
So the input rf?-nrf- rf?-nrf- to embedded_H would "never stop running"
if embedded_H never aborted its simulation?
---
*is equivalent to*
"simulated rf?-nrf- rf?-nrf- would never stop running unless aborted"
On 2025-10-07 14:59, olcott wrote:
On 10/7/2025 3:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:23, olcott wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:You already agreed to a different wording of that.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >>>>>>>> aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do you >>>>>>> think my answer will change if you keep asking it? Please get to >>>>>>> the point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?
No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1] >>>>
No. I did not. I may have agreed to something that you *think* is
simply a different wording of that, but whatever it was that I agreed
to was not something by which I meant "simulated rf?-nrf- rf?-nrf- would never
stop running unless aborted", because that is simply false.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >> -a>> aborted its simulation?
Yes.
Yes, I agreed to that. That does *not* mean that simulated rf?-nrf- rf?-nrf- would
never stop running unless aborted.
So the input rf?-nrf- rf?-nrf- to embedded_H would
---
"have the same behavior as -n applied to rf?-nrf- when embedded_H is a UTM" >> *is equivalent to*
"never stop running"
No. It isn't. a UTM will never stop running only if its input is a non- halting computation. rf?-nrf- rf?-nrf- is a halting computation.
Am Tue, 07 Oct 2025 15:59:51 -0500 schrieb olcott:<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 10/7/2025 3:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:23, olcott wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior asYes.
-n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >>>>>>>> aborted its simulation?
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1]
So the input rf?-nrf- rf?-nrf- to embedded_H would ---
"have the same behavior as -n applied to rf?-nrf- when embedded_H is a UTM" >> *is equivalent to*
"never stop running"
---
if embedded_H never aborted its simulation?
---
So the input rf?-nrf- rf?-nrf- to embedded_H would "never stop running"
if embedded_H never aborted its simulation?
---
*is equivalent to*
"simulated rf?-nrf- rf?-nrf- would never stop running unless aborted"
rCaif embedded_H never aborted its simulation.
On 10/7/2025 4:11 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:59, olcott wrote:
On 10/7/2025 3:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:23, olcott wrote:On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:You already agreed to a different wording of that.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do you >>>>>>>> think my answer will change if you keep asking it? Please get to >>>>>>>> the point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?
No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1] >>>>>
No. I did not. I may have agreed to something that you *think* is
simply a different wording of that, but whatever it was that I
agreed to was not something by which I meant "simulated rf?-nrf- rf?-nrf- >>>> would never stop running unless aborted", because that is simply false. >>>
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >>> -a>> aborted its simulation?
Yes.
Yes, I agreed to that. That does *not* mean that simulated rf?-nrf- rf?-nrf-
would never stop running unless aborted.
So the input rf?-nrf- rf?-nrf- to embedded_H would
---
"have the same behavior as -n applied to rf?-nrf- when embedded_H is a UTM" >>> *is equivalent to*
"never stop running"
No. It isn't. a UTM will never stop running only if its input is a
non- halting computation. rf?-nrf- rf?-nrf- is a halting computation.
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.reR, // accept state -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn // reject state
So you forgot the details of what you agreed to
On 2025-10-07 15:17, olcott wrote:
On 10/7/2025 4:11 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:59, olcott wrote:
On 10/7/2025 3:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:23, olcott wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:You already agreed to a different wording of that.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do >>>>>>>>> you think my answer will change if you keep asking it? Please >>>>>>>>> get to the point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?
No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1] >>>>>>
No. I did not. I may have agreed to something that you *think* is
simply a different wording of that, but whatever it was that I
agreed to was not something by which I meant "simulated rf?-nrf- rf?-nrf-
would never stop running unless aborted", because that is simply
false.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
Yes, I agreed to that. That does *not* mean that simulated rf?-nrf- rf?-nrf-
would never stop running unless aborted.
So the input rf?-nrf- rf?-nrf- to embedded_H would
---
"have the same behavior as -n applied to rf?-nrf- when embedded_H is a UTM"
*is equivalent to*
"never stop running"
No. It isn't. a UTM will never stop running only if its input is a
non- halting computation. rf?-nrf- rf?-nrf- is a halting computation.
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn // reject state
This is a non-sequitur. It has nothing to do with the post to which you
are responding.
So you forgot the details of what you agreed to
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
On 10/7/2025 4:39 PM, Andr|- G. Isaak wrote:
On 2025-10-07 15:17, olcott wrote:
On 10/7/2025 4:11 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:59, olcott wrote:
On 10/7/2025 3:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:23, olcott wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do >>>>>>>>>> you think my answer will change if you keep asking it? Please >>>>>>>>>> get to the point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?
No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1]
You already agreed to a different wording of that.
No. I did not. I may have agreed to something that you *think* is >>>>>> simply a different wording of that, but whatever it was that I
agreed to was not something by which I meant "simulated rf?-nrf- rf?-nrf-
would never stop running unless aborted", because that is simply
false.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
Yes, I agreed to that. That does *not* mean that simulated rf?-nrf- rf?-nrf-
would never stop running unless aborted.
So the input rf?-nrf- rf?-nrf- to embedded_H would
---
"have the same behavior as -n applied to rf?-nrf- when embedded_H is a UTM"
*is equivalent to*
"never stop running"
No. It isn't. a UTM will never stop running only if its input is a
non- halting computation. rf?-nrf- rf?-nrf- is a halting computation.
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.reR, // accept state >>> -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn // reject state
This is a non-sequitur. It has nothing to do with the post to which
you are responding.
So you forgot the details of what you agreed to
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
*Referring to this*
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.reR, // accept state -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn // reject state
On 2025-10-07 15:47, olcott wrote:
On 10/7/2025 4:39 PM, Andr|- G. Isaak wrote:
On 2025-10-07 15:17, olcott wrote:
On 10/7/2025 4:11 PM, Andr|- G. Isaak wrote:This is a non-sequitur. It has nothing to do with the post to which
On 2025-10-07 14:59, olcott wrote:
On 10/7/2025 3:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:23, olcott wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H >>>>>>>>>>>> never
aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do >>>>>>>>>>> you think my answer will change if you keep asking it? Please >>>>>>>>>>> get to the point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?
No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1]
You already agreed to a different wording of that.
No. I did not. I may have agreed to something that you *think* is >>>>>>> simply a different wording of that, but whatever it was that I
agreed to was not something by which I meant "simulated rf?-nrf- rf?-nrf-
would never stop running unless aborted", because that is simply >>>>>>> false.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
Yes, I agreed to that. That does *not* mean that simulated rf?-nrf- rf?-nrf-
would never stop running unless aborted.
So the input rf?-nrf- rf?-nrf- to embedded_H would
---
"have the same behavior as -n applied to rf?-nrf- when embedded_H is a UTM"
*is equivalent to*
"never stop running"
No. It isn't. a UTM will never stop running only if its input is a
non- halting computation. rf?-nrf- rf?-nrf- is a halting computation. >>>>>
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.reR, // accept state >>>> -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn // reject state >>>
you are responding.
So you forgot the details of what you agreed to
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >> -a>> aborted its simulation?
Yes.
*Referring to this*
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn // reject state
What your giving above is your formalism (such as it is) for what I
referred to as -n_NoAbort. But the -n.UTM in that description is not
taking <-n_NoAbort> as its input; It's taking <-n> as its input. And, as I pointed out -n <-n> is a halting computation.
You're trying to argue that
<-n> <-n> would need to be aborted based on the fact that <-n_NoAbort>
<-n_NoAbort> would need to be aborted, but -n and -n_NoAbort are completely different computations.
Andr|-
On 10/7/2025 5:22 PM, Andr|- G. Isaak wrote:
On 2025-10-07 15:47, olcott wrote:
On 10/7/2025 4:39 PM, Andr|- G. Isaak wrote:
On 2025-10-07 15:17, olcott wrote:
On 10/7/2025 4:11 PM, Andr|- G. Isaak wrote:This is a non-sequitur. It has nothing to do with the post to which
On 2025-10-07 14:59, olcott wrote:
On 10/7/2025 3:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:23, olcott wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same >>>>>>>>>>>>> behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H >>>>>>>>>>>>> never
aborted its simulation?
Yes.
This question has been asked and answered multiple times. Do >>>>>>>>>>>> you think my answer will change if you keep asking it? >>>>>>>>>>>> Please get to the point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless aborted ?
No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1]
You already agreed to a different wording of that.
No. I did not. I may have agreed to something that you *think* >>>>>>>> is simply a different wording of that, but whatever it was that >>>>>>>> I agreed to was not something by which I meant "simulated rf?-nrf- >>>>>>>> rf?-nrf- would never stop running unless aborted", because that is >>>>>>>> simply false.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
Yes, I agreed to that. That does *not* mean that simulated rf?-nrf- rf?-nrf-
would never stop running unless aborted.
So the input rf?-nrf- rf?-nrf- to embedded_H would
---
"have the same behavior as -n applied to rf?-nrf- when embedded_H is a >>>>>>> UTM"
*is equivalent to*
"never stop running"
No. It isn't. a UTM will never stop running only if its input is a >>>>>> non- halting computation. rf?-nrf- rf?-nrf- is a halting computation. >>>>>>
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.reR, // accept state >>>>> -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn // reject state >>>>
you are responding.
So you forgot the details of what you agreed to
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never >>> -a>> aborted its simulation?
Yes.
*Referring to this*
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.reR, // accept state >>> -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn // reject state
What your giving above is your formalism (such as it is) for what I
referred to as -n_NoAbort. But the -n.UTM in that description is not
taking <-n_NoAbort> as its input; It's taking <-n> as its input. And, as
I pointed out -n <-n> is a halting computation.
So you don't understand that you already agreed that the
above does not halt.
On 2025-10-07 16:25, olcott wrote:
On 10/7/2025 5:22 PM, Andr|- G. Isaak wrote:
On 2025-10-07 15:47, olcott wrote:
On 10/7/2025 4:39 PM, Andr|- G. Isaak wrote:What your giving above is your formalism (such as it is) for what I
On 2025-10-07 15:17, olcott wrote:
On 10/7/2025 4:11 PM, Andr|- G. Isaak wrote:This is a non-sequitur. It has nothing to do with the post to which >>>>> you are responding.
On 2025-10-07 14:59, olcott wrote:
On 10/7/2025 3:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 14:23, olcott wrote:
On 10/7/2025 3:20 PM, Andr|- G. Isaak wrote:
On 2025-10-07 13:38, olcott wrote:
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same
behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H
never
aborted its simulation?
Yes.
This question has been asked and answered multiple times. >>>>>>>>>>>>> Do you think my answer will change if you keep asking it? >>>>>>>>>>>>> Please get to the point.
Thus simulated rf?-nrf- rf?-nrf- would never stop running unless >>>>>>>>>>>> aborted ?
No. That does not follow. rf?-nrf- rf?-nrf- is a halting computation[1]
You already agreed to a different wording of that.
No. I did not. I may have agreed to something that you *think* >>>>>>>>> is simply a different wording of that, but whatever it was that >>>>>>>>> I agreed to was not something by which I meant "simulated rf?-nrf- >>>>>>>>> rf?-nrf- would never stop running unless aborted", because that is >>>>>>>>> simply false.
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H >>>>>>>> never
aborted its simulation?
Yes.
Yes, I agreed to that. That does *not* mean that simulated rf?-nrf- >>>>>>> rf?-nrf- would never stop running unless aborted.
So the input rf?-nrf- rf?-nrf- to embedded_H would
---
"have the same behavior as -n applied to rf?-nrf- when embedded_H is a
UTM"
*is equivalent to*
"never stop running"
No. It isn't. a UTM will never stop running only if its input is >>>>>>> a non- halting computation. rf?-nrf- rf?-nrf- is a halting computation. >>>>>>>
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn // reject state >>>>>
So you forgot the details of what you agreed to
On 10/7/2025 2:03 PM, Andr|- G. Isaak wrote:
On 2025-10-06 21:15, olcott wrote:
So the input rf?-nrf- rf?-nrf- to embedded_H would have the same behavior
as -n applied to rf?-nrf- when embedded_H is a UTM if embedded_H never
aborted its simulation?
Yes.
*Referring to this*
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.reR, // accept state >>>> -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn // reject state >>>
referred to as -n_NoAbort. But the -n.UTM in that description is not
taking <-n_NoAbort> as its input; It's taking <-n> as its input. And,
as I pointed out -n <-n> is a halting computation.
So you don't understand that you already agreed that the
above does not halt.
You're not paying attention.
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt.
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt.
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
When the middle state is a UTM, then because UTMs
never abort the above entire machine never aborts.
This means that when this same machine -n takes its
own machine description rf?-nrf- as its input that this
input will be copied and be input to -n.UTM rf?-nrf- rf?-nrf-. >
Here is the whole Linz proof, its only 3.5 pages long. https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
On 2025-10-07 16:53, olcott wrote:
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt.
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that it is possible to vary parameters independently of one another.
When you
contemplate an -n in which embedded_H cannot abort, you are no longer talking about -n, you are talking about something else, which I have referred to as -n_NoAbort.
-n(-n)
-n(-n_NoAbort)
-n_NoAbort(-n)
-n_NoAbort(-n_NoAbort)
are four distinct computations.
You can consider the halting status of
each of them independently of the other. -n(-n) halts, pure and simple.
When the middle state is a UTM, then because UTMs
never abort the above entire machine never aborts.
This means that when this same machine -n takes its
own machine description rf?-nrf- as its input that this
input will be copied and be input to -n.UTM rf?-nrf- rf?-nrf-. >
Here is the whole Linz proof, its only 3.5 pages long.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
You're well aware of the fact that I've read the Linz proof.
Everyone involved in this debate has.
It's rather insulting to have you
continuously post links to it.
Andr|-
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt.
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that it is
possible to vary parameters independently of one another.
I am only talking about a single proof with two variations
that always has its own machine description as its input.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
(a) -n.embedded_H is an ordinary UTM
(b) -n.embedded_H simulates its input yet never aborts
When you contemplate an -n in which embedded_H cannot abort, you are no
longer talking about -n, you are talking about something else, which I
have referred to as -n_NoAbort.
Each machine always takes its own machine description
as its input.
-n rf?-nrf--a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // Original Linz -n
-n_UTM rf?-n_UTMrf--a-a-a-a-a-a-a-a-a // can't possibly abort
-n_NoAbort rf?-n_NoAbortrf--a // never aborts on this input
-n(-n)
-n(-n_NoAbort)
-n_NoAbort(-n)
-n_NoAbort(-n_NoAbort)
are four distinct computations.
Wrong list
You can consider the halting status of each of them independently of
the other. -n(-n) halts, pure and simple.
It going to take a bunch more steps before we
get to that. You keep agreeing and retracting
and agreeing and retracting.
When the middle state is a UTM, then because UTMs
never abort the above entire machine never aborts.
This means that when this same machine -n takes its
own machine description rf?-nrf- as its input that this
input will be copied and be input to -n.UTM rf?-nrf- rf?-nrf-. >
Here is the whole Linz proof, its only 3.5 pages long.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
You're well aware of the fact that I've read the Linz proof.
-aEveryone involved in this debate has.
No one has ever acknowledged that the ever read the proof
besides Ben.
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt. >>>>>
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that it is
possible to vary parameters independently of one another.
I am only talking about a single proof with two variations
that always has its own machine description as its input.
You can't declare that a particular machine always has its own machine description as its input.
In the proof, Linz gives it its own machine
description, but it can also be given any input you want and logic
requires you to consider some of those other possibilities.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
(a) -n.embedded_H is an ordinary UTM
(b) -n.embedded_H simulates its input yet never aborts
When you contemplate an -n in which embedded_H cannot abort, you are
no longer talking about -n, you are talking about something else,
which I have referred to as -n_NoAbort.
Each machine always takes its own machine description
as its input.
-n rf?-nrf--a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // Original Linz -n
-n_UTM rf?-n_UTMrf--a-a-a-a-a-a-a-a-a // can't possibly abort
-n_NoAbort rf?-n_NoAbortrf--a // never aborts on this input
-n(-n)
-n(-n_NoAbort)
-n_NoAbort(-n)
-n_NoAbort(-n_NoAbort)
are four distinct computations.
Wrong list
No. It's the right list.
The problem you have is that whenever you
contemplate an embedded-n which does not abort (meaning you are then contemplating embedded-n_NoAbort inside -n_NoAbort) you only consider the halting status of the last of these four options, but that option isn't
the relevant one.
You can consider the halting status of each of them independently of
the other. -n(-n) halts, pure and simple.
It going to take a bunch more steps before we
get to that. You keep agreeing and retracting
and agreeing and retracting.
I have never retracted (except on one occasion where I misread your
post). You have misconstrued what I have said and then *claimed* I
retracted when in actuality I was saying the same thing all along.
And its going to take an infinite number of steps if you refuse to
advance until I've agreed to things which I consider to be false, since
I'm never going to agree to those. Which is why your instance of not
moving forward is entirely pointless.
When the middle state is a UTM, then because UTMs
never abort the above entire machine never aborts.
This means that when this same machine -n takes its
own machine description rf?-nrf- as its input that this
input will be copied and be input to -n.UTM rf?-nrf- rf?-nrf-. >
Here is the whole Linz proof, its only 3.5 pages long.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
You're well aware of the fact that I've read the Linz proof.
-aEveryone involved in this debate has.
No one has ever acknowledged that the ever read the proof
besides Ben.
People don't normally come out and say "I've read such and such". But
it's rather obvious from other people's posts that they have read it
since they have referred to details of the actual Linz proof rather than your sloppy paraphrasing of it.
Andr|-
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt. >>>>>>
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that it is
possible to vary parameters independently of one another.
I am only talking about a single proof with two variations
that always has its own machine description as its input.
You can't declare that a particular machine always has its own machine
description as its input.
It is the only relevant instance.
-aIn the proof, Linz gives it its own machine description, but it can
also be given any input you want and logic requires you to consider
some of those other possibilities.
Yes, that makes it more difficult to understand in the
key relevant case.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
(a) -n.embedded_H is an ordinary UTM
(b) -n.embedded_H simulates its input yet never aborts
When you contemplate an -n in which embedded_H cannot abort, you are
no longer talking about -n, you are talking about something else,
which I have referred to as -n_NoAbort.
Each machine always takes its own machine description
as its input.
-n rf?-nrf--a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // Original Linz -n
-n_UTM rf?-n_UTMrf--a-a-a-a-a-a-a-a-a // can't possibly abort
-n_NoAbort rf?-n_NoAbortrf--a // never aborts on this input
-n(-n)
-n(-n_NoAbort)
-n_NoAbort(-n)
-n_NoAbort(-n_NoAbort)
are four distinct computations.
Wrong list
No. It's the right list.
You don't have -n_UTM rf?-n_UTMrf-
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt. >>>>>>>
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that it
is possible to vary parameters independently of one another.
I am only talking about a single proof with two variations
that always has its own machine description as its input.
You can't declare that a particular machine always has its own
machine description as its input.
It is the only relevant instance.
-aIn the proof, Linz gives it its own machine description, but it can
also be given any input you want and logic requires you to consider
some of those other possibilities.
Yes, that makes it more difficult to understand in the
key relevant case.
The problem is that you are contemplating *misleading* cases, not
relevant ones.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
(a) -n.embedded_H is an ordinary UTM
(b) -n.embedded_H simulates its input yet never aborts
When you contemplate an -n in which embedded_H cannot abort, you are >>>>> no longer talking about -n, you are talking about something else,
which I have referred to as -n_NoAbort.
Each machine always takes its own machine description
as its input.
-n rf?-nrf--a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // Original Linz -n
-n_UTM rf?-n_UTMrf--a-a-a-a-a-a-a-a-a // can't possibly abort
-n_NoAbort rf?-n_NoAbortrf--a // never aborts on this input
-n(-n)
-n(-n_NoAbort)
-n_NoAbort(-n)
-n_NoAbort(-n_NoAbort)
are four distinct computations.
Wrong list
No. It's the right list.
You don't have -n_UTM rf?-n_UTMrf-
I already agreed that -n_UTM and -n_NoAbort are equivalent with respect to halting. You can replace all my instances of -n_NoAbort with -n_UTM if it makes you happy.
-n(-n) halts.
-n_UTM(-n_UTM) does not.
But -n_UTM(-n) *does* halt and that's the relevant case for determining whether -n really *needed* to abort its input.
Andr|-
On 10/7/2025 7:24 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt. >>>>>>>>
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that it >>>>>> is possible to vary parameters independently of one another.
I am only talking about a single proof with two variations
that always has its own machine description as its input.
You can't declare that a particular machine always has its own
machine description as its input.
It is the only relevant instance.
-aIn the proof, Linz gives it its own machine description, but it can >>>> also be given any input you want and logic requires you to consider
some of those other possibilities.
Yes, that makes it more difficult to understand in the
key relevant case.
The problem is that you are contemplating *misleading* cases, not
relevant ones.
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
On 2025-10-07 18:37, olcott wrote:
On 10/7/2025 7:24 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt. >>>>>>>>>
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that it >>>>>>> is possible to vary parameters independently of one another.
I am only talking about a single proof with two variations
that always has its own machine description as its input.
You can't declare that a particular machine always has its own
machine description as its input.
It is the only relevant instance.
-aIn the proof, Linz gives it its own machine description, but it
can also be given any input you want and logic requires you to
consider some of those other possibilities.
Yes, that makes it more difficult to understand in the
key relevant case.
The problem is that you are contemplating *misleading* cases, not
relevant ones.
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
such as -n_UTM,
you need to test those variants using the *exact* same input as in the original proof.
So the example of interest to us is -n_UTM(-n), not
-n_UTM(-n_UTM). In the latter case you've not only changed -n to a new machine, but you've also changed the *input* to the new machine, which
means your varying two *separate* variables. You're changing -n to
something which doesn't abort, but you're also changing its input from something that halts to something that doesn't halt.
Andr|-
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:How they work is that they are defined to have those properties. In
On 2025-10-07 18:37, olcott wrote:
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
such as -n_UTM, you need to test those variants using the *exact* same
input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work.
Ben has agreed that my notational conventions are correct.
On 10/7/2025 9:33 PM, olcott wrote:
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:How they work is that they are defined to have those properties.-a In
On 2025-10-07 18:37, olcott wrote:
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
such as -n_UTM, you need to test those variants using the *exact* same
input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work.
other words, it is proven true by the meaning of the words that a finite string description of a Turing machine is specified to have all of the semantic properties of that machine, including whether that machine
halts when executed directly.
On 10/7/2025 8:36 PM, dbush wrote:
On 10/7/2025 9:33 PM, olcott wrote:
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:How they work is that they are defined to have those properties.-a In
On 2025-10-07 18:37, olcott wrote:
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
such as -n_UTM, you need to test those variants using the *exact*
same input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work.
other words, it is proven true by the meaning of the words that a
finite string description of a Turing machine is specified to have all
of the semantic properties of that machine, including whether that
machine halts when executed directly.
Not in this case.
Have you read the Linz proof?
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
On 10/7/2025 9:47 PM, olcott wrote:
On 10/7/2025 8:36 PM, dbush wrote:
On 10/7/2025 9:33 PM, olcott wrote:
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:How they work is that they are defined to have those properties.-a In
On 2025-10-07 18:37, olcott wrote:
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
such as -n_UTM, you need to test those variants using the *exact*
same input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work.
other words, it is proven true by the meaning of the words that a
finite string description of a Turing machine is specified to have
all of the semantic properties of that machine, including whether
that machine halts when executed directly.
Not in this case.
Yes, in every case.-a Semantics are created by definitions.
Have you read the Linz proof?
Yes, and nowhere are the words "decider" or "specified" used.
It also
starts with the assumption that a solution to the halting problem exists
and that it is a fixed immutable set of instructions referred to as H.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
That's a loose translation of Linz's -n
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Incorrect, since the fixed immutable set of instructions that is -n
doesn't do that. It is this that does it:
On 10/7/2025 9:01 PM, dbush wrote:
On 10/7/2025 9:47 PM, olcott wrote:
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
That's a loose translation of Linz's -n
Not at all. It is exactly correct.
On 10/7/2025 9:01 PM, dbush wrote:
On 10/7/2025 9:47 PM, olcott wrote:
On 10/7/2025 8:36 PM, dbush wrote:
On 10/7/2025 9:33 PM, olcott wrote:
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:How they work is that they are defined to have those properties.-a In >>>> other words, it is proven true by the meaning of the words that a
On 2025-10-07 18:37, olcott wrote:
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
such as -n_UTM, you need to test those variants using the *exact* >>>>>> same input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work.
finite string description of a Turing machine is specified to have
all of the semantic properties of that machine, including whether
that machine halts when executed directly.
Not in this case.
Yes, in every case.-a Semantics are created by definitions.
Have you read the Linz proof?
Yes, and nowhere are the words "decider" or "specified" used.
A quick skim or a careful study? A careful study would
probably take an hour if you were already very familiar
with the halting problem and had a good background in
software engineering.
Do you have a good software engineering background?
It also starts with the assumption that a solution to the halting
problem exists and that it is a fixed immutable set of instructions
referred to as H.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
That's a loose translation of Linz's -n
Not at all. It is exactly correct.
<Linz text>
From H' we construct another Turing machine -n.
This new machine takes as input WM, copies it,
and then behaves exactly like H'. Then the action
of -n is such that
-a-a q0 WM reo* -nq0 WM WM reo* -nreR,
if M applied to WM halts, and
-a-a q0 WM reo* -nq0 WM WM reo* -n y1 qn y2,
if M applied to WM does not halt.
</Linz text>
WM is not as clear as rf?-nrf- when we are applying
-n to its own machine description.
I got rid of his mistaken second start state.
The tape states were not needed.
It is much clearer to say embedded_H rf?-nrf- rf?-nrf-
instead of -nq0 WM WM because it is the
embedded copy of H.
It made sense to label every state with
its machine name, hence -n.q0.
I prefer the Linz proof because it is specified
as explicit state transitions. Every other
proof seems much more vaguely specified.
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Incorrect, since the fixed immutable set of instructions that is -n
doesn't do that. It is this that does it:
That is merely your own ignorance of my innovation
of simulating halt deciders
-nn.q0 rf?-nnrf- reo* -nn.embedded_Hn rf?-nnrf- rf?-nnrf- reo* -nn.reR, // accept state
-nn.q0 rf?-nnrf- reo* -nn.embedded_Hn rf?-nnrf- rf?-nnrf- reo* -nn.qn // reject state
Where embedded_Hn is a non-aborting simulator
*Keep repeating unless aborted*
(a) -nn copies its input rf?-nnrf-
(b) -nn invokes embedded_Hn rf?-nnrf- rf?-nnrf-
(c) embedded_Hn simulates rf?-nnrf- rf?-nnrf-
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:37, olcott wrote:
On 10/7/2025 7:24 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:I am only talking about a single proof with two variations
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt.
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that >>>>>>>> it is possible to vary parameters independently of one another. >>>>>>>
that always has its own machine description as its input.
You can't declare that a particular machine always has its own
machine description as its input.
It is the only relevant instance.
-aIn the proof, Linz gives it its own machine description, but it >>>>>> can also be given any input you want and logic requires you to
consider some of those other possibilities.
Yes, that makes it more difficult to understand in the
key relevant case.
The problem is that you are contemplating *misleading* cases, not
relevant ones.
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
such as -n_UTM, you need to test those variants using the *exact* same
input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work. That
is the whole point of:
On 2025-10-07 20:44, olcott wrote:
On 10/7/2025 9:01 PM, dbush wrote:
On 10/7/2025 9:47 PM, olcott wrote:
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
That's a loose translation of Linz's -n
Not at all. It is exactly correct.
No. It most certainly is not. For one thing, you fail to indicate the conditions under which each branch is taken.
comments like "reject
state" say nothing.
It needs to be stated in a way similar to how Linz
does it. And the first branch is decidedly not an "accept state" since
you have an infinite loop there. An accept state is a *halting state*;
an infinite loop is not.
Andr|-
On 2025-10-07 19:33, olcott wrote:
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:37, olcott wrote:
On 10/7/2025 7:24 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:I am only talking about a single proof with two variations
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt.
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that >>>>>>>>> it is possible to vary parameters independently of one another. >>>>>>>>
that always has its own machine description as its input.
You can't declare that a particular machine always has its own
machine description as its input.
It is the only relevant instance.
-aIn the proof, Linz gives it its own machine description, but it >>>>>>> can also be given any input you want and logic requires you to
consider some of those other possibilities.
Yes, that makes it more difficult to understand in the
key relevant case.
The problem is that you are contemplating *misleading* cases, not
relevant ones.
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
Your phrase "categorically exhaustive reasoning" is largely meaningless,
but to make any sort of rigourous test you need to vary *one* parameter,
not two.
So what does your "categorically exhaustive reasoning" say about the different halting behaviours of the following two computations:
H_UTM(H_UTM)
-n_UTM(-n)
such as -n_UTM, you need to test those variants using the *exact* same
input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work. That
is the whole point of:
Finite strings don't have semantic properties except insofar as they are written in some specific language with a semantics
On 10/7/2025 9:55 PM, Andr|- G. Isaak wrote:
On 2025-10-07 19:33, olcott wrote:
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:37, olcott wrote:
On 10/7/2025 7:24 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:I am only talking about a single proof with two variations
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt.
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that >>>>>>>>>> it is possible to vary parameters independently of one another. >>>>>>>>>
that always has its own machine description as its input.
You can't declare that a particular machine always has its own >>>>>>>> machine description as its input.
It is the only relevant instance.
-aIn the proof, Linz gives it its own machine description, but it >>>>>>>> can also be given any input you want and logic requires you to >>>>>>>> consider some of those other possibilities.
Yes, that makes it more difficult to understand in the
key relevant case.
The problem is that you are contemplating *misleading* cases, not >>>>>> relevant ones.
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
Your phrase "categorically exhaustive reasoning" is largely
meaningless, but to make any sort of rigourous test you need to vary
*one* parameter, not two.
Just take the meaning of the individual terms and
combine them. Its not really all that hard.
So what does your "categorically exhaustive reasoning" say about the
different halting behaviours of the following two computations:
H_UTM(H_UTM)
-n_UTM(-n)
such as -n_UTM, you need to test those variants using the *exact*
same input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work. That
is the whole point of:
Finite strings don't have semantic properties except insofar as they
are written in some specific language with a semantics
Never heard of Rice's theorem huh?
In computability theory, Rice's theorem states
that all non-trivial semantic properties of
programs are undecidable. A semantic property
is one about the program's behavior. https://en.wikipedia.org/wiki/Rice%27s_theorem
Instead of "programs" I use finite string inputs
where only machine description inputs specify a
semantic property.
All Turing machine deciders only compute the mapping
from their finite string inputs to an accept state or reject
state on the basis that this input finite string specifies a
semantic or syntactic property.
On 10/7/2025 11:11 PM, olcott wrote:
On 10/7/2025 9:55 PM, Andr|- G. Isaak wrote:
On 2025-10-07 19:33, olcott wrote:
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:37, olcott wrote:
On 10/7/2025 7:24 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt.
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know >>>>>>>>>>> that it is possible to vary parameters independently of one >>>>>>>>>>> another.
I am only talking about a single proof with two variations >>>>>>>>>> that always has its own machine description as its input.
You can't declare that a particular machine always has its own >>>>>>>>> machine description as its input.
It is the only relevant instance.
-aIn the proof, Linz gives it its own machine description, but >>>>>>>>> it can also be given any input you want and logic requires you >>>>>>>>> to consider some of those other possibilities.
Yes, that makes it more difficult to understand in the
key relevant case.
The problem is that you are contemplating *misleading* cases, not >>>>>>> relevant ones.
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
Your phrase "categorically exhaustive reasoning" is largely
meaningless, but to make any sort of rigourous test you need to vary
*one* parameter, not two.
Just take the meaning of the individual terms and
combine them. Its not really all that hard.
So what does your "categorically exhaustive reasoning" say about the
different halting behaviours of the following two computations:
H_UTM(H_UTM)
-n_UTM(-n)
such as -n_UTM, you need to test those variants using the *exact*
same input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work. That
is the whole point of:
Finite strings don't have semantic properties except insofar as they
are written in some specific language with a semantics
Never heard of Rice's theorem huh?
In computability theory, Rice's theorem states
that all non-trivial semantic properties of
programs are undecidable. A semantic property
is one about the program's behavior.
https://en.wikipedia.org/wiki/Rice%27s_theorem
Instead of "programs" I use finite string inputs
where only machine description inputs specify a
semantic property.
And as proven true by the meaning of the words, a machine description specifies all of the semantic properties of the machine it describes, including whether it halts when executed directly.
All Turing machine deciders only compute the mapping
from their finite string inputs to an accept state or reject
state on the basis that this input finite string specifies a
semantic or syntactic property.
On 10/7/2025 9:55 PM, Andr|- G. Isaak wrote:
So what does your "categorically exhaustive reasoning" say about the
different halting behaviours of the following two computations:
-n_UTM(-n_UTM)
-n_UTM(-n)
such as -n_UTM, you need to test those variants using the *exact*
same input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work. That
is the whole point of:
Finite strings don't have semantic properties except insofar as they
are written in some specific language with a semantics
Never heard of Rice's theorem huh?
On 2025-10-07 21:11, olcott wrote:
On 10/7/2025 9:55 PM, Andr|- G. Isaak wrote:
So what does your "categorically exhaustive reasoning" say about the
different halting behaviours of the following two computations:
-n_UTM(-n_UTM)
-n_UTM(-n)
Why don't you actually address the above?
such as -n_UTM, you need to test those variants using the *exact*
same input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work. That
is the whole point of:
Finite strings don't have semantic properties except insofar as they
are written in some specific language with a semantics
Never heard of Rice's theorem huh?
Rice's theorem makes no mention of finite strings.
Andr|-
On 2025-10-07 21:11, olcott wrote:
On 10/7/2025 9:55 PM, Andr|- G. Isaak wrote:
So what does your "categorically exhaustive reasoning" say about the
different halting behaviours of the following two computations:
-n_UTM(-n_UTM)
-n_UTM(-n)
Why don't you actually address the above?
such as -n_UTM, you need to test those variants using the *exact*
same input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work. That
is the whole point of:
Finite strings don't have semantic properties except insofar as they
are written in some specific language with a semantics
Never heard of Rice's theorem huh?
Rice's theorem makes no mention of finite strings.
Andr|-
On 10/7/2025 10:43 PM, Andr|- G. Isaak wrote:
On 2025-10-07 21:11, olcott wrote:
On 10/7/2025 9:55 PM, Andr|- G. Isaak wrote:
So what does your "categorically exhaustive reasoning" say about the
different halting behaviours of the following two computations:
-n_UTM(-n_UTM)
-n_UTM(-n)
Why don't you actually address the above?
I am only making one single point here and that
is a deflection away from this point
When Rice's theorem refers to "programs" it is referring
to finite string machine descriptions. When it refers to
semantic properties of programs it is referring to the
behavior that an *ACTUAL INPUT* finite string specifies.
On 2025-10-08 08:20, olcott wrote:
When Rice's theorem refers to "programs" it is referring
to finite string machine descriptions. When it refers to
semantic properties of programs it is referring to the
behavior that an *ACTUAL INPUT* finite string specifies.
No. When Rice refers to "programs" he means programs. Don't project your
own idiosyncratic views onto others.
Andr|-
On 10/8/2025 10:30 AM, Andr|- G. Isaak wrote:
On 2025-10-08 08:20, olcott wrote:
When Rice's theorem refers to "programs" it is referring
to finite string machine descriptions. When it refers to
semantic properties of programs it is referring to the
behavior that an *ACTUAL INPUT* finite string specifies.
No. When Rice refers to "programs" he means programs. Don't project
your own idiosyncratic views onto others.
Andr|-
So he means that Turing machines take other actual
Turing machines as inputs?
On 2025-10-08 10:13, olcott wrote:
On 10/8/2025 10:30 AM, Andr|- G. Isaak wrote:
On 2025-10-08 08:20, olcott wrote:
When Rice's theorem refers to "programs" it is referring
to finite string machine descriptions. When it refers to
semantic properties of programs it is referring to the
behavior that an *ACTUAL INPUT* finite string specifies.
No. When Rice refers to "programs" he means programs. Don't project
your own idiosyncratic views onto others.
Andr|-
So he means that Turing machines take other actual
Turing machines as inputs?
Yes, Turing Machines can take other Turing Machines as input. They need
to be *encoded* as finite strings, but the semantic properties of which
Rice speaks belong to the Turing Machine, not the finite strings
themselves.
Finite strings might represent things which have semantic properties,
but finite strings by themselves have no such properties. If they did
you could describe the semantic properties of a finite string such as
AAABABABBBABABABBAABBBABBAAB
Andr|-
On 2025-10-07 19:33, olcott wrote:
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:37, olcott wrote:
On 10/7/2025 7:24 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:
On 2025-10-07 16:53, olcott wrote:I am only talking about a single proof with two variations
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt.
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know that >>>>>>>>> it is possible to vary parameters independently of one another. >>>>>>>>
that always has its own machine description as its input.
You can't declare that a particular machine always has its own
machine description as its input.
It is the only relevant instance.
-aIn the proof, Linz gives it its own machine description, but it >>>>>>> can also be given any input you want and logic requires you to
consider some of those other possibilities.
Yes, that makes it more difficult to understand in the
key relevant case.
The problem is that you are contemplating *misleading* cases, not
relevant ones.
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
Your phrase "categorically exhaustive reasoning" is largely meaningless,
but to make any sort of rigourous test you need to vary *one* parameter,
not two.
So what does your "categorically exhaustive reasoning" say about the different halting behaviours of the following two computations:
H_UTM(H_UTM)
-n_UTM(-n)
such as -n_UTM, you need to test those variants using the *exact* same
input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work. That
is the whole point of:
Finite strings don't have semantic properties except insofar as they are written in some specific language with a semantics
Do tell what the semantics of the following finite string are:
"AAABABBBAABABBBBAABBBABABBABBAAAABAABBBBBAA"
When constructing a halt decider one of your jobs is to construct a--- Synchronet 3.21a-Linux NewsLink 1.2
language which can represent any *arbitrary* Turing Machine. The same
string will *always* represent the exact same machine in any such language.
On 10/7/2025 10:14 PM, dbush wrote:In all cases. Semantics are provided by definitions. If a finite
On 10/7/2025 11:11 PM, olcott wrote:
On 10/7/2025 9:55 PM, Andr|- G. Isaak wrote:
On 2025-10-07 19:33, olcott wrote:
On 10/7/2025 8:19 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:37, olcott wrote:
On 10/7/2025 7:24 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
On 2025-10-07 17:28, olcott wrote:
On 10/7/2025 6:01 PM, Andr|- G. Isaak wrote:You can't declare that a particular machine always has its own >>>>>>>>>> machine description as its input.
On 2025-10-07 16:53, olcott wrote:
I agreed that -n.UTM rf?-n_NoAbortrf- rf?-n_NoAbortrf- wouldn't halt.
Maybe you just don't know Linz well enough.
The above is a single machine template named -n.
And maybe you don't understand proofs well enough to know >>>>>>>>>>>> that it is possible to vary parameters independently of one >>>>>>>>>>>> another.
I am only talking about a single proof with two variations >>>>>>>>>>> that always has its own machine description as its input. >>>>>>>>>>
It is the only relevant instance.
-aIn the proof, Linz gives it its own machine description, but >>>>>>>>>> it can also be given any input you want and logic requires you >>>>>>>>>> to consider some of those other possibilities.
Yes, that makes it more difficult to understand in the
key relevant case.
The problem is that you are contemplating *misleading* cases, >>>>>>>> not relevant ones.
-n applied to rf?-nrf- is the basis for the whole
conclusion of his proof.
Right, and when you start playing around with variants,
then we are using categorically exhaustive reasoning
to directly test all the possibilities.
Your phrase "categorically exhaustive reasoning" is largely
meaningless, but to make any sort of rigourous test you need to vary
*one* parameter, not two.
Just take the meaning of the individual terms and
combine them. Its not really all that hard.
So what does your "categorically exhaustive reasoning" say about the
different halting behaviours of the following two computations:
H_UTM(H_UTM)
-n_UTM(-n)
such as -n_UTM, you need to test those variants using the *exact* >>>>>> same input as in the original proof.
I am just trying to get you to understand how semantic
properties of finite string inputs actually work. That
is the whole point of:
Finite strings don't have semantic properties except insofar as they
are written in some specific language with a semantics
Never heard of Rice's theorem huh?
In computability theory, Rice's theorem states
that all non-trivial semantic properties of
programs are undecidable. A semantic property
is one about the program's behavior.
https://en.wikipedia.org/wiki/Rice%27s_theorem
Instead of "programs" I use finite string inputs
where only machine description inputs specify a
semantic property.
And as proven true by the meaning of the words, a machine description
specifies all of the semantic properties of the machine it describes,
including whether it halts when executed directly.
Not in the case
every TM has a machine description
On 10/8/2025 11:42 AM, Andr|- G. Isaak wrote:
On 2025-10-08 10:13, olcott wrote:
On 10/8/2025 10:30 AM, Andr|- G. Isaak wrote:
On 2025-10-08 08:20, olcott wrote:
When Rice's theorem refers to "programs" it is referring
to finite string machine descriptions. When it refers to
semantic properties of programs it is referring to the
behavior that an *ACTUAL INPUT* finite string specifies.
No. When Rice refers to "programs" he means programs. Don't project
your own idiosyncratic views onto others.
Andr|-
So he means that Turing machines take other actual
Turing machines as inputs?
Yes, Turing Machines can take other Turing Machines as input. They
need to be *encoded* as finite strings, but the semantic properties of
which Rice speaks belong to the Turing Machine, not the finite strings
themselves.
That turns out to not be exactly the same thing when
the halt decider actually measures the semantic
property specified by its finite string input by
the behavior of its own correct simulation of this
finite string input.
On 2025-10-08 10:51, olcott wrote:
On 10/8/2025 11:42 AM, Andr|- G. Isaak wrote:
On 2025-10-08 10:13, olcott wrote:
On 10/8/2025 10:30 AM, Andr|- G. Isaak wrote:
On 2025-10-08 08:20, olcott wrote:
When Rice's theorem refers to "programs" it is referring
to finite string machine descriptions. When it refers to
semantic properties of programs it is referring to the
behavior that an *ACTUAL INPUT* finite string specifies.
No. When Rice refers to "programs" he means programs. Don't project >>>>> your own idiosyncratic views onto others.
Andr|-
So he means that Turing machines take other actual
Turing machines as inputs?
Yes, Turing Machines can take other Turing Machines as input. They
need to be *encoded* as finite strings, but the semantic properties
of which Rice speaks belong to the Turing Machine, not the finite
strings themselves.
That turns out to not be exactly the same thing when
the halt decider actually measures the semantic
property specified by its finite string input by
the behavior of its own correct simulation of this
finite string input.
A Turing Machine description describes exactly one Turing Machine, and
that Turing Machine has exactly one behaviour.
It behaves the same
regardless of whether it is run on its own, inside a UTM, or inside a "simulating halt decider". To say otherwise is simply errant nonsense.
Andr|-
On 10/8/2025 4:48 PM, Andr|- G. Isaak wrote:
On 2025-10-08 10:51, olcott wrote:
On 10/8/2025 11:42 AM, Andr|- G. Isaak wrote:
On 2025-10-08 10:13, olcott wrote:
On 10/8/2025 10:30 AM, Andr|- G. Isaak wrote:
On 2025-10-08 08:20, olcott wrote:
When Rice's theorem refers to "programs" it is referring
to finite string machine descriptions. When it refers to
semantic properties of programs it is referring to the
behavior that an *ACTUAL INPUT* finite string specifies.
No. When Rice refers to "programs" he means programs. Don't project >>>>>> your own idiosyncratic views onto others.
Andr|-
So he means that Turing machines take other actual
Turing machines as inputs?
Yes, Turing Machines can take other Turing Machines as input. They
need to be *encoded* as finite strings, but the semantic properties
of which Rice speaks belong to the Turing Machine, not the finite
strings themselves.
That turns out to not be exactly the same thing when
the halt decider actually measures the semantic
property specified by its finite string input by
the behavior of its own correct simulation of this
finite string input.
A Turing Machine description describes exactly one Turing Machine, and
that Turing Machine has exactly one behaviour.
Provably counter-factual when this machine simulates
an instance of itself in recursive simulation.
The behavior that the input specifies as measured by
its correct simulation of its own machine description
differs from the behavior of the machine containing
the simulating halt decider, unless embedded_H never
aborts.
If you really understand that this is a correct encoding
of Linz (absent the basis for accept and reject)
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
and you understand merely how the simulation aspect
of a simulating halt decider works then you understand
that this is correct.
On 10/8/2025 4:48 PM, Andr|- G. Isaak wrote:
On 2025-10-08 10:51, olcott wrote:
On 10/8/2025 11:42 AM, Andr|- G. Isaak wrote:
On 2025-10-08 10:13, olcott wrote:
On 10/8/2025 10:30 AM, Andr|- G. Isaak wrote:
On 2025-10-08 08:20, olcott wrote:
When Rice's theorem refers to "programs" it is referring
to finite string machine descriptions. When it refers to
semantic properties of programs it is referring to the
behavior that an *ACTUAL INPUT* finite string specifies.
No. When Rice refers to "programs" he means programs. Don't
project your own idiosyncratic views onto others.
Andr|-
So he means that Turing machines take other actual
Turing machines as inputs?
Yes, Turing Machines can take other Turing Machines as input. They
need to be *encoded* as finite strings, but the semantic properties
of which Rice speaks belong to the Turing Machine, not the finite
strings themselves.
That turns out to not be exactly the same thing when
the halt decider actually measures the semantic
property specified by its finite string input by
the behavior of its own correct simulation of this
finite string input.
A Turing Machine description describes exactly one Turing Machine, and
that Turing Machine has exactly one behaviour.
Provably counter-factual when this machine simulates
an instance of itself in recursive simulation.
On 2025-10-08 18:49, olcott wrote:
On 10/8/2025 4:48 PM, Andr|- G. Isaak wrote:
On 2025-10-08 10:51, olcott wrote:
On 10/8/2025 11:42 AM, Andr|- G. Isaak wrote:
On 2025-10-08 10:13, olcott wrote:
On 10/8/2025 10:30 AM, Andr|- G. Isaak wrote:
On 2025-10-08 08:20, olcott wrote:
When Rice's theorem refers to "programs" it is referring
to finite string machine descriptions. When it refers to
semantic properties of programs it is referring to the
behavior that an *ACTUAL INPUT* finite string specifies.
No. When Rice refers to "programs" he means programs. Don't
project your own idiosyncratic views onto others.
Andr|-
So he means that Turing machines take other actual
Turing machines as inputs?
Yes, Turing Machines can take other Turing Machines as input. They
need to be *encoded* as finite strings, but the semantic properties >>>>> of which Rice speaks belong to the Turing Machine, not the finite
strings themselves.
That turns out to not be exactly the same thing when
the halt decider actually measures the semantic
property specified by its finite string input by
the behavior of its own correct simulation of this
finite string input.
A Turing Machine description describes exactly one Turing Machine,
and that Turing Machine has exactly one behaviour.
Provably counter-factual when this machine simulates
an instance of itself in recursive simulation.
It's not counterfactual at all, let alone provably counterfactual. It doesn't matter how many times you assert this. The claim is simply wrong (and laughably so).
Andr|-
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 4:48 PM, Andr|- G. Isaak wrote:
On 2025-10-08 10:51, olcott wrote:
On 10/8/2025 11:42 AM, Andr|- G. Isaak wrote:
On 2025-10-08 10:13, olcott wrote:
On 10/8/2025 10:30 AM, Andr|- G. Isaak wrote:
On 2025-10-08 08:20, olcott wrote:
When Rice's theorem refers to "programs" it is referring
to finite string machine descriptions. When it refers to
semantic properties of programs it is referring to the
behavior that an *ACTUAL INPUT* finite string specifies.
No. When Rice refers to "programs" he means programs. Don't project >>>>>>> your own idiosyncratic views onto others.
Andr|-
So he means that Turing machines take other actual
Turing machines as inputs?
Yes, Turing Machines can take other Turing Machines as input. They
need to be *encoded* as finite strings, but the semantic properties
of which Rice speaks belong to the Turing Machine, not the finite
strings themselves.
That turns out to not be exactly the same thing when
the halt decider actually measures the semantic
property specified by its finite string input by
the behavior of its own correct simulation of this
finite string input.
A Turing Machine description describes exactly one Turing Machine, and
that Turing Machine has exactly one behaviour.
Provably counter-factual when this machine simulates
an instance of itself in recursive simulation.
Provably a fuck-up caused by you not understanding your own code
and its implications.
The behavior that the input specifies as measured by
its correct simulation of its own machine description
differs from the behavior of the machine containing
the simulating halt decider, unless embedded_H never
aborts.
It doesn't differ --- and if you find that it does, you have a problem because it /must/ not differ.
If you really understand that this is a correct encoding
of Linz (absent the basis for accept and reject)
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR, // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
and you understand merely how the simulation aspect
of a simulating halt decider works then you understand
that this is correct.
Problem is, you don't understand that abandoning a simulation
of a machine which has a halting state,
before the simulation
is able to attain the halting state, does not make the machine
non-halting.
***
The manner of conducting the simulation (or neglecting to conduct it completely) does not confer any properties onto the simulated machine!
***
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation
of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation
of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
If embedded_H is an aborting simulation, then it causes
the subject to be halting.
Preventing a simulation from reproducing its subject's
halt state does NOT make the subject non-terminating.
That idea is just bat shit crazy.
The fact that a different version of the subject would
be non-terminating under a different version of the decider
which does not abort is immaterial. That's a different
diagonal pair.
On 10/9/2025 11:31 AM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation
of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
If embedded_H is an aborting simulation, then it causes
the subject to be halting.
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Yes or no?
On 10/7/2025 7:24 PM, Andr|- G. Isaak wrote:No. DDD_UTM has no relation to HHH.
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
You can't declare that a particular machine always has its ownIt is the only relevant instance.
machine description as its input.
TheyrCOre the same picture.(a) -n.embedded_H is an ordinary UTM
(b) -n.embedded_H simulates its input yet never aborts
ThatrCOs on you. But we do know that it returns 0.OK great.-n(-n)
-n(-n_NoAbort)
-n_NoAbort(-n)
-n_NoAbort(-n_NoAbort)
are four distinct computations.
-n(-n) halts.We can't say anything about that until we know the exact semantics of embedded_H.
-n_UTM doesnrCOt abort either.-n_UTM(-n_UTM) does not.-n_NoAbort(-n_NoAbort) is not exactly the same in that is does not abort
for this one input.
Whatcha gonna do about it?But -n_UTM(-n) *does* halt and that's the relevant case for determiningCurrently -n(-n) has not been defined so no conclusions can be formed.
whether -n really *needed* to abort its input.
Am Tue, 07 Oct 2025 19:37:23 -0500 schrieb olcott:
On 10/7/2025 7:24 PM, Andr|- G. Isaak wrote:
On 2025-10-07 18:09, olcott wrote:
On 10/7/2025 6:50 PM, Andr|- G. Isaak wrote:
No. DDD_UTM has no relation to HHH.You can't declare that a particular machine always has its ownIt is the only relevant instance.
machine description as its input.
TheyrCOre the same picture.(a) -n.embedded_H is an ordinary UTM
(b) -n.embedded_H simulates its input yet never aborts
OK great.-n(-n)
-n(-n_NoAbort)
-n_NoAbort(-n)
-n_NoAbort(-n_NoAbort)
are four distinct computations.
-n(-n) halts.We can't say anything about that until we know the exact semantics of
embedded_H.
ThatrCOs on you. But we do know that it returns 0.
-n_UTM doesnrCOt abort either.-n_UTM(-n_UTM) does not.-n_NoAbort(-n_NoAbort) is not exactly the same in that is does not abort
for this one input.
But -n_UTM(-n) *does* halt and that's the relevant case for determiningCurrently -n(-n) has not been defined so no conclusions can be formed.
whether -n really *needed* to abort its input.
Whatcha gonna do about it?
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 11:31 AM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation
of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
If embedded_H is an aborting simulation, then it causes
the subject to be halting.
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Yes or no?
Since aborted is something that happens or not, in two different
definitions of everything, why don't you lay out both cases?
On 10/9/2025 2:58 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 11:31 AM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation
of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
If embedded_H is an aborting simulation, then it causes
the subject to be halting.
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Yes or no?
Since aborted is something that happens or not, in two different
definitions of everything, why don't you lay out both cases?
(a) embedded_H aborts its simulation at some point
(b) embedded_H never aborts its simulation
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 2:58 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 11:31 AM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation
of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
If embedded_H is an aborting simulation, then it causes
the subject to be halting.
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Yes or no?
Since aborted is something that happens or not, in two different
definitions of everything, why don't you lay out both cases?
(a) embedded_H aborts its simulation at some point
(b) embedded_H never aborts its simulation
So if this is in reference to the same simuation subject,
it cannot be the same embedded_H. This is embedded_H_aborting,
and embedded_H_non_aborting.
"Keeps repeating unless aborted ..." means "Under
embedded_H_non_aborting, this keeps repeating, unless
embedded_H_non_aborting is embedded_H_aborting, which it isn't, so why
did I just say that?"
On 10/9/2025 7:15 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 2:58 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 11:31 AM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation
of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
If embedded_H is an aborting simulation, then it causes
the subject to be halting.
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Yes or no?
Since aborted is something that happens or not, in two different
definitions of everything, why don't you lay out both cases?
(a) embedded_H aborts its simulation at some point
(b) embedded_H never aborts its simulation
So if this is in reference to the same simuation subject,
it cannot be the same embedded_H. This is embedded_H_aborting,
and embedded_H_non_aborting.
None-the-less that is the scenario that both professor
Sipser and Ben agreed to. I know that hypothetical scenarios
are not over your head: Why play dumb?
On 2025-10-10 00:43:57 +0000, olcott said:
On 10/9/2025 7:15 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 2:58 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 11:31 AM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation >>>>>>>>> of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
If embedded_H is an aborting simulation, then it causes
the subject to be halting.
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Yes or no?
Since aborted is something that happens or not, in two different
definitions of everything, why don't you lay out both cases?
(a) embedded_H aborts its simulation at some point
(b) embedded_H never aborts its simulation
So if this is in reference to the same simuation subject,
it cannot be the same embedded_H. This is embedded_H_aborting,
and embedded_H_non_aborting.
None-the-less that is the scenario that both professor
Sipser and Ben agreed to. I know that hypothetical scenarios
are not over your head: Why play dumb?
Professsor Sipser did not agreed to any scenario. He agreed to a
conditional statemenet where the condition is a truth-bearer in
every scenario.
On 10/10/2025 2:50 AM, Mikko wrote:
On 2025-10-10 00:43:57 +0000, olcott said:
On 10/9/2025 7:15 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 2:58 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 11:31 AM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation >>>>>>>>>> of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
If embedded_H is an aborting simulation, then it causes
the subject to be halting.
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Yes or no?
Since aborted is something that happens or not, in two different
definitions of everything, why don't you lay out both cases?
(a) embedded_H aborts its simulation at some point
(b) embedded_H never aborts its simulation
So if this is in reference to the same simuation subject,
it cannot be the same embedded_H. This is embedded_H_aborting,
and embedded_H_non_aborting.
None-the-less that is the scenario that both professor
Sipser and Ben agreed to. I know that hypothetical scenarios
are not over your head: Why play dumb?
Professsor Sipser did not agreed to any scenario. He agreed to a
conditional statemenet where the condition is a truth-bearer in
every scenario.
He agreed that these words are true because they are a semantic
tautology proven completely true entirely on the basis of their
meaning.
Ben explicitly agreed that the criterion in the first
part has been met.
On 2025-10-10 15:32:49 +0000, olcott said:
On 10/10/2025 2:50 AM, Mikko wrote:
On 2025-10-10 00:43:57 +0000, olcott said:
On 10/9/2025 7:15 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 2:58 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 11:31 AM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation >>>>>>>>>>> of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
If embedded_H is an aborting simulation, then it causes
the subject to be halting.
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Yes or no?
Since aborted is something that happens or not, in two different >>>>>>> definitions of everything, why don't you lay out both cases?
(a) embedded_H aborts its simulation at some point
(b) embedded_H never aborts its simulation
So if this is in reference to the same simuation subject,
it cannot be the same embedded_H. This is embedded_H_aborting,
and embedded_H_non_aborting.
None-the-less that is the scenario that both professor
Sipser and Ben agreed to. I know that hypothetical scenarios
are not over your head: Why play dumb?
Professsor Sipser did not agreed to any scenario. He agreed to a
conditional statemenet where the condition is a truth-bearer in
every scenario.
He agreed that these words are true because they are a semantic
tautology proven completely true entirely on the basis of their
meaning.
Where did Sipser say anything about why he agreed?
Ben explicitly agreed that the criterion in the first
part has been met.
Ben's opinion does not have the same weight as Sipser's. But even
SIpser's opinion is a poor substitute for a proof.
On 10/11/2025 4:02 AM, Mikko wrote:
On 2025-10-10 15:32:49 +0000, olcott said:
On 10/10/2025 2:50 AM, Mikko wrote:
On 2025-10-10 00:43:57 +0000, olcott said:
On 10/9/2025 7:15 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 2:58 PM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/9/2025 11:31 AM, Kaz Kylheku wrote:
On 2025-10-09, olcott <polcott333@gmail.com> wrote:
On 10/8/2025 8:36 PM, Kaz Kylheku wrote:
Problem is, you don't understand that abandoning a simulation >>>>>>>>>>>> of a machine which has a halting state,
*You don't understand this**
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
If embedded_H is an aborting simulation, then it causes
the subject to be halting.
*Keep repeating unless aborted*
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-
Yes or no?
Since aborted is something that happens or not, in two different >>>>>>>> definitions of everything, why don't you lay out both cases?
(a) embedded_H aborts its simulation at some point
(b) embedded_H never aborts its simulation
So if this is in reference to the same simuation subject,
it cannot be the same embedded_H. This is embedded_H_aborting,
and embedded_H_non_aborting.
None-the-less that is the scenario that both professor
Sipser and Ben agreed to. I know that hypothetical scenarios
are not over your head: Why play dumb?
Professsor Sipser did not agreed to any scenario. He agreed to a
conditional statemenet where the condition is a truth-bearer in
every scenario.
He agreed that these words are true because they are a semantic
tautology proven completely true entirely on the basis of their
meaning.
Where did Sipser say anything about why he agreed?
Ben explicitly agreed that the criterion in the first
part has been met.
Ben's opinion does not have the same weight as Sipser's. But even
SIpser's opinion is a poor substitute for a proof.
Five LLM systems agree that HHH(DD) correctly
rejects its input when the behavior of its input
is measured by DD correctly simulation by HHH.
They only agree because this is an objectively
verified fact. Any LLM system or human that
strictly follows the Rubric that ChatGPT 5.0
wrote for me can only conclude that within the
exact meaning of words and code I am correct.
<Benchmark Task>
You are given:
1. A simulation rubric.
2. A C function (test program).
Your job:
- Apply the rubric exactly.
- Produce the required output in the given format.
- Do not skip steps or jump to conclusions.
---
<Rubric>
Rules of Simulation:
- (a) If a non-terminating behavior pattern is detected during
simulation, abort immediately and return 0.
- (b) If the simulated program reaches a return statement without
earlier detection, return 1.
- Priority: (a) always takes precedence over (b).
Procedure:
1. Restate rules before simulation.
2. Simulate step by step using a trace table with columns:
| Step | Code Location | State (variables, call stack) | Event /
Action | Rule Applied |
3. Stop immediately if recursion, infinite loop, or repeating state
occurs raA apply (a).
4. If a return is reached first raA apply (b).
5. Conclude with:
- Which rule fired first
- The correct return value
6. Optionally, provide:
- (i) Simulation result under rules
- (ii) Actual runtime behavior in C
</Rubric>
<Test Program>
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
</Test Program>
<Required Output Format>
1. Restatement of rules
2. Step-by-step execution trace in a table
3. Identification of first rule triggered
4. Final result: return value of HHH(program)
5. Optional: actual C runtime behavior if relevant
</Required Output Format>
</Benchmark Task>
Five LLM systems agree that HHH(DD) correctlyis false about the Benchmark Task. What if anything it is true about
rejects its input when the behavior of its input
is measured by DD correctly simulation by HHH.
On 2025-10-11 13:03:55 +0000, olcott said:
Of course, non of the above is relevant to may comment that Professsor
Sipser did not agreed to any scenario. He agreed to a conditional
statemenet where the condition is a truth-bearer in every scenario.
On 10/12/2025 3:36 AM, Mikko wrote:
On 2025-10-11 13:03:55 +0000, olcott said:
Of course, non of the above is relevant to may comment that Professsor
Sipser did not agreed to any scenario. He agreed to a conditional
statemenet where the condition is a truth-bearer in every scenario.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
[Updated input to LLM systems proving HHH(DD)==0 within assumptions]
This is much easier for people to understand and has been validated
across four LLM systems. It specifies the same thing that Professor
Sipser agreed to in easier to understand words.
It seems that everyone who has been reading these discussions does
understand or soon will that HHH(DD) returns 0 and that the correct
value would be 1 because DD halts
On 2025-10-12 14:36:27 +0000, olcott said:
On 10/12/2025 3:36 AM, Mikko wrote:
On 2025-10-11 13:03:55 +0000, olcott said:
Of course, non of the above is relevant to may comment that Professsor
Sipser did not agreed to any scenario. He agreed to a conditional
statemenet where the condition is a truth-bearer in every scenario.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
-a-a-a-a If simulating halt decider H correctly simulates its
-a-a-a-a input D until H correctly determines that its simulated D
-a-a-a-a would never stop running unless aborted then
Thank you for the confirmation.
[Updated input to LLM systems proving HHH(DD)==0 within assumptions]
This is much easier for people to understand and has been validated
across four LLM systems. It specifies the same thing that Professor
Sipser agreed to in easier to understand words.
It seems that everyone who has been reading these discussions does
understand or soon will that HHH(DD) returns 0 and that the correct
value would be 1 because DD halts.
However, that is irrelevant to the fact that Professor Sipser did
not agree to any scenario.
On 13/10/2025 08:59, Mikko wrote:
It seems that everyone who has been reading these discussions does
understand or soon will that HHH(DD) returns 0 and that the correct
value would be 1 because DD halts
Even Mr Olcott, in his darker moments.
On 10/13/2025 3:07 AM, Richard Heathfield wrote:
On 13/10/2025 08:59, Mikko wrote:
It seems that everyone who has been reading these discussions does
understand or soon will that HHH(DD) returns 0 and that the correct
value would be 1 because DD halts
Even Mr Olcott, in his darker moments.
LLM systems are 67-fold more powerful than they were
a year ago because their context widow increased from
3,000 words to 200,000 words. This is how much stuff
they can simultaneously keep "in their head".
It is also very valuable to know that these systems are
extremely reliable when their reasoning is limited to
semantic entailment for a well defined set of premises.
In this case AI hallucination cannot possibly occur.
https://chatgpt.com/share/68ec6e96-7eb8-8011-90c7-86248034d475
Has verified the details of the reasoning that proves
the behavior of the directly executed DD() is outside of
the domain of the function computed by HHH(DD). It also
verified that HHH(DD) is correct to reject its input and
provided all of the reasoning proving that this is correct.
On 10/13/2025 2:59 AM, Mikko wrote:
On 2025-10-12 14:36:27 +0000, olcott said:
On 10/12/2025 3:36 AM, Mikko wrote:
On 2025-10-11 13:03:55 +0000, olcott said:
Of course, non of the above is relevant to may comment that Professsor >>>> Sipser did not agreed to any scenario. He agreed to a conditional
statemenet where the condition is a truth-bearer in every scenario.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
-a-a-a-a If simulating halt decider H correctly simulates its
-a-a-a-a input D until H correctly determines that its simulated D
-a-a-a-a would never stop running unless aborted then
Thank you for the confirmation.
[Updated input to LLM systems proving HHH(DD)==0 within assumptions]
This is much easier for people to understand and has been validated
across four LLM systems. It specifies the same thing that Professor
Sipser agreed to in easier to understand words.
It seems that everyone who has been reading these discussions does
understand or soon will that HHH(DD) returns 0 and that the correct
value would be 1 because DD halts.
ChatGPT 5.0 is 67-fold smarter that ChatGPT was one year ago
because its context window grew from 3000 words to 200,000
words. When it is only providing the semantic logical entailment
from a set of premises then AI hallucination is impossible.
On 2025-10-13 16:23:56 +0000, olcott said:
On 10/13/2025 3:07 AM, Richard Heathfield wrote:
On 13/10/2025 08:59, Mikko wrote:
It seems that everyone who has been reading these discussions does
understand or soon will that HHH(DD) returns 0 and that the correct
value would be 1 because DD halts
Even Mr Olcott, in his darker moments.
LLM systems are 67-fold more powerful than they were
a year ago because their context widow increased from
3,000 words to 200,000 words. This is how much stuff
they can simultaneously keep "in their head".
It is also very valuable to know that these systems are
extremely reliable when their reasoning is limited to
semantic entailment for a well defined set of premises.
In this case AI hallucination cannot possibly occur.
Semantic entailment requires semantics. The only meaning an AI can
attach to any sequence of symbols is the same or anoother sequence
of symbols.
Consequently, an AI can only check for syntactic
entailment.
To what extent (if at all) they can identify what should
be considered as a "premise" is hard to tell. Their basic strategy
is to say what has been said before in similar contexts.
https://chatgpt.com/share/68ec6e96-7eb8-8011-90c7-86248034d475
Has verified the details of the reasoning that proves
the behavior of the directly executed DD() is outside of
the domain of the function computed by HHH(DD). It also
verified that HHH(DD) is correct to reject its input and
provided all of the reasoning proving that this is correct.
For verification of reasoning no AI is as reliable as a good proof
checker.
On 2025-10-13 13:58:09 +0000, olcott said:
On 10/13/2025 2:59 AM, Mikko wrote:
On 2025-10-12 14:36:27 +0000, olcott said:
On 10/12/2025 3:36 AM, Mikko wrote:
On 2025-10-11 13:03:55 +0000, olcott said:
Of course, non of the above is relevant to may comment that Professsor >>>>> Sipser did not agreed to any scenario. He agreed to a conditional
statemenet where the condition is a truth-bearer in every scenario.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
-a-a-a-a If simulating halt decider H correctly simulates its
-a-a-a-a input D until H correctly determines that its simulated D
-a-a-a-a would never stop running unless aborted then
Thank you for the confirmation.
[Updated input to LLM systems proving HHH(DD)==0 within assumptions]
This is much easier for people to understand and has been validated
across four LLM systems. It specifies the same thing that Professor
Sipser agreed to in easier to understand words.
It seems that everyone who has been reading these discussions does
understand or soon will that HHH(DD) returns 0 and that the correct
value would be 1 because DD halts.
ChatGPT 5.0 is 67-fold smarter that ChatGPT was one year ago
because its context window grew from 3000 words to 200,000
words. When it is only providing the semantic logical entailment
from a set of premises then AI hallucination is impossible.
The claim that AI hallucination is impossible under those conditions
is not supported by any evidence and therefore is not credible.
Of course, non of the above is relevant to may comment that Professsor
Sipser did not agreed to any scenario. He agreed to a conditional
statemenet where the condition is a truth-bearer in every scenario.
On 10/14/2025 4:27 AM, Mikko wrote:
On 2025-10-13 13:58:09 +0000, olcott said:
On 10/13/2025 2:59 AM, Mikko wrote:
On 2025-10-12 14:36:27 +0000, olcott said:
On 10/12/2025 3:36 AM, Mikko wrote:
On 2025-10-11 13:03:55 +0000, olcott said:<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> -a-a-a-a If simulating halt decider H correctly simulates its
Of course, non of the above is relevant to may comment that Professsor >>>>>> Sipser did not agreed to any scenario. He agreed to a conditional
statemenet where the condition is a truth-bearer in every scenario. >>>>>
-a-a-a-a input D until H correctly determines that its simulated D
-a-a-a-a would never stop running unless aborted then
Thank you for the confirmation.
[Updated input to LLM systems proving HHH(DD)==0 within assumptions] >>>>> This is much easier for people to understand and has been validated
across four LLM systems. It specifies the same thing that Professor
Sipser agreed to in easier to understand words.
It seems that everyone who has been reading these discussions does
understand or soon will that HHH(DD) returns 0 and that the correct
value would be 1 because DD halts.
ChatGPT 5.0 is 67-fold smarter that ChatGPT was one year ago
because its context window grew from 3000 words to 200,000
words. When it is only providing the semantic logical entailment
from a set of premises then AI hallucination is impossible.
The claim that AI hallucination is impossible under those conditions
is not supported by any evidence and therefore is not credible.
When its entire basis of reasoning is provided
then it is not free to just make up any other
basis. Current AI has proven to be smart enough
to restrict its reasoning to within a set of
well defined premises. It even smart enough to
spot ambiguity and ask for clarification.
On 10/14/2025 4:22 AM, Mikko wrote:
On 2025-10-13 16:23:56 +0000, olcott said:
On 10/13/2025 3:07 AM, Richard Heathfield wrote:
On 13/10/2025 08:59, Mikko wrote:
It seems that everyone who has been reading these discussions does
understand or soon will that HHH(DD) returns 0 and that the correct
value would be 1 because DD halts
Even Mr Olcott, in his darker moments.
LLM systems are 67-fold more powerful than they were
a year ago because their context widow increased from
3,000 words to 200,000 words. This is how much stuff
they can simultaneously keep "in their head".
It is also very valuable to know that these systems are
extremely reliable when their reasoning is limited to
semantic entailment for a well defined set of premises.
In this case AI hallucination cannot possibly occur.
Semantic entailment requires semantics. The only meaning an AI can
attach to any sequence of symbols is the same or anoother sequence
of symbols.
It turns out that has always been the way that analytic
truth has always worked.
On 2025-10-14 16:04:23 +0000, olcott said:
On 10/14/2025 4:22 AM, Mikko wrote:
On 2025-10-13 16:23:56 +0000, olcott said:
On 10/13/2025 3:07 AM, Richard Heathfield wrote:
On 13/10/2025 08:59, Mikko wrote:
It seems that everyone who has been reading these discussions does >>>>>> understand or soon will that HHH(DD) returns 0 and that the correct >>>>>> value would be 1 because DD halts
Even Mr Olcott, in his darker moments.
LLM systems are 67-fold more powerful than they were
a year ago because their context widow increased from
3,000 words to 200,000 words. This is how much stuff
they can simultaneously keep "in their head".
It is also very valuable to know that these systems are
extremely reliable when their reasoning is limited to
semantic entailment for a well defined set of premises.
In this case AI hallucination cannot possibly occur.
Semantic entailment requires semantics. The only meaning an AI can
attach to any sequence of symbols is the same or anoother sequence
of symbols.
It turns out that has always been the way that analytic
truth has always worked.
No, the usual meanings of analytic truths refer to abstract objects
that usually are other that sequences of symbols.
For example, saying
that every transfinite set is a sequence of symbols is false under the
usual meanings of the words. There is a model of the first order ZFC
where every "set" is a finite string but that model is non-standard.
On 2025-10-14 16:15:39 +0000, olcott said:
On 10/14/2025 4:27 AM, Mikko wrote:
On 2025-10-13 13:58:09 +0000, olcott said:
On 10/13/2025 2:59 AM, Mikko wrote:
On 2025-10-12 14:36:27 +0000, olcott said:
On 10/12/2025 3:36 AM, Mikko wrote:
On 2025-10-11 13:03:55 +0000, olcott said:<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>> -a-a-a-a If simulating halt decider H correctly simulates its
Of course, non of the above is relevant to may comment that
Professsor
Sipser did not agreed to any scenario. He agreed to a conditional >>>>>>> statemenet where the condition is a truth-bearer in every scenario. >>>>>>
-a-a-a-a input D until H correctly determines that its simulated D >>>>>> -a-a-a-a would never stop running unless aborted then
Thank you for the confirmation.
[Updated input to LLM systems proving HHH(DD)==0 within assumptions] >>>>>> This is much easier for people to understand and has been validated >>>>>> across four LLM systems. It specifies the same thing that Professor >>>>>> Sipser agreed to in easier to understand words.
It seems that everyone who has been reading these discussions does
understand or soon will that HHH(DD) returns 0 and that the correct
value would be 1 because DD halts.
ChatGPT 5.0 is 67-fold smarter that ChatGPT was one year ago
because its context window grew from 3000 words to 200,000
words. When it is only providing the semantic logical entailment
from a set of premises then AI hallucination is impossible.
The claim that AI hallucination is impossible under those conditions
is not supported by any evidence and therefore is not credible.
When its entire basis of reasoning is provided
then it is not free to just make up any other
basis. Current AI has proven to be smart enough
to restrict its reasoning to within a set of
well defined premises. It even smart enough to
spot ambiguity and ask for clarification.
There is no way to control that an AI does not do what it is not "free"
to do. There is no way to ensure that all its reasoning is logically
valid. It is unlikely that it could be smart enough to spot all ambiguity. You can claim whatever you want but you don't support your above claims
with any evidence.
On 10/15/2025 3:15 AM, Mikko wrote:
On 2025-10-14 16:15:39 +0000, olcott said:
On 10/14/2025 4:27 AM, Mikko wrote:
On 2025-10-13 13:58:09 +0000, olcott said:
On 10/13/2025 2:59 AM, Mikko wrote:
On 2025-10-12 14:36:27 +0000, olcott said:
On 10/12/2025 3:36 AM, Mikko wrote:
On 2025-10-11 13:03:55 +0000, olcott said:<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>> -a-a-a-a If simulating halt decider H correctly simulates its
Of course, non of the above is relevant to may comment that Professsor >>>>>>>> Sipser did not agreed to any scenario. He agreed to a conditional >>>>>>>> statemenet where the condition is a truth-bearer in every scenario. >>>>>>>
-a-a-a-a input D until H correctly determines that its simulated D >>>>>>> -a-a-a-a would never stop running unless aborted then
Thank you for the confirmation.
[Updated input to LLM systems proving HHH(DD)==0 within assumptions] >>>>>>> This is much easier for people to understand and has been validated >>>>>>> across four LLM systems. It specifies the same thing that Professor >>>>>>> Sipser agreed to in easier to understand words.
It seems that everyone who has been reading these discussions does >>>>>> understand or soon will that HHH(DD) returns 0 and that the correct >>>>>> value would be 1 because DD halts.
ChatGPT 5.0 is 67-fold smarter that ChatGPT was one year ago
because its context window grew from 3000 words to 200,000
words. When it is only providing the semantic logical entailment
from a set of premises then AI hallucination is impossible.
The claim that AI hallucination is impossible under those conditions
is not supported by any evidence and therefore is not credible.
When its entire basis of reasoning is provided
then it is not free to just make up any other
basis. Current AI has proven to be smart enough
to restrict its reasoning to within a set of
well defined premises. It even smart enough to
spot ambiguity and ask for clarification.
There is no way to control that an AI does not do what it is not "free"
to do. There is no way to ensure that all its reasoning is logically
valid. It is unlikely that it could be smart enough to spot all ambiguity. >> You can claim whatever you want but you don't support your above claims
with any evidence.
It is pretty easy to see that its reasoning is
semantically entailed by its inputs when these
inputs are very carefully crafted to leave no
ambiguity or semantics gaps.
This ambiguity and semantics gaps can be corrected on the fly
and it can keep track of the current state of the dialogue
brilliantly well.
Just last year it acted like it had Alzheimer's
when you exceeded it 3000 word limit. It now
has a 200,000 word limit yet must be told to
not guess on very important things.
On 2025-10-15 23:59:30 +0000, olcott said:
On 10/15/2025 3:15 AM, Mikko wrote:
On 2025-10-14 16:15:39 +0000, olcott said:
On 10/14/2025 4:27 AM, Mikko wrote:
On 2025-10-13 13:58:09 +0000, olcott said:
On 10/13/2025 2:59 AM, Mikko wrote:
On 2025-10-12 14:36:27 +0000, olcott said:
On 10/12/2025 3:36 AM, Mikko wrote:
On 2025-10-11 13:03:55 +0000, olcott said:
Of course, non of the above is relevant to may comment that >>>>>>>>> Professsor
Sipser did not agreed to any scenario. He agreed to a conditional >>>>>>>>> statemenet where the condition is a truth-bearer in every
scenario.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
-a-a-a-a If simulating halt decider H correctly simulates its
-a-a-a-a input D until H correctly determines that its simulated D >>>>>>>> -a-a-a-a would never stop running unless aborted then
Thank you for the confirmation.
[Updated input to LLM systems proving HHH(DD)==0 within
assumptions]
This is much easier for people to understand and has been validated >>>>>>>> across four LLM systems. It specifies the same thing that Professor >>>>>>>> Sipser agreed to in easier to understand words.
It seems that everyone who has been reading these discussions does >>>>>>> understand or soon will that HHH(DD) returns 0 and that the correct >>>>>>> value would be 1 because DD halts.
ChatGPT 5.0 is 67-fold smarter that ChatGPT was one year ago
because its context window grew from 3000 words to 200,000
words. When it is only providing the semantic logical entailment
from a set of premises then AI hallucination is impossible.
The claim that AI hallucination is impossible under those conditions >>>>> is not supported by any evidence and therefore is not credible.
When its entire basis of reasoning is provided
then it is not free to just make up any other
basis. Current AI has proven to be smart enough
to restrict its reasoning to within a set of
well defined premises. It even smart enough to
spot ambiguity and ask for clarification.
There is no way to control that an AI does not do what it is not "free"
to do. There is no way to ensure that all its reasoning is logically
valid. It is unlikely that it could be smart enough to spot all
ambiguity.
You can claim whatever you want but you don't support your above claims
with any evidence.
It is pretty easy to see that its reasoning is
semantically entailed by its inputs when these
inputs are very carefully crafted to leave no
ambiguity or semantics gaps.
It is possible to check its reasoning afterwards. When not, clarifying questions can be asked. But it is hard to be sure that the answer is sufficiently cheked.
But no checks ensure that the next answer does not do what an AI is
not "free" to do.
This ambiguity and semantics gaps can be corrected on the fly
and it can keep track of the current state of the dialogue
brilliantly well.
When they are detected. An LLM does not detect every ambiguity.
Just last year it acted like it had Alzheimer's
when you exceeded it 3000 word limit. It now
has a 200,000 word limit yet must be told to
not guess on very important things.
Even when told to not guess it may guess.