On 6/28/2022 10:03 AM, wij wrote:
> On Tuesday, 28 June 2022 at 22:22:49 UTC+8, Dennis Bush wrote:
>> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
>>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
>>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
>>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
>>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
>>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
>>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
>>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
>>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
>>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
>>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
>>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
>>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
>>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
>>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
>>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
>>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
>>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
>>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> x(y)
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The specification for H:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H does not meet the specification.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The spec is provably incorrect in this case:
>>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
>>>>>>>>>>> You are just playing word games so I will use a different word:
>>>>>>>>>>> "criterion measure".
>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>
>>>>>>>>>> As per this specification:
>>>>>>>>>>
>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>> H(x,y)==1 if and only if x(y) halts
>>>>>>>>>>
>>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
>>>>>>>>>>
>>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
>>>>>>>>>>
>>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
>>>>>>>>>>
>>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
>>>>>>>>> The formal mathematical semantics of the x86 language conclusively
>>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
>>>>>>>>
>>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
>>>>>>> BUSTED!
>>>>>>> I GOT YOU NOW!
>>>>>>>
>>>>>>> How many recursive emulations does H need to wait before its emulated P
>>>>>>> to reaches its final instruction?
>>>>>>
>>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations. But its fixed algorithm prevents it from simulating any more than N emulations.
>>>>>
>>>>> "H aborted its simulation too soon."
>>>>> Liar liar pants on fire.
>>>>
>>>> PO-speak for "I know you proved me wrong and I don't know what else to say"
>>> It is PO-speak for I just proved that you are lying:
>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>> demonstrating that H aborted its simulation too soon.
>>> How many recursive emulations must H(P,P) emulate its input until its
>>> emulated input reaches the "ret" instruction of the emulated P?
>> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
>>
>> UTM(Pa,Pa) will simulate the input for the required number of cycles and see that it halts, proving that Ha(Pa,Pa)==0 is wrong. We can also construct Hb which simulates for N+1 cycles and see that Hb(Pa,Pa)==1 which also proves that Ha(Pa,Pa)==0 is wrong.
>
> 1. PO is incapable of the BASIC LOGIC. Anything he said may looked like having
> logic but not (he recites material in PO's own understanding).
> 2. PO has no real POOH (a real program). His H is a manual/verbal decider.
>
> From 1. Reasoning TM (or any abstract) with PO is like assuming a rock understand logic.
> The only thing PO trusts, or his argument is based, is physical computer, but see 2.

On Tuesday, June 28, 2022 at 11:22:00 AM UTC-4, olcott wrote:
> On 6/28/2022 10:03 AM, wij wrote:
> > On Tuesday, 28 June 2022 at 22:22:49 UTC+8, Dennis Bush wrote:
> >> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
> >>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
> >>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
> >>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
> >>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
> >>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
> >>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
> >>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
> >>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
> >>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
> >>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
> >>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
> >>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
> >>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
> >>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
> >>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt..
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
> >>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> _main()
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
> >>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
> >>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
> >>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
> >>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
> >>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
> >>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
> >>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
> >>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
> >>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
> >>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
> >>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
> >>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
> >>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
> >>>>>>>>>>>>>>>>>>>>>>>>>> executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
> >>>>>>>>>>>>>>>>>>>>>>>>>> executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
> >>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
> >>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
> >>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
> >>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
> >>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
> >>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
> >>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
> >>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
> >>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
> >>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>> x(y)
> >>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
> >>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
> >>>>>>>>>>>>>>>>>> final state.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
> >>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
> >>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The specification for H:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
> >>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> H does not meet the specification.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The spec is provably incorrect in this case:
> >>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
> >>>>>>>>>>> You are just playing word games so I will use a different word:
> >>>>>>>>>>> "criterion measure".
> >>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>
> >>>>>>>>>> As per this specification:
> >>>>>>>>>>
> >>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
> >>>>>>>>>> H(x,y)==1 if and only if x(y) halts
> >>>>>>>>>>
> >>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
> >>>>>>>>>>
> >>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
> >>>>>>>>>>
> >>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
> >>>>>>>>>>
> >>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
> >>>>>>>>> The formal mathematical semantics of the x86 language conclusively
> >>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
> >>>>>>>>
> >>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
> >>>>>>> BUSTED!
> >>>>>>> I GOT YOU NOW!
> >>>>>>>
> >>>>>>> How many recursive emulations does H need to wait before its emulated P
> >>>>>>> to reaches its final instruction?
> >>>>>>
> >>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations. But its fixed algorithm prevents it from simulating any more than N emulations.
> >>>>>
> >>>>> "H aborted its simulation too soon."
> >>>>> Liar liar pants on fire.
> >>>>
> >>>> PO-speak for "I know you proved me wrong and I don't know what else to say"
> >>> It is PO-speak for I just proved that you are lying:
> >>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
> >>>> demonstrating that H aborted its simulation too soon.
> >>> How many recursive emulations must H(P,P) emulate its input until its
> >>> emulated input reaches the "ret" instruction of the emulated P?
> >> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
> >>
> >> UTM(Pa,Pa) will simulate the input for the required number of cycles and see that it halts, proving that Ha(Pa,Pa)==0 is wrong. We can also construct Hb which simulates for N+1 cycles and see that Hb(Pa,Pa)==1 which also proves that Ha(Pa,Pa)==0 is wrong.
> >
> > 1. PO is incapable of the BASIC LOGIC. Anything he said may looked like having
> > logic but not (he recites material in PO's own understanding).
> > 2. PO has no real POOH (a real program). His H is a manual/verbal decider.
> >
> > From 1. Reasoning TM (or any abstract) with PO is like assuming a rock understand logic.
> > The only thing PO trusts, or his argument is based, is physical computer, but see 2.
> Like Ben you resort to rhetoric instead of reasoning and do this because
> there is no correct reasoning that can be used for a rebuttal of my work.
>
> If I was incorrect then someone could correctly point out at least one
> mistake. No one has correctly pointed out one mistake.

On Tuesday, 28 June 2022 at 23:22:00 UTC+8, olcott wrote:
>...[cut]
> >> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
> >>
> >> UTM(Pa,Pa) will simulate the input for the required number of cycles and see that it halts, proving that Ha(Pa,Pa)==0 is wrong. We can also construct Hb which simulates for N+1 cycles and see that Hb(Pa,Pa)==1 which also proves that Ha(Pa,Pa)==0 is wrong.
> >
> > 1. PO is incapable of the BASIC LOGIC. Anything he said may looked like having
> > logic but not (he recites material in PO's own understanding).
> > 2. PO has no real POOH (a real program). His H is a manual/verbal decider.
> >
> > From 1. Reasoning TM (or any abstract) with PO is like assuming a rock understand logic.
> > The only thing PO trusts, or his argument is based, is physical computer, but see 2.
> Like Ben you resort to rhetoric instead of reasoning and do this because
> there is no correct reasoning that can be used for a rebuttal of my work.
>
> If I was incorrect then someone could correctly point out at least one
> mistake. No one has correctly pointed out one mistake.
>
> Ben has resorted to using pure rhetoric because he knows that he has no
> reasoning that can be used as a rebuttal. I looked at what Ben has been
> saying on the comp.lang.c forum and Ben showed much more technical
> competence with C than I was every aware of. This degree of technical
> competence should enable Ben to fully understand my x86 code.

I don't resort to any rhetoric.
Show your H that you never show and keep asking people to review (nothing).
The real implement of the H in discussion (whatever it is) will be the final
'proof' any theory has to agree (your is nothing but talk/phantasy).

I know you changed the HP to the POOH (H(P,P) has nothing to do with P(P)).
But, from the fact that you don't even understand the basic logic, you can't
even have the POOH.

On 6/28/2022 11:51 AM, wij wrote:
> On Tuesday, 28 June 2022 at 23:22:00 UTC+8, olcott wrote:
>> ...[cut]
>>>> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
>>>>
>>>> UTM(Pa,Pa) will simulate the input for the required number of cycles and see that it halts, proving that Ha(Pa,Pa)==0 is wrong. We can also construct Hb which simulates for N+1 cycles and see that Hb(Pa,Pa)==1 which also proves that Ha(Pa,Pa)==0 is wrong.
>>>
>>> 1. PO is incapable of the BASIC LOGIC. Anything he said may looked like having
>>> logic but not (he recites material in PO's own understanding).
>>> 2. PO has no real POOH (a real program). His H is a manual/verbal decider.
>>>
>>> From 1. Reasoning TM (or any abstract) with PO is like assuming a rock understand logic.
>>> The only thing PO trusts, or his argument is based, is physical computer, but see 2.
>> Like Ben you resort to rhetoric instead of reasoning and do this because
>> there is no correct reasoning that can be used for a rebuttal of my work.
>>
>> If I was incorrect then someone could correctly point out at least one
>> mistake. No one has correctly pointed out one mistake.
>>
>> Ben has resorted to using pure rhetoric because he knows that he has no
>> reasoning that can be used as a rebuttal. I looked at what Ben has been
>> saying on the comp.lang.c forum and Ben showed much more technical
>> competence with C than I was every aware of. This degree of technical
>> competence should enable Ben to fully understand my x86 code.
>
> I don't resort to any rhetoric.
> Show your H that you never show and keep asking people to review (nothing).
> The real implement of the H in discussion (whatever it is) will be the final
> 'proof' any theory has to agree (your is nothing but talk/phantasy).
>

The full halt decider is down to 10 pages of source-code.
I will not provide this source-code for review on this forum.

The key aspect of its behavior has already been reviewed and
approved by one honest competent reviewer, thus proving that honest
competent reviewers do not need to see the source-code.

> I know you changed the HP to the POOH (H(P,P) has nothing to do with P(P)).
> But, from the fact that you don't even understand the basic logic, you can't
> even have the POOH.

--
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 Tue, 28 Jun 2022 14:39:29 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/28/2022 11:51 AM, wij wrote:
> > On Tuesday, 28 June 2022 at 23:22:00 UTC+8, olcott wrote:
> >> ...[cut]
> >>>> The fixed algorithm of H, which we'll refer to as Ha and the P
> >>>> that calls it we'll refer to as Pa, simulates for N recursive
> >>>> emulations. Therefore the input must be simulated for N+1
> >>>> recursive emulations. The fixed algorthm Ha is unable to
> >>>> simulate for this many cycles and therefore gets the wrong
> >>>> answer.
> >>>>
> >>>> UTM(Pa,Pa) will simulate the input for the required number of
> >>>> cycles and see that it halts, proving that Ha(Pa,Pa)==0 is
> >>>> wrong. We can also construct Hb which simulates for N+1 cycles
> >>>> and see that Hb(Pa,Pa)==1 which also proves that Ha(Pa,Pa)==0 is
> >>>> wrong.
> >>>
> >>> 1. PO is incapable of the BASIC LOGIC. Anything he said may
> >>> looked like having logic but not (he recites material in PO's own
> >>> understanding). 2. PO has no real POOH (a real program). His H is
> >>> a manual/verbal decider.
> >>>
> >>> From 1. Reasoning TM (or any abstract) with PO is like assuming
> >>> a rock understand logic. The only thing PO trusts, or his
> >>> argument is based, is physical computer, but see 2.
> >> Like Ben you resort to rhetoric instead of reasoning and do this
> >> because there is no correct reasoning that can be used for a
> >> rebuttal of my work.
> >>
> >> If I was incorrect then someone could correctly point out at least
> >> one mistake. No one has correctly pointed out one mistake.
> >>
> >> Ben has resorted to using pure rhetoric because he knows that he
> >> has no reasoning that can be used as a rebuttal. I looked at what
> >> Ben has been saying on the comp.lang.c forum and Ben showed much
> >> more technical competence with C than I was every aware of. This
> >> degree of technical competence should enable Ben to fully
> >> understand my x86 code.
> >
> > I don't resort to any rhetoric.
> > Show your H that you never show and keep asking people to review
> > (nothing). The real implement of the H in discussion (whatever it
> > is) will be the final 'proof' any theory has to agree (your is
> > nothing but talk/phantasy).
>
> The full halt decider is down to 10 pages of source-code.
> I will not provide this source-code for review on this forum.
>
> The key aspect of its behavior has already been reviewed and
> approved by one honest competent reviewer, thus proving that honest
> competent reviewers do not need to see the source-code.

All you have shown in this forum is that you have an Olcott Simulation
Detector, S, and not a halting decider, H.

/Flibble

On 6/28/2022 10:03 AM, Dennis Bush wrote:
> On Tuesday, June 28, 2022 at 10:47:01 AM UTC-4, olcott wrote:
>> On 6/28/2022 9:22 AM, Dennis Bush wrote:
>>> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
>>>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
>>>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
>>>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
>>>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
>>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
>>>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
>>>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
>>>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
>>>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
>>>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
>>>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
>>>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
>>>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
>>>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
>>>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> x(y)
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The specification for H:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H does not meet the specification.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The spec is provably incorrect in this case:
>>>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
>>>>>>>>>>>> You are just playing word games so I will use a different word:
>>>>>>>>>>>> "criterion measure".
>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>
>>>>>>>>>>> As per this specification:
>>>>>>>>>>>
>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts
>>>>>>>>>>>
>>>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
>>>>>>>>>>>
>>>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
>>>>>>>>>>>
>>>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
>>>>>>>>>>>
>>>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
>>>>>>>>>> The formal mathematical semantics of the x86 language conclusively
>>>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
>>>>>>>>>
>>>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
>>>>>>>> BUSTED!
>>>>>>>> I GOT YOU NOW!
>>>>>>>>
>>>>>>>> How many recursive emulations does H need to wait before its emulated P
>>>>>>>> to reaches its final instruction?
>>>>>>>
>>>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations. But its fixed algorithm prevents it from simulating any more than N emulations.
>>>>>>
>>>>>> "H aborted its simulation too soon."
>>>>>> Liar liar pants on fire.
>>>>>
>>>>> PO-speak for "I know you proved me wrong and I don't know what else to say"
>>
>>>> It is PO-speak for I just proved that you are lying:
>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>> demonstrating that H aborted its simulation too soon.
>>
>>>> How many recursive emulations must H(P,P) emulate its input until its
>>>> emulated input reaches the "ret" instruction of the emulated P?
>>>
>>> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
>>>
>> *Because I boxed you into a corner* you are finally implicitly admitting
>> that there is no integer value N number of cycles of recursive emulation
>> that H(P,P) can emulate its input such that the emulated P reaches its
>> final state "ret" instruction.
>
> I already told you: N+1 cycles for Pa which is built on Ha.
>

On 6/28/2022 10:25 AM, Dennis Bush wrote:
> On Tuesday, June 28, 2022 at 11:22:00 AM UTC-4, olcott wrote:
>> On 6/28/2022 10:03 AM, wij wrote:
>>> On Tuesday, 28 June 2022 at 22:22:49 UTC+8, Dennis Bush wrote:
>>>> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
>>>>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
>>>>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
>>>>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
>>>>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
>>>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
>>>>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>>>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
>>>>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
>>>>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
>>>>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
>>>>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
>>>>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> x(y)
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
>>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The specification for H:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H does not meet the specification.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The spec is provably incorrect in this case:
>>>>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
>>>>>>>>>>>>> You are just playing word games so I will use a different word:
>>>>>>>>>>>>> "criterion measure".
>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>
>>>>>>>>>>>> As per this specification:
>>>>>>>>>>>>
>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts
>>>>>>>>>>>>
>>>>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
>>>>>>>>>>>>
>>>>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
>>>>>>>>>>>>
>>>>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
>>>>>>>>>>>>
>>>>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
>>>>>>>>>>> The formal mathematical semantics of the x86 language conclusively
>>>>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
>>>>>>>>>>
>>>>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
>>>>>>>>> BUSTED!
>>>>>>>>> I GOT YOU NOW!
>>>>>>>>>
>>>>>>>>> How many recursive emulations does H need to wait before its emulated P
>>>>>>>>> to reaches its final instruction?
>>>>>>>>
>>>>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations. But its fixed algorithm prevents it from simulating any more than N emulations.
>>>>>>>
>>>>>>> "H aborted its simulation too soon."
>>>>>>> Liar liar pants on fire.
>>>>>>
>>>>>> PO-speak for "I know you proved me wrong and I don't know what else to say"
>>>>> It is PO-speak for I just proved that you are lying:
>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>> demonstrating that H aborted its simulation too soon.
>>>>> How many recursive emulations must H(P,P) emulate its input until its
>>>>> emulated input reaches the "ret" instruction of the emulated P?
>>>> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
>>>>
>>>> UTM(Pa,Pa) will simulate the input for the required number of cycles and see that it halts, proving that Ha(Pa,Pa)==0 is wrong. We can also construct Hb which simulates for N+1 cycles and see that Hb(Pa,Pa)==1 which also proves that Ha(Pa,Pa)==0 is wrong.
>>>
>>> 1. PO is incapable of the BASIC LOGIC. Anything he said may looked like having
>>> logic but not (he recites material in PO's own understanding).
>>> 2. PO has no real POOH (a real program). His H is a manual/verbal decider.
>>>
>>> From 1. Reasoning TM (or any abstract) with PO is like assuming a rock understand logic.
>>> The only thing PO trusts, or his argument is based, is physical computer, but see 2.
>> Like Ben you resort to rhetoric instead of reasoning and do this because
>> there is no correct reasoning that can be used for a rebuttal of my work.
>>
>> If I was incorrect then someone could correctly point out at least one
>> mistake. No one has correctly pointed out one mistake.
>
> Many, *many* mistakes have been pointed out in detail, but you are apparently unable to understand why you are wrong. The most glaring issue is that H doesn't implement the specification put forward by the halting problem:
>
> H(x,y)==1 if and only if x(y) halts, and
> H(x,y)==0 if and only if x(y) does not halt
>

On 6/28/2022 2:41 PM, Mr Flibble wrote:
> On Tue, 28 Jun 2022 14:39:29 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/28/2022 11:51 AM, wij wrote:
>>> On Tuesday, 28 June 2022 at 23:22:00 UTC+8, olcott wrote:
>>>> ...[cut]
>>>>>> The fixed algorithm of H, which we'll refer to as Ha and the P
>>>>>> that calls it we'll refer to as Pa, simulates for N recursive
>>>>>> emulations. Therefore the input must be simulated for N+1
>>>>>> recursive emulations. The fixed algorthm Ha is unable to
>>>>>> simulate for this many cycles and therefore gets the wrong
>>>>>> answer.
>>>>>>
>>>>>> UTM(Pa,Pa) will simulate the input for the required number of
>>>>>> cycles and see that it halts, proving that Ha(Pa,Pa)==0 is
>>>>>> wrong. We can also construct Hb which simulates for N+1 cycles
>>>>>> and see that Hb(Pa,Pa)==1 which also proves that Ha(Pa,Pa)==0 is
>>>>>> wrong.
>>>>>
>>>>> 1. PO is incapable of the BASIC LOGIC. Anything he said may
>>>>> looked like having logic but not (he recites material in PO's own
>>>>> understanding). 2. PO has no real POOH (a real program). His H is
>>>>> a manual/verbal decider.
>>>>>
>>>>> From 1. Reasoning TM (or any abstract) with PO is like assuming
>>>>> a rock understand logic. The only thing PO trusts, or his
>>>>> argument is based, is physical computer, but see 2.
>>>> Like Ben you resort to rhetoric instead of reasoning and do this
>>>> because there is no correct reasoning that can be used for a
>>>> rebuttal of my work.
>>>>
>>>> If I was incorrect then someone could correctly point out at least
>>>> one mistake. No one has correctly pointed out one mistake.
>>>>
>>>> Ben has resorted to using pure rhetoric because he knows that he
>>>> has no reasoning that can be used as a rebuttal. I looked at what
>>>> Ben has been saying on the comp.lang.c forum and Ben showed much
>>>> more technical competence with C than I was every aware of. This
>>>> degree of technical competence should enable Ben to fully
>>>> understand my x86 code.
>>>
>>> I don't resort to any rhetoric.
>>> Show your H that you never show and keep asking people to review
>>> (nothing). The real implement of the H in discussion (whatever it
>>> is) will be the final 'proof' any theory has to agree (your is
>>> nothing but talk/phantasy).
>>
>> The full halt decider is down to 10 pages of source-code.
>> I will not provide this source-code for review on this forum.
>>
>> The key aspect of its behavior has already been reviewed and
>> approved by one honest competent reviewer, thus proving that honest
>> competent reviewers do not need to see the source-code.
>
> All you have shown in this forum is that you have an Olcott Simulation
> Detector, S, and not a halting decider, H.
>
> /Flibble
>

Every simulating halt decider correctly simulates its input until it
correctly determines that this simulated input would never reach its
final state.

That you do not understand that H(P,P) does this is merely your
insufficient technical competence with the semantics of the x86 language.

--
Copyright 2022 Pete Olcott

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

Disgusting liar and bigot Peter Olcott wrote:
....
> The full halt decider is down to 10 pages of source-code.
> I will not provide this source-code for review on this forum.

You won't either because it doesn't exist in the first place,
or because you KNOW it can be proven invalid as an halt
decider.

> The key aspect of its behavior has already been reviewed and
> approved by one honest competent reviewer, thus proving that honest
> competent reviewers do not need to see the source-code.

This is a plain lie.

On 6/28/2022 2:56 PM, Python wrote:
> Disgusting liar and bigot Peter Olcott wrote:
> ...
>> The full halt decider is down to 10 pages of source-code.
>> I will not provide this source-code for review on this forum.
>
> You won't either because it doesn't exist in the first place,
> or because you KNOW it can be proven invalid as an halt
> decider.
>
>> The key aspect of its behavior has already been reviewed and
>> approved by one honest competent reviewer, thus proving that honest
>> competent reviewers do not need to see the source-code.
>
> This is a plain lie.

comp.lang.c++
On 6/14/2022 6:47 AM, Paul N wrote:
> Yes, it is clear to us humans watching
> it that the program is repeating itself.
> Thus we can appreciate that it will never
> reach the final "ret" - indeed, it won't
> even get to the infinite loop identified above.

--
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 Tuesday, June 28, 2022 at 3:44:30 PM UTC-4, olcott wrote:
> On 6/28/2022 10:03 AM, Dennis Bush wrote:
> > On Tuesday, June 28, 2022 at 10:47:01 AM UTC-4, olcott wrote:
> >> On 6/28/2022 9:22 AM, Dennis Bush wrote:
> >>> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
> >>>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
> >>>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
> >>>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
> >>>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
> >>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
> >>>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
> >>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
> >>>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
> >>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
> >>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> _main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
> >>>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
> >>>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
> >>>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
> >>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
> >>>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
> >>>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
> >>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
> >>>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
> >>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
> >>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
> >>>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
> >>>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
> >>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
> >>>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
> >>>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
> >>>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
> >>>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
> >>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> x(y)
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
> >>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
> >>>>>>>>>>>>>>>>>>> final state.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
> >>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
> >>>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The specification for H:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
> >>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H does not meet the specification.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The spec is provably incorrect in this case:
> >>>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
> >>>>>>>>>>>> You are just playing word games so I will use a different word:
> >>>>>>>>>>>> "criterion measure".
> >>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>
> >>>>>>>>>>> As per this specification:
> >>>>>>>>>>>
> >>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
> >>>>>>>>>>> H(x,y)==1 if and only if x(y) halts
> >>>>>>>>>>>
> >>>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
> >>>>>>>>>>>
> >>>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
> >>>>>>>>>>>
> >>>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
> >>>>>>>>>>>
> >>>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
> >>>>>>>>>> The formal mathematical semantics of the x86 language conclusively
> >>>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
> >>>>>>>>>
> >>>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
> >>>>>>>> BUSTED!
> >>>>>>>> I GOT YOU NOW!
> >>>>>>>>
> >>>>>>>> How many recursive emulations does H need to wait before its emulated P
> >>>>>>>> to reaches its final instruction?
> >>>>>>>
> >>>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations.. But its fixed algorithm prevents it from simulating any more than N emulations.
> >>>>>>
> >>>>>> "H aborted its simulation too soon."
> >>>>>> Liar liar pants on fire.
> >>>>>
> >>>>> PO-speak for "I know you proved me wrong and I don't know what else to say"
> >>
> >>>> It is PO-speak for I just proved that you are lying:
> >>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
> >>>>> demonstrating that H aborted its simulation too soon.
> >>
> >>>> How many recursive emulations must H(P,P) emulate its input until its
> >>>> emulated input reaches the "ret" instruction of the emulated P?
> >>>
> >>> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
> >>>
> >> *Because I boxed you into a corner* you are finally implicitly admitting
> >> that there is no integer value N number of cycles of recursive emulation
> >> that H(P,P) can emulate its input such that the emulated P reaches its
> >> final state "ret" instruction.
> >
> > I already told you: N+1 cycles for Pa which is built on Ha.
> >
> I am asking for the exact integer value of N in (numeric digits) and you
> consistently refuse to provide it because you know that it does not exist..

Python wrote:

> Disgusting liar and bigot Peter Olcott wrote:

so true indeed. I have to "ignore" him automatically for the sake of
quoting too much. To me, what exceed 100 lines is "ignored". They are
idiots, supporting killing the Grate Mother Russia.
>> The full halt decider is down to 10 pages of source-code.
>> I will not provide this source-code for review on this forum.

On Tuesday, June 28, 2022 at 3:53:12 PM UTC-4, olcott wrote:
> On 6/28/2022 10:25 AM, Dennis Bush wrote:
> > On Tuesday, June 28, 2022 at 11:22:00 AM UTC-4, olcott wrote:
> >> On 6/28/2022 10:03 AM, wij wrote:
> >>> On Tuesday, 28 June 2022 at 22:22:49 UTC+8, Dennis Bush wrote:
> >>>> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
> >>>>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
> >>>>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
> >>>>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
> >>>>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
> >>>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
> >>>>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
> >>>>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
> >>>>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> _main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
> >>>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
> >>>>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
> >>>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
> >>>>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
> >>>>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
> >>>>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
> >>>>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
> >>>>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
> >>>>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
> >>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
> >>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>> x(y)
> >>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
> >>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
> >>>>>>>>>>>>>>>>>>>> final state.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
> >>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
> >>>>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The specification for H:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
> >>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> H does not meet the specification.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The spec is provably incorrect in this case:
> >>>>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
> >>>>>>>>>>>>> You are just playing word games so I will use a different word:
> >>>>>>>>>>>>> "criterion measure".
> >>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>>>>>>> specified by these inputs.
> >>>>>>>>>>>>
> >>>>>>>>>>>> As per this specification:
> >>>>>>>>>>>>
> >>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
> >>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts
> >>>>>>>>>>>>
> >>>>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
> >>>>>>>>>>>>
> >>>>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
> >>>>>>>>>>>>
> >>>>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
> >>>>>>>>>>> The formal mathematical semantics of the x86 language conclusively
> >>>>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
> >>>>>>>>>>
> >>>>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
> >>>>>>>>> BUSTED!
> >>>>>>>>> I GOT YOU NOW!
> >>>>>>>>>
> >>>>>>>>> How many recursive emulations does H need to wait before its emulated P
> >>>>>>>>> to reaches its final instruction?
> >>>>>>>>
> >>>>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations. But its fixed algorithm prevents it from simulating any more than N emulations.
> >>>>>>>
> >>>>>>> "H aborted its simulation too soon."
> >>>>>>> Liar liar pants on fire.
> >>>>>>
> >>>>>> PO-speak for "I know you proved me wrong and I don't know what else to say"
> >>>>> It is PO-speak for I just proved that you are lying:
> >>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
> >>>>>> demonstrating that H aborted its simulation too soon.
> >>>>> How many recursive emulations must H(P,P) emulate its input until its
> >>>>> emulated input reaches the "ret" instruction of the emulated P?
> >>>> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
> >>>>
> >>>> UTM(Pa,Pa) will simulate the input for the required number of cycles and see that it halts, proving that Ha(Pa,Pa)==0 is wrong. We can also construct Hb which simulates for N+1 cycles and see that Hb(Pa,Pa)==1 which also proves that Ha(Pa,Pa)==0 is wrong.
> >>>
> >>> 1. PO is incapable of the BASIC LOGIC. Anything he said may looked like having
> >>> logic but not (he recites material in PO's own understanding).
> >>> 2. PO has no real POOH (a real program). His H is a manual/verbal decider.
> >>>
> >>> From 1. Reasoning TM (or any abstract) with PO is like assuming a rock understand logic.
> >>> The only thing PO trusts, or his argument is based, is physical computer, but see 2.
> >> Like Ben you resort to rhetoric instead of reasoning and do this because
> >> there is no correct reasoning that can be used for a rebuttal of my work.
> >>
> >> If I was incorrect then someone could correctly point out at least one
> >> mistake. No one has correctly pointed out one mistake.
> >
> > Many, *many* mistakes have been pointed out in detail, but you are apparently unable to understand why you are wrong. The most glaring issue is that H doesn't implement the specification put forward by the halting problem:
> >
> > H(x,y)==1 if and only if x(y) halts, and
> > H(x,y)==0 if and only if x(y) does not halt
> >
> I have proven that the above specification is internally inconsistent
> with the requirements of a *software engineering* halt decider.

On 6/28/2022 3:02 PM, Dennis Bush wrote:
> On Tuesday, June 28, 2022 at 3:44:30 PM UTC-4, olcott wrote:
>> On 6/28/2022 10:03 AM, Dennis Bush wrote:
>>> On Tuesday, June 28, 2022 at 10:47:01 AM UTC-4, olcott wrote:
>>>> On 6/28/2022 9:22 AM, Dennis Bush wrote:
>>>>> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
>>>>>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
>>>>>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
>>>>>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
>>>>>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
>>>>>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
>>>>>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
>>>>>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
>>>>>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> x(y)
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
>>>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
>>>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The specification for H:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H does not meet the specification.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The spec is provably incorrect in this case:
>>>>>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
>>>>>>>>>>>>>> You are just playing word games so I will use a different word:
>>>>>>>>>>>>>> "criterion measure".
>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As per this specification:
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
>>>>>>>>>>>> The formal mathematical semantics of the x86 language conclusively
>>>>>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
>>>>>>>>>>>
>>>>>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
>>>>>>>>>> BUSTED!
>>>>>>>>>> I GOT YOU NOW!
>>>>>>>>>>
>>>>>>>>>> How many recursive emulations does H need to wait before its emulated P
>>>>>>>>>> to reaches its final instruction?
>>>>>>>>>
>>>>>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations. But its fixed algorithm prevents it from simulating any more than N emulations.
>>>>>>>>
>>>>>>>> "H aborted its simulation too soon."
>>>>>>>> Liar liar pants on fire.
>>>>>>>
>>>>>>> PO-speak for "I know you proved me wrong and I don't know what else to say"
>>>>
>>>>>> It is PO-speak for I just proved that you are lying:
>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>>> demonstrating that H aborted its simulation too soon.
>>>>
>>>>>> How many recursive emulations must H(P,P) emulate its input until its
>>>>>> emulated input reaches the "ret" instruction of the emulated P?
>>>>>
>>>>> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
>>>>>
>>>> *Because I boxed you into a corner* you are finally implicitly admitting
>>>> that there is no integer value N number of cycles of recursive emulation
>>>> that H(P,P) can emulate its input such that the emulated P reaches its
>>>> final state "ret" instruction.
>>>
>>> I already told you: N+1 cycles for Pa which is built on Ha.
>>>
>> I am asking for the exact integer value of N in (numeric digits) and you
>> consistently refuse to provide it because you know that it does not exist.
>
> I don't know the exact value because you haven't shown the full code of Ha. So assuming that Ha simulates for N iterations, then it takes N+1 iterations to reach a final state. And the fixed algorithm of Ha is unable to simulate for N+1 iterations, but UTM is.
So you are saying that when the emulated input to H(P,P) is emulated by
H that this emulated input reaches its final state just after its
emulation has been aborted?