On 11/3/2021 4:03 PM, André G. Isaak wrote:
> On 2021-11-03 14:02, olcott wrote:
>> On 11/3/2021 2:02 PM, André G. Isaak wrote:
>>> On 2021-11-03 12:23, olcott wrote:
>>>> On 11/3/2021 12:44 PM, André G. Isaak wrote:
>>>>> On 2021-11-03 11:19, olcott wrote:
>>>>>> On 11/3/2021 12:09 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-03 10:14, olcott wrote:
>>>>>>>> On 11/3/2021 11:00 AM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-03 09:47, olcott wrote:
>>>>>>>>>
>>>>>>>>>> THE IS THE MOST RECENT UPDATE TO THE CRITERION MEASURE
>>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>>> pure simulation of its input would ever reach a final state of
>>>>>>>>>> this input by a simulating halt decider.
>>>>>>>>>
>>>>>>>>> The halting problem already defines what the criterion used by
>>>>>>>>> a halt decider must be. You don't get to update it if that's
>>>>>>>>> the problem you want to work on.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> No one here seems capable of understanding is that when a halt
>>>>>>>> decider does correctly decide the halt status of its input then
>>>>>>>> its input has had its halt status correctly decided.
>>>>>>>
>>>>>>> Right. And since yours doesn't correctly decide the halt status
>>>>>>> of its input then its input has not had its halt status correctly
>>>>>>> decided.
>>>>>>>
>>>>>>
>>>>>> The only criteria for correctly deciding the halt status of the
>>>>>> actual input is whether or not the correct pure simulation of this
>>>>>> input would ever reach a final state.
>>>>>>
>>>>>> Every other criteria changes the subject to an entirely different
>>>>>> comutation.
>>>>>
>>>>>
>>>>> Both 'halting problem' and 'halt decider' were defined before you
>>>>> were born by people who actually UNDERSTOOD the topic.
>>>>>
>>>>> The definitions of these things are precise, unambiguous, and
>>>>> clearly indicate the actual criterion which a halt decider must use
>>>>> in making its decision. That criterion makes no reference to pure
>>>>> simulations. It refers only to whether the computation represented
>>>>> by the input string halts.
>>>>>
>>>>
>>>> It is impossible for any halt decider to be incorrect when the
>>>> correct pure simulation of its input never halts and it reports not
>>>> halting.
>>>
>>> Not if it contradicts the actual correct answer as determined by the
>>> criterion which defines the halting problem since that criterion
>>> alone determines which answer is correct.
>> It is impossible for any halt decider to be incorrect when the correct
>> pure simulation of its input never halts and it reports not halting.
>
> But your halt decider doesn't implement a 'pure simulation' under any
> reasonable definition of the term.

_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]

Begin Local Halt Decider Simulation at Machine Address:c36

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

We can perfectly know that H(P,P) does precisely simulate the first
seven instructions of P when it simulates the first seven instructions
of P.

We can also know that when it perfectly repeats this sequence again that
it has acted as a pure simulator for the execution of these two sequences.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 2021-11-03 15:18, olcott wrote:
> On 11/3/2021 4:03 PM, André G. Isaak wrote:

>> But your halt decider doesn't implement a 'pure simulation' under any
>> reasonable definition of the term.
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> Begin Local Halt Decider Simulation at Machine Address:c36
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> We can perfectly know that H(P,P) does precisely simulate the first
> seven instructions of P when it simulates the first seven instructions
> of P.
>
> We can also know that when it perfectly repeats this sequence again that
> it has acted as a pure simulator for the execution of these two sequences.

And so what? Somethings either a pure simulator or it isn't. You can't
call something a pure simulator based only on what it does for two
sequences.

Besides, it's irrelevant. There is ONLY ONE criterion which defines
halting and that's the only criterion that matters. That criterion makes
no mention of pure simulators, only of whether the actual computation
under consideration halts. All other considerations are entirely irrelevant.

P(P) halts. Your H claims it does not. Your H is wrong.

André

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

olcott <NoOne@NoWhere.com> writes:

> On 11/3/2021 11:25 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> No one here seems capable of understanding is that when a halt decider
>>> does correctly decide the halt status of its input then its input has
>>> had its halt status correctly decided.
>>
>> Don't be silly. No one disputes that (thought the wording is poor).
>> The only disagreement is on what the correct answer is. Since P(P)
>> halts and H(P,P) == false, H is not deciding correctly.
>
> THE MOST RECENT UPDATE TO THE CRITERION MEASURE
> A halt decider only need answer whether or not the correct pure
> simulation of its input would ever reach a final state of this input
> by a simulating halt decider.

No. H(P,P) == false is wrong because P(P) halts. Simple. No disputed
facts. All the remains is for you to agree that a halt decider should
return true when the inputs represent a halting computation like P(P).

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 11/3/2021 11:15 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/2/2021 10:17 PM, Ben Bacarisse wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>
>>>>> Every halt decider is ONLY tasked with determining the behavior of its
>>>>> input.
>>>>
>>>> No. Every halt decider is tasked with determining the behaviour of the
>>>> computation represented by its input. That's why H(P,P)==0 is wrong.
>>>> The arguments in that call represent the halting computation P(P).
>>>
>>> THE IS THE MOST RECENT UPDATE TO THE CRITERION MEASURE
>>> A halt decider only need answer whether or not the correct pure
>>> simulation of its input would ever reach a final state of this input
>>> by a simulating halt decider.
>>
>> The halting problem is already defined, thank you. H(P,P) == false is
>> wrong because P(P) halts.
>
> So in other words when H correctly determines that its input never
> reaches its final state the fact that some other entirely different
> computation does reach its final state proves that H is wrong?

No. H(P,P) == false is wrong because P(P) halts. It's not complicated,
and you don't dispute either fact.

Writing a function H which, for the conventionally derived "hat"
function, returns false when H^(H^) (AKA P(P)) halts is /trivial/.
Every programmer can do it. It can be done in one line. The only
reason you've managed to drag this on for long is by hiding the code and
refusing to say, for years, what H(P,P) returned and whether H^(H^)
halts or not. Now that those fact are in the open, you are stymied.
All you claim to have is an H that is wrong about the one case you care
about.

--
Ben.

On 11/3/2021 5:10 PM, André G. Isaak wrote:
> On 2021-11-03 15:18, olcott wrote:
>> On 11/3/2021 4:03 PM, André G. Isaak wrote:
>
>>> But your halt decider doesn't implement a 'pure simulation' under any
>>> reasonable definition of the term.
>>
>> _P()
>> [00000c36](01)  55          push ebp
>> [00000c37](02)  8bec        mov ebp,esp
>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>> [00000c3c](01)  50          push eax
>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>> [00000c40](01)  51          push ecx
>> [00000c41](05)  e820fdffff  call 00000966    // call H
>> [00000c46](03)  83c408      add esp,+08
>> [00000c49](02)  85c0        test eax,eax
>> [00000c4b](02)  7402        jz 00000c4f
>> [00000c4d](02)  ebfe        jmp 00000c4d
>> [00000c4f](01)  5d          pop ebp
>> [00000c50](01)  c3          ret
>> Size in bytes:(0027) [00000c50]
>>
>> Begin Local Halt Decider Simulation at Machine Address:c36
>>
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> [00000c36][002117ca][002117ce] 55          push ebp
>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>
>> We can perfectly know that H(P,P) does precisely simulate the first
>> seven instructions of P when it simulates the first seven instructions
>> of P.
>>
>> We can also know that when it perfectly repeats this sequence again
>> that it has acted as a pure simulator for the execution of these two
>> sequences.
>
> And so what? Somethings either a pure simulator or it isn't.

That it is a pure simulator to this point conclusively proves that
it is a pure simulator up to this point and conclusively proves that
a pure simulation would never halt.

It is impossible for any halt decider to be incorrect when the correct
pure simulation of its input never halts and it reports not halting.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 2021-11-03 16:58, olcott wrote:
> On 11/3/2021 5:10 PM, André G. Isaak wrote:
>> On 2021-11-03 15:18, olcott wrote:
>>> On 11/3/2021 4:03 PM, André G. Isaak wrote:
>>
>>>> But your halt decider doesn't implement a 'pure simulation' under
>>>> any reasonable definition of the term.
>>>
>>> _P()
>>> [00000c36](01)  55          push ebp
>>> [00000c37](02)  8bec        mov ebp,esp
>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>> [00000c3c](01)  50          push eax
>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>> [00000c40](01)  51          push ecx
>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>> [00000c46](03)  83c408      add esp,+08
>>> [00000c49](02)  85c0        test eax,eax
>>> [00000c4b](02)  7402        jz 00000c4f
>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>> [00000c4f](01)  5d          pop ebp
>>> [00000c50](01)  c3          ret
>>> Size in bytes:(0027) [00000c50]
>>>
>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> [00000c36][002117ca][002117ce] 55          push ebp
>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>>
>>> We can perfectly know that H(P,P) does precisely simulate the first
>>> seven instructions of P when it simulates the first seven
>>> instructions of P.
>>>
>>> We can also know that when it perfectly repeats this sequence again
>>> that it has acted as a pure simulator for the execution of these two
>>> sequences.
>>
>> And so what? Somethings either a pure simulator or it isn't.
>
> That it is a pure simulator to this point conclusively proves that
> it is a pure simulator up to this point and conclusively proves that
> a pure simulation would never halt.

Being a pure simulator 'to this point' is not the same thing as being a
pure simulator.

And, as I already pointed out, this is all entirely irrelevant. P(P)
halts. Your H(P, P) claims it does not. Therefore your H is wrong.
Nothing you write above changes this.

> It is impossible for any halt decider to be incorrect when the correct
> pure simulation of its input never halts and it reports not halting.

It is impossible for any halt decider to be correct when its answer
doesn't actually match the correct answer. The correct answer is
determined *solely* by the actual behaviour of P(P). This is part of the
basic definition of Halting/Halt Decider. Yet you seem determined to
talk about anything *except* the actual behaviour of P(P).

P(P) halts. Your H(P, P) claims it does not. Therefore your H is wrong.

André

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

On 11/3/21 10:45 AM, olcott wrote:
> On 11/3/2021 4:49 AM, Malcolm McLean wrote:
>> On Wednesday, 3 November 2021 at 04:09:54 UTC, Mike Terry wrote:
>>> On 03/11/2021 03:30, André G. Isaak wrote:
>>>> On 2021-11-02 21:14, olcott wrote:
>>>>> On 11/2/2021 9:26 PM, André G. Isaak wrote:
>>>>>> On 2021-11-02 19:32, olcott wrote:
>>>>>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-02 18:49, olcott wrote:
>>>>>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>>>>>>>>>>> correctly reports what the actual behavior of its actual
>>>>>>>>>>>>>>> input would be then everyone (besides me) is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>>>>>>>>>>> define it as 'wrong'. It defines what question it is supposed
>>>>>>>>>>>>>> to answer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>>>>>>>>>>> halting behaviour so your position above is entirely
>>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>>>> program and an input, whether the program will finish running,
>>>>>>>>>>>>> or continue to run forever.
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>
>>>>>>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>>>>>>
>>>>>>>>>>>> Note that the above definition doesn't make any mentions of
>>>>>>>>>>>> 'simulations' just as the more formal definition used by Linz's
>>>>>>>>>>>> does not.
>>>>>>>>>>>>
>>>>>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>>>>>> simulation of its input would ever reach a final state of this
>>>>>>>>>>>>> input by a simulating halt decider.
>>>>>>>>>>>>
>>>>>>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>>>>>>> identically to the actual TM being simulated. That means that
>>>>>>>>>>>> if the actual TM halts the simulation also must halt. Which
>>>>>>>>>>>> means that your simulation is not a 'correct simulation'.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> There are no freaking presumptions about it. As long as the
>>>>>>>>>>> simulation of P(P) matches its x86 source code then the
>>>>>>>>>>> simulation is correct.
>>>>>>>>>>
>>>>>>>>>> I have no idea what it means for a simulation of P(P) to "match
>>>>>>>>>> its x86 source code".
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When the simulator executes the instructions at
>>>>>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>>>>>>> of the x86 source code of P, then the simulator
>>>>>>>>> correctly simulated P(P).
>>>>>>>>
>>>>>>>> No. A simulator only 'correctly simulates' a machine when it
>>>>>>>> accurately duplicates *all* of the behaviour of that machine. Part
>>>>>>>> of the behaviour of P(P) is that it halts.
>>>>>>>>
>>>>>>>
>>>>>>> That is a stupid thing to say. The x86 emulator correctly emulates
>>>>>>> the x86 instructions of P iff it emulates the actual x86 intructions
>>>>>>> of P saying anything else is both pure bullshit and quite nutty.
>>>>>>
>>>>>> That's a nonsensical claim. If it correctly emulates all the
>>>>>> instructions then it should have identical behaviour. That includes
>>>>>> whether it halts or not.
>>>>>
>>>>> Maybe you don't understand the x86 language well enough to ever
>>>>> understand what I am saying.
>>>>>
>>>>> While H continues to simulate P these first seven instructions of P
>>>>> continue to repeat. Do you understand that?
>>>>
>>>> Which is irrelevant to the halting problem which asks whether P(P)
>>>> halts? Does it? Yes. Ergo the only correct for H(P, P) to give is
>>>> 'true'. *Nothing* apart from the actual behaviour of P(P) is
>>>> relevant to
>>>> determining what the correct answer to this question is, so there's not
>>>> even any point in providing all your meaningless traces.
>>>>
>>>> The correct answer to H(P, P) is determined by the actual behaviour of
>>>> P(P). We know the actual behaviour of P(P). So there's absolutely no
>>>> reason to consider anything else.
>>>>
>>>> And you conveniently ignored all the questions which I asked.
>>>>
>>>> What does the input to H(P, P) represent if not P(P)?
>>>>
>>>> How can the inputs to H1(P, P) and H(P, P) represent different things
>>>> given that they are the *same* input?
>>> My suspicion (difficult to confirm) is still that in both those cases,
>>> PO is looking at the same computation. It's simply that H and H1, in
>>> examining the identical execution traces, behave differently because
>>> they take their own machine code address and use that in interpreting
>>> the instruction trace.
>>>
>>> So e.g. H uses its address to exclude certain parts of the trace it
>>> examines, and consequently INCORRECTLY decides it is seeing infinite
>>> recursion. H1 excludes a different address range, so it doesn't see
>>> infinite recursion and so the simulation continues FURTHER than H
>>> continues it, and in fact with H1 the simulation proceeds right up to
>>> the point where it reaches its halt state, so H1 give the correct
>>> answer. [I'd guess H1 works because it is seeing the conditional branch
>>> instructions that H deliberately ignores, and so his unsound recursion
>>> test does not match.]
>>>
>>> I bet if we looked at the actual traces that H and H1 are producing,
>>> they would be exactly the same UP TO THE POINT WHERE H MAKES ITS MISTAKE
>>> AND SAYS "INFINITE RECURSION DETECTED". I.e. H just makes the wrong
>>> decision and terminates the simulation too early, like everyone has been
>>> saying for over a year... :)
>>>
>> Ah, insightful as always.
>> That would explain a lot.
>>
>
> It is very obvious to anyone here that knows the x86 language
> sufficiently well that when H is a pure simulator that the following
> first seven lines remains stuck in infinite recursion.

Yes, WHEN H is a pure simulator, the code shown is stuck in infinite
recursion, but also H will not answer.

On 11/3/21 11:34 AM, olcott wrote:
> On 11/3/2021 9:54 AM, Mike Terry wrote:
>> On 03/11/2021 04:09, Mike Terry wrote:
>>> On 03/11/2021 03:30, André G. Isaak wrote:
>>>> On 2021-11-02 21:14, olcott wrote:
>>>>> On 11/2/2021 9:26 PM, André G. Isaak wrote:
>>>>>> On 2021-11-02 19:32, olcott wrote:
>>>>>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-02 18:49, olcott wrote:
>>>>>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If everyone "defines" that the halt decider is wrong when
>>>>>>>>>>>>>>> it correctly reports what the actual behavior of its
>>>>>>>>>>>>>>> actual input would be then everyone (besides me) is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The definition tells you what a halt decider *is*. It
>>>>>>>>>>>>>> doesn't define it as 'wrong'. It defines what question it
>>>>>>>>>>>>>> is supposed to answer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to a halt decider is a string. Strings don't
>>>>>>>>>>>>>> *have* halting behaviour so your position above is
>>>>>>>>>>>>>> entirely incoherent.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> In computability theory, the halting problem is the problem
>>>>>>>>>>>>> of determining, from a description of an arbitrary computer
>>>>>>>>>>>>> program and an input, whether the program will finish
>>>>>>>>>>>>> running, or continue to run forever.
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>
>>>>>>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>>>>>>
>>>>>>>>>>>> Note that the above definition doesn't make any mentions of
>>>>>>>>>>>> 'simulations' just as the more formal definition used by
>>>>>>>>>>>> Linz's does not.
>>>>>>>>>>>>
>>>>>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>>>>>> simulation of its input would ever reach a final state of
>>>>>>>>>>>>> this input by a simulating halt decider.
>>>>>>>>>>>>
>>>>>>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>>>>>>> identically to the actual TM being simulated. That means
>>>>>>>>>>>> that if the actual TM halts the simulation also must halt.
>>>>>>>>>>>> Which means that your simulation is not a 'correct simulation'.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> There are no freaking presumptions about it. As long as the
>>>>>>>>>>> simulation of P(P) matches its x86 source code then the
>>>>>>>>>>> simulation is correct.
>>>>>>>>>>
>>>>>>>>>> I have no idea what it means for a simulation of P(P) to
>>>>>>>>>> "match its x86 source code".
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When the simulator executes the instructions at
>>>>>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>>>>>>> of the x86 source code of P, then the simulator
>>>>>>>>> correctly simulated P(P).
>>>>>>>>
>>>>>>>> No. A simulator only 'correctly simulates' a machine when it
>>>>>>>> accurately duplicates *all* of the behaviour of that machine.
>>>>>>>> Part of the behaviour of P(P) is that it halts.
>>>>>>>>
>>>>>>>
>>>>>>> That is a stupid thing to say. The x86 emulator correctly
>>>>>>> emulates the x86 instructions of P iff it emulates the actual x86
>>>>>>> intructions of P saying anything else is both pure bullshit and
>>>>>>> quite nutty.
>>>>>>
>>>>>> That's a nonsensical claim. If it correctly emulates all the
>>>>>> instructions then it should have identical behaviour. That
>>>>>> includes whether it halts or not.
>>>>>
>>>>> Maybe you don't understand the x86 language well enough to ever
>>>>> understand what I am saying.
>>>>>
>>>>> While H continues to simulate P these first seven instructions of P
>>>>> continue to repeat. Do you understand that?
>>>>
>>>> Which is irrelevant to the halting problem which asks whether P(P)
>>>> halts? Does it? Yes. Ergo the only correct for H(P, P) to give is
>>>> 'true'. *Nothing* apart from the actual behaviour of P(P) is
>>>> relevant to determining what the correct answer to this question is,
>>>> so there's not even any point in providing all your meaningless traces.
>>>>
>>>> The correct answer to H(P, P) is determined by the actual behaviour
>>>> of P(P). We know the actual behaviour of P(P). So there's absolutely
>>>> no reason to consider anything else.
>>>>
>>>> And you conveniently ignored all the questions which I asked.
>>>>
>>>> What does the input to H(P, P) represent if not P(P)?
>>>>
>>>> How can the inputs to H1(P, P) and H(P, P) represent different
>>>> things given that they are the *same* input?
>>>
>>> My suspicion (difficult to confirm) is still that in both those
>>> cases, PO is looking at the same computation.  It's simply that H and
>>> H1, in examining the identical execution traces, behave differently
>>> because they take their own machine code address and use that in
>>> interpreting the instruction trace.
>>>
>>> So e.g. H uses its address to exclude certain parts of the trace it
>>> examines, and consequently INCORRECTLY decides it is seeing infinite
>>> recursion.  H1 excludes a different address range, so it doesn't see
>>> infinite recursion and so the simulation continues FURTHER than H
>>> continues it, and in fact with H1 the simulation proceeds right up to
>>> the point where it reaches its halt state, so H1 give the correct
>>> answer.  [I'd guess H1 works because it is seeing the conditional
>>> branch instructions that H deliberately ignores, and so his unsound
>>> recursion test does not match.]
>>>
>>> I bet if we looked at the actual traces that H and H1 are producing,
>>
>> Correction - what I meant to say here is "actual traces that H and H1
>> are EXAMINING".
>>
>> Obviously the traces of H(P,P) and H1(P,P) [including the traces of
>> the outer emulations of H, H1 themselves] will be different, because H
>> and H1 addresses will be different if nothing else.
>>
>> That's a trivial point, but seems to be a constant point of
>> miscomunication between PO and others.  I reckon that when PO says
>> "computations H(P,P) and H1(P,P)" he is intending to say "the traces
>> of the SIMULATIONS of P(P) within H and H1", or similar.  [And if I'm
>> right above, those are NOT different, other than that H1 simulates
>> FURTHER than H, and so gets to observe the simulation halting.
>> Nothing to do with the presence of mysterious PSR!.]
>>
>> Mike.
>>
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> Begin Local Halt Decider Simulation at Machine Address:c36
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> I am not going to explain the difference between H1 and H at this point
> because you would be overwhelmed. You first must understand that while H
> is a pure simulator the above seven lines of P continue to repeat.
>

On 11/3/21 11:53 AM, olcott wrote:

> Begin Local Halt Decider Simulation at Machine Address:c36
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> When it is given that H is a pure simulator of its input can you
> comprhend that the above seven lines infinitely repeat?
>

If it is given that H is a pure simulator, then it is provable that this
is an infinite recursion AND that H(P,P) will NEVER return any answer
and thus fail to be a valid decider.

If H does return a Non-Halting Answer, the BY DEFINITION, it is NOT a
pure simulator, or it is wrong, or both.

On 11/3/21 12:20 PM, olcott wrote:
> On 11/3/2021 11:06 AM, André G. Isaak wrote:
>> On 2021-11-03 09:53, olcott wrote:
>>> On 11/3/2021 10:36 AM, André G. Isaak wrote:
>>>> On 2021-11-03 08:48, olcott wrote:
>>>>> On 11/2/2021 10:30 PM, André G. Isaak wrote:
>>>>>> On 2021-11-02 21:14, olcott wrote:
>>>>>>> On 11/2/2021 9:26 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-02 19:32, olcott wrote:
>>>>>>>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-02 18:49, olcott wrote:
>>>>>>>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>>>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If everyone "defines" that the halt decider is wrong
>>>>>>>>>>>>>>>>> when it correctly reports what the actual behavior of
>>>>>>>>>>>>>>>>> its actual input would be then everyone (besides me) is
>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The definition tells you what a halt decider *is*. It
>>>>>>>>>>>>>>>> doesn't define it as 'wrong'. It defines what question
>>>>>>>>>>>>>>>> it is supposed to answer.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The input to a halt decider is a string. Strings don't
>>>>>>>>>>>>>>>> *have* halting behaviour so your position above is
>>>>>>>>>>>>>>>> entirely incoherent.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>>> problem of determining, from a description of an
>>>>>>>>>>>>>>> arbitrary computer program and an input, whether the
>>>>>>>>>>>>>>> program will finish running, or continue to run forever.
>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note that the above definition doesn't make any mentions
>>>>>>>>>>>>>> of 'simulations' just as the more formal definition used
>>>>>>>>>>>>>> by Linz's does not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A halt decider only need answer whether or not the
>>>>>>>>>>>>>>> correct simulation of its input would ever reach a final
>>>>>>>>>>>>>>> state of this input by a simulating halt decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>>>>>>>>> identically to the actual TM being simulated. That means
>>>>>>>>>>>>>> that if the actual TM halts the simulation also must halt.
>>>>>>>>>>>>>> Which means that your simulation is not a 'correct
>>>>>>>>>>>>>> simulation'.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are no freaking presumptions about it. As long as the
>>>>>>>>>>>>> simulation of P(P) matches its x86 source code then the
>>>>>>>>>>>>> simulation is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> I have no idea what it means for a simulation of P(P) to
>>>>>>>>>>>> "match its x86 source code".
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> When the simulator executes the instructions at
>>>>>>>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>>>>>>>>> of the x86 source code of P, then the simulator
>>>>>>>>>>> correctly simulated P(P).
>>>>>>>>>>
>>>>>>>>>> No. A simulator only 'correctly simulates' a machine when it
>>>>>>>>>> accurately duplicates *all* of the behaviour of that machine.
>>>>>>>>>> Part of the behaviour of P(P) is that it halts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That is a stupid thing to say. The x86 emulator correctly
>>>>>>>>> emulates the x86 instructions of P iff it emulates the actual
>>>>>>>>> x86 intructions of P saying anything else is both pure bullshit
>>>>>>>>> and quite nutty.
>>>>>>>>
>>>>>>>> That's a nonsensical claim. If it correctly emulates all the
>>>>>>>> instructions then it should have identical behaviour. That
>>>>>>>> includes whether it halts or not.
>>>>>>>
>>>>>>> Maybe you don't understand the x86 language well enough to ever
>>>>>>> understand what I am saying.
>>>>>>>
>>>>>>> While H continues to simulate P these first seven instructions of
>>>>>>> P continue to repeat. Do you understand that?
>>>>>>
>>>>>> Which is irrelevant to the halting problem
>>>>>
>>>>> I will not speak with you until you answer.
>>>>
>>>> Whether it does or does not repeat cannot be determined from this
>>>> trace because you omit the instructions from the subroutine from
>>>> your trace.
>>>>
>>>
>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> [00000c36][002117ca][002117ce] 55          push ebp
>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>>
>>> When it is given that H is a pure simulator of its input can you
>>> comprhend that the above seven lines infinitely repeat?
>>
>> Nothing in the above seven lines indicates that they would repeat
>> since there is no instruction there which branches back to c36.
>>
>
> If you look in the stack data column in the // push P rows
> you will see that H is being called with 0xc36
>
> Because I already told you to assume the line c41 of P calls
> H as a pure simulator. It already says on lines c3c and c40
> that P is being pushed onto the stack.

And it we can assume that H is a pure simulator, then we know that since
we have an infinite recursion, that H will run forever and not return
any answer.

On 11/3/21 11:47 AM, olcott wrote:
> On 11/2/2021 10:17 PM, Ben Bacarisse wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 11/2/2021 12:25 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>> As long as H(P,P)==0 is correct none of my other "errors" are of any
>>>>>>> consequence what-so-ever.
>>>>>>
>>>>>> That's why I said one error really count: H(P,P)==0 is not correct
>>>>>> because P(P) halts.  How is it that you can keep ignoring this?
>>>>>
>>>>> It is a verified fact that for every possible (abort / do not abort)
>>>>> behavior of every possible encoding of simulating halt decider H that
>>>>> the input to H(P,P) never reaches its final state.
>>>> H(P,P)==0 is wrong because P(P) halts.  You keep trying to explain some
>>>> other decision problem that you think H is getting right.  For the
>>>> halting problem -- the one you've been "studying" for more than 14
>>>> years
>>>> -- H(P,P)==0 is only correct if P(P) does not halt and you've told us
>>>> that is does.
>>>>
>>>>> It is like I am telling there are no integers between 1 and 2 and you
>>>>> just don't believe it.
>>>> No, its like you are tell me that H(P,P)==false is the right answer
>>>> from
>>>> a halt decider when P(P) is a halting computation.  In fact it's very
>>>> much like that.  Almost exactly like that in fact.
>>>>
>>>>> It seems to be intuitively true that H(P,P) should report that its
>>>>> input halts because P(P) halts.
>>>> No.  I have no intuition about what you even mean because inputs don't
>>>> do anything.  What is true by definition (no intuition required) is
>>>> that
>>>> H(P,P) should be false only if P(P) does not halt.
>>>>
>>>>> This intuition
>>>> I don't have that intuition.  What "the input" does is meaningless.
>>>
>>> Every halt decider is ONLY tasked with determining the behavior of its
>>> input.
>>
>> No.  Every halt decider is tasked with determining the behaviour of the
>> computation represented by its input.  That's why H(P,P)==0 is wrong.
>> The arguments in that call represent the halting computation P(P).
>>
>
> THE IS THE MOST RECENT UPDATE TO THE CRITERION MEASURE
> A halt decider only need answer whether or not the correct pure
> simulation of its input would ever reach a final state of this input by
> a simulating halt decider.

FINALLY, HE'S GOT IT.

The right answer for the Halt decider H(M,i) is based on the results
that UTM(M,i) would do (A Halt decider can NOT be a pure simulator for a
non-halting computation, that is a conflict of definitions).

>
> This addresses two issues, it focuses analysis on the correct point in
> the execution trace.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> It does not matter whether or not the halt decider at Ĥ.qx halts or not
> the only thing that matters is whether or not the simulation of the
> input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ever reaches a final state.

WRONG, you slipped.

It is NOT a question if the partial simulation by H reached the final
halting state, but if a PURE simulation (i.e. by a UTM) would have
reached that final state.

For H^(<H^>), if H*<H^>,<H^>) says non-haltiung, it does. PERIOD.

>
> It acknowledges that inputs themselves only have behavior while they are
> simulated.
>

Right, and the simulation that matters is a ACTUAL UTM/Pure simulation,
ie a simulator that does not halt the simulation until the machihne it
is simulating halts.

Thus the Pure Simulation of a Non-Halting Computation will never halt
itself (and thus a pure simulator is NOT a Halting decider, just a
Halting Acceptor)

>>> That you say otherwise is very stupid.
>>
>> I say otherwise because I know what the halting problem is, and because
>> I want to be careful about the details.  You are deliberately not
>> talking about what the input represents because you know H is wrong
>> about that computation.  This shift in wording is all you have left
>> after 14 years of being wrong about halting.
>>
>
>

On 11/3/21 12:14 PM, olcott wrote:
> On 11/3/2021 11:00 AM, André G. Isaak wrote:
>> On 2021-11-03 09:47, olcott wrote:
>>
>>> THE IS THE MOST RECENT UPDATE TO THE CRITERION MEASURE
>>> A halt decider only need answer whether or not the correct pure
>>> simulation of its input would ever reach a final state of this input
>>> by a simulating halt decider.
>>
>> The halting problem already defines what the criterion used by a halt
>> decider must be. You don't get to update it if that's the problem you
>> want to work on.
>>
>> André
>>
>
> No one here seems capable of understanding is that when a halt decider
> does correctly decide the halt status of its input then its input has
> had its halt status correctly decided.
>

Yes, if it IS correct, it is correct.

Your answer is NOT correct because you look at the wrong and incorrect
simulation.

> Even Linz got confused about this.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> It does not matter whether or not the halt decider at Ĥ.qx halts or not
> the only thing that matters is whether or not the simulation of the
> input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ever reaches a final state.

No, you are wrong and Linz was right, BECAUSE the machine that the halt
decider was deciding on was based on a copy of itself.

The Halt decider must decide based on the ACTUAL behavior of the
Computation that the input represent. That can equivalently be seen in
the simulaton of this input by a UTM.

Note, if H answers non-halting, it is NOT a UTM, as a UTM NEVER 'aborts'
its simulation, but simulatate completely until the simulation of the
input reaches a halting state.

>
> The mistake is just like putting Bill Smith in jail for robbing a liquor
> store because Bill Jones did Rob a liquor store.

But if Bill Smith robs Bill Smiths liquor store, he is still guilty of
robbery.

This is NOT a case of mistaken identity because the input to H IS a
machine that uses a copy of H, so yes, H needs to know what H is going
to do in this case.

>
> As long as a halt decider does correctly decide the halt status of its
> input nothing else in the universe can show that the halt decider is
> incorrect.
>

And 'The Halt Status of its Input' can only be meaningfully interpreted
as the simulation of that input by a REAL UTM (not the broken and
modified maybe used to have been a UTM that is H).

On 11/3/21 1:19 PM, olcott wrote:

> The only criteria for correctly deciding the halt status of the actual
> input is whether or not the correct pure simulation of this input would
> ever reach a final state.

And the correct simulation would be by UTM, not something like H that
might abort its simulation.

>
> Every other criteria changes the subject to an entirely different
> comutation.
>

Right, no other criteria, like what the partial simulation done by H
matters, only the CORRECT simulation by a UTM does. This BY DEFINITION
matches the operation of the Computation that this input represents, ie
what P(P) does. Since P(P) halts, we know that UTM(P,P) will halt and
thus H(P,P) saying non-halting is WRONG.

On 11/3/21 2:23 PM, olcott wrote:

> It is impossible for any halt decider to be incorrect when the correct
> pure simulation of its input never halts and it reports not halting.
>

But the CORRECT pure simulation of this input halts.

The only case where it doesn't is the case where you actually make H be
a pure simulation, and while in this case P(P) is non-halting, the H for
this P never gives that answer.

You can't claim credit for some other H being right for this P as that H
needs to get the P built from IT right, not the P built from some other
H right.

On 11/3/21 3:02 PM, André G. Isaak wrote:
> On 2021-11-03 12:23, olcott wrote:
>> On 11/3/2021 12:44 PM, André G. Isaak wrote:
>>> On 2021-11-03 11:19, olcott wrote:
>>>> On 11/3/2021 12:09 PM, André G. Isaak wrote:
>>>>> On 2021-11-03 10:14, olcott wrote:
>>>>>> On 11/3/2021 11:00 AM, André G. Isaak wrote:
>>>>>>> On 2021-11-03 09:47, olcott wrote:
>>>>>>>
>>>>>>>> THE IS THE MOST RECENT UPDATE TO THE CRITERION MEASURE
>>>>>>>> A halt decider only need answer whether or not the correct pure
>>>>>>>> simulation of its input would ever reach a final state of this
>>>>>>>> input by a simulating halt decider.
>>>>>>>
>>>>>>> The halting problem already defines what the criterion used by a
>>>>>>> halt decider must be. You don't get to update it if that's the
>>>>>>> problem you want to work on.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> No one here seems capable of understanding is that when a halt
>>>>>> decider does correctly decide the halt status of its input then
>>>>>> its input has had its halt status correctly decided.
>>>>>
>>>>> Right. And since yours doesn't correctly decide the halt status of
>>>>> its input then its input has not had its halt status correctly
>>>>> decided.
>>>>>
>>>>
>>>> The only criteria for correctly deciding the halt status of the
>>>> actual input is whether or not the correct pure simulation of this
>>>> input would ever reach a final state.
>>>>
>>>> Every other criteria changes the subject to an entirely different
>>>> comutation.
>>>
>>>
>>> Both 'halting problem' and 'halt decider' were defined before you
>>> were born by people who actually UNDERSTOOD the topic.
>>>
>>> The definitions of these things are precise, unambiguous, and clearly
>>> indicate the actual criterion which a halt decider must use in making
>>> its decision. That criterion makes no reference to pure simulations.
>>> It refers only to whether the computation represented by the input
>>> string halts.
>>>
>>
>> It is impossible for any halt decider to be incorrect when the correct
>> pure simulation of its input never halts and it reports not halting.
>
> Not if it contradicts the actual correct answer as determined by the
> criterion which defines the halting problem since that criterion alone
> determines which answer is correct.

But if a real PURE simulation, ie a simulation by a UTM, then that does
match the criteria.

PO's problem is he doesn't look at that proper pure simulation, so he
obviously doesn't have the right definition of what a real 'pure
simulation' is, or he is just lying.

>
> And your H does not give the correct answer for P(P) even if "the
> correct pure simulation of its input never halts and it reports not
> halting."
>
> There are several possible explanations for this:
>
> (a) Your "revised" criterion is not equivalent to the one which defines
> the problem and thus your H is not addressing the actual halting problem.
>
> (b) Your H is buggy and therefore is not returning the answer it should.
>
> (c) The internal logic of your H doesn't actually implement the
> criterion you claim it does.
>
> (d) Your criterion is so poorly stated and involves so much equivocation
> that it isn't even possible to determine whether something meets it or not.
>
> (e) More than one of the above
>
> (f) All of the above.
>
> My money's on (f).
>
> André
>

On 11/3/21 5:18 PM, olcott wrote:
> On 11/3/2021 4:03 PM, André G. Isaak wrote:
>> On 2021-11-03 14:02, olcott wrote:
>>> On 11/3/2021 2:02 PM, André G. Isaak wrote:
>>>> On 2021-11-03 12:23, olcott wrote:
>>>>> On 11/3/2021 12:44 PM, André G. Isaak wrote:
>>>>>> On 2021-11-03 11:19, olcott wrote:
>>>>>>> On 11/3/2021 12:09 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-03 10:14, olcott wrote:
>>>>>>>>> On 11/3/2021 11:00 AM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-03 09:47, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>> THE IS THE MOST RECENT UPDATE TO THE CRITERION MEASURE
>>>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>>>> pure simulation of its input would ever reach a final state
>>>>>>>>>>> of this input by a simulating halt decider.
>>>>>>>>>>
>>>>>>>>>> The halting problem already defines what the criterion used by
>>>>>>>>>> a halt decider must be. You don't get to update it if that's
>>>>>>>>>> the problem you want to work on.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No one here seems capable of understanding is that when a halt
>>>>>>>>> decider does correctly decide the halt status of its input then
>>>>>>>>> its input has had its halt status correctly decided.
>>>>>>>>
>>>>>>>> Right. And since yours doesn't correctly decide the halt status
>>>>>>>> of its input then its input has not had its halt status
>>>>>>>> correctly decided.
>>>>>>>>
>>>>>>>
>>>>>>> The only criteria for correctly deciding the halt status of the
>>>>>>> actual input is whether or not the correct pure simulation of
>>>>>>> this input would ever reach a final state.
>>>>>>>
>>>>>>> Every other criteria changes the subject to an entirely different
>>>>>>> comutation.
>>>>>>
>>>>>>
>>>>>> Both 'halting problem' and 'halt decider' were defined before you
>>>>>> were born by people who actually UNDERSTOOD the topic.
>>>>>>
>>>>>> The definitions of these things are precise, unambiguous, and
>>>>>> clearly indicate the actual criterion which a halt decider must
>>>>>> use in making its decision. That criterion makes no reference to
>>>>>> pure simulations. It refers only to whether the computation
>>>>>> represented by the input string halts.
>>>>>>
>>>>>
>>>>> It is impossible for any halt decider to be incorrect when the
>>>>> correct pure simulation of its input never halts and it reports not
>>>>> halting.
>>>>
>>>> Not if it contradicts the actual correct answer as determined by the
>>>> criterion which defines the halting problem since that criterion
>>>> alone determines which answer is correct.
>>> It is impossible for any halt decider to be incorrect when the
>>> correct pure simulation of its input never halts and it reports not
>>> halting.
>>
>> But your halt decider doesn't implement a 'pure simulation' under any
>> reasonable definition of the term.
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> Begin Local Halt Decider Simulation at Machine Address:c36
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> We can perfectly know that H(P,P) does precisely simulate the first
> seven instructions of P when it simulates the first seven instructions
> of P.
>
> We can also know that when it perfectly repeats this sequence again that
> it has acted as a pure simulator for the execution of these two sequences.
>
>

H is only a pure simulator if it CONTINUES to repeat this pattern over
and over.

If H only simulates the loop for a finite number of iterations, it is
NOT a pure simulator because if H does abort its simulation and return
non-halting, the the first call to H MUST show the path following the
non-halting return path.

The transformation of simulating the simulator to showing the simultion
it is doing is only valid if the simulator NEVER aborts until it reaches
a final halting state.

Since you H doesn't do that (at least if it answer to H(P,P) as
non-halting) H is NOT a correct simulator, having done an incorrect
transform of the trace.

On 11/3/21 6:58 PM, olcott wrote:
> On 11/3/2021 5:10 PM, André G. Isaak wrote:
>>
>> And so what? Somethings either a pure simulator or it isn't.
>
> That it is a pure simulator to this point conclusively proves that
> it is a pure simulator up to this point and conclusively proves that
> a pure simulation would never halt.

But acting like a pure simulator up to a point does NOT prove that
something actually IS a pure simulator any more that the fact that
someone is currently living proves they are immortal.

>
> It is impossible for any halt decider to be incorrect when the correct
> pure simulation of its input never halts and it reports not halting.
>
>

Impossible. A Pure simulator can, by definition, NEVER return
'non-halting' as the pure simulation of a non-halting computation is
non-halting, since it MUST exactly reflect the behavior of the machine
it is simulating.

On 11/3/21 12:25 PM, olcott wrote:
> On 11/3/2021 11:15 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/2/2021 10:17 PM, Ben Bacarisse wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>
>>>>> Every halt decider is ONLY tasked with determining the behavior of its
>>>>> input.
>>>>
>>>> No.  Every halt decider is tasked with determining the behaviour of the
>>>> computation represented by its input.  That's why H(P,P)==0 is wrong.
>>>> The arguments in that call represent the halting computation P(P).
>>>
>>> THE IS THE MOST RECENT UPDATE TO THE CRITERION MEASURE
>>> A halt decider only need answer whether or not the correct pure
>>> simulation of its input would ever reach a final state of this input
>>> by a simulating halt decider.
>>
>> The halting problem is already defined, thank you.  H(P,P) == false is
>> wrong because P(P) halts.
>>
>
> So in other words when H correctly determines that its input never
> reaches its final state the fact that some other entirely different
> computation does reach its final state proves that H is wrong?

Except that H never correctly determins that its input never reaches its
final state when simulated by a real pure simulator.

H only shows that its input didn't read its final state during its
partial, and thus NOT pure, simulation of the input.

It then uses unsound logic of assuming that the copy of it in the
machine that it is simulating will act differently than it does, and
thus it gets the wrong answer.

>
> H1(P,P) is computationally equivalent to P(P)
> H(P,P) is NOT computationally equivalent to either P(P) or H1(P,P).
>

Just more proof you don't understand what you are saying.

On 11/3/21 11:50 AM, olcott wrote:
> On 11/2/2021 10:20 PM, Ben Bacarisse wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 11/2/2021 12:13 PM, Ben Bacarisse wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>>
>>>>> On 11/2/2021 10:10 AM, Ben Bacarisse wrote:
>>>>
>>>>>> You want me to get sucked into discussing your other errors, but
>>>>>> really
>>>>>> only one counts: H(P,P) == false is the wrong answer if P(P) halts.
>>>>>>
>>>>> As long as H(P,P)==0 is correct none of my other "errors" are of any
>>>>> consequence what-so-ever.
>>>> Only one error really matters, and that's the fact that H(P,P)==0 is
>>>> not
>>>> correct if P(P) halts,
>>>
>>> As long as the input to H(P,P) cannot possibly halt for every possible
>>> encoding of simulating halt decider H then H(P,P)==0 can't possibly be
>>> incorrect NO MATTER WHAT.
>>
>> Whether H(P,P)==0 is correct is determined by what P(P) does, and since
>> P(P) halts, H(P,P)==0 is wrong.
>>
>
>
> THE IS THE MOST RECENT UPDATE TO THE CRITERION MEASURE
> A halt decider only need answer whether or not the correct pure
> simulation of its input would ever reach a final state of this input by
> a simulating halt decider.
>
> This addresses two issues, it focuses analysis on the correct point in
> the execution trace.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> It does not matter whether or not the halt decider at Ĥ.qx halts or not
> the only thing that matters is whether or not the simulation of the
> input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ever reaches a final state.
>
> It acknowledges that inputs themselves only have behavior while they are
> simulated.
>
> It does not matter what P(P) does it matters what the simulated input to
> H(P,P) does.

This is where you go wrong.

Since H is NOT a pure simulator, it doens't matter what the simulation
of H(P,P) shows, it matters what the simulation inside UTM(P,P) would
show, which WILL exactly match what P(P) does.

The fact you get this wrong shows you don't understand what you are
talking about.

>
> H1(P,P) is computationally equivalent to P(P).
> H(P,P) is not computationally equivalent to H1(P,P) or P(P).

And more proof of your ignorance.

>
>
>>> If we have a black cat then it is utterly impossible that we do not
>>> have a cat.
>>
>> We have a hating computation, P(P), and an H that is wrong about it.  I
>> don't know what all this nonsense about cats is intended to show.
>>
>
>

On 2021-11-03 18:43, Richard Damon wrote:

> Since H is NOT a pure simulator, it doens't matter what the simulation
> of H(P,P) shows, it matters what the simulation inside UTM(P,P) would
> show, which WILL exactly match what P(P) does.

Or one could just skip the middleman and look at P(P) directly.
Involving UTMs at all is both unnecessary and exacerbates the confusion
of the oclott.

André

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

On 11/3/21 9:55 PM, André G. Isaak wrote:
> On 2021-11-03 18:43, Richard Damon wrote:
>
>> Since H is NOT a pure simulator, it doens't matter what the simulation
>> of H(P,P) shows, it matters what the simulation inside UTM(P,P) would
>> show, which WILL exactly match what P(P) does.
>
> Or one could just skip the middleman and look at P(P) directly.
> Involving UTMs at all is both unnecessary and exacerbates the confusion
> of the oclott.
>
> André
>

The problem is that if you want to actually try to phyically DO
something to show what happens when you actual do the original
computation, you need to know a lot more about Machines to convert the
representation of H^ into that actual machinbe H^.

By using a UTM, you can just run that UTM on the input that you have.

And, if you need the crux of needing a physial computer to run the
operation then likely what you are going to use is actually something
that is a real 'pure simulator'.

Yes, technically it is only an actual UTM if the execution mechanizm is
a Turing Machine, but if we accept that we are even entertaining that he
can discuss doing this as actual 'Equivalent' machines, then defining
that the simulator to be used needs to be the equivalent of a UTM is the
natural choice, and the essential property that UTM(M,i) will be
identical to actually running M(i) says that this alternative is
actually a true equivalent.

It also gives us a clear comparison between what H does and waht the UTM
program does, H stops its simulation, converting a potentially infinite
execution into a finite one, while a UTM will always have infinite
execution if its input represents an infinte computation.

Things tha behave differently can NOT be equivalent, so H can not be the
equivalent of the needed UTM simulator.

Now, it seems that PO doesn't understand this, but that just means that
his 'proof' has the glaring error of a math proof that begins with
something like assume 1 == 2.

On 11/3/2021 6:24 PM, André G. Isaak wrote:
> On 2021-11-03 16:58, olcott wrote:
>> On 11/3/2021 5:10 PM, André G. Isaak wrote:
>>> On 2021-11-03 15:18, olcott wrote:
>>>> On 11/3/2021 4:03 PM, André G. Isaak wrote:
>>>
>>>>> But your halt decider doesn't implement a 'pure simulation' under
>>>>> any reasonable definition of the term.
>>>>
>>>> _P()
>>>> [00000c36](01)  55          push ebp
>>>> [00000c37](02)  8bec        mov ebp,esp
>>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>>> [00000c3c](01)  50          push eax
>>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>>> [00000c40](01)  51          push ecx
>>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>>> [00000c46](03)  83c408      add esp,+08
>>>> [00000c49](02)  85c0        test eax,eax
>>>> [00000c4b](02)  7402        jz 00000c4f
>>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>>> [00000c4f](01)  5d          pop ebp
>>>> [00000c50](01)  c3          ret
>>>> Size in bytes:(0027) [00000c50]
>>>>
>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>>
>>>>   machine   stack     stack     machine    assembly
>>>>   address   address   data      code       language
>>>>   ========  ========  ========  =========  =============
>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>> H(P,P)
>>>>
>>>> We can perfectly know that H(P,P) does precisely simulate the first
>>>> seven instructions of P when it simulates the first seven
>>>> instructions of P.
>>>>
>>>> We can also know that when it perfectly repeats this sequence again
>>>> that it has acted as a pure simulator for the execution of these two
>>>> sequences.
>>>
>>> And so what? Somethings either a pure simulator or it isn't.
>>
>> That it is a pure simulator to this point conclusively proves that
>> it is a pure simulator up to this point and conclusively proves that
>> a pure simulation would never halt.
>
> Being a pure simulator 'to this point' is not the same thing as being a
> pure simulator.
>

That is correct yet moot.

Being a pure simulator up to the point where it is obvious that the
simulation never reaches a final state of P is all that is needed then
thus criterion takes over:

2021-11-03 Halt Deciding Criteria
It is impossible for any halt decider to be incorrect when the correct
pure simulation of its input never halts and it reports not halting.

> And, as I already pointed out, this is all entirely irrelevant. P(P)
> halts. Your H(P, P) claims it does not. Therefore your H is wrong.
> Nothing you write above changes this.
>
>> It is impossible for any halt decider to be incorrect when the correct
>> pure simulation of its input never halts and it reports not halting.
>
> It is impossible for any halt decider to be correct when its answer
> doesn't actually match the correct answer. The correct answer is
> determined *solely* by the actual behaviour of P(P). This is part of the
> basic definition of Halting/Halt Decider. Yet you seem determined to
> talk about anything *except* the actual behaviour of P(P).
>
> P(P) halts. Your H(P, P) claims it does not. Therefore your H is wrong.
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 11/3/2021 7:37 PM, Richard Damon wrote:
>
> On 11/3/21 6:58 PM, olcott wrote:
>> On 11/3/2021 5:10 PM, André G. Isaak wrote:
>>>
>>> And so what? Somethings either a pure simulator or it isn't.
>>
>> That it is a pure simulator to this point conclusively proves that
>> it is a pure simulator up to this point and conclusively proves that
>> a pure simulation would never halt.
>
> But acting like a pure simulator up to a point does NOT prove that
> something actually IS a pure simulator

Acting as a pure simulator up to a point where it is be determined that
the simulation never reaches the final state of the input is the point
where this criteria is applied:

2021-11-03 Halt Deciding Criteria
It is impossible for any halt decider to be incorrect when the correct
pure simulation of its input never halts and it reports not halting.

> any more that the fact that
> someone is currently living proves they are immortal.
>
>>
>> It is impossible for any halt decider to be incorrect when the correct
>> pure simulation of its input never halts and it reports not halting.
>>
>>
>
> Impossible. A Pure simulator can, by definition, NEVER return
> 'non-halting' as the pure simulation of a non-halting computation is
> non-halting, since it MUST exactly reflect the behavior of the machine
> it is simulating.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 11/4/21 12:54 AM, olcott wrote:
> On 11/3/2021 6:24 PM, André G. Isaak wrote:
>> On 2021-11-03 16:58, olcott wrote:
>>> On 11/3/2021 5:10 PM, André G. Isaak wrote:
>>>> On 2021-11-03 15:18, olcott wrote:
>>>>> On 11/3/2021 4:03 PM, André G. Isaak wrote:
>>>>
>>>>>> But your halt decider doesn't implement a 'pure simulation' under
>>>>>> any reasonable definition of the term.
>>>>>
>>>>> _P()
>>>>> [00000c36](01)  55          push ebp
>>>>> [00000c37](02)  8bec        mov ebp,esp
>>>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>>>> [00000c3c](01)  50          push eax
>>>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>>>> [00000c40](01)  51          push ecx
>>>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>>>> [00000c46](03)  83c408      add esp,+08
>>>>> [00000c49](02)  85c0        test eax,eax
>>>>> [00000c4b](02)  7402        jz 00000c4f
>>>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>>>> [00000c4f](01)  5d          pop ebp
>>>>> [00000c50](01)  c3          ret
>>>>> Size in bytes:(0027) [00000c50]
>>>>>
>>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>>>
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>>> H(P,P)
>>>>>
>>>>> We can perfectly know that H(P,P) does precisely simulate the first
>>>>> seven instructions of P when it simulates the first seven
>>>>> instructions of P.
>>>>>
>>>>> We can also know that when it perfectly repeats this sequence again
>>>>> that it has acted as a pure simulator for the execution of these
>>>>> two sequences.
>>>>
>>>> And so what? Somethings either a pure simulator or it isn't.
>>>
>>> That it is a pure simulator to this point conclusively proves that
>>> it is a pure simulator up to this point and conclusively proves that
>>> a pure simulation would never halt.
>>
>> Being a pure simulator 'to this point' is not the same thing as being
>> a pure simulator.
>>
>
> That is correct yet moot.
>
> Being a pure simulator up to the point where it is obvious that the
> simulation never reaches a final state of P is all that is needed then
> thus criterion takes over:

No, you don't understand what you have proven. All you have proved is
that no version of a machine designed like H can ever in a partial
simulation of the input P (akaH^) have the simulation reach a halting state.

You then incorrectly presume that this means that the input represents a
non-halting computation. You haven't proved this step, just claimed it.

You also do correctly show that if H is the version that NEVER aborts,
that the P from this version is non-halting, but ignore the fact that
this H doesn't ever give that answer, and that the P from this case is a
different P then the P from any of the cases where H does abort its
simulation and return non-halting.

You have also 'proved' that you don't understand what an actual proof
is, as you whole basis is really just a rhetorical argument, and NOT

>
> 2021-11-03 Halt Deciding Criteria
> It is impossible for any halt decider to be incorrect when the correct
> pure simulation of its input never halts and it reports not halting.

Right, but the correct pure simulation of every input based on a H that
aays H(P,P) is non-halting, is halting. PERIOD.

Only your INCORRECT ABORTED simulations don't reach that point.

Even you sort of admit that, as you admit that P(P) does Halt, but miss
that this means BY DEFINITION that a pure simulation of the
representation of this computation must also halt, as the definition of
a pure simulation is that it EXACTLY mimics what the Computation that it
has been give a reputations does, giving the same answer when it halts,
and running forever if it is non-halting.

Since H, by the simple fact that it returns an answer in finite time for
an input it claims represents a computation that never will finish,
shows itself to NOT be a pure simulator.
>
>
>> And, as I already pointed out, this is all entirely irrelevant. P(P)
>> halts. Your H(P, P) claims it does not. Therefore your H is wrong.
>> Nothing you write above changes this.
>>
>>> It is impossible for any halt decider to be incorrect when the
>>> correct pure simulation of its input never halts and it reports not
>>> halting.
>>
>> It is impossible for any halt decider to be correct when its answer
>> doesn't actually match the correct answer. The correct answer is
>> determined *solely* by the actual behaviour of P(P). This is part of
>> the basic definition of Halting/Halt Decider. Yet you seem determined
>> to talk about anything *except* the actual behaviour of P(P).
>>
>> P(P) halts. Your H(P, P) claims it does not. Therefore your H is wrong.
>>
>> André
>>
>
>

On 11/4/21 1:00 AM, olcott wrote:
> On 11/3/2021 7:37 PM, Richard Damon wrote:
>>
>> On 11/3/21 6:58 PM, olcott wrote:
>>> On 11/3/2021 5:10 PM, André G. Isaak wrote:
>>>>
>>>> And so what? Somethings either a pure simulator or it isn't.
>>>
>>> That it is a pure simulator to this point conclusively proves that
>>> it is a pure simulator up to this point and conclusively proves that
>>> a pure simulation would never halt.
>>
>> But acting like a pure simulator up to a point does NOT prove that
>> something actually IS a pure simulator
>
> Acting as a pure simulator up to a point where it is be determined that
> the simulation never reaches the final state of the input is the point
> where this criteria is applied:
>
> 2021-11-03 Halt Deciding Criteria
> It is impossible for any halt decider to be incorrect when the correct
> pure simulation of its input never halts and it reports not halting.
>

Then PROVE that interpretation of the statement. You criteria says "Pure
Simulation', NOT acting like one up to a point. (with an ACTUAL proof,
not just a rhetorical argument, you know, with formal reference to known
facts and proven deductive operations)

Since th DEFINITION of pure simulation is a machine that behaves
IDENTICAL to the machine the input represents, which means having
infinite exectution when the input represents a non-halting computation,
something that acts like one until some point and then does something
els never was one in the first place.

This is like claiming you are immortal because you haven't died, yet.

If you won't even follow basic definitions of the terms you are using,
that just shows that you are a pathological liar.

>
>> any more that the fact that someone is currently living proves they
>> are immortal.
>>
>>>
>>> It is impossible for any halt decider to be incorrect when the
>>> correct pure simulation of its input never halts and it reports not
>>> halting.
>>>
>>>
>>
>> Impossible. A Pure simulator can, by definition, NEVER return
>> 'non-halting' as the pure simulation of a non-halting computation is
>> non-halting, since it MUST exactly reflect the behavior of the machine
>> it is simulating.
>
>