Reviewers quit reviewing my work because it is now finally irrefutable [V2]

[olcott]

When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects that its correct and complete simulation
of its input would never reach the final state of this input then all
[these] inputs (including pathological inputs) are decided correctly.

*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

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

#include <stdint.h>
typedef void (*ptr)();

void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[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]

(1) It is an easily verified fact that when we assume that H is only an
x86 emulator that the correctly emulated P never reaches its "ret"
instruction it remains stuck in repeated cycles of emulation.

(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report this.

(3) When the halt status criteria is defined as correctly determining
whether or not an x86 emulated input would ever reach its "ret"
instruction then it becomes an easily verified fact H(P,P) could
correctly reject its input as non-halting.

Correct deductive inference proves that all of these things are true
without any need what-so-ever to see either the source-code or the
execution trace of H.

The one thing that is not proved is whether or not an actual encoded
H(P,P) does indeed correctly determine that its input would never reach
its "ret" instruction as a pure function of its inputs. This aspect will
be confirmed by fully operational source-code.



Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5


--
Copyright 2022 Pete Olcott

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

[Richard Damon]

Summary of your error:

At the same time you have assumes that H is a function that only
correctly and completely emulates its input and also that it aborts its
emulation (and thus not be complete) and return the answer.

That is an impossible program, and renders your logic totally invalid.

It is like assuming that the night was so dark you couldn't see the hand
in front of your face, but you could also, at exactly the same time, be
seen from a mile ways because things were so clear and light.

You are just embarassing yourself, you just seem to be too dumb to
notice it.

[Mr Flibble]

You can keep repeating yourself as many times as you like but that
won't make you correct:

(1) you assert H is a pure function so it must ALWAYS return the
SAME RESULT for the SAME ARGUMENTS with NO SIDE EFFECTS (aborting a
simulation is a side effect);
(2) you assert H(P,P) == 0;
(3) given (1) and (2) P must halt as H should return 0 to P's
invocation of H but it doesn't because it is either a different H or an
erroneous H;
(4) given (1), (2) and (3) H is not a halt decider; it is an incredibly
useless olcott simulation detector.

/Flibble

[olcott]

On 6/17/2022 8:39 AM, wij wrote:

> GUR already suggested such a halting decider H cannot exist:
>
> H(P,P)==0 means P(P) does not halt.

That is a misconception.

Halt deciders must compute the mapping from their inputs to an accept or
reject state on the basis of the actual behavior actually specified by
these inputs.

It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H would never reach its "ret"
instruction thus conclusively proving that it never halts.


> H(P,P)==1 means P(P) halts.
> H(P,P)==Otherwise means H fails as a decider (undecidable).
>
> -----
> Thanks to PO's years' tireless efforts demonstrated even himself a genius in 10000-years
> cannot refute my GUR. ...

[olcott]

On 6/17/2022 9:11 AM, Mr Flibble wrote:
> On Fri, 17 Jun 2022 06:29:29 -0500
> olcott <No...@NoWhere.com> wrote:
>

THIS IS IRREFUTABLE BECAUSE IT IS A TAUTOLOGY:

H recognizes that P is calling itself with its same arguments that it
was called with and there are no instructions preceding this call that
could possibly escape infinitely recursive emulation so H aborts its
emulation of P before P even makes its first call to H.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[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]

> (2) you assert H(P,P) == 0;
> (3) given (1) and (2) P must halt as H should return 0 to P's
> invocation of H but it doesn't because it is either a different H or an
> erroneous H;
> (4) given (1), (2) and (3) H is not a halt decider; it is an incredibly
> useless olcott simulation detector.
>
> /Flibble
>

[Mr Flibble]

On Fri, 17 Jun 2022 09:33:32 -0500
olcott <No...@NoWhere.com> wrote:

> On 6/17/2022 9:11 AM, Mr Flibble wrote:
> > On Fri, 17 Jun 2022 06:29:29 -0500
> > olcott <No...@NoWhere.com> wrote:
> >
>
> THIS IS IRREFUTABLE BECAUSE IT IS A TAUTOLOGY:
> When a simulating halt decider rejects all inputs as non-halting
> whenever it correctly detects that its correct and complete
> simulation of its input would never reach the final state of this
> input then all [these] inputs (including pathological inputs) are
> decided correctly.

There is no such thing as a simulating halt decider and your failed
attempts at proving the contrary just confirms what. Why? Because if P
is NOT pathological and never halts then nor would a simulation of P
hence the decider would never return an answer of non-halting so is
in fact not a halt decider. The fact that your decider can detect an
infinite loop as represented as the x86 opcodes "EB FE" is not proof
that your decider can detect all forms of non-halting.

Then H isn't a pure function for the computer science definition of a
pure function as pure functions can't have side effects and aborting
the simulation is a side effect.

/Flibble

[olcott]

On 6/17/2022 9:39 AM, wij wrote:

> GUR suggests no halting decider can exist. You just confirms it by not able to
> provide POOH to test/review.

It took me six months to figure out how to transform H(P,P) into a pure
function of its inputs. I did not release the code before because I knew
that its use of static local data would have been rejected. With this
update to H I will be able to publish the code.

H recognizes that P is calling itself with its same arguments that it
was called with and there are no instructions preceding this call that
could possibly escape infinitely recursive emulation so H aborts its
emulation of P before P even makes its first call to H.

Without even looking at the code competent software engineers will be
able to verify that the above H would correctly determine that that is
input is non-halting as a pure function of this input.

[Mr Flibble]

So my other reply for why your H is not a pure function for any
accepted definition of the term.

/Flibble

[olcott]

On 6/17/2022 9:43 AM, Mr Flibble wrote:
> On Fri, 17 Jun 2022 09:33:32 -0500
> olcott <No...@NoWhere.com> wrote:
>
>> On 6/17/2022 9:11 AM, Mr Flibble wrote:
>>> On Fri, 17 Jun 2022 06:29:29 -0500
>>> olcott <No...@NoWhere.com> wrote:
>>>
>>
>> THIS IS IRREFUTABLE BECAUSE IT IS A TAUTOLOGY:
>> When a simulating halt decider rejects all inputs as non-halting
>> whenever it correctly detects that its correct and complete
>> simulation of its input would never reach the final state of this
>> input then all [these] inputs (including pathological inputs) are
>> decided correctly.
>
> There is no such thing as a simulating halt decider and your failed
> attempts at proving the contrary just confirms what. Why? Because if P
> is NOT pathological and never halts then nor would a simulation of P
> hence the decider would never return an answer of non-halting so is
> in fact not a halt decider. The fact that your decider can detect an
> infinite loop as represented as the x86 opcodes "EB FE" is not proof
> that your decider can detect all forms of non-halting.

I have to repeat things to you too many times. This may get you blocked.

Refuting the halting problem proofs only requires a halt decider that
correctly decides a single input it can be totally wrong on every other
input.

[Mr Flibble]

On Fri, 17 Jun 2022 10:29:06 -0500

olcott <No...@NoWhere.com> wrote:

> On 6/17/2022 9:43 AM, Mr Flibble wrote:
> > On Fri, 17 Jun 2022 09:33:32 -0500
> > olcott <No...@NoWhere.com> wrote:
> >
> >> On 6/17/2022 9:11 AM, Mr Flibble wrote:
> >>> On Fri, 17 Jun 2022 06:29:29 -0500
> >>> olcott <No...@NoWhere.com> wrote:
> >>>
> >>
> >> THIS IS IRREFUTABLE BECAUSE IT IS A TAUTOLOGY:
> >> When a simulating halt decider rejects all inputs as non-halting
> >> whenever it correctly detects that its correct and complete
> >> simulation of its input would never reach the final state of this
> >> input then all [these] inputs (including pathological inputs) are
> >> decided correctly.
> >
> > There is no such thing as a simulating halt decider and your failed
> > attempts at proving the contrary just confirms what. Why? Because
> > if P is NOT pathological and never halts then nor would a
> > simulation of P hence the decider would never return an answer of
> > non-halting so is in fact not a halt decider. The fact that your
> > decider can detect an infinite loop as represented as the x86
> > opcodes "EB FE" is not proof that your decider can detect all forms
> > of non-halting.
>
> I have to repeat things to you too many times. This may get you
> blocked.

Block away: I will still refute your mess.

>
> Refuting the halting problem proofs only requires a halt decider that
> correctly decides a single input it can be totally wrong on every
> other input.

Nonsense.

I see you conveniently ignored my point about your H not being a pure
function: I think that is the real reason you want to block me as you
realize I am correct and you have fucked up, badly.

/Flibble

[olcott]

In computer programming, a pure function is a function that has the
following properties:

(1) the function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams), and

(2) the function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).

Thus a pure function is a computational analogue of a mathematical
function. https://en.wikipedia.org/wiki/Pure_function

The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams

[Mr Flibble]

On Fri, 17 Jun 2022 10:33:59 -0500

Aborting the simulation is a side effect; pure functions do not have
side effects.

/Flibble

[olcott]

On 6/17/2022 10:06 AM, wij wrote:

> What you say is irrelevant.
> Reviewers investigate the 'H', an algorithm that a computer can execute,
> not Peter Olcltt's Oral Halting decider.
>

H knows its own machine address and on this basis

H recognizes that P is calling itself with its same arguments that it
was called with and there are no instructions preceding this call that
could possibly escape infinitely recursive emulation so H aborts its
emulation of P before P even makes its first call to H.

Every competent software engineer can verify that H(P,P)==0 as a pure
function of its inputs according the the above algorithm.

> The irrefutable fact is clear: GUR cannot be violated, you don't have a
> real POOH for test/review.

[olcott]

You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)

[Mr Flibble]

On Fri, 17 Jun 2022 10:49:08 -0500

Not at all, but you do seem to have that problem.

Again:

[olcott]

Whether or not it is construed as a side-effect does not matter it must
be a mutation side-effect to (a)(b)(c)(d) or it does not count.

> /Flibble

[Mr Flibble]

On Fri, 17 Jun 2022 11:12:31 -0500

It doesn't count according to who? You? You have shown yourself to be
lacking in areas of computer science and software engineering.

Again:

Aborting the simulation is a side effect; pure functions do not have
side effects.

/Flibble

[olcott]

The above definition of pure functions.

[Mr Flibble]

On Fri, 17 Jun 2022 11:16:15 -0500

"In computer science, an operation, function or expression is said to
have a side effect if it modifies some state variable value(s) outside
its local environment, which is to say if it has any observable effect
other than its primary effect of returning a value to the invoker of
the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)

"any observable effect"

Aborting the simulation instead of returning a value to the invoker
disqualifies it from being a pure function.

/Flibble

[olcott]

The second part is an inaccurate paraphrase of the first part.

> which is to say if it has any observable effect
> other than its primary effect of returning a value to the invoker of
> the operation." --
> https://en.wikipedia.org/wiki/Side_effect_(computer_science)
>
> "any observable effect"
>
> Aborting the simulation instead of returning a value to the invoker
> disqualifies it from being a pure function.
>
> /Flibble
>

void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[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]

H aborts its x86 emulation of P as soon P reaches its machine address of
[0000135d] the very first time before the code at this address is
emulated. Then H returns 0 to its caller: main().

[Mr Flibble]

On Fri, 17 Jun 2022 11:33:22 -0500

Returning to main() is not returning to its invoker, P.

Again:

Aborting the simulation is a side effect; pure functions do not have
side effects.

/Flibble

[olcott]

Do you have ADD?

int main()
{
Output("Input_Halts = ", H(P, P));
}

[Mr Flibble]

On Fri, 17 Jun 2022 11:38:29 -0500

I might be on the spectrum; probably got Asperger's; whilst as far as
the topic under discussion is concerned, you've got nothing.

/Flibble

[Mr Flibble]

On Fri, 17 Jun 2022 11:38:29 -0500

If your claim is that H is only called once and the second time an
*attempt* to call H is prevented than that is equivalent to calling H
and having H do something different with side effects. This is just my
opinion though as it requires more thought and I am currently getting
drunk on gin and tonics.

/Flibble

[olcott]

Then that may explain why you didn't notice that main calls H(P,P);
When H returns to its caller it must return to main().

main() and not P is the invoker of H(P,P).

[olcott]

It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same arguments and

(b) there are no instructions preceding this call that could possibly
escape the infinite recursion / infinitely recursive emulation.

[Mr Flibble]

On Fri, 17 Jun 2022 11:59:53 -0500

Agree but refusing to analyse what P would have done if H wasn't a
simulating decider still makes what you've got worthless as far as the
Halting Problem is concerned.

/Flibble (getting drunk, possibly not quite at Ballmer's Peak)

[olcott]

It is dead obvious to everyone (even Richard) that what P would have
done if H was merely an x86 emulator and not a halt deciding emulator.

The correct and complete x86 emulation of H(P,P) would never reach its
"ret" instruction thus making H a correct "not reach ret" / halt decider
for P.

[Mr Flibble]

On Fri, 17 Jun 2022 12:13:13 -0500

You need to think about a P that calls H but is non-pathological halting
(no infinite loop).

/Flibble

[Mr Flibble]

Your assumption that any program that calls H is also pathological is
a flawed one. I have said before that all you have is a simulation
detector and not a halt decider: simulating halt deciders cannot
decide non-pathological non-halting programs in finite time so are not
actually deciders.

/Flibble

[Mr Flibble]

On Fri, 17 Jun 2022 19:04:51 +0100

The question then becomes is a simulation detector (rather than a halt
decider) sufficient to refute proofs based on the [Strachey 1965]
impossible program? I cannot answer that question as I am unfamiliar
with the proofs.

/Flibble

[olcott]

I have already done that and posted all of the details here about three
dozen times.

void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{

Output("Input_Halts = ", H1(P, P));
}

It remains true that the correct and complete x86 emulation of the input
to H(P,P) by H never reaches its "ret" instruction thus never halts.

[olcott]

I never said anything like that.

> a flawed one. I have said before that all you have is a simulation
> detector and not a halt decider: simulating halt deciders cannot
> decide non-pathological non-halting programs in finite time so are not
> actually deciders.
>
> /Flibble
>

I already proved that they do many dozen of times.
The reason that I stopped talking to Richard is that he could not
remember from one post to the next what I said in the preceding post.

[Mr Flibble]

On Fri, 17 Jun 2022 13:42:05 -0500

Try reading what I actually wrote:

void P(ptr x)
{
H(x, x); // ignore result
return; // halt
}

How does your "decider" handle that P?

/Flibble

[olcott]

[Strachey 1965] is merely P that takes no arguments and H that takes one
argument.

void P0()
{
if (H0((u32)P0))

HERE: goto HERE;
return;
}

int main()
{

Output("Input_Halts = ", H0((u32)P0));
}

_P0()
[00001396](01) 55 push ebp
[00001397](02) 8bec mov ebp,esp
[00001399](05) 6896130000 push 00001396
[0000139e](05) e813fdffff call 000010b6
[000013a3](03) 83c404 add esp,+04
[000013a6](02) 85c0 test eax,eax
[000013a8](02) 7402 jz 000013ac
[000013aa](02) ebfe jmp 000013aa
[000013ac](01) 5d pop ebp
[000013ad](01) c3 ret
Size in bytes:(0024) [000013ad]

_main()
[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp
[000013b9](05) 6896130000 push 00001396
[000013be](05) e8f3fcffff call 000010b6
[000013c3](03) 83c404 add esp,+04
[000013c6](01) 50 push eax
[000013c7](05) 6827040000 push 00000427
[000013cc](05) e8a5f0ffff call 00000476
[000013d1](03) 83c408 add esp,+08
[000013d4](02) 33c0 xor eax,eax
[000013d6](01) 5d pop ebp
[000013d7](01) c3 ret
Size in bytes:(0034) [000013d7]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000013b6][0010230c][00000000] 55 push ebp
...[000013b7][0010230c][00000000] 8bec mov ebp,esp
...[000013b9][00102308][00001396] 6896130000 push 00001396
...[000013be][00102304][000013c3] e8f3fcffff call 000010b6

Begin Local Halt Decider Simulation Execution Trace Stored at:2123c0
...[00001396][002123b0][002123b4] 55 push ebp
...[00001397][002123b0][002123b4] 8bec mov ebp,esp
...[00001399][002123ac][00001396] 6896130000 push 00001396
...[0000139e][002123a8][000013a3] e813fdffff call 000010b6
...[00001396][0025cdd8][0025cddc] 55 push ebp
...[00001397][0025cdd8][0025cddc] 8bec mov ebp,esp
...[00001399][0025cdd4][00001396] 6896130000 push 00001396
...[0000139e][0025cdd0][000013a3] e813fdffff call 000010b6
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

...[000013c3][0010230c][00000000] 83c404 add esp,+04
...[000013c6][00102308][00000000] 50 push eax
...[000013c7][00102304][00000427] 6827040000 push 00000427
---[000013cc][00102304][00000427] e8a5f0ffff call 00000476
Input_Halts = 0
...[000013d1][0010230c][00000000] 83c408 add esp,+08
...[000013d4][0010230c][00000000] 33c0 xor eax,eax
...[000013d6][00102310][00100000] 5d pop ebp
...[000013d7][00102314][00000004] c3 ret
Number of Instructions Executed(11031)

[olcott]

Removing the infinite loop does not make it non pathological.
As I have said donzens of times the infinite loop is unreachable.

void Px(u32 x)
{
H(x, x);
return;
}


int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}

_Px()

[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp

[000013b9](03) 8b4508 mov eax,[ebp+08]
[000013bc](01) 50 push eax
[000013bd](03) 8b4d08 mov ecx,[ebp+08]
[000013c0](01) 51 push ecx
[000013c1](05) e8e0fdffff call 000011a6
[000013c6](03) 83c408 add esp,+08
[000013c9](01) 5d pop ebp
[000013ca](01) c3 ret
Size in bytes:(0021) [000013ca]

_main()
[000013d6](01) 55 push ebp
[000013d7](02) 8bec mov ebp,esp
[000013d9](05) 68b6130000 push 000013b6
[000013de](05) 68b6130000 push 000013b6
[000013e3](05) e8befdffff call 000011a6
[000013e8](03) 83c408 add esp,+08
[000013eb](01) 50 push eax
[000013ec](05) 6827040000 push 00000427
[000013f1](05) e880f0ffff call 00000476
[000013f6](03) 83c408 add esp,+08
[000013f9](02) 33c0 xor eax,eax
[000013fb](01) 5d pop ebp
[000013fc](01) c3 ret
Size in bytes:(0039) [000013fc]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============

...[000013d6][00102357][00000000] 55 push ebp
...[000013d7][00102357][00000000] 8bec mov ebp,esp
...[000013d9][00102353][000013b6] 68b6130000 push 000013b6
...[000013de][0010234f][000013b6] 68b6130000 push 000013b6
...[000013e3][0010234b][000013e8] e8befdffff call 000011a6

Begin Local Halt Decider Simulation Execution Trace Stored at:21240b
...[000013b6][002123f7][002123fb] 55 push ebp
...[000013b7][002123f7][002123fb] 8bec mov ebp,esp
...[000013b9][002123f7][002123fb] 8b4508 mov eax,[ebp+08]
...[000013bc][002123f3][000013b6] 50 push eax
...[000013bd][002123f3][000013b6] 8b4d08 mov ecx,[ebp+08]
...[000013c0][002123ef][000013b6] 51 push ecx
...[000013c1][002123eb][000013c6] e8e0fdffff call 000011a6
...[000013b6][0025ce1f][0025ce23] 55 push ebp
...[000013b7][0025ce1f][0025ce23] 8bec mov ebp,esp
...[000013b9][0025ce1f][0025ce23] 8b4508 mov eax,[ebp+08]
...[000013bc][0025ce1b][000013b6] 50 push eax
...[000013bd][0025ce1b][000013b6] 8b4d08 mov ecx,[ebp+08]
...[000013c0][0025ce17][000013b6] 51 push ecx
...[000013c1][0025ce13][000013c6] e8e0fdffff call 000011a6

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)

[Mr Flibble]

On Fri, 17 Jun 2022 14:15:04 -0500

So it gets the answer wrong. QED.

/Flibble

[olcott]

comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:

This is the culmination of the essence of more than five years worth of
full time work when I first discovered that a simulating halt decider
could correctly determine the halt status of the "impossible" input:

When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects that its correct and complete simulation

of its input would never reach the final state of this input that all

[these] inputs (including pathological inputs) are decided correctly.

[Mr Flibble]

On Fri, 17 Jun 2022 14:34:12 -0500

It gets the answer wrong. QED.

/Flibble

[olcott]

It takes an actual competent software engineer to understand that the
complete and correct x86 emulation of the input to H(Px, Px) would never
reach is "ret" instruction.

[Mr Flibble]

On Fri, 17 Jun 2022 14:42:45 -0500

It gets the answer wrong, i.e. input has not been decided correctly.
QED.

/Flibble

[olcott]

In other words when I told you that the actual issued is infinitely
recursive emulation 150 times you made sure to always ignore everything
that I said.

[Mr Flibble]

On Fri, 17 Jun 2022 14:56:08 -0500

Px will always halt with a non-simulating "decider"; your "simulating
decider" behaves differently, getting the answer wrong. QED.

/Flibble

[olcott]

It is proving to be a waste of time to continue talking to you.

Now that I finally can prove my point in a single sentence I can finally
prove it quickly enough that it will not always be rejected out-of-hand
without review.

When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects that its correct and complete simulation
of its input would never reach the final state of this input that all
[these] inputs (including pathological inputs) are decided correctly.

*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

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

[Richard Damon]

What was the first instruction where it differed? Since the DEFINITION
is they are the same, you need to show some real proof that they differ.

Note, your "hand-waving" about assuming what H does is just incorrect
and NOT an actual emulation of the input, and shows that you are just lying.

[Richard Damon]

On 6/17/22 10:51 AM, olcott wrote:
> On 6/17/2022 9:39 AM, wij wrote:

>>>> H(P,P)==1 means P(P) halts.
>>>> H(P,P)==Otherwise means H fails as a decider (undecidable).
>>>>
>>>> -----
>>>> Thanks to PO's years' tireless efforts demonstrated even himself a
>>>> genius in 10000-years
>>>> cannot refute my GUR. ...

>>> --
>>> Copyright 2022 Pete Olcott
>>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>> Arthur Schopenhauer
>>

>> GUR suggests no halting decider can exist. You just confirms it by not
>> able to
>> provide POOH to test/review.
>
> It took me six months to figure out how to transform H(P,P) into a pure
> function of its inputs. I did not release the code before because I knew
> that its use of static local data would have been rejected. With this
> update to H I will be able to publish the code.
>
> H recognizes that P is calling itself with its same arguments that it
> was called with and there are no instructions preceding this call that
> could possibly escape infinitely recursive emulation so H aborts its
> emulation of P before P even makes its first call to H.
>
> Without even looking at the code competent software engineers will be
> able to verify that the above H would correctly determine that that is

> input is non-halting as a pure function of this input.
>
>

[Richard Damon]

But P calling H(P,P) is NOT a "proof" of non-halting, as since H(P,P)
has been shown to return 0 elsewhere, so must this until you can
actually prove that a "pure function" doesn't need to always behave the
same way for each call, dispite that being part of the definition of a
Pure Function.

You just fail.

[Richard Damon]

On 6/17/22 11:33 AM, olcott wrote:
> On 6/17/2022 9:56 AM, Mr Flibble wrote:
>> On Fri, 17 Jun 2022 09:51:07 -0500

>> So my other reply for why your H is not a pure function for any
>> accepted definition of the term.
>>
>> /Flibble
>>
>
> In computer programming, a pure function is a function that has the
> following properties:
>
> (1) the function return values are identical for identical arguments (no
> variation with local static variables, non-local variables, mutable
> reference arguments or input streams), and
>
> (2) the function application has no side effects (no mutation of local
> static variables, non-local variables, mutable reference arguments or
> input/output streams).
>
> Thus a pure function is a computational analogue of a mathematical
> function. https://en.wikipedia.org/wiki/Pure_function
>
> The revised H has no:
> (a) local static variables
> (b) non-local variables
> (c) mutable reference arguments
> (d) input streams
>
>

So the H(P,P) called by P(P needs to return 0 in finite time, and NOT
cause an infinite recursion just like the call to H(P,P) by main (and
thus H(P,P) retuning 0 is wrong, as the input halts), or

The H(P,P) called by main gets stuck in the same infinite loop that the
H(P,P) called by P(P) does.

You can't get different behaviors and be able to claim that H is a pure
function and that it correctly emulates its inputs.

You are claiming that x is 1 and x is 0 at the same time. Impossible.

[Richard Damon]

On 6/17/22 11:49 AM, olcott wrote:
> On 6/17/2022 10:37 AM, Mr Flibble wrote:
>> On Fri, 17 Jun 2022 10:33:59 -0500

>> Aborting the simulation is a side effect; pure functions do not have
>> side effects.
>>
>> /Flibble
>
> You have a reading comprehension problem.
> If H does not have (a)(b)(c)(d) then
> H has no mutation side effect to (a)(b)(c)(d)
>
>

But since H(P,P) is having different behaviors at two different call
sites, that shows that HY is not a pure function (or maybe that it isn't
a correct emulator).

Since you haven't actually shown the code for H (and every thing it
calls) you haven't actually established that it is a pure function.

Since it isn't behaving like one, it seems clear it isn't one, and that
you are just lying (maybe because you just don't know enough to see if H
actually is a pure function).

[Richard Damon]

On 6/17/22 12:33 PM, olcott wrote:
> On 6/17/2022 11:22 AM, Mr Flibble wrote:
>> On Fri, 17 Jun 2022 11:16:15 -0500
>> olcott <No...@NoWhere.com> wrote:
>>
>>> On 6/17/2022 11:14 AM, Mr Flibble wrote:
>>>> On Fri, 17 Jun 2022 11:12:31 -0500
>>>> olcott <No...@NoWhere.com> wrote:
>>>>> On 6/17/2022 10:56 AM, Mr Flibble wrote:
>>>>>> On Fri, 17 Jun 2022 10:49:08 -0500

>>>>>> Not at all, but you do seem to have that problem.
>>>>>>
>>>>>> Again:
>>>>>>

>>>>>> Aborting the simulation is a side effect; pure functions do not
>>>>>> have side effects.
>>>>>

>>>>> Whether or not it is construed as a side-effect does not matter it
>>>>> must be a mutation side-effect to (a)(b)(c)(d) or it does not
>>>>> count.
>>>>
>>>> It doesn't count according to who?
>>>
>>> The above definition of pure functions.
>>
>> "In computer science, an operation, function or expression is said to
>> have a side effect if it modifies some state variable value(s) outside
>> its local environment,
>
> The second part is an inaccurate paraphrase of the first part.
>
>> which is to say if it has any observable effect
>> other than its primary effect of returning a value to the invoker of
>> the operation." --
>> https://en.wikipedia.org/wiki/Side_effect_(computer_science)
>>
>> "any observable effect"
>>
>> Aborting the simulation instead of returning a value to the invoker
>> disqualifies it from being a pure function.
>>
>> /Flibble
>>
>

> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [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

> ize in bytes:(0027) [0000136c]
>
> H aborts its x86 emulation of P as soon P reaches its machine address of
> [0000135d] the very first time before the code at this address is
> emulated. Then H returns 0 to its caller: main().
>
>

Or to P when called by P when we test the results. Showing H was wrong.

Remember, since H aborted its emulation, we need to do an actual pure
emulation of the input to H(P,P) to see what the actual answer is.

That emulation will emulate through H, see H abort its emulation and
return 0 to P and P return (i.e. Halt), thus showing that H was incorrect.

All you are showing is you don't understand the requrements that you state.

[Richard Damon]

On 6/17/22 12:51 PM, olcott wrote:
> On 6/17/2022 11:41 AM, Mr Flibble wrote:
>> On Fri, 17 Jun 2022 11:38:29 -0500
>> olcott <No...@NoWhere.com> wrote:
>>
>>> On 6/17/2022 11:36 AM, Mr Flibble wrote:
>>>> On Fri, 17 Jun 2022 11:33:22 -0500

>>>>> H aborts its x86 emulation of P as soon P reaches its machine
>>>>> address of [0000135d] the very first time before the code at this
>>>>> address is emulated. Then H returns 0 to its caller: main().
>>>>

>>>> Returning to main() is not returning to its invoker, P.
>>>>

>>>> Again:
>>>>
>>>> Aborting the simulation is a side effect; pure functions do not have
>>>> side effects.
>>>>

>>>> /Flibble
>>>
>>> Do you have ADD?
>>>

>>> int main()
>>> {
>>>      Output("Input_Halts = ", H(P, P));
>>> }

>> I might be on the spectrum; probably got Asperger's; whilst as far as
>> the topic under discussion is concerned, you've got nothing.
>>
>> /Flibble
>>
>
> Then that may explain why you didn't notice that main calls H(P,P);
> When H returns to its caller it must return to main().
>
> main() and not P is the invoker of H(P,P).
>
>
>

But if H is a pure function, it returns the same answer to ALL envokers,
and thus when we test H's answer by looking at the correct emulation of
its input, we see that H(P,P) returns 0 to P(P) letting P(P) halt.

[Richard Damon]

On 6/17/22 12:59 PM, olcott wrote:

>> If your claim is that H is only called once and the second time an
>> *attempt* to call H is prevented than that is equivalent to calling H
>> and having H do something different with side effects. This is just my
>> opinion though as it requires more thought and I am currently getting
>> drunk on gin and tonics.
>>
>> /Flibble
>>
>
> It is obviously the exact same pattern as infinite recursion
> (a) calling the same function a second time with the same arguments and
>
> (b) there are no instructions preceding this call that could possibly
> escape the infinite recursion / infinitely recursive emulation.
>

Nope, shows you don't understand the difference between a direct call
and a conditional emulation done by a halt decider.

Doesn't matter that there are no instruction before the call, there are
after the call inside the H that is part of the algorithm of P, and that
counts

Maybe you don't understand that fact of programs / algorithmic
functions. The "function" P as far as behavior is concerned include all
the code that it calls, just like for H to be a "pure function" all the
funcitions that H calls also need to be pure functions.

[Richard Damon]

Right, but H ISN'T just a pure emulator, so what the pure emulator would
have done doesn't matter.

Just like the fact your cat would bark if it was a dog doesn't matter if
we ask if your actual cat barks.

You are confusing two distinct things because of your confusing
notations. It almost seems deliberate.

[Richard Damon]

So why can H validly conclude that P() doesn't halt when it calls H(P)
when we know that H(P) returns 0 in finite time?

Same error.

[Richard Damon]

On 6/17/22 2:45 PM, olcott wrote:

> I already proved that they do many dozen of times.
> The reason that I stopped talking to Richard is that he could not
> remember from one post to the next what I said in the preceding post.
>

LIE.

And you know it.

You think that just because I don't accept your fabrications that I
don't remember it.

Anyone with even a little bit of a brain can tell who is using logic and
who is just repeating lies.

The fact that you can't shows how much brain you are using.

[Richard Damon]

On 6/17/22 11:45 AM, olcott wrote:
> On 6/17/2022 10:06 AM, wij wrote:

>> On Friday, 17 June 2022 at 22:51:15 UTC+8, olcott wrote:
>>> It took me six months to figure out how to transform H(P,P) into a pure
>>> function of its inputs. I did not release the code before because I knew
>>> that its use of static local data would have been rejected. With this
>>> update to H I will be able to publish the code.
>>> H recognizes that P is calling itself with its same arguments that it
>>> was called with and there are no instructions preceding this call that
>>> could possibly escape infinitely recursive emulation so H aborts its
>>> emulation of P before P even makes its first call to H.
>>> Without even looking at the code competent software engineers will be
>>> able to verify that the above H would correctly determine that that is
>>> input is non-halting as a pure function of this input.

>>> --
>>> Copyright 2022 Pete Olcott
>>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>> Arthur Schopenhauer
>>

>> What you say is irrelevant.
>> Reviewers investigate the 'H', an algorithm that a computer can execute,
>> not Peter Olcltt's Oral Halting decider.
>>
>
> H knows its own machine address and on this basis

> H recognizes that P is calling itself with its same arguments that it
> was called with and there are no instructions preceding this call that
> could possibly escape infinitely recursive emulation so H aborts its
> emulation of P before P even makes its first call to H.
>

> Every competent software engineer can verify that H(P,P)==0 as a pure
> function of its inputs according the the above algorithm.
>
>> The irrefutable fact is clear: GUR cannot be violated, you don't have a
>> real POOH for test/review.
>
>

H may be a pure function, but not a correct emulator/decider.

Note, the pattern H(P,P) conditionally emulating P(P) which calls H(P,P)

is NOT a infinite behavior pattern.

This has been proven.

IF H's emulation is correct, including the deduction of infinite
behavior, then H is NOT a pure function.

[olcott]

On 6/18/2022 4:09 AM, Malcolm McLean wrote:

> Yes.

>>
>> (2) It is an easily verified fact that if H has been adapted to
>> correctly detect (in a finite number of steps) that the correct and
>> complete x86 emulation of its input would never each its "ret"
>> instruction that H could abort its emulation and return 0 to report this.
>>

> Yes.

>>
>> (3) When the halt status criteria is defined as correctly determining
>> whether or not an x86 emulated input would ever reach its "ret"
>> instruction then it becomes an easily verified fact H(P,P) could
>> correctly reject its input as non-halting.
>>

> No. Because by changing H from emulator to halt decider, you have changed
> P.

When H(P,P) correctly determines that P would never reach its "ret"
instruction (AKA final state) this makes H a halt decider for this input
by definition:

computation that halts … the Turing machine will halt whenever it enters

a final state. (Linz:1990:234)

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

[olcott]

On 6/18/2022 5:20 AM, Mikko wrote:
> On 2022-06-17 14:33:32 +0000, olcott said:
>
>> THIS IS IRREFUTABLE BECAUSE IT IS A TAUTOLOGY:

>> When a simulating halt decider rejects all inputs as non-halting
>> whenever it correctly detects that its correct and complete
>> simulation of its input would never reach the final state of this
>> input then all [these] inputs (including pathological inputs) are
>> decided correctly.
>

> One should not use "whenever" in a when-clause. In the beginnig
> of the above "If" would be better than "When".
>

Yes you are probably correct. The above words are a little clumsy.

> Another tautology is that the above tautology is irrelevant except
> when a correct and complete simulation of its input would never reach
> a final state of this input.
>

That is the same as saying all non-halting inputs.

> Note that "the" final state is incorrect: any state that is not
> folowed by another state is a final state, and a computation halts
> if it reaches one of its final states.
>
> Mikko
>

Yes you are technically correct that a computation can have more than
one final state. None of my test cases have more than one. I changed
"the" to "a".

[olcott]

On 6/18/2022 7:24 AM, wij wrote:

> GUR is repeatedly proved:
> olcott can never provide a real halting decider except a verbal one.
> Thanks olcott.

This one proves that H(P,P) does correctly determine that H(P,P)==0 is
correct:

H(P,P)==0 as a pure function of its inputs is fully operational V2

[Richard Damon]

You are missing that H may have determened the correct behavior for *A*
P< the one built on the H that is a pure emulator and never aborts, but
that isn't the P that this H needs to answer about. This H needs to get
right the P that is built on itself, the H that will abort when it sees
this pattern, and that P does reach that final state.

Your fundamental problem seems to be that you think the the "P" you are
deciding on is just the code for the C function with an abstract/fuzzy
definition of the behavior of the H tht it calls, but that isn't the
question, When you look at a Turing Machine, that machine includes ALL
the "code" that machine executes, even "sub-functions" that it uses, so
the code of H (and everything that H uses) is PART of the "input P".

Thus, the x86 assembly representation of the input P isn't just the code
of the function P, as that isn't an actual definition that defines the
behavior in question, but the representation needs to include all the
x86 code of H and everything that H calls.

[Richard Damon]

Except it isn't since H(P,P) returns 0, saying that P(P) is non-halting,
when P(P) will halt when H(P,P) returns 0.

If H(P,P) isn't asking about P(P), then you don't have the right
function P, as the Linz definition of P is that it will ask about that.

[olcott]

(X) H(P,P) correctly determines (in a finite number of steps) that the
correct and complete x86 emulation of its input would never reach the
"ret" instruction (AKA final state) of this input.

(Y) computation that halts … the Turing machine will halt whenever it

enters a final state. (Linz:1990:234)

(Z) H(P,P) has correctly determined that its input is non-halting.

When we know that X & Y proves Z and we know X & Y then Z is proved.
Failing to agree with this last line is sufficient evidence of dishonesty.

[Richard Damon]

FALSE. Only proven for all H(P,P) that actually DO a complete x86
emulation of its input, and those can't do it in a finite number of
steps. The H(P,P) that you have proven it for NEVER return 0 from
H(P,P). The H you are now talking about DOES return 0, and thus DOES
abort its simulation and thus DOES NOT actually do a complete x86
emulation of its input, so not applicable here.

>
> (Y) computation that halts … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)

True/

>
> (Z) H(P,P) has correctly determined that its input is non-halting.

Nope, it has correctly determined that A DIFFERENT P/H combination is
non-halting, not itself.

>
> When we know that X & Y proves Z and we know X & Y then Z is proved.
> Failing to agree with this last line is sufficient evidence of dishonesty.
>

So, since you never proved X for the H that you are talking about, you
haven't proved your point.

FAIL.