On 2021-08-06 22:23, olcott wrote:
On 8/6/2021 10:55 PM, André G. Isaak wrote:
On 2021-08-06 09:59, olcott wrote:
Yes, but bear in mind that 'halting' refers to Turing Machines
operating on a specific input. It does not refer to simulations or
what happens inside a halting decider. It refers *only* to actual
computations, i.e. an actual Turing Machine operating on an actual
input string.
So yet again you prove that you are totally clueless that pure
simulations are computationally equivalent to direct executions ?
Your H is not a pure simulator
(3) Equivalent, I have adapted the original definition to apply to
subsets of computations.
I have no idea what that's even supposed to mean.
(4) Correct means that the condition of a conditional expression is
satisfied.
Again, I have no idea what that's even supposed to mean.
(5) Proof, here is what I mean by proof, it is an adaptation of the
sound deductive inference model such that valid inference must only
include true preserving operations.
By proof I mean the application of truth preserving inference steps
to premises that are known to be true. Since mathematical logic has
some inference steps that are not truth preserving these are ruled out. >>>> https://en.wikipedia.org/wiki/Principle_of_explosion
https://en.wikipedia.org/wiki/Paradoxes_of_material_implication
Validity and Soundness
A deductive argument is said to be valid if and only if it takes a
form that makes it impossible for the premises to be true and the
conclusion nevertheless to be false. Otherwise, a deductive argument
is said to be invalid.
A deductive argument is sound if and only if it is both valid, and
all of its premises are actually true. Otherwise, a deductive
argument is unsound. https://iep.utm.edu/val-snd/
// original definition of valid (same as P → C)
Material conditional
p q p → q
T T T
T F F
F T T
F F T
Transforming the above to become truth preserving:
The definition of valid is changed to:
p q p [PROVES] q
T T T
T F F
F T F
F F F
That is definitely *not* the definition of valid.
It might be simplest to call what I consider proof simply sound
deductive inference.
Nothing you write above has anything to do with validity or sound
deductive inference.
The truth table you give above is for AND. Olympia is the capital of Washington. Salem is the capital of Oregon. It is certainly *not* the
case the either of these statements can 'prove' the other, but according
to your table.
Salem is the capital of Oregon PROVES Olympia is the capital of Washington.
A deductive argument is said to be valid if and only if it takes a form >>>> that the conclusion is only true if and only if the premises are true. >>>>
All of the above is summed up as
P [PROVES] C if and only if (True(P) ⊢ True(C) ∧ False(P) ⊢ False(C))
Again, that is definitely *not* the definition of a proof.
modal operators are most often interpreted
"□" for "Necessarily" and "◇" for "Possibly".
https://en.wikipedia.org/wiki/Modal_logic
(P [PROVES] C) ↔ (P ↔ □C)
So [PROVES] is your synomym for and and is now also equivalent to 'if
and only if'? You need to go back to logic 101.
And since P ⊢ C means something entirely different from P ⊢□C, you need to justify how that '□' magically appears. But since you don't know what
it means that's going to be difficult for you.
Not only is that not the definition of proof, but your use of □ is
entirely meaningless above.
You do realise that □ conveys absolutely *no* information unless you
"□" for "Necessarily"
Gee thanks. I already new that. And once again that conveys absolutely
no information unless you explain what you mean by 'necessarily'. The
fact that you don't understand what is being asked here just confirms my point that you have no idea what □ means and therefore shouldn't be
using it.
There are *many* different modal logics. In all of them □ is referred to
as a necessity operator, but it *means* entirely different things. You
can't just start throwing modal operators around unless you specify
*which* type of modal logic you are using.
*All* of the errors which have been pointed out to you have been
errors in the actual argument.
No you always make sure to avoid that part.
This code proves that P has no escape from infinitely nested simulation.
The escape that exists is not in P. In both cases escape/no escape P
never reaches its final state of 0xc3f, therefore P never halts.
No, it does not. In P(P) P creates a simulation of P. That simulation is eventually aborted and control returns to the outermost P which then halts.
Since your trace completely skips over the call to 955 that abort code
is not seen which means the the return of control to the outermost P is
also not seen.
There is *no* justification for not including the code of H in this trace.
_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // push P
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // push P
[00000c30](05) e820fdffff call 00000955 // call H to simulate P
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]
André
On Monday, 9 August 2021 at 17:57:18 UTC+1, olcott wrote:
On 8/8/2021 1:50 PM, André G. Isaak wrote:It's unclear to me exactly how H is a "simulator", given this execution trace.
On 2021-08-06 22:23, olcott wrote:// Simplified Linz Ĥ (Linz:1990:319)
On 8/6/2021 10:55 PM, André G. Isaak wrote:
On 2021-08-06 09:59, olcott wrote:
Yes, but bear in mind that 'halting' refers to Turing Machines
operating on a specific input. It does not refer to simulations or
what happens inside a halting decider. It refers *only* to actual
computations, i.e. an actual Turing Machine operating on an actual
input string.
So yet again you prove that you are totally clueless that pure
simulations are computationally equivalent to direct executions ?
Your H is not a pure simulator
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param
[00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param
[00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H
Begin Local Halt Decider Simulation at Machine Address:d02
...[00000d02][002118f1][002118f5] 55 push ebp
...[00000d03][002118f1][002118f5] 8bec mov ebp,esp
...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
...[00000d08][002118ed][00000d02] 50 push eax // push P
...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
...[00000d0c][002118e9][00000d02] 51 push ecx // push P
...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H
...[00000d02][0025c319][0025c31d] 55 push ebp
...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
...[00000d08][0025c315][00000d02] 50 push eax // push P
...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
...[00000d0c][0025c311][00000d02] 51 push ecx // push P
...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The fact that the execution trace of the simulation of P(P) on page 6
perfectly matches its source-code on page 5 conclusively proves that
this execution trace performed by H is a pure simulation of P(P). There
is no correct basis for disagreement, therefore anyone disagreeing
either does not know the x86 language or they are simply lying.
Normally a simulator creates a virtual machine with a virtual address space and virtual instructions. The execution trace of the simulator looks nothing like the execution trace of the simulated code - basically the simulator does a big switch on the op code of the virtual machine's instruction, then updates
memory and registers, with special rules for IO.
You don't seem to be using this model for H.
However iif P(P) halts, then any execution trace which shows it P(P) as non-halting
must have a mistake in it somewhere, either in the simulator or in the interpretation
of the trace.
On 2021-08-09 10:57, olcott wrote:
On 8/8/2021 1:50 PM, André G. Isaak wrote:
On 2021-08-06 22:23, olcott wrote:
On 8/6/2021 10:55 PM, André G. Isaak wrote:
On 2021-08-06 09:59, olcott wrote:
Yes, but bear in mind that 'halting' refers to Turing Machines
operating on a specific input. It does not refer to simulations or
what happens inside a halting decider. It refers *only* to actual
computations, i.e. an actual Turing Machine operating on an actual
input string.
So yet again you prove that you are totally clueless that pure
simulations are computationally equivalent to direct executions ?
Your H is not a pure simulator
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param >> [00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param >> [00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]
machine stack stack machine assembly
address address data code language >> ======== ======== ======== ========= =============
...[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H
Begin Local Halt Decider Simulation at Machine Address:d02
...[00000d02][002118f1][002118f5] 55 push ebp
...[00000d03][002118f1][002118f5] 8bec mov ebp,esp
...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
...[00000d08][002118ed][00000d02] 50 push eax // push P
...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
...[00000d0c][002118e9][00000d02] 51 push ecx // push P
...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H
...[00000d02][0025c319][0025c31d] 55 push ebp
...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
...[00000d08][0025c315][00000d02] 50 push eax // push P
...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
...[00000d0c][0025c311][00000d02] 51 push ecx // push P
...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The fact that the execution trace of the simulation of P(P) on page 6
perfectly matches its source-code on page 5 conclusively proves that
this execution trace performed by H is a pure simulation of P(P).
There is no correct basis for disagreement, therefore anyone
disagreeing either does not know the x86 language or they are simply
lying.
You have a *partial trace* and *partial source code*. Neither shows what happens at B82.
Your trace ends with the cryptic message "Local Halt Decider: Infinite Recursion Detected Simulation Stopped" which doesn't indicate *which* invocation of H aborted *which* simulation and to where control was transferred once that simulation was aborted.
Amdré
On 8/9/2021 12:30 PM, Malcolm McLean wrote:
On Monday, 9 August 2021 at 17:57:18 UTC+1, olcott wrote:
On 8/8/2021 1:50 PM, André G. Isaak wrote:It's unclear to me exactly how H is a "simulator", given this
On 2021-08-06 22:23, olcott wrote:// Simplified Linz Ĥ (Linz:1990:319)
On 8/6/2021 10:55 PM, André G. Isaak wrote:
On 2021-08-06 09:59, olcott wrote:
Yes, but bear in mind that 'halting' refers to Turing Machines
operating on a specific input. It does not refer to simulations or >>>>>> what happens inside a halting decider. It refers *only* to actual
computations, i.e. an actual Turing Machine operating on an actual >>>>>> input string.
So yet again you prove that you are totally clueless that pure
simulations are computationally equivalent to direct executions ?
Your H is not a pure simulator
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param
[00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param
[00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H
Begin Local Halt Decider Simulation at Machine Address:d02
...[00000d02][002118f1][002118f5] 55 push ebp
...[00000d03][002118f1][002118f5] 8bec mov ebp,esp
...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
...[00000d08][002118ed][00000d02] 50 push eax // push P
...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
...[00000d0c][002118e9][00000d02] 51 push ecx // push P
...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H
...[00000d02][0025c319][0025c31d] 55 push ebp
...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
...[00000d08][0025c315][00000d02] 50 push eax // push P
...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
...[00000d0c][0025c311][00000d02] 51 push ecx // push P
...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The fact that the execution trace of the simulation of P(P) on page 6
perfectly matches its source-code on page 5 conclusively proves that
this execution trace performed by H is a pure simulation of P(P). There
is no correct basis for disagreement, therefore anyone disagreeing
either does not know the x86 language or they are simply lying.
execution trace.
I don't see what could possibly be unclear about it to anyone knowing
the x86 language well enough. The trace shows exactly what P would do if
it was simulated by a pure simulator with itself as input.
Normally a simulator creates a virtual machine with a virtual address
space
and virtual instructions. The execution trace of the simulator looks
nothing
like the execution trace of the simulated code - basically the
simulator does
a big switch on the op code of the virtual machine's instruction, then
updates
memory and registers, with special rules for IO.
Those details only serve to get people confused. The fact that the x86
code of P acts exactly as if it was simulated by a pure simulator proves beyond all possible doubt that H does simulate P on input P as a pure simulator.
You don't seem to be using this model for H.
However iif P(P) halts, then any execution trace which shows it P(P)
as non-halting
must have a mistake in it somewhere, either in the simulator or in the
interpretation
of the trace.
On 2021-08-09 15:12, olcott wrote:
On 8/9/2021 2:38 PM, André G. Isaak wrote:
On 2021-08-09 10:57, olcott wrote:
On 8/8/2021 1:50 PM, André G. Isaak wrote:
On 2021-08-06 22:23, olcott wrote:
On 8/6/2021 10:55 PM, André G. Isaak wrote:
On 2021-08-06 09:59, olcott wrote:
Yes, but bear in mind that 'halting' refers to Turing Machines
operating on a specific input. It does not refer to simulations
or what happens inside a halting decider. It refers *only* to
actual computations, i.e. an actual Turing Machine operating on
an actual input string.
So yet again you prove that you are totally clueless that pure
simulations are computationally equivalent to direct executions ?
Your H is not a pure simulator
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param
[00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param
[00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]
machine stack stack machine assembly >>>> address address data code language
======== ======== ======== ========= =============
...[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H >>>>
Begin Local Halt Decider Simulation at Machine Address:d02
...[00000d02][002118f1][002118f5] 55 push ebp
...[00000d03][002118f1][002118f5] 8bec mov ebp,esp
...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
...[00000d08][002118ed][00000d02] 50 push eax // push P
...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
...[00000d0c][002118e9][00000d02] 51 push ecx // push P
...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H >>>> ...[00000d02][0025c319][0025c31d] 55 push ebp
...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
...[00000d08][0025c315][00000d02] 50 push eax // push P
...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
...[00000d0c][0025c311][00000d02] 51 push ecx // push P
...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H >>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The fact that the execution trace of the simulation of P(P) on page
6 perfectly matches its source-code on page 5 conclusively proves
that this execution trace performed by H is a pure simulation of
P(P). There is no correct basis for disagreement, therefore anyone
disagreeing either does not know the x86 language or they are simply
lying.
You have a *partial trace* and *partial source code*. Neither shows
what happens at B82.
if int add(int x, int y) returns 5 on add(2,3) we know for sure that
add was correct on that input.
That is a poor analogy since 5 actually *is* the correct answer to 2+3.
We know that P(P) *does* halt, which means that if H(P, P) returns false
we know for sure that H was *incorrect* on that input.
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
It's unclear to me exactly how H is a "simulator", given this
execution trace. Normally a simulator creates a virtual machine with
a virtual address space and virtual instructions. The execution trace
of the simulator looks nothing like the execution trace of the
simulated code - basically the simulator does a big switch on the op
code of the virtual machine's instruction, then updates memory and
registers, with special rules for IO.
He makes the same mistake about TMs as well. Because the classic construction of H^ from H used in proofs like Linz's makes H^ duplicate
the input string (into a pair, if the that needs to be specially
encoded) and then "behave like H", he thinks that if H is a UTM the
resulting endless looping causes the input to be endlessly duplicated.
He's even started to give these copies names: <H^[1]> and <H^[2]> etc.
But this is because he's never studied, much less written, a UTM. The
UTM has to use the tape to encode the sate and the tape of the TM being simulated, and that means the neat fiction of endless copies of the
encoding of UTM^ (i.e. <UTM^>) does not occur. The execution is
endless, but the strings on the tape are way more complex than he
thinks. He reads Linz's notation in a sort of metaphorical way, whereas
it is intended to show exactly what's on the tape.
I've glossed over this as best I can because he loves people getting
bogged down in the details whereas he's been clear that his plan is
wrong for the simplest, high-level reasons.
You don't seem to be using this model for H.
Indeed. I've thought for some time that he has not been able invoke the
x86 emulator he's found inline as a nested instance. My guess is that
his H just calls its argument function and the "detection" of the
recursion (which is now, of course, a reality) occurs outside. He
probably just thinks that it /could/ be brought into H without making
any difference. Part of the evidence for this comes from his briefly
talking about the "OS as the halt decider".
The game would be up if he ever published H, hence the need to keep it secret.
On 2021-08-09 16:47, olcott wrote:
On 8/9/2021 5:43 PM, André G. Isaak wrote:
On 2021-08-09 16:21, olcott wrote:
On 8/9/2021 5:17 PM, André G. Isaak wrote:
On 2021-08-09 15:12, olcott wrote:
On 8/9/2021 2:38 PM, André G. Isaak wrote:
On 2021-08-09 10:57, olcott wrote:
On 8/8/2021 1:50 PM, André G. Isaak wrote:
On 2021-08-06 22:23, olcott wrote:
On 8/6/2021 10:55 PM, André G. Isaak wrote:Your H is not a pure simulator
On 2021-08-06 09:59, olcott wrote:
Yes, but bear in mind that 'halting' refers to Turing
Machines operating on a specific input. It does not refer to >>>>>>>>>>> simulations or what happens inside a halting decider. It >>>>>>>>>>> refers *only* to actual computations, i.e. an actual Turing >>>>>>>>>>> Machine operating on an actual input string.
So yet again you prove that you are totally clueless that pure >>>>>>>>>> simulations are computationally equivalent to direct executions ? >>>>>>>>>
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param
[00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param
[00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>> ...[00000d0d][00101829][00000d12] e870feffff call 00000b82 // >>>>>>>> call H
Begin Local Halt Decider Simulation at Machine Address:d02
...[00000d02][002118f1][002118f5] 55 push ebp >>>>>>>> ...[00000d03][002118f1][002118f5] 8bec mov ebp,esp >>>>>>>> ...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08] >>>>>>>> ...[00000d08][002118ed][00000d02] 50 push eax //
push P
...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08] >>>>>>>> ...[00000d0c][002118e9][00000d02] 51 push ecx //
push P
...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // >>>>>>>> call H
...[00000d02][0025c319][0025c31d] 55 push ebp >>>>>>>> ...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp >>>>>>>> ...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08] >>>>>>>> ...[00000d08][0025c315][00000d02] 50 push eax //
push P
...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08] >>>>>>>> ...[00000d0c][0025c311][00000d02] 51 push ecx //
push P
...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // >>>>>>>> call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>
The fact that the execution trace of the simulation of P(P) on >>>>>>>> page 6 perfectly matches its source-code on page 5 conclusively >>>>>>>> proves that this execution trace performed by H is a pure
simulation of P(P). There is no correct basis for disagreement, >>>>>>>> therefore anyone disagreeing either does not know the x86
language or they are simply lying.
You have a *partial trace* and *partial source code*. Neither
shows what happens at B82.
if int add(int x, int y) returns 5 on add(2,3) we know for sure
that add was correct on that input.
That is a poor analogy since 5 actually *is* the correct answer to
2+3.
We know that P(P) *does* halt, which means that if H(P, P) returns
false we know for sure that H was *incorrect* on that input.
P(P) only halts because H(P,P) correctly decides that its input
never halts and aborts this input on that basis.
X only halts because Y IMPLIES that X halts. That's basic logic.
The definition of halting does not refer at all to the *reason* why a
particular computation halts.
The P that halts seems to contradict that H(P,P)==0 is correct yet it
is verifiable that H(P,P)==0 is correct.
P(P) is either in the set of halting computations or it is not. It can't
be both.
Since halting is a property defined *solely* in terms of the behaviour
of the *actual* computation in question, we know that P(P) is in this
set. Therefore H(P, P) == 0 *cannot* be verifiably correct.
That you keep ignoring this means that you are dishonest.
I am not ignoring this. I am asserting that it is false.
To consider your earlier poor analogy:
"if int add(int x, int y) returns 5 on add(2,3) we know for sure that
add was correct on that input."
The above as stated leaves out a critical piece. if int add(int x, int
y) returns 5 on add(2,3) we know for sure that add was correct on that
input *because* we know independently that 5 is actually the correct
answer.
What you are claiming is more analogous to the claim that:
if int add(int x, int y) returns 9 on add(2,3) we know for sure that add
was correct on that input.
Which of course is rubbish if add(x, y) is purported to do what its name suggests.
André
"The airplane crashed "only" because it ran out of fuel" IMPLIES that
the airplane crashed.
"The man was arrested "only" because the police chief held a grudge"
IMPLIES that the man was arrested.
Why you think that 'halting' works differently from these examples
remains a mystery.
If you want to determine the correct answer to "does P(P) halt?", you
need look only at the behaviour of P(P), not at your traces. In fact,
you *shouldn't* look at anything other than the behaviour of P(P)
because halting is defined *entirely* in terms of the behaviour of P(P). >>>
If it is the case that P(P) "only" halts because H(P, P) returns
false, it still halts, which means that H(P, P) *incorrectly* returns
false.
Until you pay enough attention to see and acknowledge this I will
simply assume that you are dishonest.
As is the case with virtually all of your terms, I assume you also
have some private definition of 'dishonest'.
On 2021-08-10 09:07, olcott wrote:
On 8/9/2021 8:47 PM, André G. Isaak wrote:
On 2021-08-09 16:47, olcott wrote:
The P that halts seems to contradict that H(P,P)==0 is correct yet
it is verifiable that H(P,P)==0 is correct.
P(P) is either in the set of halting computations or it is not. It
can't be both.
Since halting is a property defined *solely* in terms of the
behaviour of the *actual* computation in question, we know that P(P)
is in this set. Therefore H(P, P) == 0 *cannot* be verifiably correct.
That you keep ignoring this means that you are dishonest.
I am not ignoring this. I am asserting that it is false.
_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param >> [00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param >> [00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]
machine stack stack machine assembly
address address data code language >> ======== ======== ======== ========= =============
...[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H
Begin Local Halt Decider Simulation at Machine Address:d02
...[00000d02][002118f1][002118f5] 55 push ebp
...[00000d03][002118f1][002118f5] 8bec mov ebp,esp
...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
...[00000d08][002118ed][00000d02] 50 push eax // push P
...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
...[00000d0c][002118e9][00000d02] 51 push ecx // push P
...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H
...[00000d02][0025c319][0025c31d] 55 push ebp
...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
...[00000d08][0025c315][00000d02] 50 push eax // push P
...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
...[00000d0c][0025c311][00000d02] 51 push ecx // push P
...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
We can see that the above is a pure simulation of P on input P.
It *isn't* a pure simulation since a pure simulation cannot abort its
input.
We can see that the above cannot possibly stop running unless H aborts
its simulation of P on input P.
Except you are aborting in the *wrong* place. That cannot be seen in the above trace since you don't actually *show* the code at B82, and your
message that the simulation was stopped doesn't tell us *which*
invocation of H aborted *which* simulation.
When P(P) is computed, it is the H contained in the outermost P which
aborts the simulation, and control is then returned to that H and then
to P which halts.
When you run H(P, P) it is the *outermost* H which aborts the simulation
of P *rather* than the H contained in the outermost P. This means your "simulation" is not an accurate one since it does something different
from when the computation is performed independently.
You keep stressing that a simulation is "equivalent" to the computation itself. That means your simulation must actually do *exactly* the same
thing as the actual computation which yours does not, which means your "simulation" cannot be used to demonstrate anything about the actual computation under consideration.
We can see that even if H does aborts its simulation of P on input P
that P never reaches its final state, thus never halts even though its
stops running.
Until you acknowledge these things or prove that the above P does
reach its final state you are simply a liar. Proving that a different
P reaches its final state is a dishonest dodge, thus also dishonest.
What do you mean by "a different P"? There is only one Turing Machine P
under consideration, and that Turing Machine clearly halts when given
its own representation as an input.
André
On Wednesday, 11 August 2021 at 00:08:50 UTC+1, olcott wrote:
On 8/9/2021 5:25 PM, Ben Bacarisse wrote:You need to be clear about what you mean by "infinite recursion". We
Malcolm McLean <malcolm.ar...@gmail.com> writes:It is the case that Ĥ on input ⟨Ĥ⟩ does specify infinite recursion to >> every simulating halt decider embedded in Ĥ.
It's unclear to me exactly how H is a "simulator", given this
execution trace. Normally a simulator creates a virtual machine with
a virtual address space and virtual instructions. The execution trace
of the simulator looks nothing like the execution trace of the
simulated code - basically the simulator does a big switch on the op
code of the virtual machine's instruction, then updates memory and
registers, with special rules for IO.
He makes the same mistake about TMs as well. Because the classic
construction of H^ from H used in proofs like Linz's makes H^ duplicate
the input string (into a pair, if the that needs to be specially
encoded) and then "behave like H", he thinks that if H is a UTM the
resulting endless looping causes the input to be endlessly duplicated.
He's even started to give these copies names: <H^[1]> and <H^[2]> etc.
But this is because he's never studied, much less written, a UTM. The
UTM has to use the tape to encode the sate and the tape of the TM being
simulated, and that means the neat fiction of endless copies of the
encoding of UTM^ (i.e. <UTM^>) does not occur. The execution is
endless, but the strings on the tape are way more complex than he
thinks. He reads Linz's notation in a sort of metaphorical way, whereas
it is intended to show exactly what's on the tape.
That you talk all around this using all kinds of rhetoric yet never use
any actual reasoning as a rebuttal would seem to prove that you are
dishonest.
all get the basic idea - H is a simulating halt decider, therefore H_Hat gets executed multiple times under various levels of H,.
But you are not working with Turing machines. Turing machines don't really have "recursion" because it is a structured programming concept, and Turing machines are too low-level for structured programming.
In C, you can call subroutines recursively, but then how is H a "simulating halt
decider"?. Or you can create a simulation context, and another simulation context within the simulation context, and so on, indefinitely. This is not what you appear to be doing.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 465 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 50:50:01 |
| Calls: | 9,401 |
| Calls today: | 1 |
| Files: | 13,572 |
| Messages: | 6,099,667 |