On Thursday, 26 May 2022 at 21:39:00 UTC+8, olcott wrote:
> On 5/26/2022 8:22 AM, wij wrote:
> > On Thursday, 26 May 2022 at 12:28:24 UTC+8, olcott wrote:
> >>> ...[cut]
> >>> What is shown is that you lie all the time, since there has never been a real H.
> >>>
> >> The originl H was published over a year ago, only design was published.
> >
> > People had been asking for the source of H since it is declared done.
> > But, no one has ever seen it. The absence of your H is itself a solid proof
> > that a correct halting decider is impossible (GUR). I don't see any reason to
> > argue that "H(P,P)==0" is correct simply because no such 'H' exists. And, anyone
> > understands computation knows your H is a 'manual' (plus free-will) decider,
> > which cannot be a valid decider.
> >
> > GUR: A correct halting decider is impossible. Thanks to olcott's tireless
> > efforts of more than a decay for GUR which proves a correct halting decider cannot exist.
> If you were sufficiently technically competent you would be able to
> reverse-engineer this:
> H simulates P
> ...[00001352][0021233e][00212342] 55 push ebp // enter P
> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50 push eax // push P
> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51 push ecx // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> The simulated P calls H
> H is simulated simulating P yet the simulation of H is not shown
> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50 push eax // push P
> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> entirely on the basis of this and knowing that H performs and x86
> emulation of its input.
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

What do you expect reviewers to do ???
Deduce from x86 translation of C code of P, and must 'agree' your "H(P,P)==0" is correct?
You have demonstrated enough garbage showing my GUR is correct.

GUR: A correct halting decider is impossible. Thanks to olcott's tireless
efforts of more than a decay for GUR which proves a correct halting decider cannot exist.

On 5/26/22 9:38 AM, olcott wrote:
> On 5/26/2022 8:22 AM, wij wrote:
>> On Thursday, 26 May 2022 at 12:28:24 UTC+8, olcott wrote:
>>>> ...[cut]
>>>> What is shown is that you lie all the time, since there has never
>>>> been a real H.
>>>>
>>> The originl H was published over a year ago, only design was published.
>>
>> People had been asking for the source of H since it is declared done.
>> But, no one has ever seen it. The absence of your H is itself a solid
>> proof
>> that a correct halting decider is impossible (GUR). I don't see any
>> reason to
>> argue that "H(P,P)==0" is correct simply because no such 'H' exists.
>> And, anyone
>> understands computation knows your H is a 'manual' (plus free-will)
>> decider,
>> which cannot be a valid decider.
>>
>> GUR: A correct halting decider is impossible. Thanks to olcott's tireless
>> efforts of more than a decay for GUR which proves a correct halting
>> decider cannot exist.
>
> If you were sufficiently technically competent you would be able to
> reverse-engineer this:
>
> H simulates P
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> The simulated P calls H
> H is simulated simulating P yet the simulation of H is not shown
> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

So, we have that H sees that the H it is simulating will simulate the
same input as it was.

That means that the H is it simulating and that this H is deciding to
abort, would ALSO abort its input after one more cycle, so it is NOT
infinitely recursive, the H is wrong in its decision.

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

Let me ask you, WHAT IS THE DEFINITION OF CORRECT SIMULATION?

You say it is based on the clear interpreation of the x86 code, but the
BEST clear interpreation of that code would be just givning it to the
processor.

Thus it seems that you should be defining the correct simulation of the
input to H(P,P) as what the direct execution of P(P) does, since that is
what the x86 processor would say it does.

You need to explain how this is NOT the actual correct simulation of the
input to H?

Note, that code IS the input to H (not a non-input) as H gets the exact
code that the processor would see, so that is exactly the input.

It seems you must have made some error in saying this isn't the input to
H, since it LITERALLY is the input to H, the exact code that the x8
processor would run.

Or, are you saying that H can't actually duplicate what an x86 processor
does, and thus actual simulation is impossible, because that would imply
that trying to do Halt Deciding via simulation would be stupid, if you
can't actually simulate a program accurateluy.

The real answer is just that H is just wrong in its logic, as H1 shows
us, but you are to pig headed and ignorant to see that.

FAIL.

On 5/26/2022 6:01 PM, Richard Damon wrote:
>
> On 5/26/22 9:38 AM, olcott wrote:
>> On 5/26/2022 8:22 AM, wij wrote:
>>> On Thursday, 26 May 2022 at 12:28:24 UTC+8, olcott wrote:
>>>>> ...[cut]
>>>>> What is shown is that you lie all the time, since there has never
>>>>> been a real H.
>>>>>
>>>> The originl H was published over a year ago, only design was published.
>>>
>>> People had been asking for the source of H since it is declared done.
>>> But, no one has ever seen it. The absence of your H is itself a solid
>>> proof
>>> that a correct halting decider is impossible (GUR). I don't see any
>>> reason to
>>> argue that "H(P,P)==0" is correct simply because no such 'H' exists.
>>> And, anyone
>>> understands computation knows your H is a 'manual' (plus free-will)
>>> decider,
>>> which cannot be a valid decider.
>>>
>>> GUR: A correct halting decider is impossible. Thanks to olcott's
>>> tireless
>>> efforts of more than a decay for GUR which proves a correct halting
>>> decider cannot exist.
>>
>> If you were sufficiently technically competent you would be able to
>> reverse-engineer this:
>>
>> H simulates P
>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>
>> The simulated P calls H
>> H is simulated simulating P yet the simulation of H is not shown
>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
>> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> So, we have that H sees that the H it is simulating will simulate the
> same input as it was.
>
> That means that the H is it simulating and that this H is deciding to
> abort, would ALSO abort its input after one more cycle, so it is NOT
> infinitely recursive, the H is wrong in its decision.

The reason that I truly believe that you must have actual brain damage
is that I have told you that the criteria is that the correctly
simulated P cannot possibly reach its own final state and you cannot
remember this from one post to the next even when I remind you 500 times.

Also when I do say this you say (knowing that the simulation of P will
never stop unless H aborts it) and (that an aborted simulation cannot
reach its the final state of the simulated input) that P reaches its
final state anyway.

>
>>
>> entirely on the basis of this and knowing that H performs and x86
>> emulation of its input.
>>
>> _P()
>> [00001352](01)  55              push ebp
>> [00001353](02)  8bec            mov ebp,esp
>> [00001355](03)  8b4508          mov eax,[ebp+08]
>> [00001358](01)  50              push eax      // push P
>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>> [0000135c](01)  51              push ecx      // push P
>> [0000135d](05)  e840feffff      call 000011a2 // call H
>> [00001362](03)  83c408          add esp,+08
>> [00001365](02)  85c0            test eax,eax
>> [00001367](02)  7402            jz 0000136b
>> [00001369](02)  ebfe            jmp 00001369
>> [0000136b](01)  5d              pop ebp
>> [0000136c](01)  c3              ret
>> Size in bytes:(0027) [0000136c]
>>
>
> Let me ask you, WHAT IS THE DEFINITION OF CORRECT SIMULATION?
>
> You say it is based on the clear interpreation of the x86 code, but the
> BEST clear interpreation of that code would be just givning it to the
> processor.
>
> Thus it seems that you should be defining the correct simulation of the
> input to H(P,P) as what the direct execution of P(P) does, since that is
> what the x86 processor would say it does.
>
> You need to explain how this is NOT the actual correct simulation of the
> input to H?
>
> Note, that code IS the input to H (not a non-input) as H gets the exact
> code that the processor would see, so that is exactly the input.
>
> It seems you must have made some error in saying this isn't the input to
> H, since it LITERALLY is the input to H, the exact code that the x8
> processor would run.
>
> Or, are you saying that H can't actually duplicate what an x86 processor
> does, and thus actual simulation is impossible, because that would imply
> that trying to do Halt Deciding via simulation would be stupid, if you
> can't actually simulate a program accurateluy.
>
>
> The real answer is just that H is just wrong in its logic, as H1 shows
> us, but you are to pig headed and ignorant to see that.
>
> FAIL.

--
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/26/22 8:01 PM, olcott wrote:
> On 5/26/2022 6:01 PM, Richard Damon wrote:
>>
>> On 5/26/22 9:38 AM, olcott wrote:
>>> On 5/26/2022 8:22 AM, wij wrote:
>>>> On Thursday, 26 May 2022 at 12:28:24 UTC+8, olcott wrote:
>>>>>> ...[cut]
>>>>>> What is shown is that you lie all the time, since there has never
>>>>>> been a real H.
>>>>>>
>>>>> The originl H was published over a year ago, only design was
>>>>> published.
>>>>
>>>> People had been asking for the source of H since it is declared done.
>>>> But, no one has ever seen it. The absence of your H is itself a
>>>> solid proof
>>>> that a correct halting decider is impossible (GUR). I don't see any
>>>> reason to
>>>> argue that "H(P,P)==0" is correct simply because no such 'H' exists.
>>>> And, anyone
>>>> understands computation knows your H is a 'manual' (plus free-will)
>>>> decider,
>>>> which cannot be a valid decider.
>>>>
>>>> GUR: A correct halting decider is impossible. Thanks to olcott's
>>>> tireless
>>>> efforts of more than a decay for GUR which proves a correct halting
>>>> decider cannot exist.
>>>
>>> If you were sufficiently technically competent you would be able to
>>> reverse-engineer this:
>>>
>>> H simulates P
>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>
>>> The simulated P calls H
>>> H is simulated simulating P yet the simulation of H is not shown
>>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
>>> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> So, we have that H sees that the H it is simulating will simulate the
>> same input as it was.
>>
>> That means that the H is it simulating and that this H is deciding to
>> abort, would ALSO abort its input after one more cycle, so it is NOT
>> infinitely recursive, the H is wrong in its decision.
>
> The reason that I truly believe that you must have actual brain damage
> is that I have told you that the criteria is that the correctly
> simulated P cannot possibly reach its own final state and you cannot
> remember this from one post to the next even when I remind you 500 times.

Except you STILL won't define what it means to "CORRECTLY SIMULATE" the
input.

>
> Also when I do say this you say (knowing that the simulation of P will
> never stop unless H aborts it) and (that an aborted simulation cannot
> reach its the final state of the simulated input) that P reaches its
> final state anyway.
>
So, H either does, or it doesn't abort, it can't waffle, and each choice
generates a DIFFERENT program P, since the PROGRAM P includes its H.
(Which is one reason the way you try to define what your rerpesentation
of P is incorrect)

If it DOES abort, and returns non-halting, then a CORRECT simulation, at
least by how everyone else defines it, shows that the input WOULD have
reached that ret instruction, if the deciding H didn't abort (without
changing the algorithm in P) thus showing it was wrong to do so.

If it doesn't abort, then it is clear that H fails to answer and thus
isn't a decider.

All your argument about "any" H does is show that ALL the deciders built
by your algorithm all make the same mistake, or possible, that you don't
actually have a program in mind, just a meta-program that can't actually
be implemented.

Remember, H needs to be a DEFINITE program and that program gets
embedded as part of the P, so when you talk about alternate behavior to
show necessity, that doesn't affect the H that the P is calling.

>
>>
>>>
>>> entirely on the basis of this and knowing that H performs and x86
>>> emulation of its input.
>>>
>>> _P()
>>> [00001352](01)  55              push ebp
>>> [00001353](02)  8bec            mov ebp,esp
>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>> [00001358](01)  50              push eax      // push P
>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000135c](01)  51              push ecx      // push P
>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> [00001362](03)  83c408          add esp,+08
>>> [00001365](02)  85c0            test eax,eax
>>> [00001367](02)  7402            jz 0000136b
>>> [00001369](02)  ebfe            jmp 00001369
>>> [0000136b](01)  5d              pop ebp
>>> [0000136c](01)  c3              ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>
>> Let me ask you, WHAT IS THE DEFINITION OF CORRECT SIMULATION?
>>
>> You say it is based on the clear interpreation of the x86 code, but
>> the BEST clear interpreation of that code would be just givning it to
>> the processor.
>>
>> Thus it seems that you should be defining the correct simulation of
>> the input to H(P,P) as what the direct execution of P(P) does, since
>> that is what the x86 processor would say it does.
>>
>> You need to explain how this is NOT the actual correct simulation of
>> the input to H?
>>
>> Note, that code IS the input to H (not a non-input) as H gets the
>> exact code that the processor would see, so that is exactly the input.
>>
>> It seems you must have made some error in saying this isn't the input
>> to H, since it LITERALLY is the input to H, the exact code that the x8
>> processor would run.
>>
>> Or, are you saying that H can't actually duplicate what an x86
>> processor does, and thus actual simulation is impossible, because that
>> would imply that trying to do Halt Deciding via simulation would be
>> stupid, if you can't actually simulate a program accurateluy.
>>
>>
>> The real answer is just that H is just wrong in its logic, as H1 shows
>> us, but you are to pig headed and ignorant to see that.
>>
>> FAIL.
>
>

On 5/26/2022 7:49 PM, Richard Damon wrote:
> On 5/26/22 8:01 PM, olcott wrote:
>> On 5/26/2022 6:01 PM, Richard Damon wrote:
>>>
>>> On 5/26/22 9:38 AM, olcott wrote:
>>>> On 5/26/2022 8:22 AM, wij wrote:
>>>>> On Thursday, 26 May 2022 at 12:28:24 UTC+8, olcott wrote:
>>>>>>> ...[cut]
>>>>>>> What is shown is that you lie all the time, since there has never
>>>>>>> been a real H.
>>>>>>>
>>>>>> The originl H was published over a year ago, only design was
>>>>>> published.
>>>>>
>>>>> People had been asking for the source of H since it is declared done.
>>>>> But, no one has ever seen it. The absence of your H is itself a
>>>>> solid proof
>>>>> that a correct halting decider is impossible (GUR). I don't see any
>>>>> reason to
>>>>> argue that "H(P,P)==0" is correct simply because no such 'H'
>>>>> exists. And, anyone
>>>>> understands computation knows your H is a 'manual' (plus free-will)
>>>>> decider,
>>>>> which cannot be a valid decider.
>>>>>
>>>>> GUR: A correct halting decider is impossible. Thanks to olcott's
>>>>> tireless
>>>>> efforts of more than a decay for GUR which proves a correct halting
>>>>> decider cannot exist.
>>>>
>>>> If you were sufficiently technically competent you would be able to
>>>> reverse-engineer this:
>>>>
>>>> H simulates P
>>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>
>>>> The simulated P calls H
>>>> H is simulated simulating P yet the simulation of H is not shown
>>>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
>>>> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>>>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>>>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>>>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>>>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> So, we have that H sees that the H it is simulating will simulate the
>>> same input as it was.
>>>
>>> That means that the H is it simulating and that this H is deciding to
>>> abort, would ALSO abort its input after one more cycle, so it is NOT
>>> infinitely recursive, the H is wrong in its decision.
>>
>> The reason that I truly believe that you must have actual brain damage
>> is that I have told you that the criteria is that the correctly
>> simulated P cannot possibly reach its own final state and you cannot
>> remember this from one post to the next even when I remind you 500 times.
>
> Except you STILL won't define what it means to "CORRECTLY SIMULATE" the
> input.
>
I explained that 50? times too go back and look at what I said.

--
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/26/22 8:57 PM, olcott wrote:
> On 5/26/2022 7:49 PM, Richard Damon wrote:
>> On 5/26/22 8:01 PM, olcott wrote:
>>> On 5/26/2022 6:01 PM, Richard Damon wrote:
>>>>
>>>> On 5/26/22 9:38 AM, olcott wrote:
>>>>> On 5/26/2022 8:22 AM, wij wrote:
>>>>>> On Thursday, 26 May 2022 at 12:28:24 UTC+8, olcott wrote:
>>>>>>>> ...[cut]
>>>>>>>> What is shown is that you lie all the time, since there has
>>>>>>>> never been a real H.
>>>>>>>>
>>>>>>> The originl H was published over a year ago, only design was
>>>>>>> published.
>>>>>>
>>>>>> People had been asking for the source of H since it is declared done.
>>>>>> But, no one has ever seen it. The absence of your H is itself a
>>>>>> solid proof
>>>>>> that a correct halting decider is impossible (GUR). I don't see
>>>>>> any reason to
>>>>>> argue that "H(P,P)==0" is correct simply because no such 'H'
>>>>>> exists. And, anyone
>>>>>> understands computation knows your H is a 'manual' (plus
>>>>>> free-will) decider,
>>>>>> which cannot be a valid decider.
>>>>>>
>>>>>> GUR: A correct halting decider is impossible. Thanks to olcott's
>>>>>> tireless
>>>>>> efforts of more than a decay for GUR which proves a correct
>>>>>> halting decider cannot exist.
>>>>>
>>>>> If you were sufficiently technically competent you would be able to
>>>>> reverse-engineer this:
>>>>>
>>>>> H simulates P
>>>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>>
>>>>> The simulated P calls H
>>>>> H is simulated simulating P yet the simulation of H is not shown
>>>>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
>>>>> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>>>>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>>>>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>>>>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>>>>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> So, we have that H sees that the H it is simulating will simulate
>>>> the same input as it was.
>>>>
>>>> That means that the H is it simulating and that this H is deciding
>>>> to abort, would ALSO abort its input after one more cycle, so it is
>>>> NOT infinitely recursive, the H is wrong in its decision.
>>>
>>> The reason that I truly believe that you must have actual brain
>>> damage is that I have told you that the criteria is that the
>>> correctly simulated P cannot possibly reach its own final state and
>>> you cannot remember this from one post to the next even when I remind
>>> you 500 times.
>>
>> Except you STILL won't define what it means to "CORRECTLY SIMULATE"
>> the input.
>>
> I explained that 50? times too go back and look at what I said.
>

No, you haven't, all you have done is try to stipulate that H is
correct, which is not a valid stipulation,

Of course, the only VALID definition of correct is matching the behavior
of the x86 CPU executing the code, but then the correct simulation of
the input to H(P,P) matches P(P) which you say it isn't, but you have
NEVER actaully defined the criteria that means "correct" (note, examples
are not definitions either).

If you want to point to ONE of the "50?" messages where you actually
DEFINE the meaning of a correct simuation, do so be shown to be a liar.

You rarely actually define a term, which is the heart of your deception,
by having shifting meaning you can "prove" incorrect statements.

On 5/26/22 9:35 AM, olcott wrote:
> On 5/26/2022 6:21 AM, Ben wrote:
>> Malcolm McLean <malcolm.arthur.mclean@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"?
>>
>
> The only reason that you do not see the significance of this is that the
> depth of your understanding is learned-by-rote.
>
> Someone with a deeper understanding would realize that your
> interpretation that a halt decider must compute its mapping from a
> non-input would understand that this would violate the definition of a
> computable function and the definition of a decider.

No, it only CAN compute what can be determined by its processing of the
input, but a "something" decider MUST compute the "something" mapping
defined, and if that is not possible, the mapping just isn't computable.

You err in presuming (incorrectly) that the Halting Mapping Must be
Computable, and thus feel the ability to redefine it when you find it isn't

That just proves that you don't know what you are doing.

>
> They would understand that a halt determiner must only compute the
> mapping from its input to its own final accept or reject state on the
> basis of the behavior that this input actually specifies.
>

No, to be "Just a Decider", then that is what it CAN do, but to claim to
be a Halt Decider, then the results must match the Halting Function.

What you are saying is like claiming to be immortal, but saying that
since human bodies will die, we just need to change the definition of
immortality,

> If we take your interpretation as correct then computer scientists we be
> agreeing that it is perfectly OK for the requirements of a decision
> problem to violate the principles of computer science and still be a
> valid decision problem.

And, it this sense, it is, because there is no requirement that Halt
Deciders actually need to exist, and a perfectly fine answer is that
there is no such thing.

>
> Then we have other undecidable decision problems such as calculating
> whether or not the square root of a plate of scrambled eggs > 5.

Nope, not the same. The Halting Function is well defined, and if an H
existed, then the Halting of H^ applied to <H^> would be well defined
for the H^ built on that H.

>
>>> Well that's something a bit new and different.
>>
>> Being different is key for any Usenet maths crank.  No two people who
>> have "refuted Cantor" or "solved halting" will agree with each other for
>> long.  Fortunately there are infinitely many ways to be wrong, but only
>> one way to be right so it's not hard to achieve.
>>
>
>

On 5/26/2022 9:50 PM, Richard Damon wrote:
> On 5/26/22 9:35 AM, olcott wrote:
>> On 5/26/2022 6:21 AM, Ben wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@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"?
>>>
>>
>> The only reason that you do not see the significance of this is that
>> the depth of your understanding is learned-by-rote.
>>
>> Someone with a deeper understanding would realize that your
>> interpretation that a halt decider must compute its mapping from a
>> non-input would understand that this would violate the definition of a
>> computable function and the definition of a decider.
>
> No, it only CAN compute what can be determined by its processing of the
> input, but a "something" decider MUST compute the "something" mapping
> defined,
You just contradicted yourself.

The set of deciders only applies to input finite strings. It can apply
any computable criteria to these inputs. I know these things first-hand
not merely by the rote from textbooks.

--
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/26/2022 6:21 AM, Ben wrote:
> Malcolm McLean <malcolm.arthur.mclean@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.

OK then you just proved that you are not a liar on this point.
That would mean that you are not a liar.

> 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"?
>

That we do not agree on this other point does not imply any
dishonesty on your part.

>> Well that's something a bit new and different.
>
> Being different is key for any Usenet maths crank. No two people who
> have "refuted Cantor" or "solved halting" will agree with each other for
> long. Fortunately there are infinitely many ways to be wrong, but only
> one way to be right so it's not hard to achieve.
>

--
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/26/2022 6:21 AM, Ben wrote:
> Malcolm McLean <malcolm.arthur.mclean@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),

Any input that does not map to finite string(s) is not in the computable
function domain. H_Hat(H_Hat) does not map to finite string inputs to H.

> I don't see
> what's interesting about it being correct. Do you really think it's
> "deciding" some interesting property of the "input"?
>
>> Well that's something a bit new and different.
>
> Being different is key for any Usenet maths crank. No two people who
> have "refuted Cantor" or "solved halting" will agree with each other for
> long. Fortunately there are infinitely many ways to be wrong, but only
> one way to be right so it's not hard to achieve.
>

--
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/2022 12:20 AM, olcott wrote:
> On 5/26/2022 6:21 AM, Ben wrote:
>> Malcolm McLean <malcolm.arthur.mclean@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),
>
> Any input that does not map to finite string(s) is not in the computable
> function domain. H_Hat(H_Hat) does not map to finite string inputs to H.
>

All elements in the computable function domain must form a bijection to
sets of finite strings.

>
>> I don't see
>> what's interesting about it being correct.  Do you really think it's
>> "deciding" some interesting property of the "input"?
>>
>>> Well that's something a bit new and different.
>>
>> Being different is key for any Usenet maths crank.  No two people who
>> have "refuted Cantor" or "solved halting" will agree with each other for
>> long.  Fortunately there are infinitely many ways to be wrong, but only
>> one way to be right so it's not hard to achieve.
>>
>
>

--
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 04:20:41 +0000, olcott said:

>> 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"?
>
> That we do not agree on this other point does not imply any
> dishonesty on your part.

That you don't answer the question is a good reason to suspect
dishonesty on your part.

Mikko

On 2022-05-26 13:35:31 +0000, olcott said:

> Someone with a deeper understanding would realize that your
> interpretation that a halt decider must compute its mapping from a
> non-input would understand that this would violate the definition of a
> computable function and the definition of a decider.

The definition of "decider" does not require much, only that it must halt
and indicate the decision. This is not violated by the definition of "halt
decider".

The definition of "halt decider" does violate the the definition of
"coputable function". The violation is not obvious but it can be proven,
and is proven.

> They would understand that a halt determiner must only compute the
> mapping from its input to its own final accept or reject state on the
> basis of the behavior that this input actually specifies.

What a halt decider must do is fully and clearly specified in the definition.

> If we take your interpretation as correct then computer scientists we
> be agreeing that it is perfectly OK for the requirements of a decision
> problem to violate the principles of computer science and still be a
> valid decision problem.

Indeed it is. There are very little requirements for a "valid decision
problem" (or "valid problem" in general).

Mikko

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.
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.
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
the input. So "Non-halting" is correct even though H_Hat halts.
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.

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.

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.

On 5/26/22 11:06 PM, olcott wrote:
> On 5/26/2022 9:50 PM, Richard Damon wrote:
>> On 5/26/22 9:35 AM, olcott wrote:
>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@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"?
>>>>
>>>
>>> The only reason that you do not see the significance of this is that
>>> the depth of your understanding is learned-by-rote.
>>>
>>> Someone with a deeper understanding would realize that your
>>> interpretation that a halt decider must compute its mapping from a
>>> non-input would understand that this would violate the definition of
>>> a computable function and the definition of a decider.
>>
>> No, it only CAN compute what can be determined by its processing of
>> the input, but a "something" decider MUST compute the "something"
>> mapping defined,
> You just contradicted yourself.

No, just shows you don't understand English.

I am pointing out the difference between what something is ABLE to do,
and what it is REQUIRED to do.
>
> The set of deciders only applies to input finite strings.  It can apply
> any computable criteria to these inputs. I know these things first-hand
> not merely by the rote from textbooks.
>

Right, and the finite string that descibes P is the FULL contents of the
memory including ALL the code that it executes.

This is BY DEFINITION a finite string, since there are a finite number
of bytes. Thus the behavior of that when run as a program is something
in the domain of what we MAY ask.

Then we get to your second statement, and that is the crux of the
proble, is the Halting Criteria computable? The Halting Function
Halting(M,w) is DEFINED to return True if M(w) will Halt, and False if
M(w) will never halt. Halting is clearly recognizable, as we can build a
machine that accepts (in finite time) all halting inputs, by just
simulating and accepting when the simulation halts.

This is just recognition, not deciding, as it just doesn't answer for
non-halting inputs.

The question comes can we do something to some how recognize these
non-halting and be able to REJECT them, rather than just looping on them.

The "Impossible Program" proves that this can't be done. It IS a finite
string input, at least if H is (and it must be to meet the requirements
to actually be a decider), and thus is a legal input.

It also presents a problem for the decider it is built on, as whatever
answer that decider gives, will be wrong, because of the ability to
refer to that decider inside the impossible program.

What this proves is that Halting isn't a computable function, and thus
(because it isn't computable, and what makes it non-computable) no
decider can be built to compute it.

Your logical flaw is that your start with the assumption that Halting
must be computable, when that is NOT an allowable assumption, in fact,
that is the QUESTION.

This means you don't get to redefine the meaning of the problem, to
something that is actually computable to answer the question.

That is like answering about how many Dogs you have when someone asks
about fleas, because fleas are just too hard to find to count. It just
isn't the right answer to the question.

On 5/27/2022 2:29 AM, Mikko wrote:
> On 2022-05-27 04:20:41 +0000, olcott said:
>
>>> 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"?
>>
>> That we do not agree on this other point does not imply any
>> dishonesty on your part.
>
> That you don't answer the question is a good reason to suspect
> dishonesty on your part.
>
> Mikko
>

I never answer questions directly. I always provide all of the reasons
for the correct answer. The makes it much more difficult to reject what
I say out-of-hand without review.

--
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/2022 2:48 AM, Mikko wrote:
> On 2022-05-26 13:35:31 +0000, olcott said:
>
>> Someone with a deeper understanding would realize that your
>> interpretation that a halt decider must compute its mapping from a
>> non-input would understand that this would violate the definition of a
>> computable function and the definition of a decider.
>
> The definition of "decider" does not require much, only that it must halt
> and indicate the decision. This is not violated by the definition of "halt
> decider".
>

a function is computable if there exists an algorithm that can do the
job of the function, i.e. given an input of the function domain it can
return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function

P(P) is not in the domain of H because it is not an input to H.

> The definition of "halt decider" does violate the the definition of
> "coputable function". The violation is not obvious but it can be proven,
> and is proven.
>
>> They would understand that a halt determiner must only compute the
>> mapping from its input to its own final accept or reject state on the
>> basis of the behavior that this input actually specifies.
>
> What a halt decider must do is fully and clearly specified in the
> definition.
>
>> If we take your interpretation as correct then computer scientists we
>> be agreeing that it is perfectly OK for the requirements of a decision
>> problem to violate the principles of computer science and still be a
>> valid decision problem.
>
> Indeed it is. There are very little requirements for a "valid decision
> problem" (or "valid problem" in general).
>
> Mikko
>

--
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/2022 7:50 AM, Richard Damon wrote:
> On 5/26/22 11:06 PM, olcott wrote:
>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>> On 5/26/22 9:35 AM, olcott wrote:
>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>> Malcolm McLean <malcolm.arthur.mclean@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"?
>>>>>
>>>>
>>>> The only reason that you do not see the significance of this is that
>>>> the depth of your understanding is learned-by-rote.
>>>>
>>>> Someone with a deeper understanding would realize that your
>>>> interpretation that a halt decider must compute its mapping from a
>>>> non-input would understand that this would violate the definition of
>>>> a computable function and the definition of a decider.
>>>
>>> No, it only CAN compute what can be determined by its processing of
>>> the input, but a "something" decider MUST compute the "something"
>>> mapping defined,
>> You just contradicted yourself.
>
> No, just shows you don't understand English.
>
> I am pointing out the difference between what something is ABLE to do,
> and what it is REQUIRED to do.

You are requiring that a decider maps somethings that it does not have,
thus making your requirement incorrect. It is like I said give me the
$10 from your empty wallet.

>>
>> The set of deciders only applies to input finite strings.  It can
>> apply any computable criteria to these inputs. I know these things
>> first-hand not merely by the rote from textbooks.
>>
>
> Right, and the finite string that descibes P is the FULL contents of the
> memory including ALL the code that it executes.
>
> This is BY DEFINITION a finite string, since there are a finite number
> of bytes. Thus the behavior of that when run as a program is something
> in the domain of what we MAY ask.
>
> Then we get to your second statement, and that is the crux of the
> proble, is the Halting Criteria computable? The Halting Function
> Halting(M,w) is DEFINED to return True if M(w) will Halt, and False if
> M(w) will never halt. Halting is clearly recognizable, as we can build a
> machine that accepts (in finite time) all halting inputs, by just
> simulating and accepting when the simulation halts.
>
> This is just recognition, not deciding, as it just doesn't answer for
> non-halting inputs.
>
> The question comes can we do something to some how recognize these
> non-halting and be able to REJECT them, rather than just looping on them.
>
> The "Impossible Program" proves that this can't be done. It IS a finite
> string input, at least if H is (and it must be to meet the requirements
> to actually be a decider), and thus is a legal input.
>
> It also presents a problem for the decider it is built on, as whatever
> answer that decider gives, will be wrong, because of the ability to
> refer to that decider inside the impossible program.
>
> What this proves is that Halting isn't a computable function, and thus
> (because it isn't computable, and what makes it non-computable) no
> decider can be built to compute it.
>
> Your logical flaw is that your start with the assumption that Halting
> must be computable, when that is NOT an allowable assumption, in fact,
> that is the QUESTION.
>
> This means you don't get to redefine the meaning of the problem, to
> something that is actually computable to answer the question.
>
> That is like answering about how many Dogs you have when someone asks
> about fleas, because fleas are just too hard to find to count. It just
> isn't the right answer to the question.

--
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:21 AM, olcott wrote:
> On 5/27/2022 2:48 AM, Mikko wrote:
>> On 2022-05-26 13:35:31 +0000, olcott said:
>>
>>> Someone with a deeper understanding would realize that your
>>> interpretation that a halt decider must compute its mapping from a
>>> non-input would understand that this would violate the definition of
>>> a computable function and the definition of a decider.
>>
>> The definition of "decider" does not require much, only that it must halt
>> and indicate the decision. This is not violated by the definition of
>> "halt
>> decider".
>>
>
> a function is computable if there exists an algorithm that can do the
> job of the function, i.e. given an input of the function domain it can
> return the corresponding output.
> https://en.wikipedia.org/wiki/Computable_function
>
> P(P) is not in the domain of H because it is not an input to H.

Wrong. IF that is true the a UTM can't exist, but you are baisng your
argument on that.

The representation of P, in your case the object code of it. contains
all the data needed to determine the behavior of that computation, and
thus IS in the domain of H.

In fact, saying that the representation of P(P) is not in the domain of
H is, by itself, enough to prove that H can not be a correct halt decider.

You are just digging a deeper hole for yourself.

You are just proving your ignorance.

If H claims to be a Halt Decider, then we need to be able to ask it
about any computation, how do we ask it about P(P).

If we can't, then it isn't one.

>
>
>> The definition of "halt decider" does violate the the definition of
>> "coputable function". The violation is not obvious but it can be proven,
>> and is proven.
>>
>>> They would understand that a halt determiner must only compute the
>>> mapping from its input to its own final accept or reject state on the
>>> basis of the behavior that this input actually specifies.
>>
>> What a halt decider must do is fully and clearly specified in the
>> definition.
>>
>>> If we take your interpretation as correct then computer scientists we
>>> be agreeing that it is perfectly OK for the requirements of a
>>> decision problem to violate the principles of computer science and
>>> still be a valid decision problem.
>>
>> Indeed it is. There are very little requirements for a "valid decision
>> problem" (or "valid problem" in general).
>>
>> Mikko
>>
>
>

On 5/27/22 11:16 AM, olcott wrote:
> On 5/27/2022 2:29 AM, Mikko wrote:
>> On 2022-05-27 04:20:41 +0000, olcott said:
>>
>>>> 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"?
>>>
>>> That we do not agree on this other point does not imply any
>>> dishonesty on your part.
>>
>> That you don't answer the question is a good reason to suspect
>> dishonesty on your part.
>>
>> Mikko
>>
>
> I never answer questions directly. I always provide all of the reasons
> for the correct answer. The makes it much more difficult to reject what
> I say out-of-hand without review.
>

Because you don't actually have the answer, because your logic is just
too broken.

FAIL.

On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
> On 5/27/22 11:21 AM, olcott wrote:
> > On 5/27/2022 2:48 AM, Mikko wrote:
> >> On 2022-05-26 13:35:31 +0000, olcott said:
> >>
> >>> Someone with a deeper understanding would realize that your
> >>> interpretation that a halt decider must compute its mapping from a
> >>> non-input would understand that this would violate the definition of
> >>> a computable function and the definition of a decider.
> >>
> >> The definition of "decider" does not require much, only that it must halt
> >> and indicate the decision. This is not violated by the definition of
> >> "halt
> >> decider".
> >>
> >
> > a function is computable if there exists an algorithm that can do the
> > job of the function, i.e. given an input of the function domain it can
> > return the corresponding output.
> > https://en.wikipedia.org/wiki/Computable_function
> >
> > P(P) is not in the domain of H because it is not an input to H.
> Wrong. IF that is true the a UTM can't exist, but you are baisng your
> argument on that.
>
> The representation of P, in your case the object code of it. contains
> all the data needed to determine the behavior of that computation, and
> thus IS in the domain of H.
>
> In fact, saying that the representation of P(P) is not in the domain of
> H is, by itself, enough to prove that H can not be a correct halt decider.
>
> You are just digging a deeper hole for yourself.
>
> You are just proving your ignorance.
>
> If H claims to be a Halt Decider, then we need to be able to ask it
> about any computation, how do we ask it about P(P).
>
> If we can't, then it isn't one.
>
But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
would in fact achieve PO's broader objectives. It wouldn't "solve the
halting problem", but it would redefine it for future workers.

However the question is how to do this in an interesting way. As Ben says,
a lot of students, when introduced to this material, say "why not detect
the H_Hat(H_Hat) pattern and special case it?". It's a natural reaction.
But when you think about it a bit more deeply, you'll see that this strategy
doesn't work.

On 5/27/22 11:24 AM, olcott wrote:
> On 5/27/2022 7:50 AM, Richard Damon wrote:
>> On 5/26/22 11:06 PM, olcott wrote:
>>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>>> On 5/26/22 9:35 AM, olcott wrote:
>>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>>> Malcolm McLean <malcolm.arthur.mclean@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"?
>>>>>>
>>>>>
>>>>> The only reason that you do not see the significance of this is
>>>>> that the depth of your understanding is learned-by-rote.
>>>>>
>>>>> Someone with a deeper understanding would realize that your
>>>>> interpretation that a halt decider must compute its mapping from a
>>>>> non-input would understand that this would violate the definition
>>>>> of a computable function and the definition of a decider.
>>>>
>>>> No, it only CAN compute what can be determined by its processing of
>>>> the input, but a "something" decider MUST compute the "something"
>>>> mapping defined,
>>> You just contradicted yourself.
>>
>> No, just shows you don't understand English.
>>
>> I am pointing out the difference between what something is ABLE to do,
>> and what it is REQUIRED to do.
>
> You are requiring that a decider maps somethings that it does not have,
> thus making your requirement incorrect. It is like I said give me the
> $10 from your empty wallet.

But it DOES have the representation of P, so it can map it.

YOU just don't know what you are talking about.

If you are saying the Halting Problem is impossible to make as a
requirement, you have just PROVED the Theorem.

AND FAILED at its disproof.

If you disalllow the asking of a question, you make it impossible to
give a correct answer, and thus a machine that answers the question
correcctly is impossible.

Halting Theorem Proved.

YOU FAIL.

>
>
>>>
>>> The set of deciders only applies to input finite strings.  It can
>>> apply any computable criteria to these inputs. I know these things
>>> first-hand not merely by the rote from textbooks.
>>>
>>
>> Right, and the finite string that descibes P is the FULL contents of
>> the memory including ALL the code that it executes.
>>
>> This is BY DEFINITION a finite string, since there are a finite number
>> of bytes. Thus the behavior of that when run as a program is something
>> in the domain of what we MAY ask.
>>
>> Then we get to your second statement, and that is the crux of the
>> proble, is the Halting Criteria computable? The Halting Function
>> Halting(M,w) is DEFINED to return True if M(w) will Halt, and False if
>> M(w) will never halt. Halting is clearly recognizable, as we can build
>> a machine that accepts (in finite time) all halting inputs, by just
>> simulating and accepting when the simulation halts.
>>
>> This is just recognition, not deciding, as it just doesn't answer for
>> non-halting inputs.
>>
>> The question comes can we do something to some how recognize these
>> non-halting and be able to REJECT them, rather than just looping on them.
>>
>> The "Impossible Program" proves that this can't be done. It IS a
>> finite string input, at least if H is (and it must be to meet the
>> requirements to actually be a decider), and thus is a legal input.
>>
>> It also presents a problem for the decider it is built on, as whatever
>> answer that decider gives, will be wrong, because of the ability to
>> refer to that decider inside the impossible program.
>>
>> What this proves is that Halting isn't a computable function, and thus
>> (because it isn't computable, and what makes it non-computable) no
>> decider can be built to compute it.
>>
>> Your logical flaw is that your start with the assumption that Halting
>> must be computable, when that is NOT an allowable assumption, in fact,
>> that is the QUESTION.
>>
>> This means you don't get to redefine the meaning of the problem, to
>> something that is actually computable to answer the question.
>>
>> That is like answering about how many Dogs you have when someone asks
>> about fleas, because fleas are just too hard to find to count. It just
>> isn't the right answer to the question.
>
>

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:52 AM, Malcolm McLean wrote:
> On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
>> On 5/27/22 11:21 AM, olcott wrote:
>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>
>>>>> Someone with a deeper understanding would realize that your
>>>>> interpretation that a halt decider must compute its mapping from a
>>>>> non-input would understand that this would violate the definition of
>>>>> a computable function and the definition of a decider.
>>>>
>>>> The definition of "decider" does not require much, only that it must halt
>>>> and indicate the decision. This is not violated by the definition of
>>>> "halt
>>>> decider".
>>>>
>>>
>>> a function is computable if there exists an algorithm that can do the
>>> job of the function, i.e. given an input of the function domain it can
>>> return the corresponding output.
>>> https://en.wikipedia.org/wiki/Computable_function
>>>
>>> P(P) is not in the domain of H because it is not an input to H.
>> Wrong. IF that is true the a UTM can't exist, but you are baisng your
>> argument on that.
>>
>> The representation of P, in your case the object code of it. contains
>> all the data needed to determine the behavior of that computation, and
>> thus IS in the domain of H.
>>
>> In fact, saying that the representation of P(P) is not in the domain of
>> H is, by itself, enough to prove that H can not be a correct halt decider.
>>
>> You are just digging a deeper hole for yourself.
>>
>> You are just proving your ignorance.
>>
>> If H claims to be a Halt Decider, then we need to be able to ask it
>> about any computation, how do we ask it about P(P).
>>
>> If we can't, then it isn't one.
>>
> But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
> would in fact achieve PO's broader objectives. It wouldn't "solve the
> halting problem", but it would redefine it for future workers.
>
> However the question is how to do this in an interesting way. As Ben says,
> a lot of students, when introduced to this material, say "why not detect
> the H_Hat(H_Hat) pattern and special case it?". It's a natural reaction.
> But when you think about it a bit more deeply, you'll see that this strategy
> doesn't work.
>

The problem is the pesky requirement to work for ALL Computations, so
you need to find a way to make H^ not a computation, without making H
not a computation since it then can't be the decider.

That becomes the fundamental problem.

Ultimately, it seems that PO doesn't accept some of the basic properties
of computatons, thinking that a given computation with a given input can
generate different answers under some conditions.

The problem is you need to break some pretty core concepts to make that
happen.

That seems bigger than Euclid's Fifth Postulate. He needs to be able to
show that breaking it leads to something useful (like non-Euclidian
Geometry did),

On 5/27/2022 10:52 AM, Malcolm McLean wrote:
> On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
>> On 5/27/22 11:21 AM, olcott wrote:
>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>
>>>>> Someone with a deeper understanding would realize that your
>>>>> interpretation that a halt decider must compute its mapping from a
>>>>> non-input would understand that this would violate the definition of
>>>>> a computable function and the definition of a decider.
>>>>
>>>> The definition of "decider" does not require much, only that it must halt
>>>> and indicate the decision. This is not violated by the definition of
>>>> "halt
>>>> decider".
>>>>
>>>
>>> a function is computable if there exists an algorithm that can do the
>>> job of the function, i.e. given an input of the function domain it can
>>> return the corresponding output.
>>> https://en.wikipedia.org/wiki/Computable_function
>>>
>>> P(P) is not in the domain of H because it is not an input to H.
>> Wrong. IF that is true the a UTM can't exist, but you are baisng your
>> argument on that.
>>
>> The representation of P, in your case the object code of it. contains
>> all the data needed to determine the behavior of that computation, and
>> thus IS in the domain of H.
>>
>> In fact, saying that the representation of P(P) is not in the domain of
>> H is, by itself, enough to prove that H can not be a correct halt decider.
>>
>> You are just digging a deeper hole for yourself.
>>
>> You are just proving your ignorance.
>>
>> If H claims to be a Halt Decider, then we need to be able to ask it
>> about any computation, how do we ask it about P(P).
>>
>> If we can't, then it isn't one.
>>
> But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
> would in fact achieve PO's broader objectives. It wouldn't "solve the
> halting problem", but it would redefine it for future workers.
>

Halt decider are required to decide the halt status of any finite
strings that specify a sequence of configurations.

Halt deciders are not required to decide that halt status of finite
strings of English poems nor are they required to compute the halt
status of anything that is not an input finite string.

For example H is not required to compute the halt status of the behavior
that a person imagines that P(P) has. H(P,P) is only required to compute
the halt state that its input actually specifies.

> However the question is how to do this in an interesting way. As Ben says,
> a lot of students, when introduced to this material, say "why not detect
> the H_Hat(H_Hat) pattern and special case it?". It's a natural reaction.
> But when you think about it a bit more deeply, you'll see that this strategy
> doesn't work.
>

It does work when H is defined to recognize the whole infinite recursion
pattern. I threw in infinite loops for good measure.

--
Copyright 2022 Pete Olcott

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