On 5/20/2022 9:09 PM, Dennis Bush wrote:
> On Friday, May 20, 2022 at 9:59:27 PM UTC-4, olcott wrote:
>> On 5/20/2022 8:51 PM, Dennis Bush wrote:
>>> On Friday, May 20, 2022 at 9:42:11 PM UTC-4, olcott wrote:
>>>> On 5/20/2022 8:20 PM, Dennis Bush wrote:
>>>>> On Friday, May 20, 2022 at 8:56:09 PM UTC-4, olcott wrote:
>>>>>> On 5/20/2022 7:32 PM, Dennis Bush wrote:
>>>>>>> On Friday, May 20, 2022 at 8:15:31 PM UTC-4, olcott wrote:
>>>>>>>> On 5/20/2022 7:09 PM, Dennis Bush wrote:
>>>>>>>>> On Friday, May 20, 2022 at 7:37:15 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/20/2022 6:31 PM, Dennis Bush wrote:
>>>>>>>>>>> On Friday, May 20, 2022 at 7:25:15 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/20/2022 6:21 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Friday, May 20, 2022 at 7:13:37 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/20/2022 6:11 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 7:02:24 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 5/20/2022 5:53 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 6:51:42 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/20/2022 5:44 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 6:33:29 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/20/2022 5:25 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You have known that the input to H(P,P) is simulated correctly proving
>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0 is correct for the whole six months
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If H is intended to be a halt decider (even if only for the one case you
>>>>>>>>>>>>>>>>>>>>> claim to care about) then H(P,P) == 0 is wrong, because P(P) halts.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If a "correct simulation of the input to H(P,P)" is a simulation of the
>>>>>>>>>>>>>>>>>>>>> function call P(P), then H(P,P) == 0 is wrong because both P(P) and a
>>>>>>>>>>>>>>>>>>>>> correct simulation of P(P) halt.
>>>>>>>>>>>>>>>>>>>> So in other words even though there are no lines of code that are
>>>>>>>>>>>>>>>>>>>> simulated incorrectly you still claim that the simulation is incorrect.
>>>>>>>>>>>>>>>>>>>> THAT IS WHAT A DAMNED LYING BASTARD WOULD SAY.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So if we look at the execution trace of Ha3(N,5),
>>>>>>>>>>>>>>>>>> Yet another God damned lying bastard that uses the strawman error in an
>>>>>>>>>>>>>>>>>> attempt to get away with deception.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So if you believe that Ha3(N,5)==0 is either wrong or irrelevent you should have no problem explaining why without just saying "strawman".
>>>>>>>>>>>>>>>> I am talking about the correct simulation of the machine language of P
>>>>>>>>>>>>>>>> being correctly emulated by another 100% specific finite string of
>>>>>>>>>>>>>>>> machine language named H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And by the criteria you use to show that H(P,P)==0 is correct,
>>>>>>>>>>>>>> More than that.
>>>>>>>>>>>>>> I prove that the criteria that I use is correct and I prove the
>>>>>>>>>>>>>> H(P,P)==0 is correct on the basis of that criteria.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The *only* criteria for whether the result of H(P,P) is correct is whether P(P) halts, *by definition*.
>>>>>>>>>>>> Not for the specific machine language that I am referring to.
>>>>>>>>>>>> So OK you prove that you intend to stay in despicable liar mode.
>>>>>>>>>>>>
>>>>>>>>>>>> You proclaim by lying bastard dictatorial fiat that the input to H(P,P)
>>>>>>>>>>>> halts even though its correct execution trace proves otherwise.
>>>>>>>>>>>
>>>>>>>>>>> The input to H(P,P) represents P(P) by definition.
>>>>>>>>>> Not when we are talking about C functions and x86 machine-code Jackass.
>>>>>>>>>
>>>>>>>>> Then you're not talking about the halting problem, and H is computing something other that the halting function
>>>>>>>> None-the-less H(P,P)==0 is proven to be correct.
>>>>>>>
>>>>>>> Only for something that is not the halting problem.
>>>>>> So you agree that H(P,P)==0 is correct when H computes the halt status
>>>>>> of the machine language of P that is passed to H on the stack as a pair
>>>>>> of pointers to the literal string of P?
>>>>>
>>>>> If you're referring to *just* the function P, it doesn't have a halt status because it's not a complete program.
>>>>>
>>>> When we stipulate that the input to H(P,P) only halts when its correct
>>>> simulation reaches its machine address of [000009f0] otherwise it is
>>>> non-halting then H(P,P)==0 is the correct halt status of the input to
>>>> H(P,P).
>>>>
>>>> _P()
>>>> [000009d6](01) 55 push ebp
>>>> [000009d7](02) 8bec mov ebp,esp
>>>> [000009d9](03) 8b4508 mov eax,[ebp+08]
>>>> [000009dc](01) 50 push eax // push P
>>>> [000009dd](03) 8b4d08 mov ecx,[ebp+08]
>>>> [000009e0](01) 51 push ecx // push P
>>>> [000009e1](05) e840feffff call 00000826 // call H
>>>> [000009e6](03) 83c408 add esp,+08
>>>> [000009e9](02) 85c0 test eax,eax
>>>> [000009eb](02) 7402 jz 000009ef
>>>> [000009ed](02) ebfe jmp 000009ed
>>>> [000009ef](01) 5d pop ebp
>>>> [000009f0](01) c3 ret // Final state
>>>> Size in bytes:(0027) [000009f0]
>>>
>>> But H(P,P) does *not* perform a correct of its input. A correct simulation of this input is done Hb(P,P) which does in fact reach a final state. Therefore H(P,P)==0 is wrong.
>> OK then when the literal string of the machine code of H correctly
>> emulates
>
> Which is doesn't as demonstrated by Hb(P,P) reaching a final state and returning 1.

H is at machine address 00000826 every other variation is a dishonest
dodge away from the actual question.

>
>
> the pair of literal strings of the machine code of P we can
>> verify that this execution trace is correct:
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>> ...[00001358][0021233a][00001352] 50 push eax // push P
>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> You left out the fixed code of H which simulates P and will eventually abort which Hb(P,P) is able to see but not H because H aborts too soon.
>
>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>> ...[00001358][0025cd62][00001352] 50 push eax // push P
>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>
>> On the basis of this x86 source-code of this literal string:
>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>
> Plus the x86 source code of the fixed implementation of H and everything H calls all the way down.
>
>>
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx
>> [0000135d](05) e840feffff call 000011a2 // call H
>> [00001362](03) 83c408 add esp,+08
>> [00001365](02) 85c0 test eax,eax
>> [00001367](02) 7402 jz 0000136b
>> [00001369](02) ebfe jmp 00001369
>> [0000136b](01) 5d pop ebp
>> [0000136c](01) c3 ret
>> Size in bytes:(0027) [0000136c]
>>
>> Specifies the trace that H provides.
>
> And none of this matters if H(P,P) isn't telling us if P(P) halts.
>
>>>
>>> This of course is all academic because H is not computing the halting function:
>>>
>>> D(X,Y)==1 if and only if X(Y) halts, and
>>> D(X,Y)==0 if and only if X(Y) does not halt
>>>
>>> All you're doing is trying to explain how it comes up with the wrong answer.
>>>
>>> It doesn't matter whether or not this fits the description of what you think a decider should be. That's the problem description, period.
>>>
>>> If you state that no D can compute this function, then you're explicitly agreeing with the conclusion of the halting problem proofs.
>>>
>>>
>>>>> The machine language of P, as a *complete program*, includes the fixed machine language of H since P calls H, plus everything that H calls all the way down. And P(P) halts, therefore H(P,P)==0 is wrong.
>>>>>
>>>>> Your error is thinking that H doesn't matter, but it does.
>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> When the HP requires that a non-decider
>>>>>>>
>>>>>>> It doesn't matter what it's called. What matters is that it computes the halting function.
>>>>>>>
>>>>>>>> that is not a computation
>>>>>>>
>>>>>>> If it always gives the same result for the same input, it *is* a computation
>>>>>>>
>>>>>>>> is required to compute halting for a non-input
>>>>>>>
>>>>>>> Which is exactly represented by the input
>>>>>>>
>>>>>>>> it contradicts the axioms of computer science
>>>>>>>
>>>>>>> Which means what exactly? You're just making stuff up.
>>>>>>>
>>>>>>>> and therefore errs, thus making H(P,P)==0 relevant.
>>>>>>>
>>>>>>> So in other words you're saying that the conclusion of the halting problem proofs is correct.
>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The input to the C function H is a pair of pointers to the the literal
>>>>>>>>>> string of the machine code of P, passed on the stack.
>>>>>>>>>
>>>>>>>>> And the H that P calls is considered part of the program P so it's behavior must be considered. And since the fixed code of H *will* return 0, a correct simulation of the input, like that performed by Hb, does reach a final state.
>>>>>>>> The correctly simulated input to H(P,P) cannot possibly ever reach its
>>>>>>>> own final state therefore is correctly determined to be non-halting.
>>>>>>>
>>>>>>> The correctly simulated input to H(P,P) is performed by Hb(P,P) which does simulate it to a final state, therefore H(P,P)==0 is wrong.
>

--
Copyright 2022 Pete Olcott

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