On 2021-11-02 19:32, olcott wrote:
> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>> On 2021-11-02 18:49, olcott wrote:
>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>> On 2021-11-02 16:51, olcott wrote:
>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>
>>>>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>>>>> correctly reports what the actual behavior of its actual input
>>>>>>>>> would be then everyone (besides me) is wrong.
>>>>>>>>
>>>>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>>>>> define it as 'wrong'. It defines what question it is supposed to
>>>>>>>> answer.
>>>>>>>>
>>>>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>>>>> halting behaviour so your position above is entirely incoherent.
>>>>>>>>
>>>>>>>
>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>> and an input, whether the program will finish running, or
>>>>>>> continue to run forever.
>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> The definition of 'halting problem' is what it is.
>>>>>>
>>>>>> Note that the above definition doesn't make any mentions of
>>>>>> 'simulations' just as the more formal definition used by Linz's
>>>>>> does not.
>>>>>>
>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>> simulation of its input would ever reach a final state of this
>>>>>>> input by a simulating halt decider.
>>>>>>
>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>> identically to the actual TM being simulated. That means that if
>>>>>> the actual TM halts the simulation also must halt. Which means
>>>>>> that your simulation is not a 'correct simulation'.
>>>>>>
>>>>>
>>>>> There are no freaking presumptions about it. As long as the
>>>>> simulation of P(P) matches its x86 source code then the simulation
>>>>> is correct.
>>>>
>>>> I have no idea what it means for a simulation of P(P) to "match its
>>>> x86 source code".
>>>>
>>>
>>> When the simulator executes the instructions at
>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>> of the x86 source code of P, then the simulator
>>> correctly simulated P(P).
>>
>> No. A simulator only 'correctly simulates' a machine when it
>> accurately duplicates *all* of the behaviour of that machine. Part of
>> the behaviour of P(P) is that it halts.
>>
>
> That is a stupid thing to say. The x86 emulator correctly emulates the
> x86 instructions of P iff it emulates the actual x86 intructions of P
> saying anything else is both pure bullshit and quite nutty.

That's a nonsensical claim. If it correctly emulates all the
instructions then it should have identical behaviour. That includes
whether it halts or not.

>>>>> _P()
>>>>> [00000c36](01)  55          push ebp
>>>>> [00000c37](02)  8bec        mov ebp,esp
>>>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>>>> [00000c3c](01)  50          push eax
>>>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>>>> [00000c40](01)  51          push ecx
>>>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>>>> [00000c46](03)  83c408      add esp,+08
>>>>> [00000c49](02)  85c0        test eax,eax
>>>>> [00000c4b](02)  7402        jz 00000c4f
>>>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>>>> [00000c4f](01)  5d          pop ebp
>>>>> [00000c50](01)  c3          ret
>>>>> Size in bytes:(0027) [00000c50]
>>>>>
>>>>> A correct simulation of P on input P can be empirically validated
>>>>> by the simulation of the first seven x86 instruction of P.
>>>>>
>>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>>> H(P,P)
>>>>>
>>>>> Because the simulation of P(P) matches its x86 source-code it is
>>>>> necessarily correct and impossibly incorrect.
>>>>>
>>>>>
>>>>> The only possibility for every encoding of simulating halt decider
>>>>> H is:
>>>>
>>>>> (a) H fails to abort its simulation (and thus fails to be a
>>>>> decider) and the first seven instructions of P infinitely repeat in
>>>>> which case P never reaches its final state of 0xc50.
>>>>>
>>>>> (b) H aborts its simulation of P at some address of P between 0xc36
>>>>> and 0xc41 in which case the input P fails to every reach its final
>>>>> state of 0xc50.
>>>>>
>>>>> One the basis of the correct simulation of the x86 source-code of
>>>>> P(P) we can see that it is utterly impossible for P to ever reach
>>>>> its final state of 0xc50.
>>>>
>>>> Even if your argument above were sound, it is also *irrelevant*
>>>> since the criterion which defines a 'halt decider' makes no mention
>>>> about simulations, simulators or aborted simulations.
>>>
>>> Because the criteria does say by what-so-ever means, it includes
>>> simulation.
>>
>> I never claimed otherwise.
>
> You implied otherwise.

No. I didn't. I stated that the correct answer to the question isn't
about the simulation. You're welcome to make use of simulation in
determining your answer, but your answer must be correct for the
*actual* Turing Machine being asked about.

A halting decider which takes <P> <P> as its input must answer the
question 'does P halt on input <P>'. That you implement your decider
using simulation doesn't change the question which it is required to
answer nor the answer to that question. And that question is about the
behaviour of P with the input <P>. And P(P) halts. it isn't being asked
about the behaviour of the input string (which is meangingless gibberish
since strings don't have behaviours).

Both Linz's definition and the one you quoted from Wikipedia are crystal
clear on this matter.

>>
>>>>
>>>> If P(P) halts, then the correct answer to the question 'Does P(P)
>>>> halt?' is 'yes'. And that's the question *by definition* which a
>>>> halt decider must answer.
>>>>
>>>> André
>>>>
>>>
>>> A halt decider only need answer whether or not the correct simulation
>>> of its input would ever reach a final state of this input by a
>>> simulating halt decider.
>>
>>
>> No. A halt decider needs to answer the question which a halt decider
>> is required to answer.
>
> And a black cat <is> both black and a cat.
>
>>  A halt decider which takes w_M and w as its inputs must answer the
>> question 'Does M halt on input w?' since that is how a halt decider is
>> *defined*.
>>
>
> You keep screwing around with the point in the execution trace that counts.
>
>> It doesn't matter whether you reach the answer by simulating or not.
>> The question and the answer remain the same. P(P) halts,
>
> You have to have the correct computation.
> If we want to know if Bill robbed the liquor store and Bill Jones did
> rob the liquor store it is not OK to put Bill Smith in jail on the basis
> that it is true that Bill robbed the liquor store.
>
> The input to H1(P,P) is computationally equivalent to P(P).
> The input to H(P,P) is not computationally equivalent to P(P).

So pray tell exactly which computation does the input to H(P, P)
represent, then?

If it represents something other than P(P) then you have not succeeded
in your stated goal which was to construct a program which correctly
decides halting for the case which the Linz proof shows is impossible.
That would be to have H correctly decide the halting behaviour of P(P).

Stating that the input to H(P,P) doesn't represent P(P) makes about as
much sense as claiming that the input to sqrt(4) doesn't represent the
integer 4.

If the inputs to H1 and H above are different, then why on earth would
they be expressed in exactly the same way? How do I ask H about the
computation which is being given as an input to H1 above? Remember that
a Halt Decider must be able to accept *any* computation as an input,
which means I must be able to ask it about the computation which H1 is
being asked about.

Any notation which uses (P, P) to represent two distinct computations
would be deranged to say the least.

André

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