On 5/24/22 12:01 PM, olcott wrote:
> On 5/24/2022 10:35 AM, Mikko wrote:
>> On 2022-05-24 14:40:02 +0000, olcott said:
>>
>>> Any smart software engineer with a sufficient technical background
>>> can easily confirm that H(P,P)==0 is correct:
>>
>> No "would" or "can" helps if they don't.
>>
>> Mikko
>>
>
> That I know this is an established fact simply proves that my reviewers
> here have outlived their usefulness.
>

You may THINK it is an established fact, but the fact that you haven't
actaully proved it by the rules of logic says you haven't, and in fact,
says you are being a Hypocrite for claiming it.

Your "Logic" is based on untruths and out and out lies, so is invalid.

The problem is you don't seem to understand that ultimately, Halting
MUST be based on the actions of the actual machine, so since H^ applied
to <H^> (or P(P)) Halts, then whatever logic you used to show that it
seems to be correct to say it is non-halting must have been incorrect.

The obvious error is your switching from talking about the behavior of
the machine to a simulation when you also allow a simulation to differ
in behavior from the actual machine. That is NOT a logically allowable
transformation.

The fact that you make claims that you MUST be able to do so just shows
your ignorance of how logic works, and that you are just a pathological
liar.

On 6/1/22 2:11 AM, olcott wrote:
> On 5/31/2022 7:41 PM, Mr Flibble wrote:
>> On Tue, 31 May 2022 19:26:25 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 5/31/2022 6:48 PM, Malcolm McLean wrote:
>>>> On Tuesday, 31 May 2022 at 23:23:15 UTC+1, olcott wrote:
>>>>> On 5/31/2022 4:05 PM, Malcolm McLean wrote:
>>>>>> On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
>>>>>>> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
>>>>>>>>
>>>>>>>> When we assume a simulating halt decider then none of the
>>>>>>>> simulated inputs to the conventional proofs ever reach their
>>>>>>>> final state when correctly simulated by this simulating halt
>>>>>>>> decider.
>>>>>>>>
>>>>>>>> That you don't understand this does not make it false.
>>>>>>> We can't "assume a simulating halt decider" because the proof
>>>>>>> shows, or at least claims to show, that a simulating halt
>>>>>>> decider can't exist.
>>>>> None of the proofs bother to specifically examine simulating halt
>>>>> deciders this is their big mistake. All of the proofs simply
>>>>> assume that the execution trace of the input to H(P,P) reaches the
>>>>> self-contradictory part. This is a provably false assumption.
>>>> And actually, what you have done is construct a simulating
>>>> attempted halt decider, which fails on H_Hat,
>>>
>>> H(P,P) does correctly determine that its correctly simulated input
>>> never reaches the "ret" input of the input. H_Hat is off topic
>>> because all of my much clearer reasoning refers to H(P,P).
>>>
>>>> for reasons unrelated to the invert loop.
>>>> So you have actually achieved something of interest, if you could
>>>> only recognise that.
>>>
>>> I really have refuted all of the conventional halting problem proofs.
>>
>> Not by detecting an infinite recursion you haven't as no such recursion
>> exists in those proofs.
>>
>> /Flibble
>>
>
> There is a behavior pattern that prevents the correctly emulated input
> to H(P,P) from every reaching its "ret" instruction this is a sufficient
> basis to correctly determine that the input to H(P,P) is non halting.
>

And that also shows that your definition of halting is incorrrect.

Halting is ultimatly defined by the behavior of the actual machine.

You can only convert it to use simulation when simulation is defined to
be identical to the actual machine. Since you allow it to differ, you
can not use simulation as a method of proving halting. This pattern is
exactly the case where you simulation differs from actual behavior, so
the fact that you use it to show you answer is "correct", just points
out that you definitions are incorrect.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> And actually, what you have done is construct a simulating attempted halt
> decider, which fails on H_Hat, for reasons unrelated to the invert
> loop.

What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
is involved, but that's not interesting.

> So you have actually achieved something of interest, if you could only
> recognise that.

What do you think is new or interesting here? I can't see anything new
or interesting here at all.

--
Ben.

On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > And actually, what you have done is construct a simulating attempted halt
> > decider, which fails on H_Hat, for reasons unrelated to the invert
> > loop.
> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
> is involved, but that's not interesting.
> > So you have actually achieved something of interest, if you could only
> > recognise that.
> What do you think is new or interesting here? I can't see anything new
> or interesting here at all.
>
The "simulating halt decider" will fail when fed H_Hat, not because of the invert
step, but because it can't solve the simulation of H. That's inherent in the way
it is set up - it can only terminate if it detects that the series of nested
simulations is non-terminating, in which case it becomes terminating.

I don't think anyone has actually pointed that out before. It's not going to
revolutionise computer science. But it is an interesting observation.

On 6/2/2022 6:19 AM, Malcolm McLean wrote:
> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> And actually, what you have done is construct a simulating attempted halt
>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>> loop.
>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>> is involved, but that's not interesting.
>>> So you have actually achieved something of interest, if you could only
>>> recognise that.
>> What do you think is new or interesting here? I can't see anything new
>> or interesting here at all.
>>
> The "simulating halt decider" will fail when fed H_Hat, not because of the invert
> step, but because it can't solve the simulation of H. That's inherent in the way
> it is set up - it can only terminate if it detects that the series of nested
> simulations is non-terminating, in which case it becomes terminating.
>

That is not the point. The simulated input to H(P,P) only halts if it
reaches its "ret" instruction otherwise it is non-halting.

P(P) does halt yet it is an entirely different sequence of x86
instructions than the correctly simulated input to H(P,P).

People here say that they really really don't believe this thus directly
disagree with the x86 language. This is a move that only one person here
is dumb enough to make, yet more than one person does.

> I don't think anyone has actually pointed that out before. It's not going to
> revolutionise computer science. But it is an interesting observation.

--
Copyright 2022 Pete Olcott

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

On 6/2/22 7:19 AM, Malcolm McLean wrote:
> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> And actually, what you have done is construct a simulating attempted halt
>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>> loop.
>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>> is involved, but that's not interesting.
>>> So you have actually achieved something of interest, if you could only
>>> recognise that.
>> What do you think is new or interesting here? I can't see anything new
>> or interesting here at all.
>>
> The "simulating halt decider" will fail when fed H_Hat, not because of the invert
> step, but because it can't solve the simulation of H. That's inherent in the way
> it is set up - it can only terminate if it detects that the series of nested
> simulations is non-terminating, in which case it becomes terminating.
>
> I don't think anyone has actually pointed that out before. It's not going to
> revolutionise computer science. But it is an interesting observation.

I thought I mentioned that problem in the past. There are 4 different
sorts of machines that can use this broad pattern, 3 of which have
correct answers that H can give, but his method just can't handle any of
them.

These could be simply listed below:

Ph(M): just return H(M,M). This can correctly be decided by H to always
Halt

Pl(M): call H(M,M), and then loop. This can correctly by H be decided to
never halt

Pm(M), call H(M,M), and if it returns 0, loop, else just return. This
can be correctly by H decided with whatever answer is given.

Pc(M) (the H^), call H(M,M) and do the opposite of what it says, This
can Never be correctly decided by H.

TO handle these, if you can actually detect the "recursion" of the input
calling a copy of the decider (which Peter only does by breaking the
correct frame of the problem), then when you see that the input matches
the input to this decider, you can then try possible answers and find
the right answers for the first 3 cases, and the fact that you are stuck
in the forth.

On 6/2/22 8:01 AM, olcott wrote:
> On 6/2/2022 6:19 AM, Malcolm McLean wrote:
>> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> And actually, what you have done is construct a simulating attempted
>>>> halt
>>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>>> loop.
>>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>>> is involved, but that's not interesting.
>>>> So you have actually achieved something of interest, if you could only
>>>> recognise that.
>>> What do you think is new or interesting here? I can't see anything new
>>> or interesting here at all.
>>>
>> The "simulating halt decider" will fail when fed H_Hat, not because of
>> the invert
>> step, but because it can't solve the simulation of H. That's inherent
>> in the way
>> it is set up - it can only terminate if it detects that the series of
>> nested
>> simulations is non-terminating, in which case it becomes terminating.
>>
>
> That is not the point. The simulated input to H(P,P) only halts if it
> reaches its "ret" instruction otherwise it is non-halting.

No, the CORRECTLY simulated input will reach the "ret" instruction (if
H(P,P) returns 0)

All you have shown is that no H can be designed to reach the "ret"
instruction in its own simumatlion of the input, but that if it aborts
its simulation to avoid making the error of not answering, it make a
mistake because it doesn't have enough information to make a correct answer.
>
> P(P) does halt yet it is an entirely different sequence of x86
> instructions than the correctly simulated input to H(P,P).
>

No, it is EXACTLY the same sequence of x86 instuctons as the input to H.
If it isn't, then your input is incorrect. Your problem is that the
"sequence of x86 instructions" that represent the PROGRAM P, include all
the instructions of the subroutine H (and everything it calls). You H
acts as if those instructions were different then they actually are, so
doesn't create a CORRECT simulation of that input.

BAD LOGIC, BAD ANSWERS, DUMB logicitian.

> People here say that they really really don't believe this thus directly
> disagree with the x86 language. This is a move that only one person here
> is dumb enough to make, yet more than one person does.

So, what do YOU think the x86 processor manual says the "call"
instruction does?

>
>> I don't think anyone has actually pointed that out before. It's not
>> going to
>> revolutionise computer science. But it is an interesting observation.
>
>

Nope, you just prove how ignorant you are.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > And actually, what you have done is construct a simulating attempted halt
>> > decider, which fails on H_Hat, for reasons unrelated to the invert
>> > loop.
>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>> is involved, but that's not interesting.
>> > So you have actually achieved something of interest, if you could only
>> > recognise that.
>> What do you think is new or interesting here? I can't see anything new
>> or interesting here at all.
>>
> The "simulating halt decider" will fail when fed H_Hat, not because of
> the invert step, but because it can't solve the simulation of H.

What's new or interesting about that? A simulating partial halt decider
really only has only two ways to be wrong: fail to return a result or
incorrectly decide some halting computations as non-halting (ignoring
cases where it's designed to be deliberately wrong unnecessarily).

And H_Hat never has anything to do with why a decider is wrong because
we can show that any purported halt decider must get infinitely many
instances wrong, so there will be an abundance of examples that have
nothing to do with H_Hat.

But none of this is what PO is claiming. He claims H is right to be
wrong so you have your work cut out if you want to get him to accept
that H really is wrong, even if you find the reason interesting.

> That's inherent in the way
> it is set up - it can only terminate if it detects that the series of nested
> simulations is non-terminating, in which case it becomes terminating.

No, it terminates because it /incorrectly/ concludes that the nested
simulations are non-terminating. PO's silly argument is that this
conclusion is not wrong because the nested simulations /would/ be
non-terminating if they were not terminated. Go figure.

> I don't think anyone has actually pointed that out before. It's not going to
> revolutionise computer science. But it is an interesting observation.

Why would anyone want to point this out? We know simulation can't be
used to decide halting, and we know that there are only two ways a
decider that tries to do so can be wrong. Both come up every time this
is taught to a class of programmers. (I've never taught it to a class
of mathematicians but I suspect the discussion would be very different.)

--
Ben.

On 02/06/2022 12:19, Malcolm McLean wrote:
> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> And actually, what you have done is construct a simulating attempted halt
>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>> loop.
>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>> is involved, but that's not interesting.
>>> So you have actually achieved something of interest, if you could only
>>> recognise that.
>> What do you think is new or interesting here? I can't see anything new
>> or interesting here at all.
>>
> The "simulating halt decider" will fail when fed H_Hat, not because of the invert
> step, but because it can't solve the simulation of H. That's inherent in the way
> it is set up - it can only terminate if it detects that the series of nested
> simulations is non-terminating, in which case it becomes terminating.

...in which case it becomes terminating BECAUSE OF THE INVERT STEP.

>
> I don't think anyone has actually pointed that out before. It's not going to
> revolutionise computer science. But it is an interesting observation.

I'd just add a couple of observations:
- any broadly competent student (let's say certainly any researcher)
contemplating the idea of a simulating (partial) halt
decider, will straight away think of everything you've said,
so it is not especially interesting to them. (But perhaps we could
say it has a curious ring to it all...)
- just going back through my own previous posts, I find
message-id: <Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
newsgroup: comp.theory
subject: Re: Black box halt decider is NOT a partial decider
date: Sun, 25 Jul 2021 21:28:10 +0100
that seems to cover your points. (I'm not claiming any
cleverness in making those points - they're just basic
consequences for a simulating HD. Also I'm sure others will
have pointed out similar stuff.)
- PO DID NOT SAY ANY OF THIS, AND HE SPECIFICALLY DISAGREES WITH
the points you make. So when you say "So you have actually
achieved something of interest..." that is Wrong - it's not
something PO has achieved at all!

For some reason you seem determined to "big up" PO's contributions, and I've never understood why -
it's like you're /embarassed/ for him in some way, like he's your handicapped brother who needs
constant encouragement or something!

Mike.

On 02/06/2022 17:21, Ben wrote:
> [...] We know simulation can't be
> used to decide halting, and we know that there are only two ways a
> decider that tries to do so can be wrong. Both come up every time this
> is taught to a class of programmers. (I've never taught it to a class
> of mathematicians but I suspect the discussion would be very different.)

My first thought was "no, it's the same", but on reflexion, and AFAIR,
our mathematicians simply accepted what I told them, which is essentially what
is at

http://www.cuboid.me.uk/anw/G12FCO/lect17.html

[second half, but see esp the last paragraph] and

http://www.cuboid.me.uk/anw/G12FCO/lect18.html

[both lectures from a module that I gave many moons ago]. We got pretty
bright students, among the top four or five cohorts in the UK at that time
[1990s] [but that was our high point, even beating Oxford one year], and of
course many of them went into IT as a career. They found NP-completeness
much harder than UTMs, HP and related stuff.

[The code G12FCO means G1 -- maths, 2 -- second year, FCO -- Formal
Computation.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Jessel

On 6/2/2022 11:21 AM, Ben wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> And actually, what you have done is construct a simulating attempted halt
>>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>>> loop.
>>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>>> is involved, but that's not interesting.
>>>> So you have actually achieved something of interest, if you could only
>>>> recognise that.
>>> What do you think is new or interesting here? I can't see anything new
>>> or interesting here at all.
>>>
>> The "simulating halt decider" will fail when fed H_Hat, not because of
>> the invert step, but because it can't solve the simulation of H.
>
> What's new or interesting about that? A simulating partial halt decider
> really only has only two ways to be wrong: fail to return a result or
> incorrectly decide some halting computations as non-halting (ignoring
> cases where it's designed to be deliberately wrong unnecessarily).
>
> And H_Hat never has anything to do with why a decider is wrong because
> we can show that any purported halt decider must get infinitely many
> instances wrong, so there will be an abundance of examples that have
> nothing to do with H_Hat.
>
> But none of this is what PO is claiming. He claims H is right to be
> wrong so you have your work cut out if you want to get him to accept
> that H really is wrong, even if you find the reason interesting.

NO I AM NOT SAYING THAT AT ALL PLEASE PAY MUCH CLOSER ATTENTION I HAVE
HAD TO REPEAT MYSELF HUNDREDS OF TIMES AND EVERYONE CONSISTENTLY IGNORES
MY CORRECTIONS TO THEIR FALSE ASSUMPTIONS AND MISCONCEPTIONS.

It is an easily verified fact that the correctly simulated input to
H(P,P) never reaches its "ret" instruction therefore even when the
simulation is aborted P did not halt and never would halt.

This conclusively proves that H(P,P)==0 to anyone that is merely
a fully competent software engineer having the required prerequisites
of C, x86, how C translates to x86, and what x86 emulation is.

LIARS AND IDIOTS DENY THE TRUTH OF THIS
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its find “ret” instruction,
thus never halts.

Because Ben very very persistently refused to confirm the truth of this
I mistook him for a liar. When he acknowledged that he saw no evidence
that it is not true I acknowledged that my attribution of liar was
incorrect.

>
>> That's inherent in the way
>> it is set up - it can only terminate if it detects that the series of nested
>> simulations is non-terminating, in which case it becomes terminating.
>
> No, it terminates because it /incorrectly/ concludes that the nested
> simulations are non-terminating. PO's silly argument is that this
> conclusion is not wrong because the nested simulations /would/ be
> non-terminating if they were not terminated. Go figure.
>
>> I don't think anyone has actually pointed that out before. It's not going to
>> revolutionise computer science. But it is an interesting observation.
>
> Why would anyone want to point this out? We know simulation can't be
> used to decide halting, and we know that there are only two ways a
> decider that tries to do so can be wrong. Both come up every time this
> is taught to a class of programmers. (I've never taught it to a class
> of mathematicians but I suspect the discussion would be very different.)
>

--
Copyright 2022 Pete Olcott

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

On 6/2/2022 11:32 AM, Mike Terry wrote:
> On 02/06/2022 12:19, Malcolm McLean wrote:
>> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> And actually, what you have done is construct a simulating attempted
>>>> halt
>>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>>> loop.
>>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>>> is involved, but that's not interesting.
>>>> So you have actually achieved something of interest, if you could only
>>>> recognise that.
>>> What do you think is new or interesting here? I can't see anything new
>>> or interesting here at all.
>>>
>> The "simulating halt decider" will fail when fed H_Hat, not because of
>> the invert
>> step, but because it can't solve the simulation of H. That's inherent
>> in the way
>> it is set up - it can only terminate if it detects that the series of
>> nested
>> simulations is non-terminating, in which case it becomes terminating.
>
> ..in which case it becomes terminating BECAUSE OF THE INVERT STEP.
>

AS I HAVE PROVEN MANY HUNDREDS OF TIMES THE SIMULATED INPUT TO H(P,P)
NEVER REACHES THE INVERT STEP.

It is an easily verified fact that the correctly simulated input to
H(P,P) never reaches its "ret" instruction therefore even when the
simulation is aborted P did not halt and never would halt.

This conclusively proves that H(P,P)==0 to anyone that is merely
a fully competent software engineer having the required prerequisites
of C, x86, how C translates to x86, and what x86 emulation is.

LIARS AND IDIOTS DENY THE TRUTH OF THIS
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its find “ret” instruction,
thus never halts.

--
Copyright 2022 Pete Olcott

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

On 6/2/2022 1:12 PM, Andy Walker wrote:
> On 02/06/2022 17:21, Ben wrote:
>> [...]  We know simulation can't be
>> used to decide halting, and we know that there are only two ways a
>> decider that tries to do so can be wrong.  Both come up every time this
>> is taught to a class of programmers.  (I've never taught it to a class
>> of mathematicians but I suspect the discussion would be very different.)
>
>     My first thought was "no, it's the same", but on reflexion, and AFAIR,
> our mathematicians simply accepted what I told them, which is
> essentially what
> is at
>
>     http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>
> [second half, but see esp the last paragraph] and
>
>     http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>
> [both lectures from a module that I gave many moons ago].  We got pretty
> bright students, among the top four or five cohorts in the UK at that time
> [1990s] [but that was our high point, even beating Oxford one year], and of
> course many of them went into IT as a career.  They found NP-completeness
> much harder than UTMs, HP and related stuff.
>
>     [The code G12FCO means G1 -- maths, 2 -- second year, FCO -- Formal
> Computation.]
>

The HP where a decider decides what another decider will do with an
input (Like Sipser) is too convoluted. I only address what a halt
decider does with its input (Like Linz).

Any fully competent software engineer can easily verify that H(P,P)==0
is correct.

#include <stdint.h>
#define u32 uint32_t

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

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)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]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

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

Andy Walker <anw@cuboid.co.uk> writes:

> On 02/06/2022 17:21, Ben wrote:
>> [...] We know simulation can't be
>> used to decide halting, and we know that there are only two ways a
>> decider that tries to do so can be wrong. Both come up every time this
>> is taught to a class of programmers. (I've never taught it to a class
>> of mathematicians but I suspect the discussion would be very different.)
>
> My first thought was "no, it's the same", but on reflexion, and AFAIR,
> our mathematicians simply accepted what I told them, which is essentially what
> is at
>
> http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>
> [second half, but see esp the last paragraph] and
>
> http://www.cuboid.me.uk/anw/G12FCO/lect18.html

I see your notes are an explicit counterexample to PO's claims that
emulation is never considered!

> [both lectures from a module that I gave many moons ago]. We got pretty
> bright students, among the top four or five cohorts in the UK at that time
> [1990s] [but that was our high point, even beating Oxford one year], and of
> course many of them went into IT as a career. They found NP-completeness
> much harder than UTMs, HP and related stuff.

We got pretty bright students too. Bright students ask good questions
but eventually (rapidly even) settle the matter to their own
satisfaction.

And I agree that complexity is more... complex. The details become so
very significant in complexity theory. One of the depressing things
about these endless threads is that this is not a complex theorem.

--
Ben.

On 6/2/2022 2:00 PM, Ben wrote:
> Andy Walker <anw@cuboid.co.uk> writes:
>
>> On 02/06/2022 17:21, Ben wrote:
>>> [...] We know simulation can't be
>>> used to decide halting, and we know that there are only two ways a
>>> decider that tries to do so can be wrong. Both come up every time this
>>> is taught to a class of programmers. (I've never taught it to a class
>>> of mathematicians but I suspect the discussion would be very different.)
>>
>> My first thought was "no, it's the same", but on reflexion, and AFAIR,
>> our mathematicians simply accepted what I told them, which is essentially what
>> is at
>>
>> http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>
>> [second half, but see esp the last paragraph] and
>>
>> http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>
> I see your notes are an explicit counterexample to PO's claims that
> emulation is never considered!
>

The emulation is simply describing a UTM not applying an adapted UTM to
the HP.

>> [both lectures from a module that I gave many moons ago]. We got pretty
>> bright students, among the top four or five cohorts in the UK at that time
>> [1990s] [but that was our high point, even beating Oxford one year], and of
>> course many of them went into IT as a career. They found NP-completeness
>> much harder than UTMs, HP and related stuff.
>
> We got pretty bright students too. Bright students ask good questions
> but eventually (rapidly even) settle the matter to their own
> satisfaction.
>
> And I agree that complexity is more... complex. The details become so
> very significant in complexity theory. One of the depressing things
> about these endless threads is that this is not a complex theorem.
>

--
Copyright 2022 Pete Olcott

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

On 6/2/2022 2:00 PM, Ben wrote:
> Andy Walker <anw@cuboid.co.uk> writes:
>
>> On 02/06/2022 17:21, Ben wrote:
>>> [...] We know simulation can't be
>>> used to decide halting, and we know that there are only two ways a
>>> decider that tries to do so can be wrong. Both come up every time this
>>> is taught to a class of programmers. (I've never taught it to a class
>>> of mathematicians but I suspect the discussion would be very different.)
>>
>> My first thought was "no, it's the same", but on reflexion, and AFAIR,
>> our mathematicians simply accepted what I told them, which is essentially what
>> is at
>>
>> http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>
>> [second half, but see esp the last paragraph] and
>>
>> http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>
> I see your notes are an explicit counterexample to PO's claims that
> emulation is never considered!
>

For these cases, we can turn to our second weapon -- emulation. We want
to know whether a program halts, so we try it. If it halts, then we know
the answer. If it doesn't halt, then `it must be in a loop', so we
monitor its state and `detect the loop'. Sadly, although this is in one
sense correct, it is a false dichotomy. At any given moment as the
emulation proceeds, we are in one of not two but three states: the
program has halted, or it is looping, or it is still running and has not
yet entered a loop. It's the third case that kills us -- we just have to
keep going, and wait for one of the other two things to happen. The
trouble is that it may be that neither of them ever happens -- which is
why `it must be in a loop' was in quotes above.

It is not considered correctly.
(a) the program has halted
(b) the program is still running
(c) the program matched an infinite behavior pattern

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

H(P,P)==0 for the above behavior pattern. (The entire research scope)

>> [both lectures from a module that I gave many moons ago]. We got pretty
>> bright students, among the top four or five cohorts in the UK at that time
>> [1990s] [but that was our high point, even beating Oxford one year], and of
>> course many of them went into IT as a career. They found NP-completeness
>> much harder than UTMs, HP and related stuff.
>
> We got pretty bright students too. Bright students ask good questions
> but eventually (rapidly even) settle the matter to their own
> satisfaction.
>
> And I agree that complexity is more... complex. The details become so
> very significant in complexity theory. One of the depressing things
> about these endless threads is that this is not a complex theorem.
>

--
Copyright 2022 Pete Olcott

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

On 6/2/2022 1:12 PM, Andy Walker wrote:
> On 02/06/2022 17:21, Ben wrote:
>> [...]  We know simulation can't be
>> used to decide halting, and we know that there are only two ways a
>> decider that tries to do so can be wrong.  Both come up every time this
>> is taught to a class of programmers.  (I've never taught it to a class
>> of mathematicians but I suspect the discussion would be very different.)
>
>     My first thought was "no, it's the same", but on reflexion, and AFAIR,
> our mathematicians simply accepted what I told them, which is
> essentially what
> is at
>
>     http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>
> [second half, but see esp the last paragraph] and
>
>     http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>

For these cases, we can turn to our second weapon -- emulation. We want
to know whether a program halts, so we try it. If it halts, then we know
the answer. If it doesn't halt, then `it must be in a loop', so we
monitor its state and `detect the loop'. Sadly, although this is in one
sense correct, it is a false dichotomy. At any given moment as the
emulation proceeds, we are in one of not two but three states: the
program has halted, or it is looping, or it is still running and has not
yet entered a loop. It's the third case that kills us -- we just have to
keep going, and wait for one of the other two things to happen. The
trouble is that it may be that neither of them ever happens -- which is
why `it must be in a loop' was in quotes above.

It is not considered correctly.
(a) the program has halted
(b) the program is still running
(c) the program matched an infinite behavior pattern

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

Any competent software engineer can verify that H(P,P)==0
for the above behavior pattern. (The entire research scope)
As detailed in my paper:

Halting problem undecidability and infinitely nested simulation (V5)

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

> [both lectures from a module that I gave many moons ago].  We got pretty
> bright students, among the top four or five cohorts in the UK at that time
> [1990s] [but that was our high point, even beating Oxford one year], and of
> course many of them went into IT as a career.  They found NP-completeness
> much harder than UTMs, HP and related stuff.
>
>     [The code G12FCO means G1 -- maths, 2 -- second year, FCO -- Formal
> Computation.]
>

--
Copyright 2022 Pete Olcott

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

On Thu, 2 Jun 2022 15:47:22 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/2/2022 1:12 PM, Andy Walker wrote:
> > On 02/06/2022 17:21, Ben wrote:
> >> [...]  We know simulation can't be
> >> used to decide halting, and we know that there are only two ways a
> >> decider that tries to do so can be wrong.  Both come up every time
> >> this is taught to a class of programmers.  (I've never taught it
> >> to a class of mathematicians but I suspect the discussion would be
> >> very different.)
> >
> >     My first thought was "no, it's the same", but on reflexion,
> > and AFAIR, our mathematicians simply accepted what I told them,
> > which is essentially what
> > is at
> >
> >     http://www.cuboid.me.uk/anw/G12FCO/lect17.html
> >
> > [second half, but see esp the last paragraph] and
> >
> >     http://www.cuboid.me.uk/anw/G12FCO/lect18.html
> >
>
>
> For these cases, we can turn to our second weapon -- emulation. We
> want to know whether a program halts, so we try it. If it halts, then
> we know the answer. If it doesn't halt, then `it must be in a loop',
> so we monitor its state and `detect the loop'. Sadly, although this
> is in one sense correct, it is a false dichotomy. At any given moment
> as the emulation proceeds, we are in one of not two but three states:
> the program has halted, or it is looping, or it is still running and
> has not yet entered a loop. It's the third case that kills us -- we
> just have to keep going, and wait for one of the other two things to
> happen. The trouble is that it may be that neither of them ever
> happens -- which is why `it must be in a loop' was in quotes above.
>
> It is not considered correctly.
> (a) the program has halted
> (b) the program is still running
> (c) the program matched an infinite behavior pattern
>
> For any program H that might determine if programs halt, a
> "pathological"
> program P, called with some input, can pass its own source and
> its input to
> H and then specifically do the opposite of what H predicts P
> will do. No H
> can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> Any competent software engineer can verify that H(P,P)==0
> for the above behavior pattern. (The entire research scope)
> As detailed in my paper:
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>

The proofs you are attempting to refute do not contain the infinite
behaviour pattern you describe; you have been told this multiple times
now and keep ignoring it: is this because you have actually given up
trying to refute those proofs?

/Flibble

On 6/2/2022 6:38 PM, Mr Flibble wrote:
> On Thu, 2 Jun 2022 15:47:22 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/2/2022 1:12 PM, Andy Walker wrote:
>>> On 02/06/2022 17:21, Ben wrote:
>>>> [...]  We know simulation can't be
>>>> used to decide halting, and we know that there are only two ways a
>>>> decider that tries to do so can be wrong.  Both come up every time
>>>> this is taught to a class of programmers.  (I've never taught it
>>>> to a class of mathematicians but I suspect the discussion would be
>>>> very different.)
>>>
>>>     My first thought was "no, it's the same", but on reflexion,
>>> and AFAIR, our mathematicians simply accepted what I told them,
>>> which is essentially what
>>> is at
>>>
>>>     http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>
>>> [second half, but see esp the last paragraph] and
>>>
>>>     http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>>
>>
>>
>> For these cases, we can turn to our second weapon -- emulation. We
>> want to know whether a program halts, so we try it. If it halts, then
>> we know the answer. If it doesn't halt, then `it must be in a loop',
>> so we monitor its state and `detect the loop'. Sadly, although this
>> is in one sense correct, it is a false dichotomy. At any given moment
>> as the emulation proceeds, we are in one of not two but three states:
>> the program has halted, or it is looping, or it is still running and
>> has not yet entered a loop. It's the third case that kills us -- we
>> just have to keep going, and wait for one of the other two things to
>> happen. The trouble is that it may be that neither of them ever
>> happens -- which is why `it must be in a loop' was in quotes above.
>>
>> It is not considered correctly.
>> (a) the program has halted
>> (b) the program is still running
>> (c) the program matched an infinite behavior pattern
>>
>> For any program H that might determine if programs halt, a
>> "pathological"
>> program P, called with some input, can pass its own source and
>> its input to
>> H and then specifically do the opposite of what H predicts P
>> will do. No H
>> can exist that handles this case.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> Any competent software engineer can verify that H(P,P)==0
>> for the above behavior pattern. (The entire research scope)
>> As detailed in my paper:
>>
>> Halting problem undecidability and infinitely nested simulation (V5)
>>
>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>
>
> The proofs you are attempting to refute do not contain the infinite
> behaviour pattern you describe;

The correctly simulated input to a simulating halt decider never reaches
the final instruction of this simulated input thus is unequivocally
non-halting.

Halting does not mean stopped running, it means terminated normally.

Whether or not this simulated input specifies infinite behavior is a
matter of how one defines one's terms and makes no difference because
the behavior that it does exhibit is still correctly construed as
non-halting even after its simulation has been aborted.

>you have been told this multiple times
> now and keep ignoring it:

Every time that I correct my reviewers false assumptions and
misconceptions they always make sure to not read a single word of what I
have said.

It is always blah blah blah we know you must be wrong so there is no
sense in reading what your reply.

> is this because you have actually given up
> trying to refute those proofs?
>
> /Flibble
>

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

On 6/2/22 7:45 PM, olcott wrote:
> On 6/2/2022 6:38 PM, Mr Flibble wrote:
>> On Thu, 2 Jun 2022 15:47:22 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/2/2022 1:12 PM, Andy Walker wrote:
>>>> On 02/06/2022 17:21, Ben wrote:
>>>>> [...]  We know simulation can't be
>>>>> used to decide halting, and we know that there are only two ways a
>>>>> decider that tries to do so can be wrong.  Both come up every time
>>>>> this is taught to a class of programmers.  (I've never taught it
>>>>> to a class of mathematicians but I suspect the discussion would be
>>>>> very different.)
>>>>
>>>>       My first thought was "no, it's the same", but on reflexion,
>>>> and AFAIR, our mathematicians simply accepted what I told them,
>>>> which is essentially what
>>>> is at
>>>>
>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>>
>>>> [second half, but see esp the last paragraph] and
>>>>
>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>>
>>>
>>> For these cases, we can turn to our second weapon -- emulation. We
>>> want to know whether a program halts, so we try it. If it halts, then
>>> we know the answer. If it doesn't halt, then `it must be in a loop',
>>> so we monitor its state and `detect the loop'. Sadly, although this
>>> is in one sense correct, it is a false dichotomy. At any given moment
>>> as the emulation proceeds, we are in one of not two but three states:
>>> the program has halted, or it is looping, or it is still running and
>>> has not yet entered a loop. It's the third case that kills us -- we
>>> just have to keep going, and wait for one of the other two things to
>>> happen. The trouble is that it may be that neither of them ever
>>> happens -- which is why `it must be in a loop' was in quotes above.
>>>
>>> It is not considered correctly.
>>> (a) the program has halted
>>> (b) the program is still running
>>> (c) the program matched an infinite behavior pattern
>>>
>>>        For any program H that might determine if programs halt, a
>>> "pathological"
>>>        program P, called with some input, can pass its own source and
>>> its input to
>>>        H and then specifically do the opposite of what H predicts P
>>> will do. No H
>>>        can exist that handles this case.
>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> Any competent software engineer can verify that H(P,P)==0
>>> for the above behavior pattern. (The entire research scope)
>>> As detailed in my paper:
>>>
>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>
>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>
>>>
>>
>> The proofs you are attempting to refute do not contain the infinite
>> behaviour pattern you describe;
>
> The correctly simulated input to a simulating halt decider never reaches
> the final instruction of this simulated input thus is unequivocally
> non-halting.

You keep on saying that, but it isn't actually true for the PROPER
definition of "correct simulation", that being, the simulation of the
input by a UTM equiavlent. (or an x86 processor for your x86 code).

What you want to call "correct simulation" is the partial simulation by
a particular H, but partial simulation are NEVER "correct" because they
are, by definitin=on, INCOMPLETE.

>
> Halting does not mean stopped running, it means terminated normally., so we can

Non-Halting also doesn't meen only partially run and it didn't reach
completion yet.

Note, the CORRECT simulation of the input to H will terminate normally,
It is only that H didn't complete its simulation.

Your arguement about "ANY H" is invalid, as H isn't just "ANY H" but is
a particualar H, and each of the possible H's your "ANY H" talks about
have DIFFERENT inputs so you can't use your "logic" to try to tight them
together.

That is a bit like saying the number N+5 is infinite for any finte
number N, since no matter what N you choose, N+5 is bigger than you
number, so that must mean that N+5 is bigger than all numbers, and thus
infinite.

Hopefully you can see the silliness of that claim, that is exact the
sort of claim you are making with your "any H" claim.

Given an H that aborts its simulation in "N" steps, we can show that
P(P) will halt is some number of steps that can be computed as f(N) > N,
but still finite. Your "ANY N" arguement to claim that P in non-halting
is saying that f(N) is infinite, when it is actually a finite number
just bigger then the N for that H.

>
> Whether or not this simulated input specifies infinite behavior is a
> matter of how one defines one's terms and makes no difference because
> the behavior that it does exhibit is still correctly construed as
> non-halting even after its simulation has been aborted.

Nope. Since there is ONE definition of Halting, and that is does the
ACTUAL MACHINE reach a final state in a finite number of steps, any
defintion that can't be proved to be EXACTLY EQUIVALENT is BY DEFINITION
incorrect.

With your definition of "Correctly Simulated' being based on the
simulation of the decider, that isn't true, so you can't use it as an
alternate definition of halting, so your definition is just INCORRECT.

>
>> you have been told this multiple times
>> now and keep ignoring it:
>
> Every time that I correct my reviewers false assumptions and
> misconceptions they always make sure to not read a single word of what I
> have said.

Nope, YOU don't read what people say and thus PROVE that you are just a
pathological liar or a totally incompetent and ignorate fool.

>
> It is always blah blah blah we know you must be wrong so there is no
> sense in reading what your reply.

So, what is actually wrong with what I said, or are YOU the one just
going blah, blah, blah?

(My guess is that is exactly what you will do, thus proving your status
as a fool)

>
>> is this because you have actually given up
>> trying to refute those proofs?
>>
>> /Flibble
>>
>
>

On 6/2/22 2:42 PM, olcott wrote:
> On 6/2/2022 11:21 AM, Ben wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> And actually, what you have done is construct a simulating
>>>>> attempted halt
>>>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>>>> loop.
>>>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>>>> is involved, but that's not interesting.
>>>>> So you have actually achieved something of interest, if you could only
>>>>> recognise that.
>>>> What do you think is new or interesting here? I can't see anything new
>>>> or interesting here at all.
>>>>
>>> The "simulating halt decider" will fail when fed H_Hat, not because of
>>> the invert step, but because it can't solve the simulation of H.
>>
>> What's new or interesting about that?  A simulating partial halt decider
>> really only has only two ways to be wrong: fail to return a result or
>> incorrectly decide some halting computations as non-halting (ignoring
>> cases where it's designed to be deliberately wrong unnecessarily).
>>
>> And H_Hat never has anything to do with why a decider is wrong because
>> we can show that any purported halt decider must get infinitely many
>> instances wrong, so there will be an abundance of examples that have
>> nothing to do with H_Hat.
>>
>> But none of this is what PO is claiming.  He claims H is right to be
>> wrong so you have your work cut out if you want to get him to accept
>> that H really is wrong, even if you find the reason interesting.
>
> NO I AM NOT SAYING THAT AT ALL PLEASE PAY MUCH CLOSER ATTENTION I HAVE
> HAD TO REPEAT MYSELF HUNDREDS OF TIMES AND EVERYONE CONSISTENTLY IGNORES
> MY CORRECTIONS TO THEIR FALSE ASSUMPTIONS AND MISCONCEPTIONS.
>
> It is an easily verified fact that the correctly simulated input to
> H(P,P) never reaches its "ret" instruction therefore even when the
> simulation is aborted P did not halt and never would halt.

Really, then what have traces of this input being correctly simulated
been posted showing that it does reach the re tstatement.

Perhaps the problem is that you are using wrong definitions of what a
correct simulation is?

If you mean something besides the simulation that exactly duplicates the
behavor of the machine that the input rerpesents, you need to CLEARLY
state what you think the definition is and show why it is correct.

Note, just saying that you think it makes more sense isn't actually a
good reason.

>
> This conclusively proves that H(P,P)==0 to anyone that is merely
> a fully competent software engineer having the required prerequisites
> of C, x86, how C translates to x86, and what x86 emulation is.
>

No, it just shows that you don't know what the right definitions are.

> LIARS AND IDIOTS DENY THE TRUTH OF THIS
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction repeats this process we can know with complete
> certainty that the emulated P never reaches its find “ret” instruction,
> thus never halts.

OK, so you show your ignorance as to what a correct emulation of
assembly code is.

The is ZERO grounds for the "break" in your simulation, thus it is
INCORRECT, and your instance that it is "correct" proves you to be a liar.

The ONLY correct simulation of the input needs to show the exectution of
the eighth instruction too, since that is what the code IS.

You failure to see that shows that you just don't understand how
computers works.

>
> Because Ben very very persistently refused to confirm the truth of this
> I mistook him for a liar. When he acknowledged that he saw no evidence
> that it is not true I acknowledged that my attribution of liar was
> incorrect.
>
>
>>
>>> That's inherent in the way
>>> it is set up - it can only terminate if it detects that the series of
>>> nested
>>> simulations is non-terminating, in which case it becomes terminating.
>>
>> No, it terminates because it /incorrectly/ concludes that the nested
>> simulations are non-terminating.  PO's silly argument is that this
>> conclusion is not wrong because the nested simulations /would/ be
>> non-terminating if they were not terminated.  Go figure.
>>
>>> I don't think anyone has actually pointed that out before. It's not
>>> going to
>>> revolutionise computer science. But it is an interesting observation.
>>
>> Why would anyone want to point this out?  We know simulation can't be
>> used to decide halting, and we know that there are only two ways a
>> decider that tries to do so can be wrong.  Both come up every time this
>> is taught to a class of programmers.  (I've never taught it to a class
>> of mathematicians but I suspect the discussion would be very different.)
>>
>
>

On 6/2/22 2:47 PM, olcott wrote:
> On 6/2/2022 11:32 AM, Mike Terry wrote:
>> On 02/06/2022 12:19, Malcolm McLean wrote:
>>> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> And actually, what you have done is construct a simulating
>>>>> attempted halt
>>>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>>>> loop.
>>>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>>>> is involved, but that's not interesting.
>>>>> So you have actually achieved something of interest, if you could only
>>>>> recognise that.
>>>> What do you think is new or interesting here? I can't see anything new
>>>> or interesting here at all.
>>>>
>>> The "simulating halt decider" will fail when fed H_Hat, not because
>>> of the invert
>>> step, but because it can't solve the simulation of H. That's inherent
>>> in the way
>>> it is set up - it can only terminate if it detects that the series of
>>> nested
>>> simulations is non-terminating, in which case it becomes terminating.
>>
>> ..in which case it becomes terminating BECAUSE OF THE INVERT STEP.
>>
>
> AS I HAVE PROVEN MANY HUNDREDS OF TIMES THE SIMULATED INPUT TO H(P,P)
> NEVER REACHES THE INVERT STEP.

You hav shown that the PARTIAL simulation by H never reaches that step.

You CLAIM this is a correct simulation,

>
> It is an easily verified fact that the correctly simulated input to
> H(P,P) never reaches its "ret" instruction therefore even when the
> simulation is aborted P did not halt and never would halt.

Nope, LIE. FAIL.

>
> This conclusively proves that H(P,P)==0 to anyone that is merely
> a fully competent software engineer having the required prerequisites
> of C, x86, how C translates to x86, and what x86 emulation is.

Nope, LIE, FAIL.

>
> LIARS AND IDIOTS DENY THE TRUTH OF THIS
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction repeats this process we can know with complete
> certainty that the emulated P never reaches its find “ret” instruction,
> thus never halts.
>
>

YOU ARE THE LIAR because you use FALSE definitions.

It is actually completely true that a real correct simulation of the
input to HH(P,P) must match the behavior of P(P), and go through all the
instructions of the copy of H that P calls, and see that H abort its
simulation of ITS input, and returning its answer to the P that called
it, and that P reaching its "ret" instruction.

It is IMPOSSIBLE for H to do this, but that doesn't change the
definition of a CORRECT simulation.

The ONLY way that H can be a "Correct Simulator" is for it to NEVER
abort its simulation, and then if fails to answer. Yes, if THAT is your
H, then P(P) is non-halting, and H(P,P) returning zero WOULD have been a
right answer for the problem, but NOT correct behavior for the machine,
as we started with the premise that H didn't abort (or that it actual
was a correct simulator, which is the same thing).

You just show that you don't understand the meaning of the terms that
you use.

On 6/2/22 3:54 PM, olcott wrote:
> On 6/2/2022 2:00 PM, Ben wrote:
>> Andy Walker <anw@cuboid.co.uk> writes:
>>
>>> On 02/06/2022 17:21, Ben wrote:
>>>> [...]  We know simulation can't be
>>>> used to decide halting, and we know that there are only two ways a
>>>> decider that tries to do so can be wrong.  Both come up every time this
>>>> is taught to a class of programmers.  (I've never taught it to a class
>>>> of mathematicians but I suspect the discussion would be very
>>>> different.)
>>>
>>>     My first thought was "no, it's the same", but on reflexion, and
>>> AFAIR,
>>> our mathematicians simply accepted what I told them, which is
>>> essentially what
>>> is at
>>>
>>>     http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>
>>> [second half, but see esp the last paragraph] and
>>>
>>>     http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>
>> I see your notes are an explicit counterexample to PO's claims that
>> emulation is never considered!
>>
>
> For these cases, we can turn to our second weapon -- emulation. We want
> to know whether a program halts, so we try it. If it halts, then we know
> the answer. If it doesn't halt, then `it must be in a loop', so we
> monitor its state and `detect the loop'. Sadly, although this is in one
> sense correct, it is a false dichotomy. At any given moment as the
> emulation proceeds, we are in one of not two but three states: the
> program has halted, or it is looping, or it is still running and has not
> yet entered a loop. It's the third case that kills us -- we just have to
> keep going, and wait for one of the other two things to happen. The
> trouble is that it may be that neither of them ever happens -- which is
> why `it must be in a loop' was in quotes above.
>
> It is not considered correctly.
> (a) the program has halted
> (b) the program is still running
> (c) the program matched an infinite behavior pattern
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> H(P,P)==0 for the above behavior pattern. (The entire research scope)
>
>

And your problem is that while H is simulating its input H^, that H^ is
in the state (b) case, not state (c).

This is shown because if H THINKS that H^ has entered state (c), then
when we actually look that what H^ does, we see that after H has aborted
it, that an ACTUAL CORRECT simulation of this input that does continue
will see the H that this H^ is using also making that same (incorrect)
decision, aborting its simulation, and returning to H^ and then H^
entering state (a).

There is no ACTUAL finite pattern that H sees in its simulation of H^
applied to H^ that actually correctly matchs a correct "infinite behavor
pattern".

You just don't seem to be smart enough to understand this.

>>> [both lectures from a module that I gave many moons ago].  We got pretty
>>> bright students, among the top four or five cohorts in the UK at that
>>> time
>>> [1990s] [but that was our high point, even beating Oxford one year],
>>> and of
>>> course many of them went into IT as a career.  They found
>>> NP-completeness
>>> much harder than UTMs, HP and related stuff.
>>
>> We got pretty bright students too.  Bright students ask good questions
>> but eventually (rapidly even) settle the matter to their own
>> satisfaction.
>>
>> And I agree that complexity is more... complex.  The details become so
>> very significant in complexity theory.  One of the depressing things
>> about these endless threads is that this is not a complex theorem.
>>
>
>

On 6/2/2022 9:41 PM, Richard Damon wrote:
> On 6/2/22 7:45 PM, olcott wrote:
>> On 6/2/2022 6:38 PM, Mr Flibble wrote:
>>> On Thu, 2 Jun 2022 15:47:22 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/2/2022 1:12 PM, Andy Walker wrote:
>>>>> On 02/06/2022 17:21, Ben wrote:
>>>>>> [...]  We know simulation can't be
>>>>>> used to decide halting, and we know that there are only two ways a
>>>>>> decider that tries to do so can be wrong.  Both come up every time
>>>>>> this is taught to a class of programmers.  (I've never taught it
>>>>>> to a class of mathematicians but I suspect the discussion would be
>>>>>> very different.)
>>>>>
>>>>>       My first thought was "no, it's the same", but on reflexion,
>>>>> and AFAIR, our mathematicians simply accepted what I told them,
>>>>> which is essentially what
>>>>> is at
>>>>>
>>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>>>
>>>>> [second half, but see esp the last paragraph] and
>>>>>
>>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>>>
>>>>
>>>> For these cases, we can turn to our second weapon -- emulation. We
>>>> want to know whether a program halts, so we try it. If it halts, then
>>>> we know the answer. If it doesn't halt, then `it must be in a loop',
>>>> so we monitor its state and `detect the loop'. Sadly, although this
>>>> is in one sense correct, it is a false dichotomy. At any given moment
>>>> as the emulation proceeds, we are in one of not two but three states:
>>>> the program has halted, or it is looping, or it is still running and
>>>> has not yet entered a loop. It's the third case that kills us -- we
>>>> just have to keep going, and wait for one of the other two things to
>>>> happen. The trouble is that it may be that neither of them ever
>>>> happens -- which is why `it must be in a loop' was in quotes above.
>>>>
>>>> It is not considered correctly.
>>>> (a) the program has halted
>>>> (b) the program is still running
>>>> (c) the program matched an infinite behavior pattern
>>>>
>>>>        For any program H that might determine if programs halt, a
>>>> "pathological"
>>>>        program P, called with some input, can pass its own source and
>>>> its input to
>>>>        H and then specifically do the opposite of what H predicts P
>>>> will do. No H
>>>>        can exist that handles this case.
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> Any competent software engineer can verify that H(P,P)==0
>>>> for the above behavior pattern. (The entire research scope)
>>>> As detailed in my paper:
>>>>
>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>
>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>
>>>>
>>>
>>> The proofs you are attempting to refute do not contain the infinite
>>> behaviour pattern you describe;
>>
>> The correctly simulated input to a simulating halt decider never
>> reaches the final instruction of this simulated input thus is
>> unequivocally non-halting.
>
> You keep on saying that, but it isn't actually true for the PROPER
> definition of "correct simulation", that being, the simulation of the
> input by a UTM equiavlent. (or an x86 processor for your x86 code).
>
> What you want to call "correct simulation" is the partial simulation by
> a particular H, but partial simulation are NEVER "correct" because they
> are, by definitin=on, INCOMPLETE.
void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

In other words you keep saying the same cockamamy bullshit that it is
utterly impossible to correctly determine what a complete simulation
would be from a partial simulation.

This is the exactly same numbskull idea that it is utterly impossible to
determine that a loop is infinite until after waiting forever to see if
it stops running. *Why are you such a jackass?*

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

On Fri, 3 Jun 2022 16:08:34 -0500
olcott <polcott2@gmail.com> wrote:

> On 6/2/2022 9:41 PM, Richard Damon wrote:
> > On 6/2/22 7:45 PM, olcott wrote:
> >> On 6/2/2022 6:38 PM, Mr Flibble wrote:
> >>> On Thu, 2 Jun 2022 15:47:22 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/2/2022 1:12 PM, Andy Walker wrote:
> >>>>> On 02/06/2022 17:21, Ben wrote:
> >>>>>> [...]  We know simulation can't be
> >>>>>> used to decide halting, and we know that there are only two
> >>>>>> ways a decider that tries to do so can be wrong.  Both come up
> >>>>>> every time this is taught to a class of programmers.  (I've
> >>>>>> never taught it to a class of mathematicians but I suspect the
> >>>>>> discussion would be very different.)
> >>>>>
> >>>>>       My first thought was "no, it's the same", but on
> >>>>> reflexion, and AFAIR, our mathematicians simply accepted what I
> >>>>> told them, which is essentially what
> >>>>> is at
> >>>>>
> >>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect17.html
> >>>>>
> >>>>> [second half, but see esp the last paragraph] and
> >>>>>
> >>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect18.html
> >>>>
> >>>>
> >>>> For these cases, we can turn to our second weapon -- emulation.
> >>>> We want to know whether a program halts, so we try it. If it
> >>>> halts, then we know the answer. If it doesn't halt, then `it
> >>>> must be in a loop', so we monitor its state and `detect the
> >>>> loop'. Sadly, although this is in one sense correct, it is a
> >>>> false dichotomy. At any given moment as the emulation proceeds,
> >>>> we are in one of not two but three states: the program has
> >>>> halted, or it is looping, or it is still running and has not yet
> >>>> entered a loop. It's the third case that kills us -- we just
> >>>> have to keep going, and wait for one of the other two things to
> >>>> happen. The trouble is that it may be that neither of them ever
> >>>> happens -- which is why `it must be in a loop' was in quotes
> >>>> above.
> >>>>
> >>>> It is not considered correctly.
> >>>> (a) the program has halted
> >>>> (b) the program is still running
> >>>> (c) the program matched an infinite behavior pattern
> >>>>
> >>>>        For any program H that might determine if programs halt, a
> >>>> "pathological"
> >>>>        program P, called with some input, can pass its own
> >>>> source and its input to
> >>>>        H and then specifically do the opposite of what H
> >>>> predicts P will do. No H
> >>>>        can exist that handles this case.
> >>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>
> >>>> Any competent software engineer can verify that H(P,P)==0
> >>>> for the above behavior pattern. (The entire research scope)
> >>>> As detailed in my paper:
> >>>>
> >>>> Halting problem undecidability and infinitely nested simulation
> >>>> (V5)
> >>>>
> >>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >>>>
> >>>>
> >>>
> >>> The proofs you are attempting to refute do not contain the
> >>> infinite behaviour pattern you describe;
> >>
> >> The correctly simulated input to a simulating halt decider never
> >> reaches the final instruction of this simulated input thus is
> >> unequivocally non-halting.
> >
> > You keep on saying that, but it isn't actually true for the PROPER
> > definition of "correct simulation", that being, the simulation of
> > the input by a UTM equiavlent. (or an x86 processor for your x86
> > code).
> >
> > What you want to call "correct simulation" is the partial
> > simulation by a particular H, but partial simulation are NEVER
> > "correct" because they are, by definitin=on, INCOMPLETE.
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H0(Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001342](01) 55 push ebp
> [00001343](02) 8bec mov ebp,esp
> [00001345](02) ebfe jmp 00001345
> [00001347](01) 5d pop ebp
> [00001348](01) c3 ret
> Size in bytes:(0007) [00001348]
>
> In other words you keep saying the same cockamamy bullshit that it is
> utterly impossible to correctly determine what a complete simulation
> would be from a partial simulation.
>
> This is the exactly same numbskull idea that it is utterly impossible
> to determine that a loop is infinite until after waiting forever to
> see if it stops running. *Why are you such a jackass?*

Your "infinite loop" only starts if an infinite recursion is detected
however the proofs you are attempting to refute contain no such
infinite recursion so your "infinite loop" is irrelevant.

/Flibble