Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: olcott's correct refutation of the Peter Linz HP proof

11 views
Skip to first unread message

olcott

unread,
Dec 6, 2020, 11:23:55 AM12/6/20
to
On 12/6/2020 10:03 AM, Alan Mackenzie wrote:
> olcott <No...@nowhere.com> wrote:
>> On 12/6/2020 5:19 AM, Mr Flibble wrote:
>>> If EVERYONE is saying you are wrong then which is more likely?
>
>>> 1) You are not wrong.
>>> 2) You are wrong.
>
>>> /Flibble
>
>
>> Not everyone say that I am wrong, Kaz says that I am correct and no one
>> else bothers to carefully examine what I say.
>
> Lots of people have examined in great detail what you have said.
>
>> When people say that you are wrong and they do not back up their
>> assertion with reasoning the assertion that you are wrong is utterly
>> vacuous.
>
> The impossibility of a halt decider is a mathematical theorem. There is
> no need to back that up with further reasoning. It is true.

Find the actual mistake in my correct refutation of the Peter Linz proof
Knucklehead !!!

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf


Just in case your knowledge of software engineering is abysmal I will
give you this little hint whenever an execution trace includes a
function call to the same function from the same machine address without
any intervening conditional branch instructions in-between:

(trace lines 13-21 shown below) THIS IS INFINITE RECURSION !!!

Actual debug trace of H() deciding halting on H_Hat()


void H_Hat(u32 P)
{
u32 Input_Halts = H(P, P);
if (Input_Halts)
HERE: goto HERE;
else
HALT
}


int main()
{
H((u32)H_Hat, (u32)H_Hat);
HALT;
}


_H_Hat()
[000005e0](01) 55 push ebp
[000005e1](02) 8bec mov ebp,esp
[000005e3](01) 51 push ecx
[000005e4](03) 8b4508 mov eax,[ebp+08]
[000005e7](01) 50 push eax
[000005e8](03) 8b4d08 mov ecx,[ebp+08]
[000005eb](01) 51 push ecx
[000005ec](05) e87ffdffff call 00000370
[000005f1](03) 83c408 add esp,+08
[000005f4](03) 8945fc mov [ebp-04],eax
[000005f7](04) 837dfc00 cmp dword [ebp-04],+00
[000005fb](02) 7404 jz 00000601
[000005fd](02) ebfe jmp 000005fd
[000005ff](02) eb01 jmp 00000602
[00000601](01) f4 hlt
[00000602](02) 8be5 mov esp,ebp
[00000604](01) 5d pop ebp
[00000605](01) c3 ret

_main()
[00000610](01) 55 push ebp
[00000611](02) 8bec mov ebp,esp
[00000613](05) 68e0050000 push 000005e0
[00000618](05) 68e0050000 push 000005e0
[0000061d](05) e84efdffff call 00000370
[00000622](03) 83c408 add esp,+08
[00000625](01) f4 hlt
[00000626](01) 5d pop ebp
[00000627](01) c3 ret


Output_Debug_Trace() Trace_List.size(20)
[00000610](01) 55 push ebp
[00000611](02) 8bec mov ebp,esp
[00000613](05) 68e0050000 push 000005e0
[00000618](05) 68e0050000 push 000005e0
[0000061d](05) e84efdffff call 00000370
[000005e0](01) 55 push ebp
[000005e1](02) 8bec mov ebp,esp
[000005e3](01) 51 push ecx
[000005e4](03) 8b4508 mov eax,[ebp+08]
[000005e7](01) 50 push eax
[000005e8](03) 8b4d08 mov ecx,[ebp+08]
[000005eb](01) 51 push ecx
[000005ec](05) e87ffdffff call 00000370
[000005e0](01) 55 push ebp
[000005e1](02) 8bec mov ebp,esp
[000005e3](01) 51 push ecx
[000005e4](03) 8b4508 mov eax,[ebp+08]
[000005e7](01) 50 push eax
[000005e8](03) 8b4d08 mov ecx,[ebp+08]
[000005eb](01) 51 push ecx
[000005ec](05) e87ffdffff call 00000370
The PRIOR Instruction Specifies Infinite Recursion: Simulation Stopped:
Number of Instructions Executed(2777)


--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott

unread,
Dec 6, 2020, 11:50:25 AM12/6/20
to
On 12/6/2020 10:34 AM, Richard Damon wrote:
> On 12/6/20 11:23 AM, olcott wrote:
>>
>> Just in case your knowledge of software engineering is abysmal I will
>> give you this little hint whenever an execution trace includes a
>> function call to the same function from the same machine address without
>> any intervening conditional branch instructions in-between:
>
> Except that the abpve rule is a bit flawed, as it needs to include ALL
> forms of conditional execution, including an indirect jump or call, and

In this case there are zero control flow instructions in-between, thus
making this point entirely moot for the current computation.

> needs to include ALL instructions in the loop, not just 'User' instructions.
>
> There are gaps in your traces that hide those conditionals.
>

On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
> A computation that would not halt if its simulation were not
> halted is indeed a non-halting computation.

On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
> Every computation that would not halt if its simulation
> were not halted is by logical necessity a non-halting computation.

Because of the above (halt deciding) criterion measure conditionals that
are a part of the halt decider and not a part of the user code are
correctly excluded when determining the non-halting behavior of the user
code.

olcott

unread,
Dec 8, 2020, 3:09:25 PM12/8/20
to
On 12/6/2020 12:06 PM, Mostowski Collapse wrote:
>
> There are dozen and dozen University professors
> that need to teach something, do scaffold some
> script, maybe they even don't do it
>
> by themselves, more their assistants. Then
> maybe such a script becomes a book, carrying
> all the errors from the script into the
>
> book. What do you expect. That every book
> is error free? Then there is the problem
> that a moron like you interprets the script.
>
Both the Sipser proof and the Kozen proof succumb to my refutation of
Linz. Sipser's D is equivalent to the Peter Linz Ĥ.

u32 D(u32 P)
{
u32 Input_Halts = H(P, P);
if (Input_Halts)
return 0; // Indicating not halting
else
return 1; // Indicating halting
}

http://www.liarparadox.org/sipser_165.pdf

Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
PWS Publishing Company (165-167)


The Kozen computation is identical to the Peter Linz computation merely
swapping function names Linz.H is swapped for Kozen.K and Linz.Ĥ is
swapped for Kozen.N

http://www.liarparadox.org/kozen_233.pdf

Kozen, Dexter 1997. Automata and Computability. New York:
Springer-Verlag. (231-234).
0 new messages