On 5/28/22 3:27 PM, olcott wrote:
> On 5/28/2022 2:21 PM, André G. Isaak wrote:
>> On 2022-05-28 12:52, olcott wrote:
>>> On 5/28/2022 1:38 PM, André G. Isaak wrote:
>>>> On 2022-05-28 12:26, olcott wrote:
>>>>> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>>>>>> On 2022-05-28 10:24, olcott wrote:
>>>>>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>>>>>
>>>>>>>> And since the computation that H(P,P) is deciding on *by
>>>>>>>> definition* is P(P), and the computation P(P) completes, H is
>>>>>>>> incorrect to abort and return 0.
>>>>>>>
>>>>>>> A halt decider must only compute the mapping of its input to an
>>>>>>> accept or reject state based on the actual behavior specified by
>>>>>>> this input.
>>>>>>
>>>>>> And what exactly is the above supposed to mean? You still haven't
>>>>>> provided a coherent definition of what you mean by 'specified'.
>>>>>> What does it mean for an input string to specify a behaviour?
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> In other words when I prove what I mean by "specified" 100 times
>>>>> the fact that you always make sure to ignore what I said is
>>>>> equivalent to me having never said anything about it.
>>>>
>>>> You can't "prove" what you mean by something. You define what
>>>> something is intended to mean. And so far you haven't provided a
>>>> definition for 'specify'. When asked you've either hurled insults or
>>>> given strange analogies involving milkshakes.
>>>>
>>>>> The behavior specified by an input is the execution trace derived
>>>>> by the correct x86 emulation of this input by its simulating halt
>>>>> decider.
>>>>
>>>> And how exactly do you define 'correct x86 emulation'?
>>>
>>> I have told you this many times. Why do you persistently ignore what
>>> I say and then claim that I said nothing?
>>
>> No, you have not. When asked in the past you've given vaguely worded
>> 'explanations' or unclear examples, but you've never provided anything
>> resembling a definition. A definition would take the form:
>>
>> A program S correctly emulates an input M, I if and only if ...
> *THIS IS THE CORRECT WAY TO ANALYZE IT*
> The sequence of instructions that program S emulates is the same
> sequence that the x86 machine language input M specifies when it is
> being emulated by S.
>
> *THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
> The sequence of instructions that program S emulates is the same
> sequence that the x86 machine language input M specifies when it is
> being emulated by R.
>
>

So CORRECTNESS is relative to the one doing it?

The ACTUAL correct answer the sequence of instructions that would occur
from a simulator that doesn't stop until the program ends. Yes, this
means that the correct simulation of a non-halting computation is
non-halting and generates an infinite sequence.

So, If S decided to stop after one step, its simulation would still be
correct?

That seems to be what you mean.

That means almost ALL programs can be correctly decided as "Non-Halting"
by a dumb enough.

That definition makes your definition of the halting problem incorrect,
as the Halting behavior of a Compuation is NOT a funciton of the decider
that is deciding it.

Thus you are not working on the halting problem but just your POOP.

On 5/28/2022 3:46 PM, André G. Isaak wrote:
> On 2022-05-28 13:58, olcott wrote:
>> On 5/28/2022 2:51 PM, André G. Isaak wrote:
>>> On 2022-05-28 13:27, olcott wrote:
>>>> On 5/28/2022 2:21 PM, André G. Isaak wrote:
>>>>> On 2022-05-28 12:52, olcott wrote:
>>>>>> On 5/28/2022 1:38 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-28 12:26, olcott wrote:
>>>>>>>> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-28 10:24, olcott wrote:
>>>>>>>>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>>>>>>>>
>>>>>>>>>>> And since the computation that H(P,P) is deciding on *by
>>>>>>>>>>> definition* is P(P), and the computation P(P) completes, H is
>>>>>>>>>>> incorrect to abort and return 0.
>>>>>>>>>>
>>>>>>>>>> A halt decider must only compute the mapping of its input to
>>>>>>>>>> an accept or reject state based on the actual behavior
>>>>>>>>>> specified by this input.
>>>>>>>>>
>>>>>>>>> And what exactly is the above supposed to mean? You still
>>>>>>>>> haven't provided a coherent definition of what you mean by
>>>>>>>>> 'specified'. What does it mean for an input string to specify a
>>>>>>>>> behaviour?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> In other words when I prove what I mean by "specified" 100 times
>>>>>>>> the fact that you always make sure to ignore what I said is
>>>>>>>> equivalent to me having never said anything about it.
>>>>>>>
>>>>>>> You can't "prove" what you mean by something. You define what
>>>>>>> something is intended to mean. And so far you haven't provided a
>>>>>>> definition for 'specify'. When asked you've either hurled insults
>>>>>>> or given strange analogies involving milkshakes.
>>>>>>>
>>>>>>>> The behavior specified by an input is the execution trace
>>>>>>>> derived by the correct x86 emulation of this input by its
>>>>>>>> simulating halt decider.
>>>>>>>
>>>>>>> And how exactly do you define 'correct x86 emulation'?
>>>>>>
>>>>>> I have told you this many times. Why do you persistently ignore
>>>>>> what I say and then claim that I said nothing?
>>>>>
>>>>> No, you have not. When asked in the past you've given vaguely
>>>>> worded 'explanations' or unclear examples, but you've never
>>>>> provided anything resembling a definition. A definition would take
>>>>> the form:
>>>>>
>>>>> A program S correctly emulates an input M, I if and only if ...
>>>> *THIS IS THE CORRECT WAY TO ANALYZE IT*
>>>> The sequence of instructions that program S emulates is the same
>>>> sequence that the x86 machine language input M specifies when it is
>>>> being emulated by S.
>>>>
>>>> *THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
>>>> The sequence of instructions that program S emulates is the same
>>>> sequence that the x86 machine language input M specifies when it is
>>>> being emulated by R.
>>>
>>> And again you fail to provide a definition but just give examples
>>> which do nothing to increase clarity. The above might be clearer if
>>> you had actually answered my other question, the one which you
>>> dishonestly snipped which I repeat below:
>>>
>>> How does one determine what behaviour the above code specifies if not
>>> by assembling it, running it independently and observing its behaviour?
>>>
>>
>> When one is using an independent computation as the measure of the
>> behavior of a dependent computation one is objectively incorrect.
>
> And, as usual, you entirely fail to address my question. You claim that
> the input string somehow "specifies" behaviour. How do we determine what
> behaviour it specifies?

I have already fully addressed this. That you refuse to acknowledge that
I have already fully addressed this cannot be reasonably construed as
anything besides dishonesty on your part.

Now I will put the burden on you.

When H(P,P) correctly emulates its input what are the first seven
instructions that H would emulate?

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/28/22 3:58 PM, olcott wrote:
> On 5/28/2022 2:51 PM, André G. Isaak wrote:
>> On 2022-05-28 13:27, olcott wrote:
>>> On 5/28/2022 2:21 PM, André G. Isaak wrote:
>>>> On 2022-05-28 12:52, olcott wrote:
>>>>> On 5/28/2022 1:38 PM, André G. Isaak wrote:
>>>>>> On 2022-05-28 12:26, olcott wrote:
>>>>>>> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-28 10:24, olcott wrote:
>>>>>>>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>>>>>>>
>>>>>>>>>> And since the computation that H(P,P) is deciding on *by
>>>>>>>>>> definition* is P(P), and the computation P(P) completes, H is
>>>>>>>>>> incorrect to abort and return 0.
>>>>>>>>>
>>>>>>>>> A halt decider must only compute the mapping of its input to an
>>>>>>>>> accept or reject state based on the actual behavior specified
>>>>>>>>> by this input.
>>>>>>>>
>>>>>>>> And what exactly is the above supposed to mean? You still
>>>>>>>> haven't provided a coherent definition of what you mean by
>>>>>>>> 'specified'. What does it mean for an input string to specify a
>>>>>>>> behaviour?
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> In other words when I prove what I mean by "specified" 100 times
>>>>>>> the fact that you always make sure to ignore what I said is
>>>>>>> equivalent to me having never said anything about it.
>>>>>>
>>>>>> You can't "prove" what you mean by something. You define what
>>>>>> something is intended to mean. And so far you haven't provided a
>>>>>> definition for 'specify'. When asked you've either hurled insults
>>>>>> or given strange analogies involving milkshakes.
>>>>>>
>>>>>>> The behavior specified by an input is the execution trace derived
>>>>>>> by the correct x86 emulation of this input by its simulating halt
>>>>>>> decider.
>>>>>>
>>>>>> And how exactly do you define 'correct x86 emulation'?
>>>>>
>>>>> I have told you this many times. Why do you persistently ignore
>>>>> what I say and then claim that I said nothing?
>>>>
>>>> No, you have not. When asked in the past you've given vaguely worded
>>>> 'explanations' or unclear examples, but you've never provided
>>>> anything resembling a definition. A definition would take the form:
>>>>
>>>> A program S correctly emulates an input M, I if and only if ...
>>> *THIS IS THE CORRECT WAY TO ANALYZE IT*
>>> The sequence of instructions that program S emulates is the same
>>> sequence that the x86 machine language input M specifies when it is
>>> being emulated by S.
>>>
>>> *THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
>>> The sequence of instructions that program S emulates is the same
>>> sequence that the x86 machine language input M specifies when it is
>>> being emulated by R.
>>
>> And again you fail to provide a definition but just give examples
>> which do nothing to increase clarity. The above might be clearer if
>> you had actually answered my other question, the one which you
>> dishonestly snipped which I repeat below:
>>
>> How does one determine what behaviour the above code specifies if not
>> by assembling it, running it independently and observing its behaviour?
>>
>
> When one is using an independent computation as the measure of the
> behavior of a dependent computation one is objectively incorrect.

What is "dependent".

H has to have been previously defined. That is the definition.

THus P is defined, and we are only testing to see if H gives the right
answer. P is LOCKED into the definition of H that was proposed as being
a correct decider.

You seem to have some idea that computations can adapt themselves to
their input, they don't they just follow their programming.

There is no "Dependent Variable" like in calculus, as we don't have
anything changing.

>
> The behavior of the correct x86 emulation of the input to H(P,P) by H is
> this behavior:
>
> // H emulates the first seven instructions of P
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

And it goes wrong right here.

Call H needs to be followed by the trace of the copy of H tht P is
calling, That even matches you definition, as that is what the actual
x86 processor would do.

>
> // The emulated H emulates the first seven instructions of P
> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>
>
>
>

On 2022-05-28 14:56, olcott wrote:
> On 5/28/2022 3:46 PM, André G. Isaak wrote:
>> On 2022-05-28 13:58, olcott wrote:
>>> On 5/28/2022 2:51 PM, André G. Isaak wrote:
>>>> On 2022-05-28 13:27, olcott wrote:
>>>>> On 5/28/2022 2:21 PM, André G. Isaak wrote:
>>>>>> On 2022-05-28 12:52, olcott wrote:
>>>>>>> On 5/28/2022 1:38 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-28 12:26, olcott wrote:
>>>>>>>>> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-28 10:24, olcott wrote:
>>>>>>>>>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>>>>>>>>>
>>>>>>>>>>>> And since the computation that H(P,P) is deciding on *by
>>>>>>>>>>>> definition* is P(P), and the computation P(P) completes, H
>>>>>>>>>>>> is incorrect to abort and return 0.
>>>>>>>>>>>
>>>>>>>>>>> A halt decider must only compute the mapping of its input to
>>>>>>>>>>> an accept or reject state based on the actual behavior
>>>>>>>>>>> specified by this input.
>>>>>>>>>>
>>>>>>>>>> And what exactly is the above supposed to mean? You still
>>>>>>>>>> haven't provided a coherent definition of what you mean by
>>>>>>>>>> 'specified'. What does it mean for an input string to specify
>>>>>>>>>> a behaviour?
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In other words when I prove what I mean by "specified" 100
>>>>>>>>> times the fact that you always make sure to ignore what I said
>>>>>>>>> is equivalent to me having never said anything about it.
>>>>>>>>
>>>>>>>> You can't "prove" what you mean by something. You define what
>>>>>>>> something is intended to mean. And so far you haven't provided a
>>>>>>>> definition for 'specify'. When asked you've either hurled
>>>>>>>> insults or given strange analogies involving milkshakes.
>>>>>>>>
>>>>>>>>> The behavior specified by an input is the execution trace
>>>>>>>>> derived by the correct x86 emulation of this input by its
>>>>>>>>> simulating halt decider.
>>>>>>>>
>>>>>>>> And how exactly do you define 'correct x86 emulation'?
>>>>>>>
>>>>>>> I have told you this many times. Why do you persistently ignore
>>>>>>> what I say and then claim that I said nothing?
>>>>>>
>>>>>> No, you have not. When asked in the past you've given vaguely
>>>>>> worded 'explanations' or unclear examples, but you've never
>>>>>> provided anything resembling a definition. A definition would take
>>>>>> the form:
>>>>>>
>>>>>> A program S correctly emulates an input M, I if and only if ...
>>>>> *THIS IS THE CORRECT WAY TO ANALYZE IT*
>>>>> The sequence of instructions that program S emulates is the same
>>>>> sequence that the x86 machine language input M specifies when it is
>>>>> being emulated by S.
>>>>>
>>>>> *THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
>>>>> The sequence of instructions that program S emulates is the same
>>>>> sequence that the x86 machine language input M specifies when it is
>>>>> being emulated by R.
>>>>
>>>> And again you fail to provide a definition but just give examples
>>>> which do nothing to increase clarity. The above might be clearer if
>>>> you had actually answered my other question, the one which you
>>>> dishonestly snipped which I repeat below:
>>>>
>>>> How does one determine what behaviour the above code specifies if
>>>> not by assembling it, running it independently and observing its
>>>> behaviour?
>>>>
>>>
>>> When one is using an independent computation as the measure of the
>>> behavior of a dependent computation one is objectively incorrect.
>>
>> And, as usual, you entirely fail to address my question. You claim
>> that the input string somehow "specifies" behaviour. How do we
>> determine what behaviour it specifies?
>
>
> I have already fully addressed this. That you refuse to acknowledge that
> I have already fully addressed this cannot be reasonably construed as
> anything besides dishonesty on your part.

No, you have not. Not coherently. I really do not believe you actually
understand what 'definition' means.

> Now I will put the burden on you.
>
> When H(P,P) correctly emulates its input what are the first seven
> instructions that H would emulate?

That is trivial. What is less clear is what the *eighth* instruction
emulated should be given you've never revealed which instruction lives
as 0x000011A2.

André

> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
>

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 5/28/2022 4:23 PM, André G. Isaak wrote:
> On 2022-05-28 14:56, olcott wrote:
>> On 5/28/2022 3:46 PM, André G. Isaak wrote:
>>> On 2022-05-28 13:58, olcott wrote:
>>>> On 5/28/2022 2:51 PM, André G. Isaak wrote:
>>>>> On 2022-05-28 13:27, olcott wrote:
>>>>>> On 5/28/2022 2:21 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-28 12:52, olcott wrote:
>>>>>>>> On 5/28/2022 1:38 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-28 12:26, olcott wrote:
>>>>>>>>>> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-28 10:24, olcott wrote:
>>>>>>>>>>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> And since the computation that H(P,P) is deciding on *by
>>>>>>>>>>>>> definition* is P(P), and the computation P(P) completes, H
>>>>>>>>>>>>> is incorrect to abort and return 0.
>>>>>>>>>>>>
>>>>>>>>>>>> A halt decider must only compute the mapping of its input to
>>>>>>>>>>>> an accept or reject state based on the actual behavior
>>>>>>>>>>>> specified by this input.
>>>>>>>>>>>
>>>>>>>>>>> And what exactly is the above supposed to mean? You still
>>>>>>>>>>> haven't provided a coherent definition of what you mean by
>>>>>>>>>>> 'specified'. What does it mean for an input string to specify
>>>>>>>>>>> a behaviour?
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In other words when I prove what I mean by "specified" 100
>>>>>>>>>> times the fact that you always make sure to ignore what I said
>>>>>>>>>> is equivalent to me having never said anything about it.
>>>>>>>>>
>>>>>>>>> You can't "prove" what you mean by something. You define what
>>>>>>>>> something is intended to mean. And so far you haven't provided
>>>>>>>>> a definition for 'specify'. When asked you've either hurled
>>>>>>>>> insults or given strange analogies involving milkshakes.
>>>>>>>>>
>>>>>>>>>> The behavior specified by an input is the execution trace
>>>>>>>>>> derived by the correct x86 emulation of this input by its
>>>>>>>>>> simulating halt decider.
>>>>>>>>>
>>>>>>>>> And how exactly do you define 'correct x86 emulation'?
>>>>>>>>
>>>>>>>> I have told you this many times. Why do you persistently ignore
>>>>>>>> what I say and then claim that I said nothing?
>>>>>>>
>>>>>>> No, you have not. When asked in the past you've given vaguely
>>>>>>> worded 'explanations' or unclear examples, but you've never
>>>>>>> provided anything resembling a definition. A definition would
>>>>>>> take the form:
>>>>>>>
>>>>>>> A program S correctly emulates an input M, I if and only if ...
>>>>>> *THIS IS THE CORRECT WAY TO ANALYZE IT*
>>>>>> The sequence of instructions that program S emulates is the same
>>>>>> sequence that the x86 machine language input M specifies when it
>>>>>> is being emulated by S.
>>>>>>
>>>>>> *THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
>>>>>> The sequence of instructions that program S emulates is the same
>>>>>> sequence that the x86 machine language input M specifies when it
>>>>>> is being emulated by R.
>>>>>
>>>>> And again you fail to provide a definition but just give examples
>>>>> which do nothing to increase clarity. The above might be clearer if
>>>>> you had actually answered my other question, the one which you
>>>>> dishonestly snipped which I repeat below:
>>>>>
>>>>> How does one determine what behaviour the above code specifies if
>>>>> not by assembling it, running it independently and observing its
>>>>> behaviour?
>>>>>
>>>>
>>>> When one is using an independent computation as the measure of the
>>>> behavior of a dependent computation one is objectively incorrect.
>>>
>>> And, as usual, you entirely fail to address my question. You claim
>>> that the input string somehow "specifies" behaviour. How do we
>>> determine what behaviour it specifies?
>>
>>
>> I have already fully addressed this. That you refuse to acknowledge
>> that I have already fully addressed this cannot be reasonably
>> construed as anything besides dishonesty on your part.
>
> No, you have not. Not coherently. I really do not believe you actually
> understand what 'definition' means.
>
>> Now I will put the burden on you.
>>
>> When H(P,P) correctly emulates its input what are the first seven
>> instructions that H would emulate?
>
> That is trivial. What is less clear is what the *eighth* instruction
> emulated should be given you've never revealed which instruction lives
> as 0x000011A2.

>> [0000135d](05) e840feffff call 000011a2 // call H
I never said this? // call H
I never said this? // call H
I never said this? // call H
I never said this? // call H
I never said this? // call H

>
> André
>
>> _P()
>> [00001352](01)  55              push ebp
>> [00001353](02)  8bec            mov ebp,esp
>> [00001355](03)  8b4508          mov eax,[ebp+08]
>> [00001358](01)  50              push eax      // push P
>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>> [0000135c](01)  51              push ecx      // push P
>> [0000135d](05)  e840feffff      call 000011a2 // call H
>> [00001362](03)  83c408          add esp,+08
>> [00001365](02)  85c0            test eax,eax
>> [00001367](02)  7402            jz 0000136b
>> [00001369](02)  ebfe            jmp 00001369
>> [0000136b](01)  5d              pop ebp
>> [0000136c](01)  c3              ret
>> Size in bytes:(0027) [0000136c]
>>
>>
>
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/28/22 5:33 PM, olcott wrote:
> On 5/28/2022 4:23 PM, André G. Isaak wrote:
>> On 2022-05-28 14:56, olcott wrote:
>>> On 5/28/2022 3:46 PM, André G. Isaak wrote:
>>>> On 2022-05-28 13:58, olcott wrote:
>>>>> On 5/28/2022 2:51 PM, André G. Isaak wrote:
>>>>>> On 2022-05-28 13:27, olcott wrote:
>>>>>>> On 5/28/2022 2:21 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-28 12:52, olcott wrote:
>>>>>>>>> On 5/28/2022 1:38 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-28 12:26, olcott wrote:
>>>>>>>>>>> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-28 10:24, olcott wrote:
>>>>>>>>>>>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> And since the computation that H(P,P) is deciding on *by
>>>>>>>>>>>>>> definition* is P(P), and the computation P(P) completes, H
>>>>>>>>>>>>>> is incorrect to abort and return 0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A halt decider must only compute the mapping of its input
>>>>>>>>>>>>> to an accept or reject state based on the actual behavior
>>>>>>>>>>>>> specified by this input.
>>>>>>>>>>>>
>>>>>>>>>>>> And what exactly is the above supposed to mean? You still
>>>>>>>>>>>> haven't provided a coherent definition of what you mean by
>>>>>>>>>>>> 'specified'. What does it mean for an input string to
>>>>>>>>>>>> specify a behaviour?
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In other words when I prove what I mean by "specified" 100
>>>>>>>>>>> times the fact that you always make sure to ignore what I
>>>>>>>>>>> said is equivalent to me having never said anything about it.
>>>>>>>>>>
>>>>>>>>>> You can't "prove" what you mean by something. You define what
>>>>>>>>>> something is intended to mean. And so far you haven't provided
>>>>>>>>>> a definition for 'specify'. When asked you've either hurled
>>>>>>>>>> insults or given strange analogies involving milkshakes.
>>>>>>>>>>
>>>>>>>>>>> The behavior specified by an input is the execution trace
>>>>>>>>>>> derived by the correct x86 emulation of this input by its
>>>>>>>>>>> simulating halt decider.
>>>>>>>>>>
>>>>>>>>>> And how exactly do you define 'correct x86 emulation'?
>>>>>>>>>
>>>>>>>>> I have told you this many times. Why do you persistently ignore
>>>>>>>>> what I say and then claim that I said nothing?
>>>>>>>>
>>>>>>>> No, you have not. When asked in the past you've given vaguely
>>>>>>>> worded 'explanations' or unclear examples, but you've never
>>>>>>>> provided anything resembling a definition. A definition would
>>>>>>>> take the form:
>>>>>>>>
>>>>>>>> A program S correctly emulates an input M, I if and only if ...
>>>>>>> *THIS IS THE CORRECT WAY TO ANALYZE IT*
>>>>>>> The sequence of instructions that program S emulates is the same
>>>>>>> sequence that the x86 machine language input M specifies when it
>>>>>>> is being emulated by S.
>>>>>>>
>>>>>>> *THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
>>>>>>> The sequence of instructions that program S emulates is the same
>>>>>>> sequence that the x86 machine language input M specifies when it
>>>>>>> is being emulated by R.
>>>>>>
>>>>>> And again you fail to provide a definition but just give examples
>>>>>> which do nothing to increase clarity. The above might be clearer
>>>>>> if you had actually answered my other question, the one which you
>>>>>> dishonestly snipped which I repeat below:
>>>>>>
>>>>>> How does one determine what behaviour the above code specifies if
>>>>>> not by assembling it, running it independently and observing its
>>>>>> behaviour?
>>>>>>
>>>>>
>>>>> When one is using an independent computation as the measure of the
>>>>> behavior of a dependent computation one is objectively incorrect.
>>>>
>>>> And, as usual, you entirely fail to address my question. You claim
>>>> that the input string somehow "specifies" behaviour. How do we
>>>> determine what behaviour it specifies?
>>>
>>>
>>> I have already fully addressed this. That you refuse to acknowledge
>>> that I have already fully addressed this cannot be reasonably
>>> construed as anything besides dishonesty on your part.
>>
>> No, you have not. Not coherently. I really do not believe you actually
>> understand what 'definition' means.
>>
>>> Now I will put the burden on you.
>>>
>>> When H(P,P) correctly emulates its input what are the first seven
>>> instructions that H would emulate?
>>
>> That is trivial. What is less clear is what the *eighth* instruction
>> emulated should be given you've never revealed which instruction lives
>> as 0x000011A2.
>
>
>
> >> [0000135d](05)  e840feffff      call 000011a2 // call H
> I never said this?  // call H
> I never said this?  // call H
> I never said this?  // call H
> I never said this?  // call H
> I never said this?  // call H

You have said it was a call H (but the finite string byte code actually
doesn't indicate that.

What you haven't done is actually define the byte codes in H, so it is
impossible to say what the 8th properly simulated instruction would be,
since it would be the instruction at location 000011a2

Note, your "definite" of correct simulation doesn't have anything about
the emulators being able to skip some of the instructions they emulate.
(since the x86 processor wouldn't do that).

So by skipping that instruction, your H fails to meet even YOUR
definition of correct emulation.

And if you make it so that is ok, the all computations can be correctly
decided as non-halting and you thus break the usefulness of the Halting
Property.

FAIL.

>
>
>
>>
>> André
>>
>>> _P()
>>> [00001352](01)  55              push ebp
>>> [00001353](02)  8bec            mov ebp,esp
>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>> [00001358](01)  50              push eax      // push P
>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000135c](01)  51              push ecx      // push P
>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> [00001362](03)  83c408          add esp,+08
>>> [00001365](02)  85c0            test eax,eax
>>> [00001367](02)  7402            jz 0000136b
>>> [00001369](02)  ebfe            jmp 00001369
>>> [0000136b](01)  5d              pop ebp
>>> [0000136c](01)  c3              ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>>
>>
>>
>
>

On 2022-05-28 15:33, olcott wrote:
> On 5/28/2022 4:23 PM, André G. Isaak wrote:
>> On 2022-05-28 14:56, olcott wrote:

>>> When H(P,P) correctly emulates its input what are the first seven
>>> instructions that H would emulate?
>>
>> That is trivial. What is less clear is what the *eighth* instruction
>> emulated should be given you've never revealed which instruction lives
>> as 0x000011A2.
>
>
>
> >> [0000135d](05)  e840feffff      call 000011a2 // call H
> I never said this?  // call H

Call H is the seventh instruction. I asked what the EIGHTH instruction is.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 5/28/2022 5:06 PM, André G. Isaak wrote:
> On 2022-05-28 15:33, olcott wrote:
>> On 5/28/2022 4:23 PM, André G. Isaak wrote:
>>> On 2022-05-28 14:56, olcott wrote:
>
>>>> When H(P,P) correctly emulates its input what are the first seven
>>>> instructions that H would emulate?
>>>
>>> That is trivial. What is less clear is what the *eighth* instruction
>>> emulated should be given you've never revealed which instruction
>>> lives as 0x000011A2.
>>
>>
>>
>>  >> [0000135d](05)  e840feffff      call 000011a2 // call H
>> I never said this?  // call H
>
> Call H is the seventh instruction. I asked what the EIGHTH instruction is.
>
> André
>
>

236 pages of H(P,P) correctly emulating its input.

Because we know that the invocation of H(P,P) derives the exact same
first seven instructions of P every time that it is invoked we know that
the emulated P never reaches its "ret" instruction.

The 236 pages of H emulating P adds nothing to this correct analysis.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/28/22 6:38 PM, olcott wrote:
> On 5/28/2022 5:06 PM, André G. Isaak wrote:
>> On 2022-05-28 15:33, olcott wrote:
>>> On 5/28/2022 4:23 PM, André G. Isaak wrote:
>>>> On 2022-05-28 14:56, olcott wrote:
>>
>>>>> When H(P,P) correctly emulates its input what are the first seven
>>>>> instructions that H would emulate?
>>>>
>>>> That is trivial. What is less clear is what the *eighth* instruction
>>>> emulated should be given you've never revealed which instruction
>>>> lives as 0x000011A2.
>>>
>>>
>>>
>>>  >> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> I never said this?  // call H
>>
>> Call H is the seventh instruction. I asked what the EIGHTH instruction
>> is.
>>
>> André
>>
>>
>
> 236 pages of H(P,P) correctly emulating its input.
>
> Because we know that the invocation of H(P,P) derives the exact same
> first seven instructions of P every time that it is invoked we know that
> the emulated P never reaches its "ret" instruction.
>
> The 236 pages of H emulating P adds nothing to this correct analysis.
>
>

We may be able to deduce that H can never simulate its input to reach
the ret instruction, but that does NOT say that H is correct in saying 0
for the HALTING PROBLEM.

The issue here is that the Halting Problem doesn't ask if H can simulate
its input to the Halting State, it asks if the input represents a
Halting Computaiton, which means what an actual correct simulation, but
an actual UTM would do.

Since you seem to be changing this definition, your H just isn't a Hald
Decider, and thus it isn't surprizing that the answer it gets isn't the
correct answer for the Halting Problem.

It also means that it doesn't refute the proof at all, since it isn't
the H described in the proof.

So, you FAIL.

On 27/05/2022 22:32, Richard Damon wrote:
> On 5/27/22 5:21 PM, André G. Isaak wrote:
>> On 2022-05-27 14:38, olcott wrote:
>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>> On 2022-05-27 13:41, olcott wrote:
>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>
>>>>>>>> The input to H is NOT a "sequence of configuratios", but the representation of an algorithm
>>>>>>>> and its input.
>>>>>>>
>>>>>>> The finite string inputs to a halt decider specify (rather then merely represent) a sequence
>>>>>>> of configurations that may or may not reach their own final state.
>>>>>>
>>>>>> I really don't think you have any idea what terms like 'represent', 'specify', or 'sequence of
>>>>>> configurations' mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>
>>>>>
>>>>> The distinction that I make between represent and specify is that the x86 source-code for P
>>>>> represents P(P) whereas the actual correct x86 emulation of the input to H(P,P) specifies the
>>>>> actual behavior of this input. This is not the same behavior as the behavior specified by P(P).
>>>>>
>>>>> A sequence of configurations means a list of x86 program steps executed or emulated in the
>>>>> order that their source-code specifies.
>>>>>
>>>>> Likewise with a TM or the UTM simulation of a TM description specifies a sequence of state
>>>>> transitions.
>>>>
>>>> And this decidedly is *not* what a halt decider is given as its input. It is not given a
>>>> sequence of state transitions. It is given a representation of a computation.
>>>>
>>>
>>> No it is not and you know that it is not. A halt decider is given a finite string TM description
>>> that specifies a sequence of configurations.
>>
>> A TM description and a sequence of configurations are entirely different things (and the former
>> certainly does not 'specify' the latter). It's given either one or the other. Make up your mind.
>>
>> André
>>
>
> Well, a TM description, and a description of an input to that TM, does specify a "sequence of
> configurations" based on what running that TM on that input would do.

"Specify" is not the word I'd use. (If I write a shopping list I specify what I'm going to get when
I go shopping: one loaf of bread and 4oz jar of strawberry jam. I don't write various clues which
can together be used to generate what I want by applying some algorithm.)

For your scenario, "determine" seems accurate. But PO also says that P(P) "specifies non-halting
behaviour", and that computation halts. I think that this use just means "matches PO's abort test".

>
> The sequence of configurations may be finite (if the TM would halt on that input) or it might be
> infinite (if the TM would not halt on that input), but ANY TM description + an input generates such
> an output.

Just to add more room for misunderstanding, I believe Linz actually defines "computation" as meaning
your sequence of configurations, while some define it as the combination (P,I) (which together
determine Linz's calculation...). Now, anyone for "...on the basis of.."?

Mike.

On 5/28/2022 7:22 PM, Mike Terry wrote:
> On 27/05/2022 22:32, Richard Damon wrote:
>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>> On 2022-05-27 14:38, olcott wrote:
>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>
>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>
>>>>>>>> The finite string inputs to a halt decider specify (rather then
>>>>>>>> merely represent) a sequence of configurations that may or may
>>>>>>>> not reach their own final state.
>>>>>>>
>>>>>>> I really don't think you have any idea what terms like
>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>
>>>>>>
>>>>>> The distinction that I make between represent and specify is that
>>>>>> the x86 source-code for P represents P(P) whereas the actual
>>>>>> correct x86 emulation of the input to H(P,P) specifies the actual
>>>>>> behavior of this input. This is not the same behavior as the
>>>>>> behavior specified by P(P).
>>>>>>
>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>> executed or emulated in the order that their source-code specifies.
>>>>>>
>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>> specifies a sequence of state transitions.
>>>>>
>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>> input. It is not given a sequence of state transitions. It is given
>>>>> a representation of a computation.
>>>>>
>>>>
>>>> No it is not and you know that it is not. A halt decider is given a
>>>> finite string TM description that specifies a sequence of
>>>> configurations.
>>>
>>> A TM description and a sequence of configurations are entirely
>>> different things (and the former certainly does not 'specify' the
>>> latter). It's given either one or the other. Make up your mind.
>>>
>>> André
>>>
>>
>> Well, a TM description, and a description of an input to that TM, does
>> specify a "sequence of configurations" based on what running that TM
>> on that input would do.
>
> "Specify" is not the word I'd use.  (If I write a shopping list I
> specify what I'm going to get when I go shopping: one loaf of bread and
> 4oz jar of strawberry jam.  I don't write various clues which can
> together be used to generate what I want by applying some algorithm.)
>
> For your scenario, "determine" seems accurate.  But PO also says that
> P(P) "specifies non-halting behaviour", and that computation halts.  I
> think that this use just means "matches PO's abort test".
>

I never said that: "P(P) specifies non-halting behaviour".
Your term "determine" is better than my term "specify".

The input to H(P,P) determines the sequence of x86 instructions of the
correct x86 emulation of P by H. This sequence never reaches the "ret"
instruction of P.

The input to H1(P,P) determines the sequence of x86 instructions of the
correct x86 emulation of P by H1. This sequence reaches the "ret"
instruction of P and halts.

This latter sequence of x86 instructions of P is identical to the
sequence specified by P(P).

>>
>> The sequence of configurations may be finite (if the TM would halt on
>> that input) or it might be infinite (if the TM would not halt on that
>> input), but ANY TM description + an input generates such an output.
>
> Just to add more room for misunderstanding, I believe Linz actually
> defines "computation" as meaning your sequence of configurations, while
> some define it as the combination (P,I) (which together determine Linz's
> calculation...).  Now, anyone for "...on the basis of.."?
>
> Mike.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/28/22 10:43 PM, olcott wrote:
> On 5/28/2022 7:22 PM, Mike Terry wrote:
>> On 27/05/2022 22:32, Richard Damon wrote:
>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>> On 2022-05-27 14:38, olcott wrote:
>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>
>>>>>>>>> The finite string inputs to a halt decider specify (rather then
>>>>>>>>> merely represent) a sequence of configurations that may or may
>>>>>>>>> not reach their own final state.
>>>>>>>>
>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>
>>>>>>>
>>>>>>> The distinction that I make between represent and specify is that
>>>>>>> the x86 source-code for P represents P(P) whereas the actual
>>>>>>> correct x86 emulation of the input to H(P,P) specifies the actual
>>>>>>> behavior of this input. This is not the same behavior as the
>>>>>>> behavior specified by P(P).
>>>>>>>
>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>> executed or emulated in the order that their source-code specifies.
>>>>>>>
>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>> specifies a sequence of state transitions.
>>>>>>
>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>> given a representation of a computation.
>>>>>>
>>>>>
>>>>> No it is not and you know that it is not. A halt decider is given a
>>>>> finite string TM description that specifies a sequence of
>>>>> configurations.
>>>>
>>>> A TM description and a sequence of configurations are entirely
>>>> different things (and the former certainly does not 'specify' the
>>>> latter). It's given either one or the other. Make up your mind.
>>>>
>>>> André
>>>>
>>>
>>> Well, a TM description, and a description of an input to that TM,
>>> does specify a "sequence of configurations" based on what running
>>> that TM on that input would do.
>>
>> "Specify" is not the word I'd use.  (If I write a shopping list I
>> specify what I'm going to get when I go shopping: one loaf of bread
>> and 4oz jar of strawberry jam.  I don't write various clues which can
>> together be used to generate what I want by applying some algorithm.)
>>
>> For your scenario, "determine" seems accurate.  But PO also says that
>> P(P) "specifies non-halting behaviour", and that computation halts.  I
>> think that this use just means "matches PO's abort test".
>>
>
> I never said that: "P(P) specifies non-halting behaviour".
> Your term "determine" is better than my term "specify".

But that is what a Halt Decider saying its input represents a
Non-Halting Computaiton IS saying. If that is not what H is saying, it
isn't a Halt DEcider.

>
> The input to H(P,P) determines the sequence of x86 instructions of the
> correct x86 emulation of P by H. This sequence never reaches the "ret"
> instruction of P.

How is it a "Correct Emulation" if it doesn't match the behavior of the
thing it is emulating?

Note, the ONLY reason H doesn't reach the ret instruction is because H
stopped to soon.

Remember, if you change THIS copy of H into a different program that
simulates longer, it will see the simulation reach the end. This is
because H^/P doesn't use "self-refenceing" to refer to the decider
deciding it, it uses a copy of the Halt Decider that it is designed to foil.

In fact, they way you are showing your programs being built actually
shows that H and P are not correctly defined as independent
computations. Your design error is what makes an actual self-referential
system. My guess is you are doing it this way because the right way is
too complicated for you to understand with the input being in a virtual
address range independent of the decider (it also breaks you method of
detecting the 'recursion').

>
> The input to H1(P,P) determines the sequence of x86 instructions of the
> correct x86 emulation of P by H1. This sequence reaches the "ret"
> instruction of P and halts.

Rignt, because it doesn't stop to soon.

The input is the same, so the "Correct Simulation" of that input is the
same.

>
> This latter sequence of x86 instructions of P is identical to the
> sequence specified by P(P).

As is required by the term "Correct Simulation"

>
>>>
>>> The sequence of configurations may be finite (if the TM would halt on
>>> that input) or it might be infinite (if the TM would not halt on that
>>> input), but ANY TM description + an input generates such an output.
>>
>> Just to add more room for misunderstanding, I believe Linz actually
>> defines "computation" as meaning your sequence of configurations,
>> while some define it as the combination (P,I) (which together
>> determine Linz's calculation...).  Now, anyone for "...on the basis
>> of.."?
>>
>> Mike.
>
>

On Sunday, 29 May 2022 at 03:43:14 UTC+1, olcott wrote:
> On 5/28/2022 7:22 PM, Mike Terry wrote:
> > On 27/05/2022 22:32, Richard Damon wrote:
> >> On 5/27/22 5:21 PM, André G. Isaak wrote:
> >>> On 2022-05-27 14:38, olcott wrote:
> >>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
> >>>>> On 2022-05-27 13:41, olcott wrote:
> >>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
> >>>>>>> On 2022-05-27 13:01, olcott wrote:
> >>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
> >>>>>>>
> >>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
> >>>>>>>>> representation of an algorithm and its input.
> >>>>>>>>
> >>>>>>>> The finite string inputs to a halt decider specify (rather then
> >>>>>>>> merely represent) a sequence of configurations that may or may
> >>>>>>>> not reach their own final state.
> >>>>>>>
> >>>>>>> I really don't think you have any idea what terms like
> >>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
> >>>>>>> Richard is perfectly correct. You, as usual, are not.
> >>>>>>>
> >>>>>>
> >>>>>> The distinction that I make between represent and specify is that
> >>>>>> the x86 source-code for P represents P(P) whereas the actual
> >>>>>> correct x86 emulation of the input to H(P,P) specifies the actual
> >>>>>> behavior of this input. This is not the same behavior as the
> >>>>>> behavior specified by P(P).
> >>>>>>
> >>>>>> A sequence of configurations means a list of x86 program steps
> >>>>>> executed or emulated in the order that their source-code specifies..
> >>>>>>
> >>>>>> Likewise with a TM or the UTM simulation of a TM description
> >>>>>> specifies a sequence of state transitions.
> >>>>>
> >>>>> And this decidedly is *not* what a halt decider is given as its
> >>>>> input. It is not given a sequence of state transitions. It is given
> >>>>> a representation of a computation.
> >>>>>
> >>>>
> >>>> No it is not and you know that it is not. A halt decider is given a
> >>>> finite string TM description that specifies a sequence of
> >>>> configurations.
> >>>
> >>> A TM description and a sequence of configurations are entirely
> >>> different things (and the former certainly does not 'specify' the
> >>> latter). It's given either one or the other. Make up your mind.
> >>>
> >>> André
> >>>
> >>
> >> Well, a TM description, and a description of an input to that TM, does
> >> specify a "sequence of configurations" based on what running that TM
> >> on that input would do.
> >
> > "Specify" is not the word I'd use. (If I write a shopping list I
> > specify what I'm going to get when I go shopping: one loaf of bread and
> > 4oz jar of strawberry jam. I don't write various clues which can
> > together be used to generate what I want by applying some algorithm.)
> >
> > For your scenario, "determine" seems accurate. But PO also says that
> > P(P) "specifies non-halting behaviour", and that computation halts. I
> > think that this use just means "matches PO's abort test".
> >
> I never said that: "P(P) specifies non-halting behaviour".
> Your term "determine" is better than my term "specify".
>
In Linz's system, a Turing machine which is purportedly a halt decider reads
the description of another machine, together with the input to that
machine.
In PO's system, a fucntion works on the physical machine code which is the
"machine" under test. The most important difference is that there is no
dustinction between H and the representation of H embedded in H_Hat.
They are the identical transistors that hold the machine code of H.

This isn't really important, but it means that terminology can get confused..

On 29/05/2022 03:43, olcott wrote:
> On 5/28/2022 7:22 PM, Mike Terry wrote:
>> On 27/05/2022 22:32, Richard Damon wrote:
>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>> On 2022-05-27 14:38, olcott wrote:
>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the representation of an
>>>>>>>>>> algorithm and its input.
>>>>>>>>>
>>>>>>>>> The finite string inputs to a halt decider specify (rather then merely represent) a
>>>>>>>>> sequence of configurations that may or may not reach their own final state.
>>>>>>>>
>>>>>>>> I really don't think you have any idea what terms like 'represent', 'specify', or 'sequence
>>>>>>>> of configurations' mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>>>
>>>>>>>
>>>>>>> The distinction that I make between represent and specify is that the x86 source-code for P
>>>>>>> represents P(P) whereas the actual correct x86 emulation of the input to H(P,P) specifies the
>>>>>>> actual behavior of this input. This is not the same behavior as the behavior specified by P(P).
>>>>>>>
>>>>>>> A sequence of configurations means a list of x86 program steps executed or emulated in the
>>>>>>> order that their source-code specifies.
>>>>>>>
>>>>>>> Likewise with a TM or the UTM simulation of a TM description specifies a sequence of state
>>>>>>> transitions.
>>>>>>
>>>>>> And this decidedly is *not* what a halt decider is given as its input. It is not given a
>>>>>> sequence of state transitions. It is given a representation of a computation.
>>>>>>
>>>>>
>>>>> No it is not and you know that it is not. A halt decider is given a finite string TM
>>>>> description that specifies a sequence of configurations.
>>>>
>>>> A TM description and a sequence of configurations are entirely different things (and the former
>>>> certainly does not 'specify' the latter). It's given either one or the other. Make up your mind.
>>>>
>>>> André
>>>>
>>>
>>> Well, a TM description, and a description of an input to that TM, does specify a "sequence of
>>> configurations" based on what running that TM on that input would do.
>>
>> "Specify" is not the word I'd use.  (If I write a shopping list I specify what I'm going to get
>> when I go shopping: one loaf of bread and 4oz jar of strawberry jam.  I don't write various clues
>> which can together be used to generate what I want by applying some algorithm.)
>>
>> For your scenario, "determine" seems accurate.  But PO also says that P(P) "specifies non-halting
>> behaviour", and that computation halts.  I think that this use just means "matches PO's abort test".
>>
>
> I never said that: "P(P) specifies non-halting behaviour".
> Your term "determine" is better than my term "specify".
>
> The input to H(P,P) determines the sequence of x86 instructions of the correct x86 emulation of P by
> H. This sequence never reaches the "ret" instruction of P.

Obviously H never gets to emulate the final ret of P - because it aborts the emulation before it
gets there. Duh! Not seeing the final ret /because you gave up and stopped emulating/ does not
mean the computation P(P) never halts, or that "never halts" is "the correct answer" for H to return
for input (P,P). That's some gibberish idea you've come up with in your confusion.

If UTM emulates the P(P) computation, it will see all the EXACT SAME config steps that H emulated,
except that where H gave up due to spotting some pattern, UTM carries on and sees the P(P) steps
after H gave up, INCLUDING THE FINAL RET OF P.

What's going on? CLEARLY:
1) P(P) is a halting computation
2) H calculates the initial P(P) computation steps, but before it gets to the ret,
it stops and incorrectly reports "never halts". [I.e. your abort test is unsound.]

Hey, didn't I explain all this to you a couple of years ago? And nothing of worth has changed since
then - you're still making exactly the same errors! You've just tinkered with your wording as
though that will make any difference...

Oh, well, at least I've done my bit now for the next couple of years! :)

>
> The input to H1(P,P) determines the sequence of x86 instructions of the correct x86 emulation of P
> by H1. This sequence reaches the "ret" instruction of P and halts.

Yes, H1 is like UTM: it continues calculating P(P) config steps past the point where H gives up, so
it gets to see the final ret.

I even explained WHY this happens to you a few months ago when you first introduced H1 (which is a
renamed source-level clone of function H, right?) :

a) *H* gives up emulating and aborts because your so called "specifies infinite recursion" test
matched. [Which does not mean there /really is/ infinite recursion. Even if your program prints a
message saying "aborted due to infinite recursion" that still doesn't mean there /really is/
infinitite recursion. Duh, it's just a text string you print!]

b) *H1* computes the same P(P) computation steps, and applies a similar abort test to H [well, the
source code is cloned from H, so it should...]. But there's a crucial difference with H1:
- H cheated and used its own address *H* to decide to IGNORE all the conditional branches in
emulated P(P) made by *H*, so your "no conditional branches..." clause matched (along with the other
clauses), causing H to abort simulation.
- H1 cheated in a similar way, but used its own *H1* address to decide to IGNORE all the
conditional branches in emulated P(P) *made by H1*. Well, there is no H1 code in P(P), but there is
H code which is now /not/ ignored - so H1 sees all the conditional branches in H, preventing your
[faulty] abort test from matching. Result: H1 never aborts, so it continues until P(P) actually
terminates. At that point it correctly reports P(P) halts.

Nothing mysterious in all this. Your explanations of why H and H1 report different results, based
on PSR mysteriously causing the simulation of P(P) to calculate different computation steps, is just
your usual duffer confusion as to what's going on. You've shown NO REASON to think the P(P)
calculation steps emulated within H and H1 are different [beyond the obvious fact that H stops
calculating steps at some point whereas H1 carries on to P(P) completion]. It is not the emulation
of P(P) that differs between H and H1 to give the difference - it's just the difference between H
and H1 algorithms that give the difference. [And if you hadn't cheated by using H and H1's memory
addresses as hidden inputs, the algorithms in H and H1 would be the same, so reported outcomes would
have matched as Linz requires for source code clones.]

Sometimes I think I understand your code better than you do, and I've never seen it! (Previously
when I've suggested the above explanation you've neither confirmed nor denied that's what's going
on, which is a sure sign you don't understand it yourself so you hold back from commenting...)

>
> This latter sequence of x86 instructions of P is identical to the sequence specified by P(P).
>

....and identical to what UTM would simulate,
....and identical to what H simulates, up to the point where it gives up emulating and reports "does
not halt".

Mike.

On 5/29/22 1:04 PM, Mike Terry wrote:
> On 29/05/2022 03:43, olcott wrote:
>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>>
>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>
>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>> the actual behavior of this input. This is not the same behavior
>>>>>>>> as the behavior specified by P(P).
>>>>>>>>
>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>> executed or emulated in the order that their source-code specifies.
>>>>>>>>
>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>> specifies a sequence of state transitions.
>>>>>>>
>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>> given a representation of a computation.
>>>>>>>
>>>>>>
>>>>>> No it is not and you know that it is not. A halt decider is given
>>>>>> a finite string TM description that specifies a sequence of
>>>>>> configurations.
>>>>>
>>>>> A TM description and a sequence of configurations are entirely
>>>>> different things (and the former certainly does not 'specify' the
>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Well, a TM description, and a description of an input to that TM,
>>>> does specify a "sequence of configurations" based on what running
>>>> that TM on that input would do.
>>>
>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>> specify what I'm going to get when I go shopping: one loaf of bread
>>> and 4oz jar of strawberry jam.  I don't write various clues which can
>>> together be used to generate what I want by applying some algorithm.)
>>>
>>> For your scenario, "determine" seems accurate.  But PO also says that
>>> P(P) "specifies non-halting behaviour", and that computation halts.
>>> I think that this use just means "matches PO's abort test".
>>>
>>
>> I never said that: "P(P) specifies non-halting behaviour".
>> Your term "determine" is better than my term "specify".
>>
>> The input to H(P,P) determines the sequence of x86 instructions of the
>> correct x86 emulation of P by H. This sequence never reaches the "ret"
>> instruction of P.
>
> Obviously H never gets to emulate the final ret of P - because it aborts
> the emulation before it gets there.  Duh!  Not seeing the final ret
> /because you gave up and stopped emulating/ does not mean the
> computation P(P) never halts, or that "never halts" is "the correct
> answer" for H to return for input (P,P).  That's some gibberish idea
> you've come up with in your confusion.

The ultimate issue is that PO has changed the definition of what a
Halting Decider is supposed to be deciding. Seemingly because it is
unfair to ask it to do something it can't.

Please note, he is converting the requirement from the actual execution
of the machine to a "correct emulation" of the machine, which actually
IS valid *IF* your definition of "correct emulation" is what a UTM would
have done (and where he pulls that transform from).

Then, having done that, he argues that a "Correct Simulation" needs to
be restricted to what a given machine itself can generate. (He gives no
actually justification for this other than that it is all that it CAN do).

What this is really doing it trying to replace the actually uncomputable
mapping of the Halting Problem to something that can't be shown to be
uncomputable by this simple counter example (which seems to be the only
one he knows about and thinks he understands). He doesn't realize that
since he hasn't actually come up with a restriction on what rules the
decider can use to claim that is the best it can do, he is allowing even
"obviously" broken deciders to make the exact same claim, showing his
change results in just a broken alternative for Halting.

This change in definitions in the middle of a "Proof" makes the whole
proof invalid, but he just doesn't understand this, I think because he
just doesn't understand the nature of things like "Definitions" (or even
what is a Truth).

>
> If UTM emulates the P(P) computation, it will see all the EXACT SAME
> config steps that H emulated, except that where H gave up due to
> spotting some pattern, UTM carries on and sees the P(P) steps after H
> gave up, INCLUDING THE FINAL RET OF P.
>
> What's going on?  CLEARLY:
> 1)   P(P) is a halting computation
> 2)   H calculates the initial P(P) computation steps, but before it gets
> to the ret,
>      it stops and incorrectly reports "never halts".  [I.e. your abort
> test is unsound.]
>
> Hey, didn't I explain all this to you a couple of years ago?  And
> nothing of worth has changed since then - you're still making exactly
> the same errors!  You've just tinkered with your wording as though that
> will make any difference...
>
> Oh, well, at least I've done my bit now for the next couple of years!  :)
>
>>
>> The input to H1(P,P) determines the sequence of x86 instructions of
>> the correct x86 emulation of P by H1. This sequence reaches the "ret"
>> instruction of P and halts.
>
> Yes, H1 is like UTM: it continues calculating P(P) config steps past the
> point where H gives up, so it gets to see the final ret.
>
> I even explained WHY this happens to you a few months ago when you first
> introduced H1 (which is a renamed source-level clone of function H,
> right?) :
>
> a)  *H* gives up emulating and aborts because your so called "specifies
> infinite recursion" test matched.  [Which does not mean there /really
> is/ infinite recursion.  Even if your program prints a message saying
> "aborted due to infinite recursion" that still doesn't mean there
> /really is/ infinitite recursion.  Duh, it's just a text string you print!]
>
> b)  *H1* computes the same P(P) computation steps, and applies a similar
> abort test to H [well, the source code is cloned from H, so it
> should...].    But there's a crucial difference with H1:
> -  H cheated and used its own address *H* to decide to IGNORE all the
> conditional branches in emulated P(P) made by *H*, so your "no
> conditional branches..." clause matched (along with the other clauses),
> causing H to abort simulation.
> -  H1 cheated in a similar way, but used its own *H1* address to decide
> to IGNORE all the conditional branches in emulated P(P) *made by H1*.
> Well, there is no H1 code in P(P), but there is H code which is now
> /not/ ignored - so H1 sees all the conditional branches in H, preventing
> your [faulty] abort test from matching.  Result: H1 never aborts, so it
> continues until P(P) actually terminates.  At that point it correctly
> reports P(P) halts.
>
> Nothing mysterious in all this.  Your explanations of why H and H1
> report different results, based on PSR mysteriously causing the
> simulation of P(P) to calculate different computation steps, is just
> your usual duffer confusion as to what's going on.  You've shown NO
> REASON to think the P(P) calculation steps emulated within H and H1 are
> different [beyond the obvious fact that H stops calculating steps at
> some point whereas H1 carries on to P(P) completion].  It is not the
> emulation of P(P) that differs between H and H1 to give the difference -
> it's just the difference between H and H1 algorithms that give the
> difference.  [And if you hadn't cheated by using H and H1's memory
> addresses as hidden inputs, the algorithms in H and H1 would be the
> same, so reported outcomes would have matched as Linz requires for
> source code clones.]
>
> Sometimes I think I understand your code better than you do, and I've
> never seen it!  (Previously when I've suggested the above explanation
> you've neither confirmed nor denied that's what's going on, which is a
> sure sign you don't understand it yourself so you hold back from
> commenting...)
>
>>
>> This latter sequence of x86 instructions of P is identical to the
>> sequence specified by P(P).
>>
>
> ...and identical to what UTM would simulate,
> ...and identical to what H simulates, up to the point where it gives up
> emulating and reports "does not halt".
>
>
> Mike.

On 5/29/2022 12:04 PM, Mike Terry wrote:
> On 29/05/2022 03:43, olcott wrote:
>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>>
>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>
>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>> the actual behavior of this input. This is not the same behavior
>>>>>>>> as the behavior specified by P(P).
>>>>>>>>
>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>> executed or emulated in the order that their source-code specifies.
>>>>>>>>
>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>> specifies a sequence of state transitions.
>>>>>>>
>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>> given a representation of a computation.
>>>>>>>
>>>>>>
>>>>>> No it is not and you know that it is not. A halt decider is given
>>>>>> a finite string TM description that specifies a sequence of
>>>>>> configurations.
>>>>>
>>>>> A TM description and a sequence of configurations are entirely
>>>>> different things (and the former certainly does not 'specify' the
>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Well, a TM description, and a description of an input to that TM,
>>>> does specify a "sequence of configurations" based on what running
>>>> that TM on that input would do.
>>>
>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>> specify what I'm going to get when I go shopping: one loaf of bread
>>> and 4oz jar of strawberry jam.  I don't write various clues which can
>>> together be used to generate what I want by applying some algorithm.)
>>>
>>> For your scenario, "determine" seems accurate.  But PO also says that
>>> P(P) "specifies non-halting behaviour", and that computation halts.
>>> I think that this use just means "matches PO's abort test".
>>>
>>
>> I never said that: "P(P) specifies non-halting behaviour".
>> Your term "determine" is better than my term "specify".
>>
>> The input to H(P,P) determines the sequence of x86 instructions of the
>> correct x86 emulation of P by H. This sequence never reaches the "ret"
>> instruction of P.
>
> Obviously H never gets to emulate the final ret of P - because it aborts
> the emulation before it gets there.  Duh!  Not seeing the final ret
> /because you gave up and stopped emulating/ does not mean the
> computation P(P) never halts, or that "never halts" is "the correct
> answer" for H to return for input (P,P).  That's some gibberish idea
> you've come up with in your confusion.
>
> If UTM emulates the P(P) computation, it will see all the EXACT SAME
> config steps that H emulated, except that where H gave up due to
> spotting some pattern, UTM carries on and sees the P(P) steps after H
> gave up, INCLUDING THE FINAL RET OF P.
The correct x86 emulation of the input to H(P,P) by H never reaches the
"ret" instruction of P in 1 to ∞ emulated steps.

Honest reviewers can very easily verify the truth of this by simply
reverse-engineering the execution trace of the sequence of instructions
of P when the input to H(P,P) is correctly emulated by H.

Honest reviewers that are not stupid will also know that when H(P,P)
aborts the simulation of its input that this does not magically cause P
to leap to its "ret" instruction.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Sunday, May 29, 2022 at 1:19:18 PM UTC-4, olcott wrote:
> On 5/29/2022 12:04 PM, Mike Terry wrote:
> > On 29/05/2022 03:43, olcott wrote:
> >> On 5/28/2022 7:22 PM, Mike Terry wrote:
> >>> On 27/05/2022 22:32, Richard Damon wrote:
> >>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
> >>>>> On 2022-05-27 14:38, olcott wrote:
> >>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
> >>>>>>> On 2022-05-27 13:41, olcott wrote:
> >>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
> >>>>>>>>> On 2022-05-27 13:01, olcott wrote:
> >>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
> >>>>>>>>>
> >>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
> >>>>>>>>>>> representation of an algorithm and its input.
> >>>>>>>>>>
> >>>>>>>>>> The finite string inputs to a halt decider specify (rather
> >>>>>>>>>> then merely represent) a sequence of configurations that may
> >>>>>>>>>> or may not reach their own final state.
> >>>>>>>>>
> >>>>>>>>> I really don't think you have any idea what terms like
> >>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
> >>>>>>>>> Richard is perfectly correct. You, as usual, are not.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> The distinction that I make between represent and specify is
> >>>>>>>> that the x86 source-code for P represents P(P) whereas the
> >>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
> >>>>>>>> the actual behavior of this input. This is not the same behavior
> >>>>>>>> as the behavior specified by P(P).
> >>>>>>>>
> >>>>>>>> A sequence of configurations means a list of x86 program steps
> >>>>>>>> executed or emulated in the order that their source-code specifies.
> >>>>>>>>
> >>>>>>>> Likewise with a TM or the UTM simulation of a TM description
> >>>>>>>> specifies a sequence of state transitions.
> >>>>>>>
> >>>>>>> And this decidedly is *not* what a halt decider is given as its
> >>>>>>> input. It is not given a sequence of state transitions. It is
> >>>>>>> given a representation of a computation.
> >>>>>>>
> >>>>>>
> >>>>>> No it is not and you know that it is not. A halt decider is given
> >>>>>> a finite string TM description that specifies a sequence of
> >>>>>> configurations.
> >>>>>
> >>>>> A TM description and a sequence of configurations are entirely
> >>>>> different things (and the former certainly does not 'specify' the
> >>>>> latter). It's given either one or the other. Make up your mind.
> >>>>>
> >>>>> André
> >>>>>
> >>>>
> >>>> Well, a TM description, and a description of an input to that TM,
> >>>> does specify a "sequence of configurations" based on what running
> >>>> that TM on that input would do.
> >>>
> >>> "Specify" is not the word I'd use. (If I write a shopping list I
> >>> specify what I'm going to get when I go shopping: one loaf of bread
> >>> and 4oz jar of strawberry jam. I don't write various clues which can
> >>> together be used to generate what I want by applying some algorithm.)
> >>>
> >>> For your scenario, "determine" seems accurate. But PO also says that
> >>> P(P) "specifies non-halting behaviour", and that computation halts.
> >>> I think that this use just means "matches PO's abort test".
> >>>
> >>
> >> I never said that: "P(P) specifies non-halting behaviour".
> >> Your term "determine" is better than my term "specify".
> >>
> >> The input to H(P,P) determines the sequence of x86 instructions of the
> >> correct x86 emulation of P by H. This sequence never reaches the "ret"
> >> instruction of P.
> >
> > Obviously H never gets to emulate the final ret of P - because it aborts
> > the emulation before it gets there. Duh! Not seeing the final ret
> > /because you gave up and stopped emulating/ does not mean the
> > computation P(P) never halts, or that "never halts" is "the correct
> > answer" for H to return for input (P,P). That's some gibberish idea
> > you've come up with in your confusion.
> >
> > If UTM emulates the P(P) computation, it will see all the EXACT SAME
> > config steps that H emulated, except that where H gave up due to
> > spotting some pattern, UTM carries on and sees the P(P) steps after H
> > gave up, INCLUDING THE FINAL RET OF P.
> The correct x86 emulation of the input to H(P,P) by H

Has not been established, so anything resting on that assumption is invalid..

On 5/29/22 1:19 PM, olcott wrote:
> On 5/29/2022 12:04 PM, Mike Terry wrote:
>> On 29/05/2022 03:43, olcott wrote:
>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>>>
>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>>
>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>
>>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>>> executed or emulated in the order that their source-code
>>>>>>>>> specifies.
>>>>>>>>>
>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>
>>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>>> given a representation of a computation.
>>>>>>>>
>>>>>>>
>>>>>>> No it is not and you know that it is not. A halt decider is given
>>>>>>> a finite string TM description that specifies a sequence of
>>>>>>> configurations.
>>>>>>
>>>>>> A TM description and a sequence of configurations are entirely
>>>>>> different things (and the former certainly does not 'specify' the
>>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Well, a TM description, and a description of an input to that TM,
>>>>> does specify a "sequence of configurations" based on what running
>>>>> that TM on that input would do.
>>>>
>>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>>> specify what I'm going to get when I go shopping: one loaf of bread
>>>> and 4oz jar of strawberry jam.  I don't write various clues which
>>>> can together be used to generate what I want by applying some
>>>> algorithm.)
>>>>
>>>> For your scenario, "determine" seems accurate.  But PO also says
>>>> that P(P) "specifies non-halting behaviour", and that computation
>>>> halts. I think that this use just means "matches PO's abort test".
>>>>
>>>
>>> I never said that: "P(P) specifies non-halting behaviour".
>>> Your term "determine" is better than my term "specify".
>>>
>>> The input to H(P,P) determines the sequence of x86 instructions of
>>> the correct x86 emulation of P by H. This sequence never reaches the
>>> "ret" instruction of P.
>>
>> Obviously H never gets to emulate the final ret of P - because it
>> aborts the emulation before it gets there.  Duh!  Not seeing the final
>> ret /because you gave up and stopped emulating/ does not mean the
>> computation P(P) never halts, or that "never halts" is "the correct
>> answer" for H to return for input (P,P).  That's some gibberish idea
>> you've come up with in your confusion.
>>
>> If UTM emulates the P(P) computation, it will see all the EXACT SAME
>> config steps that H emulated, except that where H gave up due to
>> spotting some pattern, UTM carries on and sees the P(P) steps after H
>> gave up, INCLUDING THE FINAL RET OF P.
> The correct x86 emulation of the input to H(P,P) by H never reaches the
> "ret" instruction of P in 1 to ∞ emulated steps.

No, H will abort it at whatever number of steps would abort that input.

Remember, H is a FIXED algorithm (or needs to be to be a decider) and
thus has DEFINITE behavior for a given input.

Your arguement isn't about a given H, but confounds the behavior of
different members of a whole class of them, each generating a DIFFERENT
input, and thus not making an actual arguement about any of the input.

This is the fallacy of your notation. Your H keeps on being shown to not
be a definite algorithm, so it can't be a Halt Decider.

>
> Honest reviewers can very easily verify the truth of this by simply
> reverse-engineering the execution trace of the sequence of instructions
> of P when the input to H(P,P) is correctly emulated by H.
>

What, that P(P) calls H(P,P) which is defined to return a 0 after some
period of time and thus halts.

The problem is you have introduced incorrect assumptions into your logic
system making it inconsistent, thus we can actually prove opposites
sides of a number of questions.

> Honest reviewers that are not stupid will also know that when H(P,P)
> aborts the simulation of its input that this does not magically cause P
> to leap to its "ret" instruction.
>

In one sense, you are right, THAT instance of P doesn't just jump to the
ret instruction.

But, H returning 0, mean that an P that called that H WILL go to its ret
instruction.

This PROVES that if H is actually a Computation, and thus the property
that ALL copies of it given the same input will produce the same
behavior, proves that the P that H aborted, would have reached that ret
instruction if continued to be simulated by what the field defines as a
correct simulation (that of a UTM), even if that is not what you want to
define as a correct simulation in your proof.

You INCORRECT definition of what a "Correct Simulation", and then
assuming it has all the properties of what the theory calls a correct
simulation, is what broke you logic system.

You are just shown to not be actually working on the halting problem,
and are working in a logic system broken by your incorrect assumptions.

> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
>

On 29/05/2022 18:15, Richard Damon wrote:
> On 5/29/22 1:04 PM, Mike Terry wrote:
>> On 29/05/2022 03:43, olcott wrote:
>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the representation of an
>>>>>>>>>>>> algorithm and its input.
>>>>>>>>>>>
>>>>>>>>>>> The finite string inputs to a halt decider specify (rather then merely represent) a
>>>>>>>>>>> sequence of configurations that may or may not reach their own final state.
>>>>>>>>>>
>>>>>>>>>> I really don't think you have any idea what terms like 'represent', 'specify', or
>>>>>>>>>> 'sequence of configurations' mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The distinction that I make between represent and specify is that the x86 source-code for P
>>>>>>>>> represents P(P) whereas the actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>> the actual behavior of this input. This is not the same behavior as the behavior specified
>>>>>>>>> by P(P).
>>>>>>>>>
>>>>>>>>> A sequence of configurations means a list of x86 program steps executed or emulated in the
>>>>>>>>> order that their source-code specifies.
>>>>>>>>>
>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description specifies a sequence of state
>>>>>>>>> transitions.
>>>>>>>>
>>>>>>>> And this decidedly is *not* what a halt decider is given as its input. It is not given a
>>>>>>>> sequence of state transitions. It is given a representation of a computation.
>>>>>>>>
>>>>>>>
>>>>>>> No it is not and you know that it is not. A halt decider is given a finite string TM
>>>>>>> description that specifies a sequence of configurations.
>>>>>>
>>>>>> A TM description and a sequence of configurations are entirely different things (and the
>>>>>> former certainly does not 'specify' the latter). It's given either one or the other. Make up
>>>>>> your mind.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Well, a TM description, and a description of an input to that TM, does specify a "sequence of
>>>>> configurations" based on what running that TM on that input would do.
>>>>
>>>> "Specify" is not the word I'd use.  (If I write a shopping list I specify what I'm going to get
>>>> when I go shopping: one loaf of bread and 4oz jar of strawberry jam.  I don't write various
>>>> clues which can together be used to generate what I want by applying some algorithm.)
>>>>
>>>> For your scenario, "determine" seems accurate.  But PO also says that P(P) "specifies
>>>> non-halting behaviour", and that computation halts. I think that this use just means "matches
>>>> PO's abort test".
>>>>
>>>
>>> I never said that: "P(P) specifies non-halting behaviour".
>>> Your term "determine" is better than my term "specify".
>>>
>>> The input to H(P,P) determines the sequence of x86 instructions of the correct x86 emulation of P
>>> by H. This sequence never reaches the "ret" instruction of P.
>>
>> Obviously H never gets to emulate the final ret of P - because it aborts the emulation before it
>> gets there.  Duh!  Not seeing the final ret /because you gave up and stopped emulating/ does not
>> mean the computation P(P) never halts, or that "never halts" is "the correct answer" for H to
>> return for input (P,P).  That's some gibberish idea you've come up with in your confusion.
>
> The ultimate issue is that PO has changed the definition of what a Halting Decider is supposed to be
> deciding. Seemingly because it is unfair to ask it to do something it can't.

Agree. I think PO probably can't understand the proper definition of halting. That definition
doesn't involve any UTMs or emulation - it's just a mathematical definition, first of the
computation steps, then of halting in terms of there being an n such that computation step n is a
final state of the TM. That's TOO ABSTRACT for PO, so all he can do is replace it with something he
thinks he /can/ understand: something more concrete - a simulation run in some "actual machine"
processing a TM description and tape description!

>
> Please note, he is converting the requirement from the actual execution of the machine to a "correct
> emulation" of the machine, which actually IS valid *IF* your definition of "correct emulation" is
> what a UTM would have done (and where he pulls that transform from).
>
> Then, having done that, he argues that a "Correct Simulation" needs to be restricted to what a given
> machine itself can generate. (He gives no actually justification for this other than that it is all
> that it CAN do).

Yes, it's just PO's confusion when things get even slightly abstract.

He can't even handle that the outer H would need to be replaced with a UTM for his simulation test!
The "correct simulation" can only be the (for PO, "concrete") "what H ACTUALLY DOES".

The fact that this would make the halting definition incoherent doesn't occur to him! [Because the
definition would then depend not only on the (P,I) but also on the H doing the simulation. And a
halt decider is under no obligation to do /any/ simulation at all. Well, of course this is all
hopeless...]

And it goes back to his Aborted_Because_Non_Halting_Behavior_Detected() function! I tried for a
long time to get PO to give a specification for that routine, but he never could. When I pointed
out that without such a spec, how could anyone confirm it was working, or /reason/ about
consequences of the results from the routine, he had no sensible response. All he could say is
something like "the routine IS correct, because it detected non-halting behaviour and it DID abort
the simulation! So the input WAS aborted! And that's the real correct halting question." etc..

I.e. in PO's mind the spec is "WHAT THE CODE DOES" or at best "the algorithm description"! [Like he
couldn't give Ben the logical spec for his IsPrime or IsEven TM. Instead he wanted to say "move to
the last character of the binary number, and accept/reject according to whether this is 0/1." What
Ben was hoping for was just too abstract an idea for PO, I think. In the end I think PO actually
did give a correct spec for one of the TMs, but I'm convinced he just cut and pasted stuff Ben had
already said... Remember - even when PO writes something that's correct, THAT DOESN'T MEAN HE
UNDERSTANDS WHY IT IS CORRECT! so he may well change his mind later on if circumstances or his
intuitions change...]

>
> What this is really doing it trying to replace the actually uncomputable mapping of the Halting
> Problem to something that can't be shown to be uncomputable by this simple counter example (which
> seems to be the only one he knows about and thinks he understands). He doesn't realize that since he
> hasn't actually come up with a restriction on what rules the decider can use to claim that is the
> best it can do, he is allowing even "obviously" broken deciders to make the exact same claim,
> showing his change results in just a broken alternative for Halting.

Yes, that's DB's approach, but the thinking is /waaaay/ too abstract to work with PO. Well, his
effort is still ongoing, so we'll see.

>
> This change in definitions in the middle of a "Proof" makes the whole proof invalid, but he just
> doesn't understand this, I think because he just doesn't understand the nature of things like
> "Definitions" (or even what is a Truth).

On 5/29/22 2:18 PM, Mike Terry wrote:
> On 29/05/2022 18:15, Richard Damon wrote:
>> On 5/29/22 1:04 PM, Mike Terry wrote:
>>> On 29/05/2022 03:43, olcott wrote:
>>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but
>>>>>>>>>>>>> the representation of an algorithm and its input.
>>>>>>>>>>>>
>>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>>>
>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>>
>>>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>>>> executed or emulated in the order that their source-code
>>>>>>>>>> specifies.
>>>>>>>>>>
>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>>
>>>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>>>> given a representation of a computation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>> given a finite string TM description that specifies a sequence
>>>>>>>> of configurations.
>>>>>>>
>>>>>>> A TM description and a sequence of configurations are entirely
>>>>>>> different things (and the former certainly does not 'specify' the
>>>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Well, a TM description, and a description of an input to that TM,
>>>>>> does specify a "sequence of configurations" based on what running
>>>>>> that TM on that input would do.
>>>>>
>>>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>>>> specify what I'm going to get when I go shopping: one loaf of bread
>>>>> and 4oz jar of strawberry jam.  I don't write various clues which
>>>>> can together be used to generate what I want by applying some
>>>>> algorithm.)
>>>>>
>>>>> For your scenario, "determine" seems accurate.  But PO also says
>>>>> that P(P) "specifies non-halting behaviour", and that computation
>>>>> halts. I think that this use just means "matches PO's abort test".
>>>>>
>>>>
>>>> I never said that: "P(P) specifies non-halting behaviour".
>>>> Your term "determine" is better than my term "specify".
>>>>
>>>> The input to H(P,P) determines the sequence of x86 instructions of
>>>> the correct x86 emulation of P by H. This sequence never reaches the
>>>> "ret" instruction of P.
>>>
>>> Obviously H never gets to emulate the final ret of P - because it
>>> aborts the emulation before it gets there.  Duh!  Not seeing the
>>> final ret /because you gave up and stopped emulating/ does not mean
>>> the computation P(P) never halts, or that "never halts" is "the
>>> correct answer" for H to return for input (P,P).  That's some
>>> gibberish idea you've come up with in your confusion.
>>
>> The ultimate issue is that PO has changed the definition of what a
>> Halting Decider is supposed to be deciding. Seemingly because it is
>> unfair to ask it to do something it can't.
>
> Agree.  I think PO probably can't understand the proper definition of
> halting.  That definition doesn't involve any UTMs or emulation - it's
> just a mathematical definition, first of the computation steps, then of
> halting in terms of there being an n such that computation step n is a
> final state of the TM.  That's TOO ABSTRACT for PO, so all he can do is
> replace it with something he thinks he /can/ understand: something more
> concrete - a simulation run in some "actual machine" processing a TM
> description and tape description!
>
>>
>> Please note, he is converting the requirement from the actual
>> execution of the machine to a "correct emulation" of the machine,
>> which actually IS valid *IF* your definition of "correct emulation" is
>> what a UTM would have done (and where he pulls that transform from).
>>
>> Then, having done that, he argues that a "Correct Simulation" needs to
>> be restricted to what a given machine itself can generate. (He gives
>> no actually justification for this other than that it is all that it
>> CAN do).
>
> Yes, it's just PO's confusion when things get even slightly abstract.
>
> He can't even handle that the outer H would need to be replaced with a
> UTM for his simulation test! The "correct simulation" can only be the
> (for PO, "concrete") "what H ACTUALLY DOES".
>
> The fact that this would make the halting definition incoherent doesn't
> occur to him!  [Because the definition would then depend not only on the
> (P,I) but also on the H doing the simulation.  And a halt decider is
> under no obligation to do /any/ simulation at all.  Well, of course this
> is all hopeless...]
>
> And it goes back to his Aborted_Because_Non_Halting_Behavior_Detected()
> function!  I tried for a long time to get PO to give a specification for
> that routine, but he never could.  When I pointed out that without such
> a spec, how could anyone confirm it was working, or /reason/ about
> consequences of the results from the routine, he had no sensible
> response.  All he could say is something like "the routine IS correct,
> because it detected non-halting behaviour and it DID abort the
> simulation!  So the input WAS aborted!  And that's the real correct
> halting question." etc..
>
> I.e. in PO's mind the spec is "WHAT THE CODE DOES" or at best "the
> algorithm description"!  [Like he couldn't give Ben the logical spec for
> his IsPrime or IsEven TM.  Instead he wanted to say "move to the last
> character of the binary number, and accept/reject according to whether
> this is 0/1."  What Ben was hoping for was just too abstract an idea for
> PO, I think.  In the end I think PO actually did give a correct spec for
> one of the TMs, but I'm convinced he just cut and pasted stuff Ben had
> already said...  Remember - even when PO writes something that's
> correct, THAT DOESN'T MEAN HE UNDERSTANDS WHY IT IS CORRECT! so he may
> well change his mind later on if circumstances or his intuitions change...]
>
>>
>> What this is really doing it trying to replace the actually
>> uncomputable mapping of the Halting Problem to something that can't be
>> shown to be uncomputable by this simple counter example (which seems
>> to be the only one he knows about and thinks he understands). He
>> doesn't realize that since he hasn't actually come up with a
>> restriction on what rules the decider can use to claim that is the
>> best it can do, he is allowing even "obviously" broken deciders to
>> make the exact same claim, showing his change results in just a broken
>> alternative for Halting.
>
> Yes, that's DB's approach, but the thinking is /waaaay/ too abstract to
> work with PO.  Well, his effort is still ongoing, so we'll see.
>
>>
>> This change in definitions in the middle of a "Proof" makes the whole
>> proof invalid, but he just doesn't understand this, I think because he
>> just doesn't understand the nature of things like "Definitions" (or
>> even what is a Truth).
>
> Agree.  All his refutations start with PO not understanding the basics
> [what Tarski means by "truth", or "undefinability" etc.] so he invents
> his own "corrected" definitions for terms and then observes that the
> "PO-redefined theorems" don't hold any more, so he's "refuted" them!
> Silly, but then nobody takes any of that seriously...
>
> Mike.

On 5/29/2022 12:39 PM, Richard Damon wrote:
> On 5/29/22 1:19 PM, olcott wrote:
>> On 5/29/2022 12:04 PM, Mike Terry wrote:
>>> On 29/05/2022 03:43, olcott wrote:
>>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but
>>>>>>>>>>>>> the representation of an algorithm and its input.
>>>>>>>>>>>>
>>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>>>
>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>>
>>>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>>>> executed or emulated in the order that their source-code
>>>>>>>>>> specifies.
>>>>>>>>>>
>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>>
>>>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>>>> given a representation of a computation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>> given a finite string TM description that specifies a sequence
>>>>>>>> of configurations.
>>>>>>>
>>>>>>> A TM description and a sequence of configurations are entirely
>>>>>>> different things (and the former certainly does not 'specify' the
>>>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Well, a TM description, and a description of an input to that TM,
>>>>>> does specify a "sequence of configurations" based on what running
>>>>>> that TM on that input would do.
>>>>>
>>>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>>>> specify what I'm going to get when I go shopping: one loaf of bread
>>>>> and 4oz jar of strawberry jam.  I don't write various clues which
>>>>> can together be used to generate what I want by applying some
>>>>> algorithm.)
>>>>>
>>>>> For your scenario, "determine" seems accurate.  But PO also says
>>>>> that P(P) "specifies non-halting behaviour", and that computation
>>>>> halts. I think that this use just means "matches PO's abort test".
>>>>>
>>>>
>>>> I never said that: "P(P) specifies non-halting behaviour".
>>>> Your term "determine" is better than my term "specify".
>>>>
>>>> The input to H(P,P) determines the sequence of x86 instructions of
>>>> the correct x86 emulation of P by H. This sequence never reaches the
>>>> "ret" instruction of P.
>>>
>>> Obviously H never gets to emulate the final ret of P - because it
>>> aborts the emulation before it gets there.  Duh!  Not seeing the
>>> final ret /because you gave up and stopped emulating/ does not mean
>>> the computation P(P) never halts, or that "never halts" is "the
>>> correct answer" for H to return for input (P,P).  That's some
>>> gibberish idea you've come up with in your confusion.
>>>
>>> If UTM emulates the P(P) computation, it will see all the EXACT SAME
>>> config steps that H emulated, except that where H gave up due to
>>> spotting some pattern, UTM carries on and sees the P(P) steps after H
>>> gave up, INCLUDING THE FINAL RET OF P.
>> The correct x86 emulation of the input to H(P,P) by H never reaches
>> the "ret" instruction of P in 1 to ∞ emulated steps.
>
> No, H will abort it at whatever number of steps would abort that input.
>
> Remember, H is a FIXED algorithm (or needs to be to be a decider) and
> thus has DEFINITE behavior for a given input.
>
> Your arguement isn't about a given H, but confounds the behavior of
> different members of a whole class of them,

Yes, that is how categorically exhaustive reasoning** works.
** Reasoning that cannot possibly have any gaps.

The alternative method that you suggest is to test each element of an
infinite set one-at-a-time.

> each generating a DIFFERENT
> input, and thus not making an actual arguement about any of the input.
>

The literal string of machine code bytes is the only actual input.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

H is defined to be at machine address 000011a2.

> This is the fallacy of your notation. Your H keeps on being shown to not
> be a definite algorithm, so it can't be a Halt Decider.
>

There are only two possible ways that H can be defined:
(a) H that aborts its simulation after some fixed number of emulated steps.

(b) H that does not abort its simulation after some fixed number of
emulated steps.

In neither of these categorically exhaustive cases does the correctly
emulated input to H(P,P) ever reach its "ret" instruction.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/29/2022 1:18 PM, Mike Terry wrote:
> On 29/05/2022 18:15, Richard Damon wrote:
>> On 5/29/22 1:04 PM, Mike Terry wrote:
>>> On 29/05/2022 03:43, olcott wrote:
>>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but
>>>>>>>>>>>>> the representation of an algorithm and its input.
>>>>>>>>>>>>
>>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>>>
>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>>
>>>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>>>> executed or emulated in the order that their source-code
>>>>>>>>>> specifies.
>>>>>>>>>>
>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>>
>>>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>>>> given a representation of a computation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>> given a finite string TM description that specifies a sequence
>>>>>>>> of configurations.
>>>>>>>
>>>>>>> A TM description and a sequence of configurations are entirely
>>>>>>> different things (and the former certainly does not 'specify' the
>>>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Well, a TM description, and a description of an input to that TM,
>>>>>> does specify a "sequence of configurations" based on what running
>>>>>> that TM on that input would do.
>>>>>
>>>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>>>> specify what I'm going to get when I go shopping: one loaf of bread
>>>>> and 4oz jar of strawberry jam.  I don't write various clues which
>>>>> can together be used to generate what I want by applying some
>>>>> algorithm.)
>>>>>
>>>>> For your scenario, "determine" seems accurate.  But PO also says
>>>>> that P(P) "specifies non-halting behaviour", and that computation
>>>>> halts. I think that this use just means "matches PO's abort test".
>>>>>
>>>>
>>>> I never said that: "P(P) specifies non-halting behaviour".
>>>> Your term "determine" is better than my term "specify".
>>>>
>>>> The input to H(P,P) determines the sequence of x86 instructions of
>>>> the correct x86 emulation of P by H. This sequence never reaches the
>>>> "ret" instruction of P.
>>>
>>> Obviously H never gets to emulate the final ret of P - because it
>>> aborts the emulation before it gets there.  Duh!  Not seeing the
>>> final ret /because you gave up and stopped emulating/ does not mean
>>> the computation P(P) never halts, or that "never halts" is "the
>>> correct answer" for H to return for input (P,P).  That's some
>>> gibberish idea you've come up with in your confusion.
>>
>> The ultimate issue is that PO has changed the definition of what a
>> Halting Decider is supposed to be deciding. Seemingly because it is
>> unfair to ask it to do something it can't.
>
> Agree.  I think PO probably can't understand the proper definition of
> halting.  That definition doesn't involve any UTMs or emulation - it's
> just a mathematical definition, first of the computation steps, then of
> halting in terms of there being an n such that computation step n is a
> final state of the TM.  That's TOO ABSTRACT for PO, so all he can do is
> replace it with something he thinks he /can/ understand: something more
> concrete - a simulation run in some "actual machine" processing a TM
> description and tape description!

HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
Every decider computes the mapping from its input finite string(s) to an
accept or reject state based on a semantic or syntactic property of this
finite string.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/29/22 3:16 PM, olcott wrote:
> On 5/29/2022 12:39 PM, Richard Damon wrote:
>> On 5/29/22 1:19 PM, olcott wrote:
>>> On 5/29/2022 12:04 PM, Mike Terry wrote:
>>>> On 29/05/2022 03:43, olcott wrote:
>>>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but
>>>>>>>>>>>>>> the representation of an algorithm and its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>>>> then merely represent) a sequence of configurations that
>>>>>>>>>>>>> may or may not reach their own final state.
>>>>>>>>>>>>
>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>>>
>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>
>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>>>
>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
>>>>>>>>>> its input. It is not given a sequence of state transitions. It
>>>>>>>>>> is given a representation of a computation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>>> given a finite string TM description that specifies a sequence
>>>>>>>>> of configurations.
>>>>>>>>
>>>>>>>> A TM description and a sequence of configurations are entirely
>>>>>>>> different things (and the former certainly does not 'specify'
>>>>>>>> the latter). It's given either one or the other. Make up your mind.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Well, a TM description, and a description of an input to that TM,
>>>>>>> does specify a "sequence of configurations" based on what running
>>>>>>> that TM on that input would do.
>>>>>>
>>>>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>>>>> specify what I'm going to get when I go shopping: one loaf of
>>>>>> bread and 4oz jar of strawberry jam.  I don't write various clues
>>>>>> which can together be used to generate what I want by applying
>>>>>> some algorithm.)
>>>>>>
>>>>>> For your scenario, "determine" seems accurate.  But PO also says
>>>>>> that P(P) "specifies non-halting behaviour", and that computation
>>>>>> halts. I think that this use just means "matches PO's abort test".
>>>>>>
>>>>>
>>>>> I never said that: "P(P) specifies non-halting behaviour".
>>>>> Your term "determine" is better than my term "specify".
>>>>>
>>>>> The input to H(P,P) determines the sequence of x86 instructions of
>>>>> the correct x86 emulation of P by H. This sequence never reaches
>>>>> the "ret" instruction of P.
>>>>
>>>> Obviously H never gets to emulate the final ret of P - because it
>>>> aborts the emulation before it gets there.  Duh!  Not seeing the
>>>> final ret /because you gave up and stopped emulating/ does not mean
>>>> the computation P(P) never halts, or that "never halts" is "the
>>>> correct answer" for H to return for input (P,P).  That's some
>>>> gibberish idea you've come up with in your confusion.
>>>>
>>>> If UTM emulates the P(P) computation, it will see all the EXACT SAME
>>>> config steps that H emulated, except that where H gave up due to
>>>> spotting some pattern, UTM carries on and sees the P(P) steps after
>>>> H gave up, INCLUDING THE FINAL RET OF P.
>>> The correct x86 emulation of the input to H(P,P) by H never reaches
>>> the "ret" instruction of P in 1 to ∞ emulated steps.
>>
>> No, H will abort it at whatever number of steps would abort that input.
>>
>> Remember, H is a FIXED algorithm (or needs to be to be a decider) and
>> thus has DEFINITE behavior for a given input.
>>
>> Your arguement isn't about a given H, but confounds the behavior of
>> different members of a whole class of them,
>
> Yes, that is how categorically exhaustive reasoning** works.
> ** Reasoning that cannot possibly have any gaps.

But it does have gaps.

>
> The alternative method that you suggest is to test each element of an
> infinite set one-at-a-time.

What infinite set.

H is supposed to be *A* Halt Decider.

You need to show that *IT* is correct.

>
>> each generating a DIFFERENT input, and thus not making an actual
>> arguement about any of the input.
>>
>
> The literal string of machine code bytes is the only actual input.

WRONG. That string of code does NOT define the behavior of the PROGRAM
P, because it doesn't define the contents of the memory at 000011A2

THAT is the "GAP" in your logic.

>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> H is defined to be at machine address 000011a2.

WHICH H? You said H is an infinite set of deciders. You have just
defined that No H can actually look at a P that does't use it.

Let us lable each of the members of that set H as Hi where i is the
number of steps that it will simulate its corresponding Pi before
aborting it.

First thing to note, as defined, your H's fail to be valid halt deciders
as it is impossible to give Hi the input Pj,Pj for j != i, so there are
inputs it BY YOUR DEFINITION can't answer. Let us fix that by making an
actual copy of the code of H (as Linz says to do) and include that in P,
and make that call go to that one, thus for the code above 000011a2 has
diffent contents for the different Pi's based on the value of i and will
always be the corresponding Hi.

On 2022-05-29 13:26, olcott wrote:

>> Agree.  I think PO probably can't understand the proper definition of
>> halting.  That definition doesn't involve any UTMs or emulation - it's
>> just a mathematical definition, first of the computation steps, then
>> of halting in terms of there being an n such that computation step n
>> is a final state of the TM.  That's TOO ABSTRACT for PO, so all he can
>> do is replace it with something he thinks he /can/ understand:
>> something more concrete - a simulation run in some "actual machine"
>> processing a TM description and tape description!
>
> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
> Every decider computes the mapping from its input finite string(s) to an
> accept or reject state based on a semantic or syntactic property of this
> finite string.

Finite strings don't have semantic properties. This is a big part of
your confusion: You conflate strings with the things they represent,
whereas others here draw a clear distinction between the two.

Consider the following finite string:

"TΗЕ QUΙСΚ ВRΟWΝ FОΧ ЈUΜРS ΟVЕR ТHΕ LАΖY DОG."

That string has no semantic content at all. Only if you construe it as a
representation of a sentence of English can you talk about semantic
content, but that semantic content belongs to the sentence of English,
not the string.

You complain that when people ask a halt decider about P(P) they are
asking about a 'non-input' since a computation is not a finite string.

At the same time you talk about the input specifying a sequence of
configurations, but as soon as you talk about a sequence of
configurations (or about the input 'specifying anything, for that
matter) you too are no longer talking about finite strings; you are
taking about something which the string might potentially represent (I
add "potentially" since you refuse to clarify your use of 'specify' --
under my usage, and I suspect most other people's usage, the string
doesn't represent such a thing).

So you are just as guilty of having a machine answer about 'non-inputs'
as everyone else is.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 5/29/22 3:26 PM, olcott wrote:
> On 5/29/2022 1:18 PM, Mike Terry wrote:
>> On 29/05/2022 18:15, Richard Damon wrote:
>>> On 5/29/22 1:04 PM, Mike Terry wrote:
>>>> On 29/05/2022 03:43, olcott wrote:
>>>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but
>>>>>>>>>>>>>> the representation of an algorithm and its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>>>> then merely represent) a sequence of configurations that
>>>>>>>>>>>>> may or may not reach their own final state.
>>>>>>>>>>>>
>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>>>
>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>
>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>>>
>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
>>>>>>>>>> its input. It is not given a sequence of state transitions. It
>>>>>>>>>> is given a representation of a computation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>>> given a finite string TM description that specifies a sequence
>>>>>>>>> of configurations.
>>>>>>>>
>>>>>>>> A TM description and a sequence of configurations are entirely
>>>>>>>> different things (and the former certainly does not 'specify'
>>>>>>>> the latter). It's given either one or the other. Make up your mind.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Well, a TM description, and a description of an input to that TM,
>>>>>>> does specify a "sequence of configurations" based on what running
>>>>>>> that TM on that input would do.
>>>>>>
>>>>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>>>>> specify what I'm going to get when I go shopping: one loaf of
>>>>>> bread and 4oz jar of strawberry jam.  I don't write various clues
>>>>>> which can together be used to generate what I want by applying
>>>>>> some algorithm.)
>>>>>>
>>>>>> For your scenario, "determine" seems accurate.  But PO also says
>>>>>> that P(P) "specifies non-halting behaviour", and that computation
>>>>>> halts. I think that this use just means "matches PO's abort test".
>>>>>>
>>>>>
>>>>> I never said that: "P(P) specifies non-halting behaviour".
>>>>> Your term "determine" is better than my term "specify".
>>>>>
>>>>> The input to H(P,P) determines the sequence of x86 instructions of
>>>>> the correct x86 emulation of P by H. This sequence never reaches
>>>>> the "ret" instruction of P.
>>>>
>>>> Obviously H never gets to emulate the final ret of P - because it
>>>> aborts the emulation before it gets there.  Duh!  Not seeing the
>>>> final ret /because you gave up and stopped emulating/ does not mean
>>>> the computation P(P) never halts, or that "never halts" is "the
>>>> correct answer" for H to return for input (P,P).  That's some
>>>> gibberish idea you've come up with in your confusion.
>>>
>>> The ultimate issue is that PO has changed the definition of what a
>>> Halting Decider is supposed to be deciding. Seemingly because it is
>>> unfair to ask it to do something it can't.
>>
>> Agree.  I think PO probably can't understand the proper definition of
>> halting.  That definition doesn't involve any UTMs or emulation - it's
>> just a mathematical definition, first of the computation steps, then
>> of halting in terms of there being an n such that computation step n
>> is a final state of the TM.  That's TOO ABSTRACT for PO, so all he can
>> do is replace it with something he thinks he /can/ understand:
>> something more concrete - a simulation run in some "actual machine"
>> processing a TM description and tape description!
>
> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
> Every decider computes the mapping from its input finite string(s) to an
> accept or reject state based on a semantic or syntactic property of this
> finite string.
>

Right, and for a Halting Decider, that property is the semantic property
that H(<M>,<w>) accepts if M(w) would halt, and reject otherwise.

An equivalent rule would be

H(<M>,<w>) accepts if UTM(<M>,<w>) would halt.

That is a valid semantic property.

It turns out not to be a Computatable Property, but it IS a valid
semantic property of that input.

There is no requirement that a given function that we might want a
decider to be computable, that fact that it isn't just says that no
(universal) decider for that property can exist, which is exactly what
the Halting Theorem states.

You make the error in assuming that a Halt Decider is actually capable
of being created, which is a false assumption, but goes to the actual
question.