On 5/27/2022 4:36 AM, Malcolm McLean wrote:
> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>
>>>> I admit it's all guesswork though. I seriously lost interest when all I
>>>> thought it worth doing was pointing out that if H(X,Y) does not report
>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>> talking about.
>>>>
>>> To me, that's what retains the interest.
>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>> wouldn't they?
>>>
>>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>>> that they are refusing to provide the source, then really the whole
>>> thing must be dismissed.
>>>
>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>> reports non-halting, and they can prove that H is correct.
>> There's no reason at all to think that H is /not/ correct. But since H
>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>> what's interesting about it being correct. Do you really think it's
>> "deciding" some interesting property of the "input"?
>>
> I can't follow all the arguments, and they seem to shift over time.
> But basically PO is trying to argue that H_Hat is an invalid input,
> on the analogue that a sentence like "this sentence is false" isn't
> a valid sentence.

No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or the
current way of saying that input to H(P,P) specifies behavior to H that
would never reach its under its correct x86 emulation by H.

_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]

When the above is correctly emulated by H the first seven instructions
are emulated then P calls H(P,P) which causes H to emulate the first
seven instructions again. This infinite emulation never stops unless
aborted. Whether or not it is aborted the emulated P never reaches its
"ret" instruction thus never halts. The H(P,P)==0 is proved to be correct.

> He then makes the observation that a simulating halt decider will
> be thrown into infinitely nested simulations by H_Hat. So its own
> behaviour is what is problematical, not the "invert the answer"
> step.

It is that P calls H(P,P) that causes the nested emulation.
It is not that H(P,P) emulates its input that causes this.
P specifies infinite emulation to H.

> I can't quite follow his next step of reasoning, which seems to be
> that because H aborts itself (the simulated copy of itself which it
> is running, which in PO's system is the identical same physical
> machine code), the abort doesn't count as part of the behavior of

H(P,P) does not abort itself it aborts its input which also aborts
everything that this input invoked.

> the input. So "Non-halting" is correct even though H_Hat halts.

This input does not halt (meaning that it has reached its "ret"
instruction) it was aborted because it will never reach its "ret"
instruction.

_Infinite_Loop()
[000012c2](01) 55 push ebp
[000012c3](02) 8bec mov ebp,esp
[000012c5](02) ebfe jmp 000012c5
[000012c7](01) 5d pop ebp
[000012c8](01) c3 ret
Size in bytes:(0007) [000012c8]

The exact same process applies to the above _Infinite_Loop()

> PO will probably come in here as a mischaracterisation of his
> position.
>
> A simulator is a perfectly reasonable program to write, and there are
> many practical simulators. Adding a bit of simple loop detection to
> a simulator is also a reasonable thing to do, and might be of practical
> value. However it's not of much theoretical value, because however
> complicated you make the loop detection, there will always be some
> examples of unterminating loops it fails to catch.
>

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own (x86) source
and its input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

When I correctly determine the halt status of that input I have refuted
all of the HP proofs.

> I'm sceptical that PO's H detects nested simulation rather than recursion,
> partly because he himself said it was infinite recursion before I pointed
> out that it was not, and partly because nested simulation is more
> challenging to detect, and he hasn't been forthcoming on how it is
> achieved. But since has hasn't yet made H available, there's no way of
> knowing.
>

The nested simulation pattern derives behavior precisely matching
infinite recursion. If H(P,P) simulates its input (as in nested
simulation) or directly executes its input (as in infinite recursion)
the exact same behavior is derived to outside observers:

If the execution trace of function H() called by function P() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no conditional branch or indexed jump instructions in P().
(4) With no function call returns from H() to P().
then the function call from P() to H() is infinitely recursive.

> As for the "H_Hat is a form of invalid speech" argument, I don't really
> understand the philosophy of maths, but I don't see it myself.
>

To sum it all up I show how H can treat its pathological input as an
ordinary input and simply decide that this input never halts.

--
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/27/22 11:54 AM, olcott wrote:
> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>
>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>> all I
>>>>> thought it worth doing was pointing out that if H(X,Y) does not report
>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>> talking about.
>>>>>
>>>> To me, that's what retains the interest.
>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>> wouldn't they?
>>>>
>>>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>>>> that they are refusing to provide the source, then really the whole
>>>> thing must be dismissed.
>>>>
>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>> reports non-halting, and they can prove that H is correct.
>>> There's no reason at all to think that H is /not/ correct. But since H
>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>> what's interesting about it being correct. Do you really think it's
>>> "deciding" some interesting property of the "input"?
>>>
>> I can't follow all the arguments, and they seem to shift over time.
>> But basically PO is trying to argue that H_Hat is an invalid input,
>> on the analogue that a sentence like "this sentence is false" isn't
>> a valid sentence.
>
> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or the
> current way of saying that input to H(P,P) specifies behavior to H that
> would never reach its under its correct x86 emulation by H.

But the question isn't does *H* reach the final state of the input in
its processing, it is does the computation the input represents reach
its final state.

You are just admitting to trying to answer the WRONG question.

>
> _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]
>
> When the above is correctly emulated by H the first seven instructions
> are emulated then P calls H(P,P) which causes H to emulate the first
> seven instructions again. This infinite emulation never stops unless
> aborted. Whether or not it is aborted the emulated P never reaches its
> "ret" instruction thus never halts. The H(P,P)==0 is proved to be correct.
>

But H can't correctly emulate all of the input, and give an answer. That
is your problem

Again, what is your definition of "Correct emulation" here, it seems
different that that which is normally taken

>> He then makes the observation that a simulating halt decider will
>> be thrown into infinitely nested simulations by H_Hat. So its own
>> behaviour is what is problematical, not the "invert the answer"
>> step.
>
> It is that P calls H(P,P) that causes the nested emulation.
> It is not that H(P,P) emulates its input that causes this.
> P specifies infinite emulation to H.

Except P doesn't specify infinite emulation to H if H knowns that H can
abort its emulation.

>
>> I can't quite follow his next step of reasoning, which seems to be
>> that because H aborts itself (the simulated copy of itself which it
>> is running, which in PO's system is the identical same physical
>> machine code), the abort doesn't count as part of the behavior of
>
> H(P,P) does not abort itself it aborts its input which also aborts
> everything that this input invoked.
>

Right, which means that a P that calls this H gets the answer and
returns, showing it is Haling.

This also shows up in a CORRECT emulaton of the input, which H doesn't do.

>> the input. So "Non-halting" is correct even though H_Hat halts.
>
> This input does not halt (meaning that it has reached its "ret"
> instruction) it was aborted because it will never reach its "ret"
> instruction.
>
> _Infinite_Loop()
> [000012c2](01)  55              push ebp
> [000012c3](02)  8bec            mov ebp,esp
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c7](01)  5d              pop ebp
> [000012c8](01)  c3              ret
> Size in bytes:(0007) [000012c8]

Right, THIS input never halts

>
> The exact same process applies to the above _Infinite_Loop()

But P does Halt if correctly emulated, as your traces for H1 show.

>
>> PO will probably come in here as a mischaracterisation of his
>> position.
>>
>> A simulator is a perfectly reasonable program to write, and there are
>> many practical simulators. Adding a bit of simple loop detection to
>> a simulator is also a reasonable thing to do, and might be of practical
>> value. However it's not of much theoretical value, because however
>> complicated you make the loop detection, there will always be some
>> examples of unterminating loops it fails to catch.
>>
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own (x86) source
> and its input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> When I correctly determine the halt status of that input I have refuted
> all of the HP proofs.

Except you didn't. You say P(P) is non-halting when it halts.

You apparently just can't read a requirements document.

H needs to determine if the program its input represent will Halt, not
if its own simulation of that input will halt, because it doesn't
actualy need to do a simulation of the input.

>
>> I'm sceptical that PO's H detects nested simulation rather than
>> recursion,
>> partly because he himself said it was infinite recursion before I pointed
>> out that it was  not, and partly because nested simulation is more
>> challenging to detect, and he hasn't been forthcoming on how it is
>> achieved. But since has hasn't yet made H available, there's no way of
>> knowing.
>>
>
> The nested simulation pattern derives behavior precisely matching
> infinite recursion. If H(P,P) simulates its input (as in nested
> simulation) or directly executes its input (as in infinite recursion)
> the exact same behavior is derived to outside observers:
>
> If the execution trace of function H() called by function P() shows:
> (1) Function H() is called twice in sequence from the same machine
> address of P().
> (2) With the same parameters to H().
> (3) With no conditional branch or indexed jump instructions in P().
> (4) With no function call returns from H() to P().
> then the function call from P() to H() is infinitely recursive.

Nope, not proven.

(3) needs to include ALL the code in the computation P between the
loops, which includes the code in H. There is no exclusion for the
"system code" of H, because the copy of H that P calls is user code.

You just are proving you don't understand how programs work.

Can you provide a reference that states it YOUR way, allowing the
ignoring of the code in H?

I don't think so.

>
>> As for the "H_Hat is a form of invalid speech" argument, I don't really
>> understand the philosophy of maths, but I don't see it myself.
>>
>
> To sum it all up I show how H can treat its pathological input as an
> ordinary input and simply decide that this input never halts.
>

On 5/27/2022 12:00 PM, Richard Damon wrote:
>
> On 5/27/22 11:54 AM, olcott wrote:
>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>
>>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>>> all I
>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>> report
>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>> talking about.
>>>>>>
>>>>> To me, that's what retains the interest.
>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>> wouldn't they?
>>>>>
>>>>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>>>>> that they are refusing to provide the source, then really the whole
>>>>> thing must be dismissed.
>>>>>
>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>> reports non-halting, and they can prove that H is correct.
>>>> There's no reason at all to think that H is /not/ correct. But since H
>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>>> what's interesting about it being correct. Do you really think it's
>>>> "deciding" some interesting property of the "input"?
>>>>
>>> I can't follow all the arguments, and they seem to shift over time.
>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>> on the analogue that a sentence like "this sentence is false" isn't
>>> a valid sentence.
>>
>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or
>> the current way of saying that input to H(P,P) specifies behavior to H
>> that would never reach its under its correct x86 emulation by H.
>
> But the question isn't does *H* reach the final state of the input in
> its processing, it is does the computation the input represents reach
> its final state.
>
> You are just admitting to trying to answer the WRONG question.

Does the correct simulation of the input to H(P,P) ever reach its "ret"
instruction? No, therfore non-halting.

>
>>
>> _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]
>>
>> When the above is correctly emulated by H the first seven instructions
>> are emulated then P calls H(P,P) which causes H to emulate the first
>> seven instructions again. This infinite emulation never stops unless
>> aborted. Whether or not it is aborted the emulated P never reaches its
>> "ret" instruction thus never halts. The H(P,P)==0 is proved to be
>> correct.
>>
>
> But H can't correctly emulate all of the input, and give an answer. That
> is your problem
>

The set of valid inputs to the algorithm that computes the halt status
of its inputs is the set of sequences of configurations that can be
encoded as finite string inputs to H.

--
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 2022-05-27 11:20, olcott wrote:
> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>
>> On 5/27/22 11:54 AM, olcott wrote:
>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>
>>>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>>>> all I
>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>> report
>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>> talking about.
>>>>>>>
>>>>>> To me, that's what retains the interest.
>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>> wouldn't they?
>>>>>>
>>>>>> If it turns out that H isn't a Turing machine but a C/x86 program,
>>>>>> and
>>>>>> that they are refusing to provide the source, then really the whole
>>>>>> thing must be dismissed.
>>>>>>
>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>> reports non-halting, and they can prove that H is correct.
>>>>> There's no reason at all to think that H is /not/ correct. But since H
>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>>>> what's interesting about it being correct. Do you really think it's
>>>>> "deciding" some interesting property of the "input"?
>>>>>
>>>> I can't follow all the arguments, and they seem to shift over time.
>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>> a valid sentence.
>>>
>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or
>>> the current way of saying that input to H(P,P) specifies behavior to
>>> H that would never reach its under its correct x86 emulation by H.
>>
>> But the question isn't does *H* reach the final state of the input in
>> its processing, it is does the computation the input represents reach
>> its final state.
>>
>> You are just admitting to trying to answer the WRONG question.
>
> Does the correct simulation of the input to H(P,P) ever reach its "ret"
> instruction? No, therfore non-halting.

The simulation of P(P) by your H() does not reach its RET instruction.
That tells us nothing about whether a correct simulation of P(P) reaches
its RET instruction. You'd have to first prove that your H() actually
performs a correct simulation, and that's not the sort of thing you can
prove using traces. That's why continuing to post the same traces over
and over isn't going to convince anyone of anything.

André

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

On 5/27/2022 1:03 PM, André G. Isaak wrote:
> On 2022-05-27 11:20, olcott wrote:
>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>
>>> On 5/27/22 11:54 AM, olcott wrote:
>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>
>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>> when all I
>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>>> report
>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>>> talking about.
>>>>>>>>
>>>>>>> To me, that's what retains the interest.
>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>> wouldn't they?
>>>>>>>
>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>> program, and
>>>>>>> that they are refusing to provide the source, then really the whole
>>>>>>> thing must be dismissed.
>>>>>>>
>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>> There's no reason at all to think that H is /not/ correct. But
>>>>>> since H
>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't
>>>>>> see
>>>>>> what's interesting about it being correct. Do you really think it's
>>>>>> "deciding" some interesting property of the "input"?
>>>>>>
>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>> a valid sentence.
>>>>
>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or
>>>> the current way of saying that input to H(P,P) specifies behavior to
>>>> H that would never reach its under its correct x86 emulation by H.
>>>
>>> But the question isn't does *H* reach the final state of the input in
>>> its processing, it is does the computation the input represents reach
>>> its final state.
>>>
>>> You are just admitting to trying to answer the WRONG question.
>>
>> Does the correct simulation of the input to H(P,P) ever reach its
>> "ret" instruction? No, therfore non-halting.
>
> The simulation of P(P) by your H() does not reach its RET instruction.

It is also easily proven that H does perform a correct x86 emulation of
its input, hence H(P,P)==0 is proven to be correct.

> That tells us nothing about whether a correct simulation of P(P) reaches
> its RET instruction.

H is correctly forbidden from do this. H1(P,P)==1.
Every halt decider must only compute the halt status based on the actual
behavior that its input actually specifies.

That everyone here disagrees with the x86 language is the same as if
they disagreed with arithmetic, impossibly correct.

> You'd have to first prove that your H() actually
> performs a correct simulation, and that's not the sort of thing you can
> prove using traces.

Actually it can only be proved using traces. As long as P has the
behavior that its x86 source code specifies then its x86 emulation is
conclusively proved to be correct.

> That's why continuing to post the same traces over
> and over isn't going to convince anyone of anything.
>
> André
>

--
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/27/22 1:20 PM, olcott wrote:
> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>
>> On 5/27/22 11:54 AM, olcott wrote:
>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>
>>>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>>>> all I
>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>> report
>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>> talking about.
>>>>>>>
>>>>>> To me, that's what retains the interest.
>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>> wouldn't they?
>>>>>>
>>>>>> If it turns out that H isn't a Turing machine but a C/x86 program,
>>>>>> and
>>>>>> that they are refusing to provide the source, then really the whole
>>>>>> thing must be dismissed.
>>>>>>
>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>> reports non-halting, and they can prove that H is correct.
>>>>> There's no reason at all to think that H is /not/ correct. But since H
>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>>>> what's interesting about it being correct. Do you really think it's
>>>>> "deciding" some interesting property of the "input"?
>>>>>
>>>> I can't follow all the arguments, and they seem to shift over time.
>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>> a valid sentence.
>>>
>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or
>>> the current way of saying that input to H(P,P) specifies behavior to
>>> H that would never reach its under its correct x86 emulation by H.
>>
>> But the question isn't does *H* reach the final state of the input in
>> its processing, it is does the computation the input represents reach
>> its final state.
>>
>> You are just admitting to trying to answer the WRONG question.
>
> Does the correct simulation of the input to H(P,P) ever reach its "ret"
> instruction? No, therfore non-halting.
>
>>
>>>
>>> _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]
>>>
>>> When the above is correctly emulated by H the first seven
>>> instructions are emulated then P calls H(P,P) which causes H to
>>> emulate the first seven instructions again. This infinite emulation
>>> never stops unless aborted. Whether or not it is aborted the emulated
>>> P never reaches its "ret" instruction thus never halts. The H(P,P)==0
>>> is proved to be correct.
>>>
>>
>> But H can't correctly emulate all of the input, and give an answer.
>> That is your problem
>>
>
> The set of valid inputs to the algorithm that computes the halt status
> of its inputs is the set of sequences of configurations that can be
> encoded as finite string inputs to H.
>
>

The input to H is NOT a "sequence of configuratios", but the
representation of an algorithm and its input.

Sounds like your H isn't even close to being a Halt Decider.

Seems like you really don't understand a thing that you are talking
about but just word jumbling from stuff you have read,

H takes in a finite string that represents the compuation it is to
decider on. That exists, as in your example, that string can be the
binary code of ALL the memory that the function P will execute (that is
the code of P, H, and all that H calls). Since you claim this program
exists, there is a finite string that represents it, or you couldn't run it.

H, when it runs, creates a sequence of configurations as it progresses
through its processing, but that sequence isn't the "input" to H, it is
the processing of H.

Since the program P can be fully expressed as a finite string to H, as
can its input (another copy of that exact same input), then H can
definitely be given the string that represent the computation P(P), via
the pointers P and P (with the proper interpretation of those pointers
providing access to all that representation).

This means that you claim that P(P) can't be an input is just FALSE, it
is fully representable to H.

THe problem is that H can't actually compute the needed results, because
it will take an infinite number of steps, which just shows that Halting
is NOT a Computable Funcition, which is exactly what the Theorem says.

You are just proving how stupid you are, and how much your statements
are based on lying.

On 5/27/2022 1:57 PM, Richard Damon wrote:
> On 5/27/22 1:20 PM, olcott wrote:
>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>
>>> On 5/27/22 11:54 AM, olcott wrote:
>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>
>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>> when all I
>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>>> report
>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>>> talking about.
>>>>>>>>
>>>>>>> To me, that's what retains the interest.
>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>> wouldn't they?
>>>>>>>
>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>> program, and
>>>>>>> that they are refusing to provide the source, then really the whole
>>>>>>> thing must be dismissed.
>>>>>>>
>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>> There's no reason at all to think that H is /not/ correct. But
>>>>>> since H
>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't
>>>>>> see
>>>>>> what's interesting about it being correct. Do you really think it's
>>>>>> "deciding" some interesting property of the "input"?
>>>>>>
>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>> a valid sentence.
>>>>
>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or
>>>> the current way of saying that input to H(P,P) specifies behavior to
>>>> H that would never reach its under its correct x86 emulation by H.
>>>
>>> But the question isn't does *H* reach the final state of the input in
>>> its processing, it is does the computation the input represents reach
>>> its final state.
>>>
>>> You are just admitting to trying to answer the WRONG question.
>>
>> Does the correct simulation of the input to H(P,P) ever reach its
>> "ret" instruction? No, therfore non-halting.
>>
>>>
>>>>
>>>> _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]
>>>>
>>>> When the above is correctly emulated by H the first seven
>>>> instructions are emulated then P calls H(P,P) which causes H to
>>>> emulate the first seven instructions again. This infinite emulation
>>>> never stops unless aborted. Whether or not it is aborted the
>>>> emulated P never reaches its "ret" instruction thus never halts. The
>>>> H(P,P)==0 is proved to be correct.
>>>>
>>>
>>> But H can't correctly emulate all of the input, and give an answer.
>>> That is your problem
>>>
>>
>> The set of valid inputs to the algorithm that computes the halt status
>> of its inputs is the set of sequences of configurations that can be
>> encoded as finite string inputs to H.
>>
>>
>
> 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.

>
> Sounds like your H isn't even close to being a Halt Decider.
>
> Seems like you really don't understand a thing that you are talking
> about but just word jumbling from stuff you have read,
>
> H takes in a finite string that represents the compuation it is to
> decider on. That exists, as in your example, that string can be the
> binary code of ALL the memory that the function P will execute (that is
> the code of P, H, and all that H calls). Since you claim this program
> exists, there is a finite string that represents it, or you couldn't run
> it.
>
> H, when it runs, creates a sequence of configurations as it progresses
> through its processing, but that sequence isn't the "input" to H, it is
> the processing of H.
>
> Since the program P can be fully expressed as a finite string to H, as
> can its input (another copy of that exact same input), then H can
> definitely be given the string that represent the computation P(P), via
> the pointers P and P (with the proper interpretation of those pointers
> providing access to all that representation).
>
> This means that you claim that P(P) can't be an input is just FALSE, it
> is fully representable to H.
>
> THe problem is that H can't actually compute the needed results, because
> it will take an infinite number of steps, which just shows that Halting
> is NOT a Computable Funcition, which is exactly what the Theorem says.
>
> You are just proving how stupid you are, and how much your statements
> are based on lying.

--
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/27/22 2:34 PM, olcott wrote:
> On 5/27/2022 1:03 PM, André G. Isaak wrote:
>> On 2022-05-27 11:20, olcott wrote:
>>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>>
>>>> On 5/27/22 11:54 AM, olcott wrote:
>>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>
>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>> when all I
>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>>>> report
>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>>>> talking about.
>>>>>>>>>
>>>>>>>> To me, that's what retains the interest.
>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>> wouldn't they?
>>>>>>>>
>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>> program, and
>>>>>>>> that they are refusing to provide the source, then really the whole
>>>>>>>> thing must be dismissed.
>>>>>>>>
>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>> There's no reason at all to think that H is /not/ correct. But
>>>>>>> since H
>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>> don't see
>>>>>>> what's interesting about it being correct. Do you really think it's
>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>
>>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>>> a valid sentence.
>>>>>
>>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat)
>>>>> or the current way of saying that input to H(P,P) specifies
>>>>> behavior to H that would never reach its under its correct x86
>>>>> emulation by H.
>>>>
>>>> But the question isn't does *H* reach the final state of the input
>>>> in its processing, it is does the computation the input represents
>>>> reach its final state.
>>>>
>>>> You are just admitting to trying to answer the WRONG question.
>>>
>>> Does the correct simulation of the input to H(P,P) ever reach its
>>> "ret" instruction? No, therfore non-halting.
>>
>> The simulation of P(P) by your H() does not reach its RET instruction.
>
> It is also easily proven that H does perform a correct x86 emulation of
> its input, hence H(P,P)==0 is proven to be correct.

HOW?

Remember, correct means matches that actual behavior, and H creates only
a PARTIAL simulation, then gives up.

It then using either an incorrect rules or an incorrect premise to feed
logic for it to decide (incorrectly) to abort.

The CORRECT trace, by H1, shows that H was wrong.

>
>
>> That tells us nothing about whether a correct simulation of P(P)
>> reaches its RET instruction.
>
> H is correctly forbidden from do this. H1(P,P)==1.

WHY?

> Every halt decider must only compute the halt status based on the actual
> behavior that its input actually specifies.

Rigbt, and P,P specifies P(P) which Halts.

Unless you H isn't actually a computation (sometimes H(P,P) is 0 and
sometimes it is an infinite loop) then H is just incorrect. If H isn't a
computation, the your whole argument is a LIE>

>
> That everyone here disagrees with the x86 language is the same as if
> they disagreed with arithmetic, impossibly correct.

Nope, we AGREE with the x86 language, which says the correct simulation
of the input to H(P,P) is exactly what P(P) would do (that is, give the
exact same input to an x86 processor and let it run.

You have to explain how that definition doesn't apply?

>
>> You'd have to first prove that your H() actually performs a correct
>> simulation, and that's not the sort of thing you can prove using traces.
>
> Actually it can only be proved using traces. As long as P has the
> behavior that its x86 source code specifies then its x86 emulation is
> conclusively proved to be correct.

Except your traces don't, since an x86 executing a CALL instruction then
executes the code at the destination of the call, but your traces don't
show that.

Note, x86 at the processor level, doesn't distiguish between User Code
and System Code in a single memory context.

You don't seem to understand that basic fact.

>
>> That's why continuing to post the same traces over and over isn't
>> going to convince anyone of anything.
>>
>> André
>>
>
>

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.

Perhaps you can explain your own idiosyncratic usage of these terms.

André

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

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.

This is more general than a computation in that every computation must
reach its own final state.

> Perhaps you can explain your own idiosyncratic usage of these terms.
>
> André
>

--
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/27/22 3:01 PM, olcott wrote:
> On 5/27/2022 1:57 PM, Richard Damon wrote:
>> On 5/27/22 1:20 PM, olcott wrote:
>>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>>
>>>> On 5/27/22 11:54 AM, olcott wrote:
>>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>
>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>> when all I
>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>>>> report
>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>>>> talking about.
>>>>>>>>>
>>>>>>>> To me, that's what retains the interest.
>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>> wouldn't they?
>>>>>>>>
>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>> program, and
>>>>>>>> that they are refusing to provide the source, then really the whole
>>>>>>>> thing must be dismissed.
>>>>>>>>
>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>> There's no reason at all to think that H is /not/ correct. But
>>>>>>> since H
>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>> don't see
>>>>>>> what's interesting about it being correct. Do you really think it's
>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>
>>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>>> a valid sentence.
>>>>>
>>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat)
>>>>> or the current way of saying that input to H(P,P) specifies
>>>>> behavior to H that would never reach its under its correct x86
>>>>> emulation by H.
>>>>
>>>> But the question isn't does *H* reach the final state of the input
>>>> in its processing, it is does the computation the input represents
>>>> reach its final state.
>>>>
>>>> You are just admitting to trying to answer the WRONG question.
>>>
>>> Does the correct simulation of the input to H(P,P) ever reach its
>>> "ret" instruction? No, therfore non-halting.
>>>
>>>>
>>>>>
>>>>> _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]
>>>>>
>>>>> When the above is correctly emulated by H the first seven
>>>>> instructions are emulated then P calls H(P,P) which causes H to
>>>>> emulate the first seven instructions again. This infinite emulation
>>>>> never stops unless aborted. Whether or not it is aborted the
>>>>> emulated P never reaches its "ret" instruction thus never halts.
>>>>> The H(P,P)==0 is proved to be correct.
>>>>>
>>>>
>>>> But H can't correctly emulate all of the input, and give an answer.
>>>> That is your problem
>>>>
>>>
>>> The set of valid inputs to the algorithm that computes the halt
>>> status of its inputs is the set of sequences of configurations that
>>> can be encoded as finite string inputs to H.
>>>
>>>
>>
>> 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.

And there is no requirement that a finite string representation yields a
finite sequence of configuarions for that machine.

If it did, then ALL compuations would halt.

The input to H is a representation of a machine/algorithm and its input.

The x86 byte string for ALL of the program P meets your definition of an
input to H, and thus P,P is in the domain of H.

It may be that H can't correctly compute the results of that input, but
that is the question of the problem (and in fact, we know it can't).

The fact that H can't answer the question correctly (and will either go
into a infinite loop or return a wrong answer) doesn't give it a "Get
out of Jail Free" card to avoid the question, it just makes it WRONG,
and thus not the required counter example.

>
>>
>> Sounds like your H isn't even close to being a Halt Decider.
>>
>> Seems like you really don't understand a thing that you are talking
>> about but just word jumbling from stuff you have read,
>>
>> H takes in a finite string that represents the compuation it is to
>> decider on. That exists, as in your example, that string can be the
>> binary code of ALL the memory that the function P will execute (that
>> is the code of P, H, and all that H calls). Since you claim this
>> program exists, there is a finite string that represents it, or you
>> couldn't run it.
>>
>> H, when it runs, creates a sequence of configurations as it progresses
>> through its processing, but that sequence isn't the "input" to H, it
>> is the processing of H.
>>
>> Since the program P can be fully expressed as a finite string to H, as
>> can its input (another copy of that exact same input), then H can
>> definitely be given the string that represent the computation P(P),
>> via the pointers P and P (with the proper interpretation of those
>> pointers providing access to all that representation).
>>
>> This means that you claim that P(P) can't be an input is just FALSE,
>> it is fully representable to H.
>>
>> THe problem is that H can't actually compute the needed results,
>> because it will take an infinite number of steps, which just shows
>> that Halting is NOT a Computable Funcition, which is exactly what the
>> Theorem says.
>>
>> You are just proving how stupid you are, and how much your statements
>> are based on lying.
>
>

On 5/27/2022 2:54 PM, Richard Damon wrote:
> On 5/27/22 3:01 PM, olcott wrote:
>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>> On 5/27/22 1:20 PM, olcott wrote:
>>>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>>>
>>>>> On 5/27/22 11:54 AM, olcott wrote:
>>>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>>
>>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>>> when all I
>>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does
>>>>>>>>>> not report
>>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone
>>>>>>>>>> else is
>>>>>>>>>> talking about.
>>>>>>>>>>
>>>>>>>>> To me, that's what retains the interest.
>>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>>> wouldn't they?
>>>>>>>>>
>>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>>> program, and
>>>>>>>>> that they are refusing to provide the source, then really the
>>>>>>>>> whole
>>>>>>>>> thing must be dismissed.
>>>>>>>>>
>>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>>> There's no reason at all to think that H is /not/ correct. But
>>>>>>>> since H
>>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>>> don't see
>>>>>>>> what's interesting about it being correct. Do you really think it's
>>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>>
>>>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>>>> a valid sentence.
>>>>>>
>>>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat)
>>>>>> or the current way of saying that input to H(P,P) specifies
>>>>>> behavior to H that would never reach its under its correct x86
>>>>>> emulation by H.
>>>>>
>>>>> But the question isn't does *H* reach the final state of the input
>>>>> in its processing, it is does the computation the input represents
>>>>> reach its final state.
>>>>>
>>>>> You are just admitting to trying to answer the WRONG question.
>>>>
>>>> Does the correct simulation of the input to H(P,P) ever reach its
>>>> "ret" instruction? No, therfore non-halting.
>>>>
>>>>>
>>>>>>
>>>>>> _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]
>>>>>>
>>>>>> When the above is correctly emulated by H the first seven
>>>>>> instructions are emulated then P calls H(P,P) which causes H to
>>>>>> emulate the first seven instructions again. This infinite
>>>>>> emulation never stops unless aborted. Whether or not it is aborted
>>>>>> the emulated P never reaches its "ret" instruction thus never
>>>>>> halts. The H(P,P)==0 is proved to be correct.
>>>>>>
>>>>>
>>>>> But H can't correctly emulate all of the input, and give an answer.
>>>>> That is your problem
>>>>>
>>>>
>>>> The set of valid inputs to the algorithm that computes the halt
>>>> status of its inputs is the set of sequences of configurations that
>>>> can be encoded as finite string inputs to H.
>>>>
>>>>
>>>
>>> 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.
>
> And there is no requirement that a finite string representation yields a
> finite sequence of configuarions for that machine.
>

There is a requirement that a finite string specifies a sequence of
configurations for the machine.

--
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 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.

If it were given a sequence of state transitions as its input, then it
would only be possible to ask it about finite computations which would
entirely defeat the purpose of having a halt decider.

> This is more general than a computation in that every computation must
> reach its own final state.

You keep conflating two entirely different definitions which Linz gave
in entirely different contexts. When talking about halting, it is *not*
the case that every computation must reach a final state. Otherwise
there would be no halting problem to discuss.

Words often have different definitions in different fields, or even in
different subfields. You seem to have serious problems with this
concept. When using a term you must consider only the *relevant* definition.

André

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

On 5/27/22 4:03 PM, olcott wrote:
> On 5/27/2022 2:54 PM, Richard Damon wrote:
>> On 5/27/22 3:01 PM, olcott wrote:
>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>> On 5/27/22 1:20 PM, olcott wrote:
>>>>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 5/27/22 11:54 AM, olcott wrote:
>>>>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>>>
>>>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>>>> when all I
>>>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does
>>>>>>>>>>> not report
>>>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone
>>>>>>>>>>> else is
>>>>>>>>>>> talking about.
>>>>>>>>>>>
>>>>>>>>>> To me, that's what retains the interest.
>>>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H
>>>>>>>>>> such
>>>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>>>> wouldn't they?
>>>>>>>>>>
>>>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>>>> program, and
>>>>>>>>>> that they are refusing to provide the source, then really the
>>>>>>>>>> whole
>>>>>>>>>> thing must be dismissed.
>>>>>>>>>>
>>>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>>>> There's no reason at all to think that H is /not/ correct. But
>>>>>>>>> since H
>>>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>>>> don't see
>>>>>>>>> what's interesting about it being correct. Do you really think
>>>>>>>>> it's
>>>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>>>
>>>>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>>>>> a valid sentence.
>>>>>>>
>>>>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat)
>>>>>>> or the current way of saying that input to H(P,P) specifies
>>>>>>> behavior to H that would never reach its under its correct x86
>>>>>>> emulation by H.
>>>>>>
>>>>>> But the question isn't does *H* reach the final state of the input
>>>>>> in its processing, it is does the computation the input represents
>>>>>> reach its final state.
>>>>>>
>>>>>> You are just admitting to trying to answer the WRONG question.
>>>>>
>>>>> Does the correct simulation of the input to H(P,P) ever reach its
>>>>> "ret" instruction? No, therfore non-halting.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> _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]
>>>>>>>
>>>>>>> When the above is correctly emulated by H the first seven
>>>>>>> instructions are emulated then P calls H(P,P) which causes H to
>>>>>>> emulate the first seven instructions again. This infinite
>>>>>>> emulation never stops unless aborted. Whether or not it is
>>>>>>> aborted the emulated P never reaches its "ret" instruction thus
>>>>>>> never halts. The H(P,P)==0 is proved to be correct.
>>>>>>>
>>>>>>
>>>>>> But H can't correctly emulate all of the input, and give an
>>>>>> answer. That is your problem
>>>>>>
>>>>>
>>>>> The set of valid inputs to the algorithm that computes the halt
>>>>> status of its inputs is the set of sequences of configurations that
>>>>> can be encoded as finite string inputs to H.
>>>>>
>>>>>
>>>>
>>>> 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.
>>
>> And there is no requirement that a finite string representation yields
>> a finite sequence of configuarions for that machine.
>>
>
> There is a requirement that a finite string specifies a sequence of
> configurations for the machine.
>
>
>

WHERE?

The requirement for the execution of the decider to be finite is on the
DECIDER, not the input.

If H doesn't have finite behavior on some inputs, that means H fails,
not that the input isn't allowed.

You fail basic requirements understanding.

PROOF INVALID.

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.

--
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/27/22 4:38 PM, 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.
>

So, you don't even know how to parse English.

Look at your sentence, what was the Halt Decider Given:

[a finite string TM description]

and what does the Decider do with that:

[that specifies a sequence of cnfigurations]

The input is JUST "A finite String TM Description", that is ALL the
input is.

yes, as a computation, when we run that TM described (with the input) we
get a sequence of state transistion, that the decider needs to figure
out if it will be a finite sequence (because the TM halted) or an
infinite sequence (because it didn't).

Giving H the input P,P does EXACTLY THAT.

The input exactly specifies what the behavior is of the computation, and
H has to be a computation and thus have a FIXED, DEFINED, algorithm of
what it does.

If that algorith DOES abort it simulation of that input, then when we
look at the sequence of configurations the input actually specifies, we
see it tracing through all the steps that H went through to make that
decision, then it aborting its processing, and returning to P and P halting.

Thus the string of configurations that the input specifies is FINITE,
and thus HALTING.

Now, H can't actually simulate the input that far, because the number of
steps that H uses to decide is more than the number of steps of its
input it processes, so it needs to decide somehow what to do.

The designer of H has a couple of options.

1) They can make H refuse to be wrong, and keep on simulating until H
actually CAN prove that the input either Halts or will never halt, and n
that case, H will just never halt and fails to decide, and thus fails to
be a decider.

2) They can choose a pattern that is in the simulation, and presume
(incorrectly) that this pattern indicates non-halting behavior, which
seems to be what you have done, and then we get the case above, that
pattern is shown to NOT conclusively prove non-halting, as P will
generate that pattern and the later halt.

3) An option you haven't tried, is to choose a pattern in the
simulation, and presume (incorrectly) that this pattern will lead to
HALTING behavior, at which point the pattern is proved wrong as in the
above case, P will get the answer and enter a tight loop.

THERE IS NO RIGHT ANSWER FOR H.

The input is absolutely correcct, H just can not correctly simulate that
input and give an answer in finite time and be correct, because P will
be contrary.

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é

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

On 5/27/2022 4: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é
>

_Infinite_Loop()
[000012c2](01) 55 push ebp
[000012c3](02) 8bec mov ebp,esp
[000012c5](02) ebfe jmp 000012c5
[000012c7](01) 5d pop ebp
[000012c8](01) c3 ret
Size in bytes:(0007) [000012c8]

So then the above x86 code may specify a game of tic-tac-toe and there
is no possible way to determine that it does not because the x86 source
code of a function has nothing to do with the sequence of steps of its
correct simulation.

--
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/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.

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.

The fact that H isn't able to recreate the full output isn't the fault
of the input, but of H, and H shouldn't expect to be able to generate
the full output.

On 2022-05-27 15:31, olcott wrote:
> On 5/27/2022 4: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é
>>
>
> _Infinite_Loop()
> [000012c2](01)  55              push ebp
> [000012c3](02)  8bec            mov ebp,esp
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c7](01)  5d              pop ebp
> [000012c8](01)  c3              ret
> Size in bytes:(0007) [000012c8]
>
> So then the above x86 code may specify a game of tic-tac-toe and there
> is no possible way to determine that it does not because the x86 source
> code of a function has nothing to do with the sequence of steps of its
> correct simulation.

That is not a sequence of configurations. It is a piece of assembly code
which represents a subroutine which is an infinite loop. The sequence of
configurations would look something like this:

[000012c2](01) 55 push ebp
[000012c3](02) 8bec mov ebp,esp
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
etc.

There's no way the above sequence of configurations could be given to a
halt decider as an input because it is not finite. You can only give it
the representation of the subroutine which is finite.

André

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

On 2022-05-27 15:32, Richard Damon wrote:
> On 5/27/22 5:21 PM, André G. Isaak wrote:

>> 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.

A TM description and the description of an input to that TM can be used
to *derive* a sequence of configurations, but they don't specify such a
sequence.

André

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

On 5/27/22 5:31 PM, olcott wrote:
> On 5/27/2022 4: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é
>>
>
> _Infinite_Loop()
> [000012c2](01)  55              push ebp
> [000012c3](02)  8bec            mov ebp,esp
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c7](01)  5d              pop ebp
> [000012c8](01)  c3              ret
> Size in bytes:(0007) [000012c8]
>
> So then the above x86 code may specify a game of tic-tac-toe and there
> is no possible way to determine that it does not because the x86 source
> code of a function has nothing to do with the sequence of steps of its
> correct simulation.
>

That REALY your possition? You seem to have a few nuts loose.

On 5/27/2022 4:41 PM, André G. Isaak wrote:
> On 2022-05-27 15:31, olcott wrote:
>> On 5/27/2022 4: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é
>>>
>>
>> _Infinite_Loop()
>> [000012c2](01)  55              push ebp
>> [000012c3](02)  8bec            mov ebp,esp
>> [000012c5](02)  ebfe            jmp 000012c5
>> [000012c7](01)  5d              pop ebp
>> [000012c8](01)  c3              ret
>> Size in bytes:(0007) [000012c8]
>>
>> So then the above x86 code may specify a game of tic-tac-toe and there
>> is no possible way to determine that it does not because the x86
>> source code of a function has nothing to do with the sequence of steps
>> of its correct simulation.
>
>
> That is not a sequence of configurations. It is a piece of assembly code
> which represents a subroutine which is an infinite loop. The sequence of
> configurations would look something like this:
>

Yes that code specifies this sequence.

> [000012c2](01)  55              push ebp
> [000012c3](02)  8bec            mov ebp,esp
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c5](02)  ebfe            jmp 000012c5
> etc.
>
> There's no way the above sequence of configurations could be given to a
> halt decider as an input because it is not finite. You can only give it
> the representation of the subroutine which is finite.
>
> André
>

The code is correctly decided by H on the basis that its corresponding
sequence of configurations never reachs the "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/27/22 5:44 PM, André G. Isaak wrote:
> On 2022-05-27 15:32, Richard Damon wrote:
>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>
>>> 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.
>
> A TM description and the description of an input to that TM can be used
> to *derive* a sequence of configurations, but they don't specify such a
> sequence.
>
> André
>

Depends on your meaning of specify.

An algorithm specifies that path the computation will take when run.
That path doesn't get instantiated until your run it.

They don't PROVIDE the sequence of configurations, they specify how to
derive them.

The specifications of the Death Star was not the Death Star itself, but
the instructions that said what was requried to build it.

On 5/27/2022 4:44 PM, André G. Isaak wrote:
> On 2022-05-27 15:32, Richard Damon wrote:
>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>
>>> 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.
>
> A TM description and the description of an input to that TM can be used
> to *derive* a sequence of configurations, but they don't specify such a
> sequence.
>
> André
>

So maybe this actually does specify an tic-tac-toe game?

_Infinite_Loop()
[000012c2](01) 55 push ebp
[000012c3](02) 8bec mov ebp,esp
[000012c5](02) ebfe jmp 000012c5
[000012c7](01) 5d pop ebp
[000012c8](01) c3 ret
Size in bytes:(0007) [000012c8]

The x86 source-code of a function specifies the sequence of instructions
that would occur in the execution trace of its correct x86 emulation.

If this code has no conditional branches then its behavior is always the
same and does not vary on the basis of different inputs.

--
Copyright 2022 Pete Olcott

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