On 4/17/22 8:20 PM, olcott wrote:
> On 4/17/2022 7:09 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/17/2022 10:11 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>
>>>>> That is false.
>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>>>>
>>>> So do you admit that the problem of deciding what the call does is
>>>> indeed undecidable?  That would be a massive step forwards.
>>>>
>>>
>>> I admit that when you are looking for a white dog in your living room
>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
>>> this on the basis of cats in your kitchen {the execution of P(P)
>>> halts}.
>>
>> So you have nothing to say about the problem of deciding whether P(P)
>> halts?
>
> As long as the input to H(P,P) is non-halting then H(P,P)==false is
> necessarily correct.

Yes, and as long as the CORRECT behavior of the input to H(P,P) is
halting, then the answer H(P,P) == false is necessarily incorrect.

>
> This follows the general principle that when {an X is a Y} Z is
> necessarily correct to report that {an X is a Y}.

You need to define what you mean by X and Y, and Z.

>
>
> _P()
> [000009d6](01) 55         push ebp
> [000009d7](02) 8bec       mov ebp,esp
> [000009d9](03) 8b4508     mov eax,[ebp+08]
> [000009dc](01) 50         push eax         // push P
> [000009dd](03) 8b4d08     mov ecx,[ebp+08]
> [000009e0](01) 51         push ecx         // push P
> [000009e1](05) e840feffff call 00000826    // call H
> [000009e6](03) 83c408     add esp,+08
> [000009e9](02) 85c0       test eax,eax
> [000009eb](02) 7402       jz 000009ef
> [000009ed](02) ebfe       jmp 000009ed
> [000009ef](01) 5d         pop ebp
> [000009f0](01) c3         ret              // Final state
> Size in bytes:(0027) [000009f0]
>
> Begin Local Halt Decider Simulation
> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
>
>

You are missing the trace of what happens in H, which is PART of the
behavior of the input.

Note, aborting at this point is NOT a 'correct simulation'.

If H will return false, then the correct simulation will trace that
behaivor, which will then reach the return and show the input is Halting.

If H will not return, then H fails to be a decider.

So, which error does H make, not returning, or returning the wrong answer.

On 4/17/22 8:13 PM, olcott wrote:
> On 4/17/2022 7:08 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/17/2022 10:37 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/17/2022 10:09 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/16/2022 7:45 PM, Ben wrote:
>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>
>>>>>>> That requires a halt decider to compute the mapping from
>>>>>>> non-inputs on
>>>>>>> the basis of the behavior specified by these non-inputs.
>>>>>> No.
>>>>>> Would you like me to explain again?  I won't bother unless you ask
>>>>>> nicely because you've ignored it every time I've done so before.
>>>>>
>>>>> P(P) executed independently is not an input to H(P,P) that you would
>>>>> say otherwise makes you a bald faced liar.
>>>> So you don't want me to explain?  OK.  Stay in the dark.  That works
>>>> for
>>>> me because nothing makes it more certain that you won't be taken
>>>> seriously than pretending that the halting problem is not about the
>>>> computations represented by inputs.
>>>>
>>>> Your problem is that you /have/ to find a way to neutralise what you
>>>> said for years about H(P,P)==false and P(P) halting.  Unless you can
>>>
>>> The fact that the correctly simulated input to H(P,P) is non-halting
>>> is a 100% sufficient reason for H to report that its input does not
>>> halt.  That you disagree makes you a bald faced liar.
>>
>> What makes you think I disagree with that?  You won't say what you mean,
>> or more exactly, you mean to be vague.
>>
>
>
> So then you must agree that when H correctly simulates the input to
> H(P,P) that it would never reach its own final state.

Except that H doesn't correct simulate the input to H(P,P). The CORRECT
simulation of the input to H(P,P) will Halt if H(P,P) returns false.

>
> We can determine the correct simulation of this input entirely on the
> basis of the following machine code and the definition of the x86 language.
>
> _P()
> [000009d6](01) 55         push ebp
> [000009d7](02) 8bec       mov ebp,esp
> [000009d9](03) 8b4508     mov eax,[ebp+08]
> [000009dc](01) 50         push eax         // push P
> [000009dd](03) 8b4d08     mov ecx,[ebp+08]
> [000009e0](01) 51         push ecx         // push P
> [000009e1](05) e840feffff call 00000826    // call H
> [000009e6](03) 83c408     add esp,+08
> [000009e9](02) 85c0       test eax,eax
> [000009eb](02) 7402       jz 000009ef
> [000009ed](02) ebfe       jmp 000009ed
> [000009ef](01) 5d         pop ebp
> [000009f0](01) c3         ret              // Final state
> Size in bytes:(0027) [000009f0]
>
> Begin Local Halt Decider Simulation
> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
>
>

So either you are admitting that H mever returns, or you have an
incorrect simulation.

The correct trace needs to show what happens IN H, and after it returns
(if it will).

olcott <NoOne@NoWhere.com> writes:

> On 4/17/2022 7:08 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/17/2022 10:37 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/17/2022 10:09 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/16/2022 7:45 PM, Ben wrote:
>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>
>>>>>>> That requires a halt decider to compute the mapping from non-inputs on
>>>>>>> the basis of the behavior specified by these non-inputs.
>>>>>> No.
>>>>>> Would you like me to explain again? I won't bother unless you ask
>>>>>> nicely because you've ignored it every time I've done so before.
>>>>>
>>>>> P(P) executed independently is not an input to H(P,P) that you would
>>>>> say otherwise makes you a bald faced liar.
>>>> So you don't want me to explain? OK. Stay in the dark. That works for
>>>> me because nothing makes it more certain that you won't be taken
>>>> seriously than pretending that the halting problem is not about the
>>>> computations represented by inputs.
>>>>
>>>> Your problem is that you /have/ to find a way to neutralise what you
>>>> said for years about H(P,P)==false and P(P) halting. Unless you can
>>>
>>> The fact that the correctly simulated input to H(P,P) is non-halting
>>> is a 100% sufficient reason for H to report that its input does not
>>> halt. That you disagree makes you a bald faced liar.
>>
>> What makes you think I disagree with that? You won't say what you mean,
>> or more exactly, you mean to be vague.
>
> So then you must agree that when H correctly simulates the input to
> H(P,P) that it would never reach its own final state.

I think you are just cutting and pasting without any thought now. You
may not be the sharpest knife in the drawer, but if you'd read what I
wrote I don't believe even you could not possibly think it logical to
write that sentence.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

olcott <NoOne@NoWhere.com> writes:

> On 4/17/2022 7:09 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/17/2022 10:11 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>
>>>>> That is false.
>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>>>>
>>>> So do you admit that the problem of deciding what the call does is
>>>> indeed undecidable? That would be a massive step forwards.
>>>>
>>>
>>> I admit that when you are looking for a white dog in your living room
>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
>>> this on the basis of cats in your kitchen {the execution of P(P)
>>> halts}.
>>
>> So you have nothing to say about the problem of deciding whether P(P)
>> halts?
>
> As long as the input to H(P,P) is non-halting then H(P,P)==false is
> necessarily correct.

The halting problem does not go away because you declare that P(P) is a
"non-input". The problem you used to talk about is still there. Your
supposed answer to that problem is still wrong. You are just (wisely I
might add) trying to avoid talking about it.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

On 4/18/2022 4:53 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/17/2022 7:08 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/17/2022 10:37 AM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/17/2022 10:09 AM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/16/2022 7:45 PM, Ben wrote:
>>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>>
>>>>>>>> That requires a halt decider to compute the mapping from non-inputs on
>>>>>>>> the basis of the behavior specified by these non-inputs.
>>>>>>> No.
>>>>>>> Would you like me to explain again? I won't bother unless you ask
>>>>>>> nicely because you've ignored it every time I've done so before.
>>>>>>
>>>>>> P(P) executed independently is not an input to H(P,P) that you would
>>>>>> say otherwise makes you a bald faced liar.
>>>>> So you don't want me to explain? OK. Stay in the dark. That works for
>>>>> me because nothing makes it more certain that you won't be taken
>>>>> seriously than pretending that the halting problem is not about the
>>>>> computations represented by inputs.
>>>>>
>>>>> Your problem is that you /have/ to find a way to neutralise what you
>>>>> said for years about H(P,P)==false and P(P) halting. Unless you can
>>>>
>>>> The fact that the correctly simulated input to H(P,P) is non-halting
>>>> is a 100% sufficient reason for H to report that its input does not
>>>> halt. That you disagree makes you a bald faced liar.
>>>
>>> What makes you think I disagree with that? You won't say what you mean,
>>> or more exactly, you mean to be vague.
>>
>> So then you must agree that when H correctly simulates the input to
>> H(P,P) that it would never reach its own final state.
>
> I think you are just cutting and pasting without any thought now. You
> may not be the sharpest knife in the drawer, but if you'd read what I
> wrote I don't believe even you could not possibly think it logical to
> write that sentence.
>

You never do anything besides dodge the point at hand so I continue to
present this point until everyone else realizes that you always only
dodge it and are thereby dishonest.

Since there are a total of two points that prove that I am correct I am
not going to change the subject away from these two points until they
are fully addressed.

--
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 4/18/2022 4:53 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/17/2022 7:09 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/17/2022 10:11 AM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>
>>>>>> That is false.
>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>>>>>
>>>>> So do you admit that the problem of deciding what the call does is
>>>>> indeed undecidable? That would be a massive step forwards.
>>>>>
>>>>
>>>> I admit that when you are looking for a white dog in your living room
>>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
>>>> this on the basis of cats in your kitchen {the execution of P(P)
>>>> halts}.
>>>
>>> So you have nothing to say about the problem of deciding whether P(P)
>>> halts?
>>
>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
>> necessarily correct.
>
> The halting problem does not go away because you declare that P(P) is a
> "non-input".

In other words you are claiming that a decider computes the mapping from
non-inputs ?

Since you already know this is false and everyone knowing the theory of
computation knows that this is false it makes no sense to me why you
would so thoroughly denigrate yourself with such obvious dishonesty.

> The problem you used to talk about is still there. Your
> supposed answer to that problem is still wrong. You are just (wisely I
> might add) trying to avoid talking about it.
>

--
Copyright 2022 Pete Olcott

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

Pathetic Crank Peter Olcott wrote:
> On 4/18/2022 4:53 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/17/2022 7:08 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/17/2022 10:37 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/17/2022 10:09 AM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/16/2022 7:45 PM, Ben wrote:
>>>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>>>
>>>>>>>>> That requires a halt decider to compute the mapping from
>>>>>>>>> non-inputs on
>>>>>>>>> the basis of the behavior specified by these non-inputs.
>>>>>>>> No.
>>>>>>>> Would you like me to explain again?  I won't bother unless you ask
>>>>>>>> nicely because you've ignored it every time I've done so before.
>>>>>>>
>>>>>>> P(P) executed independently is not an input to H(P,P) that you would
>>>>>>> say otherwise makes you a bald faced liar.
>>>>>> So you don't want me to explain?  OK.  Stay in the dark.  That
>>>>>> works for
>>>>>> me because nothing makes it more certain that you won't be taken
>>>>>> seriously than pretending that the halting problem is not about the
>>>>>> computations represented by inputs.
>>>>>>
>>>>>> Your problem is that you /have/ to find a way to neutralise what you
>>>>>> said for years about H(P,P)==false and P(P) halting.  Unless you can
>>>>>
>>>>> The fact that the correctly simulated input to H(P,P) is non-halting
>>>>> is a 100% sufficient reason for H to report that its input does not
>>>>> halt.  That you disagree makes you a bald faced liar.
>>>>
>>>> What makes you think I disagree with that?  You won't say what you
>>>> mean,
>>>> or more exactly, you mean to be vague.
>>>
>>> So then you must agree that when H correctly simulates the input to
>>> H(P,P) that it would never reach its own final state.
>>
>> I think you are just cutting and pasting without any thought now.  You
>> may not be the sharpest knife in the drawer, but if you'd read what I
>> wrote I don't believe even you could not possibly think it logical to
>> write that sentence.
>>
>
> You never do anything besides dodge the point at hand so I continue to
> present this point until everyone else realizes that you always only
> dodge it and are thereby dishonest.
>
> Since there are a total of two points that prove that I am correct I am
> not going to change the subject away from these two points until they
> are fully addressed.

They are: you are a kook. EOS.

On 4/18/22 6:57 PM, olcott wrote:
> On 4/18/2022 4:53 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/17/2022 7:09 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/17/2022 10:11 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>
>>>>>>> That is false.
>>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>>>>>>
>>>>>> So do you admit that the problem of deciding what the call does is
>>>>>> indeed undecidable?  That would be a massive step forwards.
>>>>>>
>>>>>
>>>>> I admit that when you are looking for a white dog in your living room
>>>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
>>>>> this on the basis of cats in your kitchen {the execution of P(P)
>>>>> halts}.
>>>>
>>>> So you have nothing to say about the problem of deciding whether P(P)
>>>> halts?
>>>
>>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
>>> necessarily correct.
>>
>> The halting problem does not go away because you declare that P(P) is a
>> "non-input".
>
> In other words you are claiming that a decider computes the mapping from
> non-inputs ?

It isn't a non-input. It is the defined behavior of the input that it
was given.

>
> Since you already know this is false and everyone knowing the theory of
> computation knows that this is false it makes no sense to me why you
> would so thoroughly denigrate yourself with such obvious dishonesty.

Note, you are correct that H can't actually compute this behavior, but
that isn't can't as in not allowed, but can't as in unable (but requried
to meet its definition).

>
>>  The problem you used to talk about is still there.  Your
>> supposed answer to that problem is still wrong.  You are just (wisely I
>> might add) trying to avoid talking about it.
>>
>
>

On Monday, 18 April 2022 at 23:58:01 UTC+1, olcott wrote:
> On 4/18/2022 4:53 PM, Ben wrote:
> > olcott <No...@NoWhere.com> writes:
> >
> >> On 4/17/2022 7:09 PM, Ben wrote:
> >>> olcott <No...@NoWhere.com> writes:
> >>>
> >>>> On 4/17/2022 10:11 AM, Ben wrote:
> >>>>> olcott <No...@NoWhere.com> writes:
> >>>>>
> >>>>>>> H(P,P)==false is correct only if P(P) is non halting,
> >>>>>>
> >>>>>> That is false.
> >>>>>> H(P,P)==false is correct if an only if its input is non-halting.
> >>>>>
> >>>>> So do you admit that the problem of deciding what the call does is
> >>>>> indeed undecidable? That would be a massive step forwards.
> >>>>>
> >>>>
> >>>> I admit that when you are looking for a white dog in your living room
> >>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
> >>>> this on the basis of cats in your kitchen {the execution of P(P)
> >>>> halts}.
> >>>
> >>> So you have nothing to say about the problem of deciding whether P(P)
> >>> halts?
> >>
> >> As long as the input to H(P,P) is non-halting then H(P,P)==false is
> >> necessarily correct.
> >
> > The halting problem does not go away because you declare that P(P) is a
> > "non-input".
> In other words you are claiming that a decider computes the mapping from
> non-inputs ?
>
By "the input to H(P,P)", do you mean "those portions of P which exclude the
embedded H"?

On 4/19/2022 5:26 AM, Malcolm McLean wrote:
> On Monday, 18 April 2022 at 23:58:01 UTC+1, olcott wrote:
>> On 4/18/2022 4:53 PM, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 4/17/2022 7:09 PM, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 4/17/2022 10:11 AM, Ben wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>>
>>>>>>>> That is false.
>>>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>>>>>>>
>>>>>>> So do you admit that the problem of deciding what the call does is
>>>>>>> indeed undecidable? That would be a massive step forwards.
>>>>>>>
>>>>>>
>>>>>> I admit that when you are looking for a white dog in your living room
>>>>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
>>>>>> this on the basis of cats in your kitchen {the execution of P(P)
>>>>>> halts}.
>>>>>
>>>>> So you have nothing to say about the problem of deciding whether P(P)
>>>>> halts?
>>>>
>>>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
>>>> necessarily correct.
>>>
>>> The halting problem does not go away because you declare that P(P) is a
>>> "non-input".
>> In other words you are claiming that a decider computes the mapping from
>> non-inputs ?
>>
> By "the input to H(P,P)", do you mean "those portions of P which exclude the
> embedded H"?

There is no embedded_H

The technical computer science term "halt" means that a program will
reach its last instruction technically called its final state. For P
this would be its machine address [000009f0].

The function named H continues to simulate its input using an x86
emulator until this input either halts on its own or H detects that it
would never halt. If its input halts H returns 1. If H detects that its
input would never halt H returns 0.

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

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
}

_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]

The simulated input to H(P,P) cannot possibly reach its own final state
of [000009f0] it keeps repeating [000009d6] to [000009e1] until aborted.

Begin Local Halt Decider Simulation
....[000009d6][00211368][0021136c] 55 push ebp // enter P
....[000009d7][00211368][0021136c] 8bec mov ebp,esp
....[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
....[000009dc][00211364][000009d6] 50 push eax // Push P
....[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][00211360][000009d6] 51 push ecx // Push P
....[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
....[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
....[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
....[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
....[000009dc][0025bd8c][000009d6] 50 push eax // Push P
....[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][0025bd88][000009d6] 51 push ecx // Push P
....[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Because the correctly simulated input to H(P,P) cannot possibly reach
its own final state at [000009f0] it is necessarily correct for H to
reject this input as non-halting.

--
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 4/19/22 7:35 AM, olcott wrote:
> On 4/19/2022 5:26 AM, Malcolm McLean wrote:
>> On Monday, 18 April 2022 at 23:58:01 UTC+1, olcott wrote:
>>> On 4/18/2022 4:53 PM, Ben wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> On 4/17/2022 7:09 PM, Ben wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/17/2022 10:11 AM, Ben wrote:
>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>>>
>>>>>>>>> That is false.
>>>>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>>>>>>>>
>>>>>>>> So do you admit that the problem of deciding what the call does is
>>>>>>>> indeed undecidable? That would be a massive step forwards.
>>>>>>>>
>>>>>>>
>>>>>>> I admit that when you are looking for a white dog in your living
>>>>>>> room
>>>>>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
>>>>>>> this on the basis of cats in your kitchen {the execution of P(P)
>>>>>>> halts}.
>>>>>>
>>>>>> So you have nothing to say about the problem of deciding whether P(P)
>>>>>> halts?
>>>>>
>>>>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
>>>>> necessarily correct.
>>>>
>>>> The halting problem does not go away because you declare that P(P) is a
>>>> "non-input".
>>> In other words you are claiming that a decider computes the mapping from
>>> non-inputs ?
>>>
>> By "the input to H(P,P)", do you mean "those portions of P which
>> exclude the
>> embedded H"?
>
> There is no embedded_H

Flip-Flop, you used to say there was no H!

Basing your arguement on confusing people by changing you conventions is
a sign of a scam.

The clear meaning is the copy of H that is supposed to be in P.

>
> The technical computer science term "halt" means that a program will
> reach its last instruction technically called its final state. For P
> this would be its machine address [000009f0].
>
> The function named H continues to simulate its input using an x86
> emulator until this input either halts on its own or H detects that it
> would never halt. If its input halts H returns 1. If H detects that its
> input would never halt H returns 0.

Right, but a CORRECT simulation of the input to H(P,P) will not abort
its simulation, and see that P call H, and that H will either abort its
simulation and return false to P making P(P) a halting computation, or
it will never abort its simulation, showing that H(P,P) fails to anwers.

Neither version of H returned the right answer, so all version of H
proven themselves to be wrong.

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [000009d6](01) 55         push ebp
> [000009d7](02) 8bec       mov ebp,esp
> [000009d9](03) 8b4508     mov eax,[ebp+08]
> [000009dc](01) 50         push eax         // push P
> [000009dd](03) 8b4d08     mov ecx,[ebp+08]
> [000009e0](01) 51         push ecx         // push P
> [000009e1](05) e840feffff call 00000826    // call H
> [000009e6](03) 83c408     add esp,+08
> [000009e9](02) 85c0       test eax,eax
> [000009eb](02) 7402       jz 000009ef
> [000009ed](02) ebfe       jmp 000009ed
> [000009ef](01) 5d         pop ebp
> [000009f0](01) c3         ret              // Final state
> Size in bytes:(0027) [000009f0]
>
> The simulated input to H(P,P) cannot possibly reach its own final state
> of [000009f0] it keeps repeating [000009d6] to [000009e1] until aborted.

WRONG, as stated above, a CORRECT simulation doesn't abort, as the
machine being simulated doesn't just stop in the middle. Only the
incorrect/partial simulation of H 'stops' here in the middle.

The CORRECT simulation of the input either shows that P is a halting
computation, or that H fails to answer the question.

>
> Begin Local Halt Decider Simulation
> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> Because the correctly simulated input to H(P,P) cannot possibly reach
> its own final state at [000009f0] it is necessarily correct for H to
> reject this input as non-halting.
>

Nope, you have used an INCORRECT Simulation of the input.

A CORRECT simulation will show either that P is halting or H fails to
answer, neither of which is correct.

FAIL.

olcott <NoOne@NoWhere.com> writes:

> On 4/18/2022 4:53 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/17/2022 7:08 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/17/2022 10:37 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/17/2022 10:09 AM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/16/2022 7:45 PM, Ben wrote:
>>>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>>>
>>>>>>>>> That requires a halt decider to compute the mapping from non-inputs on
>>>>>>>>> the basis of the behavior specified by these non-inputs.
>>>>>>>> No.
>>>>>>>> Would you like me to explain again? I won't bother unless you ask
>>>>>>>> nicely because you've ignored it every time I've done so before.
>>>>>>>
>>>>>>> P(P) executed independently is not an input to H(P,P) that you would
>>>>>>> say otherwise makes you a bald faced liar.
>>>>>> So you don't want me to explain? OK. Stay in the dark. That works for
>>>>>> me because nothing makes it more certain that you won't be taken
>>>>>> seriously than pretending that the halting problem is not about the
>>>>>> computations represented by inputs.
>>>>>>
>>>>>> Your problem is that you /have/ to find a way to neutralise what you
>>>>>> said for years about H(P,P)==false and P(P) halting. Unless you can
>>>>>
>>>>> The fact that the correctly simulated input to H(P,P) is non-halting
>>>>> is a 100% sufficient reason for H to report that its input does not
>>>>> halt. That you disagree makes you a bald faced liar.
>>>>
>>>> What makes you think I disagree with that? You won't say what you mean,
>>>> or more exactly, you mean to be vague.
>>>
>>> So then you must agree that when H correctly simulates the input to
>>> H(P,P) that it would never reach its own final state.
>>
>> I think you are just cutting and pasting without any thought now. You
>> may not be the sharpest knife in the drawer, but if you'd read what I
>> wrote I don't believe even you could not possibly think it logical to
>> write that sentence.
>
> You never do anything besides dodge the point at hand so I continue to
> present this point until everyone else realizes that you always only
> dodge it and are thereby dishonest.

That's a truly silly objective, but I suppose it makes sense to you. In
your position, if I had anything important to say I'd publish in a
quality journal rather than obsess about what "everyone else realises"
about some random bloke on Usenet!

I won't parse, yet again, what it is that's wrong with your recent
mantra (I've done so yet again in another reply just a few minutes ago)
because you are wrong on far more basic grounds: H(P,P)==false is
incorrect because P(P) halts.

Nothing you can say can get round this problem. It's the definition of
the problem you took on, and pretending that the correct result is not
based on what P(P) (because it's a "non-input") but on some deliberately
vague attribute of "the input to H(P,P)" does not make the original
problem go away. H does not fit the specification you originally took
on.

> Since there are a total of two points that prove that I am correct I
> am not going to change the subject away from these two points until
> they are fully addressed.

Ah, but then you don't know what a proof is, do you? Do you still think
that if A,B,C ⊦ X then A,B,C,~A ⊬ X?

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

olcott <NoOne@NoWhere.com> writes:

> On 4/18/2022 4:53 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/17/2022 7:09 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/17/2022 10:11 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>
>>>>>>> That is false.
>>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>>>>>>
>>>>>> So do you admit that the problem of deciding what the call does is
>>>>>> indeed undecidable? That would be a massive step forwards.
>>>>>>
>>>>>
>>>>> I admit that when you are looking for a white dog in your living room
>>>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
>>>>> this on the basis of cats in your kitchen {the execution of P(P)
>>>>> halts}.
>>>>
>>>> So you have nothing to say about the problem of deciding whether P(P)
>>>> halts?
>>>
>>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
>>> necessarily correct.
>>
>> The halting problem does not go away because you declare that P(P) is a
>> "non-input".
>
> In other words you are claiming that a decider computes the mapping
> from non-inputs ?

You really must stop these attempts to paraphrase. I don't think anyone
but you is confused about a property of the "input" is used to define
the correct answer. In fact, I think you know it. I think that's why
you could not define a "prime" decider TM -- you knew you'd have to
specify the correct result in terms of the numerical value /represented/
by the input. And numerical values are non-inputs.

Is that why you ducked out of specifying that TM, or could you really
not do it?

> Since you already know this is false and everyone knowing the theory
> of computation knows that this is false it makes no sense to me why
> you would so thoroughly denigrate yourself with such obvious
> dishonesty.

I am content with my reputation for honesty here. How do you stack up:

"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz specs
does not exist. I now have a fully encoded pair of Turing Machines H / Ĥ
proving them wrong."

"Furthermore I have repeated H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn many
times."

"No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
times."

"The fact the a computation stops running does not prove that it
halts."

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
> olcott <No...@NoWhere.com> writes:
>
> > On 4/18/2022 4:53 PM, Ben wrote:
> >> olcott <No...@NoWhere.com> writes:
> >>
> >>> On 4/17/2022 7:09 PM, Ben wrote:
> >>>> olcott <No...@NoWhere.com> writes:
> >>>>
> >>>>> On 4/17/2022 10:11 AM, Ben wrote:
> >>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>
> >>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
> >>>>>>>
> >>>>>>> That is false.
> >>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
> >>>>>>
> >>>>>> So do you admit that the problem of deciding what the call does is
> >>>>>> indeed undecidable? That would be a massive step forwards.
> >>>>>>
> >>>>>
> >>>>> I admit that when you are looking for a white dog in your living room
> >>>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
> >>>>> this on the basis of cats in your kitchen {the execution of P(P)
> >>>>> halts}.
> >>>>
> >>>> So you have nothing to say about the problem of deciding whether P(P)
> >>>> halts?
> >>>
> >>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
> >>> necessarily correct.
> >>
> >> The halting problem does not go away because you declare that P(P) is a
> >> "non-input".
> >
> > In other words you are claiming that a decider computes the mapping
> > from non-inputs ?
> You really must stop these attempts to paraphrase. I don't think anyone
> but you is confused about a property of the "input" is used to define
> the correct answer. In fact, I think you know it. I think that's why
> you could not define a "prime" decider TM -- you knew you'd have to
> specify the correct result in terms of the numerical value /represented/
> by the input. And numerical values are non-inputs.
>
> Is that why you ducked out of specifying that TM, or could you really
> not do it?
>
He needs to write an even-odd decider first. Then try a "divisible by three"
decider. Then write a decider which takes numerator and denominator as
input (hard). Then a prime decider. After that is achieved, it's time to consider
the basic principles on which a UTM could be built. Finally, after we have a
UTM, we can consider whether the UTM can be modified with infinite cycle
detection logic to create a halt decider.
Slowly, each step built on the next. Don't claim to be a brain surgeon when
a) you have no formal medical qualifications and b) you don't know what a
bed pan looks like.

On 4/19/2022 9:39 AM, Malcolm McLean wrote:
> On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
>> olcott <No...@NoWhere.com> writes:

<SNIP>

> Slowly, each step built on the next. Don't claim to be a brain surgeon when
> a) you have no formal medical qualifications and b) you don't know what a
> bed pan looks like.

Since I believe that PO knows what a bedpan looks like, might I conclude
that he's on his way to being a surgeon? If so, he could be more
productive if he added some additional medical newsgroup destinations to
the silly messages he writes. That way he can also seek some information
on his health. (Though I still believe that his cancer claims are just
tools of the troll trade, I could be persuaded otherwise if it were
brain cancer.) In any event, it's food for thought.
--
Jeff Barnett

On Tue, 19 Apr 2022 11:53:06 -0600
Jeff Barnett <jbb@notatt.com> wrote:

> On 4/19/2022 9:39 AM, Malcolm McLean wrote:
> > On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
> >> olcott <No...@NoWhere.com> writes:
>
> <SNIP>
>
> > Slowly, each step built on the next. Don't claim to be a brain
> > surgeon when a) you have no formal medical qualifications and b)
> > you don't know what a bed pan looks like.
>
> Since I believe that PO knows what a bedpan looks like, might I
> conclude that he's on his way to being a surgeon? If so, he could be
> more productive if he added some additional medical newsgroup
> destinations to the silly messages he writes. That way he can also
> seek some information on his health. (Though I still believe that his
> cancer claims are just tools of the troll trade, I could be persuaded
> otherwise if it were brain cancer.) In any event, it's food for
> thought.

Your personality is egregious, mate.

/Flibble

On Tuesday, 19 April 2022 at 18:53:15 UTC+1, Jeff Barnett wrote:
> On 4/19/2022 9:39 AM, Malcolm McLean wrote:
> > On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
> >> olcott <No...@NoWhere.com> writes:
> <SNIP>
> > Slowly, each step built on the next. Don't claim to be a brain surgeon when
> > a) you have no formal medical qualifications and b) you don't know what a
> > bed pan looks like.
> Since I believe that PO knows what a bedpan looks like, might I conclude
> that he's on his way to being a surgeon? If so, he could be more
> productive if he added some additional medical newsgroup destinations to
> the silly messages he writes. That way he can also seek some information
> on his health. (Though I still believe that his cancer claims are just
> tools of the troll trade, I could be persuaded otherwise if it were
> brain cancer.) In any event, it's food for thought.
>
I think you haven't been following the threads. PO compared himself to a
brain surgeon and specifying a simple Turing machine to changing a
bedpan. We don't normally ask surgeons to change bedpans, but we
assume that they would be capable of doing so, if it were an emergency
and a nurse was not available.
The difference is that PO is not a recognised computer scientist. Also, he's
shown himself to have some basic misconceptions about Turing machines,
like the idea that the normal way to move the head 1000 positions is to
have 1000 states. One way to clear that kind of misconception up is to
write a few Turing machines. It's not sufficient qualification to be an expert,
maybe it's not strictly a necessary qualification, but it's how most people
start.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>> > On 4/18/2022 4:53 PM, Ben wrote:
>> >> olcott <No...@NoWhere.com> writes:
>> >>
>> >>> On 4/17/2022 7:09 PM, Ben wrote:
>> >>>> olcott <No...@NoWhere.com> writes:
>> >>>>
>> >>>>> On 4/17/2022 10:11 AM, Ben wrote:
>> >>>>>> olcott <No...@NoWhere.com> writes:
>> >>>>>>
>> >>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>> >>>>>>>
>> >>>>>>> That is false.
>> >>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>> >>>>>>
>> >>>>>> So do you admit that the problem of deciding what the call does is
>> >>>>>> indeed undecidable? That would be a massive step forwards.
>> >>>>>>
>> >>>>>
>> >>>>> I admit that when you are looking for a white dog in your living room
>> >>>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
>> >>>>> this on the basis of cats in your kitchen {the execution of P(P)
>> >>>>> halts}.
>> >>>>
>> >>>> So you have nothing to say about the problem of deciding whether P(P)
>> >>>> halts?
>> >>>
>> >>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
>> >>> necessarily correct.
>> >>
>> >> The halting problem does not go away because you declare that P(P) is a
>> >> "non-input".
>> >
>> > In other words you are claiming that a decider computes the mapping
>> > from non-inputs ?
>> You really must stop these attempts to paraphrase. I don't think anyone
>> but you is confused about a property of the "input" is used to define
>> the correct answer. In fact, I think you know it. I think that's why
>> you could not define a "prime" decider TM -- you knew you'd have to
>> specify the correct result in terms of the numerical value /represented/
>> by the input. And numerical values are non-inputs.
>>
>> Is that why you ducked out of specifying that TM, or could you really
>> not do it?
>>
> He needs to write an even-odd decider first. Then try a "divisible by three"
> decider. Then write a decider which takes numerator and denominator as
> input (hard). Then a prime decider.

I would not typically ask for that. A prime decider is sufficiently
fiddly that the benefit gets lost.

Note that what I asked for was the /specification/ of a prime decider
because PO was specifying a the parity decider in terms of surface
syntax -- the string ends in 0, 2, 4, 6 or 8 (he'd chosen decimal
representation).

> After that is achieved, it's time to consider
> the basic principles on which a UTM could be built. Finally, after we have a
> UTM, we can consider whether the UTM can be modified with infinite cycle
> detection logic to create a halt decider.

Why would we consider this?

The questions I was asking were intended to lead up to how TMs that
decider properties of computations are specified because PO did not
accept how this is done.

> Slowly, each step built on the next. Don't claim to be a brain surgeon when
> a) you have no formal medical qualifications and b) you don't know what a
> bed pan looks like.

--
Ben.

On 4/19/2022 4:32 PM, Malcolm McLean wrote:
> On Tuesday, 19 April 2022 at 18:53:15 UTC+1, Jeff Barnett wrote:
>> On 4/19/2022 9:39 AM, Malcolm McLean wrote:
>>> On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
>>>> olcott <No...@NoWhere.com> writes:
>> <SNIP>
>>> Slowly, each step built on the next. Don't claim to be a brain surgeon when
>>> a) you have no formal medical qualifications and b) you don't know what a
>>> bed pan looks like.
>> Since I believe that PO knows what a bedpan looks like, might I conclude
>> that he's on his way to being a surgeon? If so, he could be more
>> productive if he added some additional medical newsgroup destinations to
>> the silly messages he writes. That way he can also seek some information
>> on his health. (Though I still believe that his cancer claims are just
>> tools of the troll trade, I could be persuaded otherwise if it were
>> brain cancer.) In any event, it's food for thought.
>>
> I think you haven't been following the threads. PO compared himself to a
> brain surgeon and specifying a simple Turing machine to changing a
> bedpan. We don't normally ask surgeons to change bedpans, but we
> assume that they would be capable of doing so, if it were an emergency
> and a nurse was not available.
> The difference is that PO is not a recognised computer scientist. Also, he's
> shown himself to have some basic misconceptions about Turing machines,
> like the idea that the normal way to move the head 1000 positions is to
> have 1000 states. One way to clear that kind of misconception up is to
> write a few Turing machines. It's not sufficient qualification to be an expert,
> maybe it's not strictly a necessary qualification, but it's how most people
> start.

EVERYTHING ELSE IS AN OFF TOPIC DISHONEST DODGE:
The fact that the correctly simulated input to H(P,P) is provably
non-halting is an entirely sufficient basis for H to report that it's
input is non-halting.

--
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 4/19/2022 10:39 AM, Malcolm McLean wrote:
> On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> On 4/18/2022 4:53 PM, Ben wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> On 4/17/2022 7:09 PM, Ben wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/17/2022 10:11 AM, Ben wrote:
>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>>>
>>>>>>>>> That is false.
>>>>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>>>>>>>>
>>>>>>>> So do you admit that the problem of deciding what the call does is
>>>>>>>> indeed undecidable? That would be a massive step forwards.
>>>>>>>>
>>>>>>>
>>>>>>> I admit that when you are looking for a white dog in your living room
>>>>>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
>>>>>>> this on the basis of cats in your kitchen {the execution of P(P)
>>>>>>> halts}.
>>>>>>
>>>>>> So you have nothing to say about the problem of deciding whether P(P)
>>>>>> halts?
>>>>>
>>>>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
>>>>> necessarily correct.
>>>>
>>>> The halting problem does not go away because you declare that P(P) is a
>>>> "non-input".
>>>
>>> In other words you are claiming that a decider computes the mapping
>>> from non-inputs ?
>> You really must stop these attempts to paraphrase. I don't think anyone
>> but you is confused about a property of the "input" is used to define
>> the correct answer. In fact, I think you know it. I think that's why
>> you could not define a "prime" decider TM -- you knew you'd have to
>> specify the correct result in terms of the numerical value /represented/
>> by the input. And numerical values are non-inputs.
>>
>> Is that why you ducked out of specifying that TM, or could you really
>> not do it?
>>
> He needs to write an even-odd decider first. Then try a "divisible by three"
> decider. Then write a decider which takes numerator and denominator as
> input (hard). Then a prime decider. After that is achieved, it's time to consider
> the basic principles on which a UTM could be built. Finally, after we have a
> UTM, we can consider whether the UTM can be modified with infinite cycle
> detection logic to create a halt decider.
> Slowly, each step built on the next. Don't claim to be a brain surgeon when
> a) you have no formal medical qualifications and b) you don't know what a
> bed pan looks like.
>

The fact that the correctly simulated input to H(P,P) is provably
non-halting is an entirely sufficient basis for H to report that it's
input is non-halting.

--
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 4/19/2022 1:24 PM, Mr Flibble wrote:
> On Tue, 19 Apr 2022 11:53:06 -0600
> Jeff Barnett <jbb@notatt.com> wrote:
>
>> On 4/19/2022 9:39 AM, Malcolm McLean wrote:
>>> On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>
>> <SNIP>
>>
>>> Slowly, each step built on the next. Don't claim to be a brain
>>> surgeon when a) you have no formal medical qualifications and b)
>>> you don't know what a bed pan looks like.
>>
>> Since I believe that PO knows what a bedpan looks like, might I
>> conclude that he's on his way to being a surgeon? If so, he could be
>> more productive if he added some additional medical newsgroup
>> destinations to the silly messages he writes. That way he can also
>> seek some information on his health. (Though I still believe that his
>> cancer claims are just tools of the troll trade, I could be persuaded
>> otherwise if it were brain cancer.) In any event, it's food for
>> thought.
>
> Your personality is egregious, mate.
>

He is a jackass that will eventually get his comeuppance. The universe
is intentionally designed to make sure that this will occur.

> /Flibble
>

--
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 4/19/2022 10:05 AM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/18/2022 4:53 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/17/2022 7:08 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/17/2022 10:37 AM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/17/2022 10:09 AM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/16/2022 7:45 PM, Ben wrote:
>>>>>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>>>>>>>>>>
>>>>>>>>>> That requires a halt decider to compute the mapping from non-inputs on
>>>>>>>>>> the basis of the behavior specified by these non-inputs.
>>>>>>>>> No.
>>>>>>>>> Would you like me to explain again? I won't bother unless you ask
>>>>>>>>> nicely because you've ignored it every time I've done so before.
>>>>>>>>
>>>>>>>> P(P) executed independently is not an input to H(P,P) that you would
>>>>>>>> say otherwise makes you a bald faced liar.
>>>>>>> So you don't want me to explain? OK. Stay in the dark. That works for
>>>>>>> me because nothing makes it more certain that you won't be taken
>>>>>>> seriously than pretending that the halting problem is not about the
>>>>>>> computations represented by inputs.
>>>>>>>
>>>>>>> Your problem is that you /have/ to find a way to neutralise what you
>>>>>>> said for years about H(P,P)==false and P(P) halting. Unless you can
>>>>>>
>>>>>> The fact that the correctly simulated input to H(P,P) is non-halting
>>>>>> is a 100% sufficient reason for H to report that its input does not
>>>>>> halt. That you disagree makes you a bald faced liar.
>>>>>
>>>>> What makes you think I disagree with that? You won't say what you mean,
>>>>> or more exactly, you mean to be vague.
>>>>
>>>> So then you must agree that when H correctly simulates the input to
>>>> H(P,P) that it would never reach its own final state.
>>>
>>> I think you are just cutting and pasting without any thought now. You
>>> may not be the sharpest knife in the drawer, but if you'd read what I
>>> wrote I don't believe even you could not possibly think it logical to
>>> write that sentence.
>>
>> You never do anything besides dodge the point at hand so I continue to
>> present this point until everyone else realizes that you always only
>> dodge it and are thereby dishonest.
>
> That's a truly silly objective, but I suppose it makes sense to you. In
> your position, if I had anything important to say I'd publish in a
> quality journal rather than obsess about what "everyone else realises"
> about some random bloke on Usenet!
>
> I won't parse, yet again, what it is that's wrong with your recent
> mantra (I've done so yet again in another reply just a few minutes ago)
> because you are wrong on far more basic grounds: H(P,P)==false is
> incorrect because P(P) halts.
>
> Nothing you can say can get round this problem. It's the definition of
> the problem you took on, and pretending that the correct result is not
> based on what P(P) (because it's a "non-input") but on some deliberately
> vague attribute of "the input to H(P,P)" does not make the original
> problem go away. H does not fit the specification you originally took
> on.
>
>> Since there are a total of two points that prove that I am correct I
>> am not going to change the subject away from these two points until
>> they are fully addressed.
>
> Ah, but then you don't know what a proof is, do you? Do you still think
> that if A,B,C ⊦ X then A,B,C,~A ⊬ X?
>

If {an X is a Y} and Z says that {an X is a Y} then Z is necessarily
correct.

When a sequence of configurations never halts then this sequence is
non-halting making H(P,P)==0 necessarily correct.

--
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 Wednesday, 20 April 2022 at 00:52:13 UTC+1, Ben wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
> >> olcott <No...@NoWhere.com> writes:
> >>
> >> > On 4/18/2022 4:53 PM, Ben wrote:
> >> >> olcott <No...@NoWhere.com> writes:
> >> >>
> >> >>> On 4/17/2022 7:09 PM, Ben wrote:
> >> >>>> olcott <No...@NoWhere.com> writes:
> >> >>>>
> >> >>>>> On 4/17/2022 10:11 AM, Ben wrote:
> >> >>>>>> olcott <No...@NoWhere.com> writes:
> >> >>>>>>
> >> >>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
> >> >>>>>>>
> >> >>>>>>> That is false.
> >> >>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
> >> >>>>>>
> >> >>>>>> So do you admit that the problem of deciding what the call does is
> >> >>>>>> indeed undecidable? That would be a massive step forwards.
> >> >>>>>>
> >> >>>>>
> >> >>>>> I admit that when you are looking for a white dog in your living room
> >> >>>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
> >> >>>>> this on the basis of cats in your kitchen {the execution of P(P)
> >> >>>>> halts}.
> >> >>>>
> >> >>>> So you have nothing to say about the problem of deciding whether P(P)
> >> >>>> halts?
> >> >>>
> >> >>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
> >> >>> necessarily correct.
> >> >>
> >> >> The halting problem does not go away because you declare that P(P) is a
> >> >> "non-input".
> >> >
> >> > In other words you are claiming that a decider computes the mapping
> >> > from non-inputs ?
> >> You really must stop these attempts to paraphrase. I don't think anyone
> >> but you is confused about a property of the "input" is used to define
> >> the correct answer. In fact, I think you know it. I think that's why
> >> you could not define a "prime" decider TM -- you knew you'd have to
> >> specify the correct result in terms of the numerical value /represented/
> >> by the input. And numerical values are non-inputs.
> >>
> >> Is that why you ducked out of specifying that TM, or could you really
> >> not do it?
> >>
> > He needs to write an even-odd decider first. Then try a "divisible by three"
> > decider. Then write a decider which takes numerator and denominator as
> > input (hard). Then a prime decider.
> I would not typically ask for that. A prime decider is sufficiently
> fiddly that the benefit gets lost.
>
> Note that what I asked for was the /specification/ of a prime decider
> because PO was specifying a the parity decider in terms of surface
> syntax -- the string ends in 0, 2, 4, 6 or 8 (he'd chosen decimal
> representation).
> > After that is achieved, it's time to consider
> > the basic principles on which a UTM could be built. Finally, after we have a
> > UTM, we can consider whether the UTM can be modified with infinite cycle
> > detection logic to create a halt decider.
> Why would we consider this?
>
Where have you been? All of these threads have been about whether a UTM can
be modified by the addition of infinite cycle detection logic to become a halt
decider.
But PO doesn't yet know how to write a UTM. He's got what he calls a "UTM-
equivalent", but it operates on x86 assembly code, and there are certain differences
from Turing machines which seem to be causing confusion. For instance x86 code
has subroutines which can be identified by address, whilst Turing machines don't.

If we had an actual universal Turing machine, that would be a good basis on which
to work.
> The questions I was asking were intended to lead up to how TMs that
> decider properties of computations are specified because PO did not
> accept how this is done.
>
Right. I'd suggest that this is something you are likely to "get" as a natural
consequence of writing machines. For instance, having written an even-odd
decider, in unary or binary are the easiest choices, a natural next step is to
write the decider that uses the other representation. That way, you come to
understand that the same information can be encoded in different ways,
without necessarily being taught that explictly. Similarly, having written a few
machines to do various things, some are "deciders" - (separate the input into
two groups , "yes/no") and some are "mappers" (produce another pattern on
the tape which is related to the input, e.g. the sum of two numbers).

The other thing is that, having written a few basic Turing machines, you can
explore machines which are related to the halting problem, but not
identical to it. You can write a busy beaver. This is interesting, and it
gives a sense of achievement.

Really it's time to write some machines.

You guys might all be missing something simple: The "correct simulation" does halt. So when the decider says it doesn't halt, it's wrong.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 20 April 2022 at 00:52:13 UTC+1, Ben wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Tuesday, 19 April 2022 at 16:15:38 UTC+1, Ben wrote:
>> >> olcott <No...@NoWhere.com> writes:
>> >>
>> >> > On 4/18/2022 4:53 PM, Ben wrote:
>> >> >> olcott <No...@NoWhere.com> writes:
>> >> >>
>> >> >>> On 4/17/2022 7:09 PM, Ben wrote:
>> >> >>>> olcott <No...@NoWhere.com> writes:
>> >> >>>>
>> >> >>>>> On 4/17/2022 10:11 AM, Ben wrote:
>> >> >>>>>> olcott <No...@NoWhere.com> writes:
>> >> >>>>>>
>> >> >>>>>>>> H(P,P)==false is correct only if P(P) is non halting,
>> >> >>>>>>>
>> >> >>>>>>> That is false.
>> >> >>>>>>> H(P,P)==false is correct if an only if its input is non-halting.
>> >> >>>>>>
>> >> >>>>>> So do you admit that the problem of deciding what the call does is
>> >> >>>>>> indeed undecidable? That would be a massive step forwards.
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>> I admit that when you are looking for a white dog in your living room
>> >> >>>>> {that the simulated input to H(P,P) halts} it is incorrect to answer
>> >> >>>>> this on the basis of cats in your kitchen {the execution of P(P)
>> >> >>>>> halts}.
>> >> >>>>
>> >> >>>> So you have nothing to say about the problem of deciding whether P(P)
>> >> >>>> halts?
>> >> >>>
>> >> >>> As long as the input to H(P,P) is non-halting then H(P,P)==false is
>> >> >>> necessarily correct.
>> >> >>
>> >> >> The halting problem does not go away because you declare that P(P) is a
>> >> >> "non-input".
>> >> >
>> >> > In other words you are claiming that a decider computes the mapping
>> >> > from non-inputs ?
>> >> You really must stop these attempts to paraphrase. I don't think anyone
>> >> but you is confused about a property of the "input" is used to define
>> >> the correct answer. In fact, I think you know it. I think that's why
>> >> you could not define a "prime" decider TM -- you knew you'd have to
>> >> specify the correct result in terms of the numerical value /represented/
>> >> by the input. And numerical values are non-inputs.
>> >>
>> >> Is that why you ducked out of specifying that TM, or could you really
>> >> not do it?
>> >>
>> > He needs to write an even-odd decider first. Then try a "divisible by three"
>> > decider. Then write a decider which takes numerator and denominator as
>> > input (hard). Then a prime decider.
>> I would not typically ask for that. A prime decider is sufficiently
>> fiddly that the benefit gets lost.
>>
>> Note that what I asked for was the /specification/ of a prime decider
>> because PO was specifying a the parity decider in terms of surface
>> syntax -- the string ends in 0, 2, 4, 6 or 8 (he'd chosen decimal
>> representation).
>>
>> > After that is achieved, it's time to consider the basic principles
>> > on which a UTM could be built. Finally, after we have a UTM, we can
>> > consider whether the UTM can be modified with infinite cycle
>> > detection logic to create a halt decider.
>>
>> Why would we consider this?
>>
> Where have you been? All of these threads have been about whether a UTM can
> be modified by the addition of infinite cycle detection logic to become a halt
> decider.

Of course. But you said "we" in some sort of general sense. Cranks
consider such things, but no one else does.

> But PO doesn't yet know how to write a UTM. He's got what he calls a
> "UTM- equivalent", but it operates on x86 assembly code, and there are
> certain differences from Turing machines which seem to be causing
> confusion. For instance x86 code has subroutines which can be
> identified by address, whilst Turing machines don't.

Does any of that profound confusion lead to his claiming that the wrong
answer is the right tone? The irony is that by examining the context of
a C function's execution, it would be possible to write H so that H(P,P)
== true /and/ have P(P) halt.

> If we had an actual universal Turing machine, that would be a good
> basis on which to work.

I don't think so. He is currently rejecting the very specification of a
halt decider.

A UTM that is clearly a UTM is very messy, while the simple ones are
UTMs in the a sense that is too abstract for PO to grasp. A Lisp model
works well because a Lisp evaluator (ULM?) can be written in not too
many lines of Lisp. But that's so far out if PO's wheelhouse that it's
a non-starter.

>> The questions I was asking were intended to lead up to how TMs that
>> decider properties of computations are specified because PO did not
>> accept how this is done.
>>
> Right. I'd suggest that this is something you are likely to "get" as a
> natural consequence of writing machines. For instance, having written
> an even-odd decider, in unary or binary are the easiest choices, a
> natural next step is to write the decider that uses the other
> representation. That way, you come to understand that the same
> information can be encoded in different ways, without necessarily
> being taught that explictly. Similarly, having written a few machines
> to do various things, some are "deciders" - (separate the input into
> two groups , "yes/no") and some are "mappers" (produce another pattern
> on the tape which is related to the input, e.g. the sum of two
> numbers).

All good starting points but if he can't write a parity decider, we'll
get nowhere.

His latest ruse it to say that stating that H(X,Y) must decide on the
halting of X(Y) is in some way "against the rules" because X(Y) is a
"non-input". And then by being vague about "the input to H(P,P)" he is
trying to say that what P(P) does is irrelevant.

What PO needs to learn is that it is perfectly valid to specify a TM
that decides some property of a computation:

E5 <M> y ⊦* qy
if (and only if) M applied to y (or M(y)) makes more than 5 steps.

My exercises were leading up to having an actual encoded TM (E) so PO
could see how this specification works for real encoded TM. I was
aiming to address only the specific "P(P) is a non-input" daftness.

I never thought that writing a TM with just a few states would be the
blocker.

> The other thing is that, having written a few basic Turing machines, you can
> explore machines which are related to the halting problem, but not
> identical to it. You can write a busy beaver. This is interesting, and it
> gives a sense of achievement.

Yes.

> Really it's time to write some machines.

I don't think that is going to happen. He thinks I'm lying and I don't
think he has much more respect for you, despite your clearly
good-natured posts.

--
Ben.