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