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

That's not a criterion. It's a statement.

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

You fail to respond to the above, further evidence that you are
determined to ignore the elephant in the room.

P(P) is a halting computation. You acknowledge this yourself.

A halt decider, *BY DEFINITION*, takes a description of a computation as
its input and decides whether that computation halts.

So the only correct answer for H(P, P) to give is 'HALTS'. But this is
not the answer your H gives, demonstrating that your H is incorrect.

Instead of acknowledging this, you are grasping at straws to somehow
justify the wrong answer which your decider generates.

You realize that if P(P) halts and your decider claims it does not and
your decider is "correct" (according to your various "arguments", using
that term rather loosely) then you have a contradiction.

That means your other bugaboo, the principle of explosion, rears its
ugly head. Any system which contains a contradiction can be used to
prove that absolutely *anything* is true. And also to prove that those
same things are false. That's the type of system you seem determined to
create.

André

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

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

On 11/2/21 9:32 PM, 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.

So, you think it is ok for a simulation, that claims to be an accurate
simulation, to give a different result then what the thing it is
supposed to be simulating does?

Yes, if it accurate simulates ALL of the instructions of the program
that it emulating, it will be accurate.

Note, PROGRAM P, includes the code of H, which your emulator never seems
to actually emulate (or at least emulate correctly) so that is where you
get your error.

>
>>>>> _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.
>

Nope, NO ONE has every said that simulation is an INVALID method, just
that it has inherent problems that will make it fail.

The proof that it can't work was method independent, so it includes the
use of simulation.

Yes, it does NOT allow for the use of Unicorn Machines that use 'Magic'
to violate the laws of Compuation, like the property that a specific
algorithm given the same data will always produce the same result.

>>
>>>>
>>>> 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.