All of the recent discussions are simply disagreement with an easily
verifiable fact. Any smart software engineer with a sufficient technical
background can easily confirm that H(P,P)==0 is correct:

Where H is a C function that correctly emulates its input pair of finite
strings of the x86 machine code of function P and criterion for
returning 0 is that the simulated P would never reach its "ret" instruction.

(1) Good software engineering proves that H(P,P)==0 is correct.

The only other remaining objection is whether or not a halt decider must
compute the mapping of its input finite strings to an accept or reject
state on the basis of the actual behavior actually specified by its
input OR SOME OTHER MEASURE.

A decider must compute the mapping from its inputs finite strings to an
accept of reject state. A computable function must compute the mapping
of from inputs finite strings to its corresponding output.
https://en.wikipedia.org/wiki/Computable_function

(2) Good computer science shows that a halt decider must
compute the mapping from its input finite strings to an accept or
reject state on the basis of the actual behavior actually specified by
its input. Since P(P) is not an input to H(P,P) it is excluded.

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

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

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.

--
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 Tue, 24 May 2022 09:40:02 -0500
olcott <NoOne@NoWhere.com> wrote:

> All of the recent discussions are simply disagreement with an easily
> verifiable fact. Any smart software engineer with a sufficient
> technical background can easily confirm that H(P,P)==0 is correct:
>
> Where H is a C function that correctly emulates its input pair of
> finite strings of the x86 machine code of function P and criterion
> for returning 0 is that the simulated P would never reach its "ret"
> instruction.

The only reason P "never" reaches its "ret" instruction is because you
have introduced an infinite recursion that does not exist in the proofs
you are trying to refute, i.e. your H is erroneous.

/Flibble

On 5/24/2022 3:54 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 09:40:02 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> All of the recent discussions are simply disagreement with an easily
>> verifiable fact. Any smart software engineer with a sufficient
>> technical background can easily confirm that H(P,P)==0 is correct:
>>
>> Where H is a C function that correctly emulates its input pair of
>> finite strings of the x86 machine code of function P and criterion
>> for returning 0 is that the simulated P would never reach its "ret"
>> instruction.
>
> The only reason P "never" reaches its "ret" instruction is because you
> have introduced an infinite recursion that does not exist in the proofs
> you are trying to refute, i.e. your H is erroneous.
>
> /Flibble
>

For the time being I am only referring to when the C function named H
determines whether ore not its correct x86 emulation of the machine
language of P would ever reach the "ret" instruction of P in 0 to
infinity number of steps of correct x86 emulation.

_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]

--
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 Tue, 24 May 2022 16:12:13 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> > On Tue, 24 May 2022 09:40:02 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> All of the recent discussions are simply disagreement with an
> >> easily verifiable fact. Any smart software engineer with a
> >> sufficient technical background can easily confirm that H(P,P)==0
> >> is correct:
> >>
> >> Where H is a C function that correctly emulates its input pair of
> >> finite strings of the x86 machine code of function P and criterion
> >> for returning 0 is that the simulated P would never reach its "ret"
> >> instruction.
> >
> > The only reason P "never" reaches its "ret" instruction is because
> > you have introduced an infinite recursion that does not exist in
> > the proofs you are trying to refute, i.e. your H is erroneous.
> >
> > /Flibble
> >
>
> For the time being I am only referring to when the C function named H
> determines whether ore not its correct x86 emulation of the machine
> language of P would ever reach the "ret" instruction of P in 0 to
> infinity number of steps of correct x86 emulation.

You can't have it both ways: either H is supposed to be a decider or it
isn't; if it is a decider then it fails at that as you have introduced
an infinite recursion; if it isn't a decider and is merely a tool for
refuting the proofs then it fails at that too as the proofs you are
trying to refute do not contain an infinite recursion.

/Flibble

On 5/24/2022 4:27 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 16:12:13 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 09:40:02 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> All of the recent discussions are simply disagreement with an
>>>> easily verifiable fact. Any smart software engineer with a
>>>> sufficient technical background can easily confirm that H(P,P)==0
>>>> is correct:
>>>>
>>>> Where H is a C function that correctly emulates its input pair of
>>>> finite strings of the x86 machine code of function P and criterion
>>>> for returning 0 is that the simulated P would never reach its "ret"
>>>> instruction.
>>>
>>> The only reason P "never" reaches its "ret" instruction is because
>>> you have introduced an infinite recursion that does not exist in
>>> the proofs you are trying to refute, i.e. your H is erroneous.
>>>
>>> /Flibble
>>>
>>
>> For the time being I am only referring to when the C function named H
>> determines whether ore not its correct x86 emulation of the machine
>> language of P would ever reach the "ret" instruction of P in 0 to
>> infinity number of steps of correct x86 emulation.
>
> You can't have it both ways: either H is supposed to be a decider or it
> isn't; if it is a decider then it fails at that as you have introduced
> an infinite recursion; if it isn't a decider and is merely a tool for
> refuting the proofs then it fails at that too as the proofs you are
> trying to refute do not contain an infinite recursion.
>
> /Flibble
>

You have to actually stick with the words that I actually said as the
basis of any rebuttal.

It is an easily verified fact that the correct x86 emulation of the
input to H(P,P) would never reach the "ret" instruction of P in 0 to
infinity steps of the correct x86 emulation of P by H.

When you evaluate what I said according to those exact words instead of
rephrasing them as the deception of the strawman error then they are
proved to be correct.

--
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 Tue, 24 May 2022 16:34:12 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> > On Tue, 24 May 2022 16:12:13 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> >>> On Tue, 24 May 2022 09:40:02 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> All of the recent discussions are simply disagreement with an
> >>>> easily verifiable fact. Any smart software engineer with a
> >>>> sufficient technical background can easily confirm that H(P,P)==0
> >>>> is correct:
> >>>>
> >>>> Where H is a C function that correctly emulates its input pair of
> >>>> finite strings of the x86 machine code of function P and
> >>>> criterion for returning 0 is that the simulated P would never
> >>>> reach its "ret" instruction.
> >>>
> >>> The only reason P "never" reaches its "ret" instruction is because
> >>> you have introduced an infinite recursion that does not exist in
> >>> the proofs you are trying to refute, i.e. your H is erroneous.
> >>>
> >>> /Flibble
> >>>
> >>
> >> For the time being I am only referring to when the C function
> >> named H determines whether ore not its correct x86 emulation of
> >> the machine language of P would ever reach the "ret" instruction
> >> of P in 0 to infinity number of steps of correct x86 emulation.
> >
> > You can't have it both ways: either H is supposed to be a decider
> > or it isn't; if it is a decider then it fails at that as you have
> > introduced an infinite recursion; if it isn't a decider and is
> > merely a tool for refuting the proofs then it fails at that too as
> > the proofs you are trying to refute do not contain an infinite
> > recursion.
> >
> > /Flibble
> >
>
> You have to actually stick with the words that I actually said as the
> basis of any rebuttal.
>
> It is an easily verified fact that the correct x86 emulation of the
> input to H(P,P) would never reach the "ret" instruction of P in 0 to
> infinity steps of the correct x86 emulation of P by H.
>
> When you evaluate what I said according to those exact words instead
> of rephrasing them as the deception of the strawman error then they
> are proved to be correct.
You are now merely trying to obfuscate what H is; I wonder why you
do that? Is it because you realize you are wrong as far as the Halting
Problem and its proofs are concerned?

/Flibble

On 5/24/2022 4:40 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 16:34:12 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 16:12:13 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> All of the recent discussions are simply disagreement with an
>>>>>> easily verifiable fact. Any smart software engineer with a
>>>>>> sufficient technical background can easily confirm that H(P,P)==0
>>>>>> is correct:
>>>>>>
>>>>>> Where H is a C function that correctly emulates its input pair of
>>>>>> finite strings of the x86 machine code of function P and
>>>>>> criterion for returning 0 is that the simulated P would never
>>>>>> reach its "ret" instruction.
>>>>>
>>>>> The only reason P "never" reaches its "ret" instruction is because
>>>>> you have introduced an infinite recursion that does not exist in
>>>>> the proofs you are trying to refute, i.e. your H is erroneous.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> For the time being I am only referring to when the C function
>>>> named H determines whether ore not its correct x86 emulation of
>>>> the machine language of P would ever reach the "ret" instruction
>>>> of P in 0 to infinity number of steps of correct x86 emulation.
>>>
>>> You can't have it both ways: either H is supposed to be a decider
>>> or it isn't; if it is a decider then it fails at that as you have
>>> introduced an infinite recursion; if it isn't a decider and is
>>> merely a tool for refuting the proofs then it fails at that too as
>>> the proofs you are trying to refute do not contain an infinite
>>> recursion.
>>>
>>> /Flibble
>>>
>>
>> You have to actually stick with the words that I actually said as the
>> basis of any rebuttal.
>>
>> It is an easily verified fact that the correct x86 emulation of the
>> input to H(P,P) would never reach the "ret" instruction of P in 0 to
>> infinity steps of the correct x86 emulation of P by H.
>>
>> When you evaluate what I said according to those exact words instead
>> of rephrasing them as the deception of the strawman error then they
>> are proved to be correct.
>
> You are now merely trying to obfuscate what H is; I wonder why you
> do that? Is it because you realize you are wrong as far as the Halting
> Problem and its proofs are concerned?
>
> /Flibble
>

In software engineering terms:
H(P,P) correctly determines that its input never reaches its "ret"
instruction.

I can translate this to computer science terms yet will not do that
until after the software engineering has been accepted.

--
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 Tue, 24 May 2022 16:51:50 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/24/2022 4:40 PM, Mr Flibble wrote:
> > On Tue, 24 May 2022 16:34:12 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>> On Tue, 24 May 2022 16:12:13 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> >>>>> On Tue, 24 May 2022 09:40:02 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> All of the recent discussions are simply disagreement with an
> >>>>>> easily verifiable fact. Any smart software engineer with a
> >>>>>> sufficient technical background can easily confirm that
> >>>>>> H(P,P)==0 is correct:
> >>>>>>
> >>>>>> Where H is a C function that correctly emulates its input pair
> >>>>>> of finite strings of the x86 machine code of function P and
> >>>>>> criterion for returning 0 is that the simulated P would never
> >>>>>> reach its "ret" instruction.
> >>>>>
> >>>>> The only reason P "never" reaches its "ret" instruction is
> >>>>> because you have introduced an infinite recursion that does not
> >>>>> exist in the proofs you are trying to refute, i.e. your H is
> >>>>> erroneous.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> For the time being I am only referring to when the C function
> >>>> named H determines whether ore not its correct x86 emulation of
> >>>> the machine language of P would ever reach the "ret" instruction
> >>>> of P in 0 to infinity number of steps of correct x86 emulation.
> >>>
> >>> You can't have it both ways: either H is supposed to be a decider
> >>> or it isn't; if it is a decider then it fails at that as you have
> >>> introduced an infinite recursion; if it isn't a decider and is
> >>> merely a tool for refuting the proofs then it fails at that too as
> >>> the proofs you are trying to refute do not contain an infinite
> >>> recursion.
> >>>
> >>> /Flibble
> >>>
> >>
> >> You have to actually stick with the words that I actually said as
> >> the basis of any rebuttal.
> >>
> >> It is an easily verified fact that the correct x86 emulation of the
> >> input to H(P,P) would never reach the "ret" instruction of P in 0
> >> to infinity steps of the correct x86 emulation of P by H.
> >>
> >> When you evaluate what I said according to those exact words
> >> instead of rephrasing them as the deception of the strawman error
> >> then they are proved to be correct.
> >
> > You are now merely trying to obfuscate what H is; I wonder why you
> > do that? Is it because you realize you are wrong as far as the
> > Halting Problem and its proofs are concerned?
> >
> > /Flibble
> >
>
> In software engineering terms:
> H(P,P) correctly determines that its input never reaches its "ret"
> instruction.

As far as I can tell you have only shown that that is the case for the
limited scenario that involves you introducing a specious infinite
recursion, an infinite recursion not present in the proofs you are
attempting to refute.

>
> I can translate this to computer science terms yet will not do that
> until after the software engineering has been accepted.
Weasel words.

/Flibble

On 5/24/2022 4:56 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 16:51:50 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 16:34:12 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> All of the recent discussions are simply disagreement with an
>>>>>>>> easily verifiable fact. Any smart software engineer with a
>>>>>>>> sufficient technical background can easily confirm that
>>>>>>>> H(P,P)==0 is correct:
>>>>>>>>
>>>>>>>> Where H is a C function that correctly emulates its input pair
>>>>>>>> of finite strings of the x86 machine code of function P and
>>>>>>>> criterion for returning 0 is that the simulated P would never
>>>>>>>> reach its "ret" instruction.
>>>>>>>
>>>>>>> The only reason P "never" reaches its "ret" instruction is
>>>>>>> because you have introduced an infinite recursion that does not
>>>>>>> exist in the proofs you are trying to refute, i.e. your H is
>>>>>>> erroneous.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> For the time being I am only referring to when the C function
>>>>>> named H determines whether ore not its correct x86 emulation of
>>>>>> the machine language of P would ever reach the "ret" instruction
>>>>>> of P in 0 to infinity number of steps of correct x86 emulation.
>>>>>
>>>>> You can't have it both ways: either H is supposed to be a decider
>>>>> or it isn't; if it is a decider then it fails at that as you have
>>>>> introduced an infinite recursion; if it isn't a decider and is
>>>>> merely a tool for refuting the proofs then it fails at that too as
>>>>> the proofs you are trying to refute do not contain an infinite
>>>>> recursion.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> You have to actually stick with the words that I actually said as
>>>> the basis of any rebuttal.
>>>>
>>>> It is an easily verified fact that the correct x86 emulation of the
>>>> input to H(P,P) would never reach the "ret" instruction of P in 0
>>>> to infinity steps of the correct x86 emulation of P by H.
>>>>
>>>> When you evaluate what I said according to those exact words
>>>> instead of rephrasing them as the deception of the strawman error
>>>> then they are proved to be correct.
>>>
>>> You are now merely trying to obfuscate what H is; I wonder why you
>>> do that? Is it because you realize you are wrong as far as the
>>> Halting Problem and its proofs are concerned?
>>>
>>> /Flibble
>>>
>>
>> In software engineering terms:
>> H(P,P) correctly determines that its input never reaches its "ret"
>> instruction.
>
> As far as I can tell you have only shown that that is the case for the
> limited scenario that involves you introducing a specious infinite
> recursion, an infinite recursion not present in the proofs you are
> attempting to refute.

The concept of a halt decider that determines the halt status of its
input on the basis of watching the behavior of this input while it
simulates this input is novel yet not specious.

H(P,P) correctly determines that its input never reaches its "ret"
instruction. This is a verified fact that several God damned liars deny.

_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]

>>
>> I can translate this to computer science terms yet will not do that
>> until after the software engineering has been accepted.
>
> Weasel words.
>
> /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 Tue, 24 May 2022 17:04:15 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/24/2022 4:56 PM, Mr Flibble wrote:
> > On Tue, 24 May 2022 16:51:50 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/24/2022 4:40 PM, Mr Flibble wrote:
> >>> On Tue, 24 May 2022 16:34:12 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>>>> On Tue, 24 May 2022 16:12:13 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> >>>>>>> On Tue, 24 May 2022 09:40:02 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> All of the recent discussions are simply disagreement with an
> >>>>>>>> easily verifiable fact. Any smart software engineer with a
> >>>>>>>> sufficient technical background can easily confirm that
> >>>>>>>> H(P,P)==0 is correct:
> >>>>>>>>
> >>>>>>>> Where H is a C function that correctly emulates its input
> >>>>>>>> pair of finite strings of the x86 machine code of function P
> >>>>>>>> and criterion for returning 0 is that the simulated P would
> >>>>>>>> never reach its "ret" instruction.
> >>>>>>>
> >>>>>>> The only reason P "never" reaches its "ret" instruction is
> >>>>>>> because you have introduced an infinite recursion that does
> >>>>>>> not exist in the proofs you are trying to refute, i.e. your H
> >>>>>>> is erroneous.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> For the time being I am only referring to when the C function
> >>>>>> named H determines whether ore not its correct x86 emulation of
> >>>>>> the machine language of P would ever reach the "ret"
> >>>>>> instruction of P in 0 to infinity number of steps of correct
> >>>>>> x86 emulation.
> >>>>>
> >>>>> You can't have it both ways: either H is supposed to be a
> >>>>> decider or it isn't; if it is a decider then it fails at that
> >>>>> as you have introduced an infinite recursion; if it isn't a
> >>>>> decider and is merely a tool for refuting the proofs then it
> >>>>> fails at that too as the proofs you are trying to refute do not
> >>>>> contain an infinite recursion.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> You have to actually stick with the words that I actually said as
> >>>> the basis of any rebuttal.
> >>>>
> >>>> It is an easily verified fact that the correct x86 emulation of
> >>>> the input to H(P,P) would never reach the "ret" instruction of P
> >>>> in 0 to infinity steps of the correct x86 emulation of P by H.
> >>>>
> >>>> When you evaluate what I said according to those exact words
> >>>> instead of rephrasing them as the deception of the strawman error
> >>>> then they are proved to be correct.
> >>>
> >>> You are now merely trying to obfuscate what H is; I wonder why you
> >>> do that? Is it because you realize you are wrong as far as the
> >>> Halting Problem and its proofs are concerned?
> >>>
> >>> /Flibble
> >>>
> >>
> >> In software engineering terms:
> >> H(P,P) correctly determines that its input never reaches its "ret"
> >> instruction.
> >
> > As far as I can tell you have only shown that that is the case for
> > the limited scenario that involves you introducing a specious
> > infinite recursion, an infinite recursion not present in the proofs
> > you are attempting to refute.
>
> The concept of a halt decider that determines the halt status of its
> input on the basis of watching the behavior of this input while it
> simulates this input is novel yet not specious.

Novel? I sincerely doubt that the idea of using a simulator to
attempt to solve the halting problem was your idea. The simulation
approach was always doomed to failure; you think differently due to
your misunderstanding of the proofs you are attempting to refute.

/Flibble

On 5/24/2022 5:20 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 17:04:15 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/24/2022 4:56 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 16:51:50 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
>>>>> On Tue, 24 May 2022 16:34:12 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> All of the recent discussions are simply disagreement with an
>>>>>>>>>> easily verifiable fact. Any smart software engineer with a
>>>>>>>>>> sufficient technical background can easily confirm that
>>>>>>>>>> H(P,P)==0 is correct:
>>>>>>>>>>
>>>>>>>>>> Where H is a C function that correctly emulates its input
>>>>>>>>>> pair of finite strings of the x86 machine code of function P
>>>>>>>>>> and criterion for returning 0 is that the simulated P would
>>>>>>>>>> never reach its "ret" instruction.
>>>>>>>>>
>>>>>>>>> The only reason P "never" reaches its "ret" instruction is
>>>>>>>>> because you have introduced an infinite recursion that does
>>>>>>>>> not exist in the proofs you are trying to refute, i.e. your H
>>>>>>>>> is erroneous.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> For the time being I am only referring to when the C function
>>>>>>>> named H determines whether ore not its correct x86 emulation of
>>>>>>>> the machine language of P would ever reach the "ret"
>>>>>>>> instruction of P in 0 to infinity number of steps of correct
>>>>>>>> x86 emulation.
>>>>>>>
>>>>>>> You can't have it both ways: either H is supposed to be a
>>>>>>> decider or it isn't; if it is a decider then it fails at that
>>>>>>> as you have introduced an infinite recursion; if it isn't a
>>>>>>> decider and is merely a tool for refuting the proofs then it
>>>>>>> fails at that too as the proofs you are trying to refute do not
>>>>>>> contain an infinite recursion.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> You have to actually stick with the words that I actually said as
>>>>>> the basis of any rebuttal.
>>>>>>
>>>>>> It is an easily verified fact that the correct x86 emulation of
>>>>>> the input to H(P,P) would never reach the "ret" instruction of P
>>>>>> in 0 to infinity steps of the correct x86 emulation of P by H.
>>>>>>
>>>>>> When you evaluate what I said according to those exact words
>>>>>> instead of rephrasing them as the deception of the strawman error
>>>>>> then they are proved to be correct.
>>>>>
>>>>> You are now merely trying to obfuscate what H is; I wonder why you
>>>>> do that? Is it because you realize you are wrong as far as the
>>>>> Halting Problem and its proofs are concerned?
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> In software engineering terms:
>>>> H(P,P) correctly determines that its input never reaches its "ret"
>>>> instruction.
>>>
>>> As far as I can tell you have only shown that that is the case for
>>> the limited scenario that involves you introducing a specious
>>> infinite recursion, an infinite recursion not present in the proofs
>>> you are attempting to refute.
>>
>> The concept of a halt decider that determines the halt status of its
>> input on the basis of watching the behavior of this input while it
>> simulates this input is novel yet not specious.
>
> Novel? I sincerely doubt that the idea of using a simulator to
> attempt to solve the halting problem was your idea. The simulation
> approach was always doomed to failure; you think differently due to
> your misunderstanding of the proofs you are attempting to refute.
>
> /Flibble
>

Linz disregards the simulation ONLY approach on the basis that some
inputs never stop running. It never occurs to Linz to simulate the input
and compare the behavior of this input to known infinite behavior
patterns. To the best of my knowledge this is my brand new idea.

My work on this has been published for a year:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
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 Tue, 24 May 2022 17:25:40 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/24/2022 5:20 PM, Mr Flibble wrote:
> > On Tue, 24 May 2022 17:04:15 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/24/2022 4:56 PM, Mr Flibble wrote:
> >>> On Tue, 24 May 2022 16:51:50 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
> >>>>> On Tue, 24 May 2022 16:34:12 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>>>>>> On Tue, 24 May 2022 16:12:13 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> >>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> All of the recent discussions are simply disagreement with
> >>>>>>>>>> an easily verifiable fact. Any smart software engineer
> >>>>>>>>>> with a sufficient technical background can easily confirm
> >>>>>>>>>> that H(P,P)==0 is correct:
> >>>>>>>>>>
> >>>>>>>>>> Where H is a C function that correctly emulates its input
> >>>>>>>>>> pair of finite strings of the x86 machine code of function
> >>>>>>>>>> P and criterion for returning 0 is that the simulated P
> >>>>>>>>>> would never reach its "ret" instruction.
> >>>>>>>>>
> >>>>>>>>> The only reason P "never" reaches its "ret" instruction is
> >>>>>>>>> because you have introduced an infinite recursion that does
> >>>>>>>>> not exist in the proofs you are trying to refute, i.e. your
> >>>>>>>>> H is erroneous.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> For the time being I am only referring to when the C function
> >>>>>>>> named H determines whether ore not its correct x86 emulation
> >>>>>>>> of the machine language of P would ever reach the "ret"
> >>>>>>>> instruction of P in 0 to infinity number of steps of correct
> >>>>>>>> x86 emulation.
> >>>>>>>
> >>>>>>> You can't have it both ways: either H is supposed to be a
> >>>>>>> decider or it isn't; if it is a decider then it fails at that
> >>>>>>> as you have introduced an infinite recursion; if it isn't a
> >>>>>>> decider and is merely a tool for refuting the proofs then it
> >>>>>>> fails at that too as the proofs you are trying to refute do
> >>>>>>> not contain an infinite recursion.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> You have to actually stick with the words that I actually said
> >>>>>> as the basis of any rebuttal.
> >>>>>>
> >>>>>> It is an easily verified fact that the correct x86 emulation of
> >>>>>> the input to H(P,P) would never reach the "ret" instruction of
> >>>>>> P in 0 to infinity steps of the correct x86 emulation of P by
> >>>>>> H.
> >>>>>>
> >>>>>> When you evaluate what I said according to those exact words
> >>>>>> instead of rephrasing them as the deception of the strawman
> >>>>>> error then they are proved to be correct.
> >>>>>
> >>>>> You are now merely trying to obfuscate what H is; I wonder why
> >>>>> you do that? Is it because you realize you are wrong as far as
> >>>>> the Halting Problem and its proofs are concerned?
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> In software engineering terms:
> >>>> H(P,P) correctly determines that its input never reaches its
> >>>> "ret" instruction.
> >>>
> >>> As far as I can tell you have only shown that that is the case for
> >>> the limited scenario that involves you introducing a specious
> >>> infinite recursion, an infinite recursion not present in the
> >>> proofs you are attempting to refute.
> >>
> >> The concept of a halt decider that determines the halt status of
> >> its input on the basis of watching the behavior of this input
> >> while it simulates this input is novel yet not specious.
> >
> > Novel? I sincerely doubt that the idea of using a simulator to
> > attempt to solve the halting problem was your idea. The simulation
> > approach was always doomed to failure; you think differently due to
> > your misunderstanding of the proofs you are attempting to refute.
> >
> > /Flibble
> >
>
> Linz disregards the simulation ONLY approach on the basis that some
> inputs never stop running. It never occurs to Linz to simulate the
> input and compare the behavior of this input to known infinite
> behavior patterns. To the best of my knowledge this is my brand new
> idea.

The only pattern you have shown to detect is the erroneous infinite
recursion that you have yourself introduced; there are actually O(2^n)
patterns (n = machine "memory" size) and you have not shown that you
have a general solution for detecting every such pattern.

/Flibble

On 5/24/2022 5:30 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 17:25:40 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/24/2022 5:20 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 17:04:15 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/24/2022 4:56 PM, Mr Flibble wrote:
>>>>> On Tue, 24 May 2022 16:51:50 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
>>>>>>> On Tue, 24 May 2022 16:34:12 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> All of the recent discussions are simply disagreement with
>>>>>>>>>>>> an easily verifiable fact. Any smart software engineer
>>>>>>>>>>>> with a sufficient technical background can easily confirm
>>>>>>>>>>>> that H(P,P)==0 is correct:
>>>>>>>>>>>>
>>>>>>>>>>>> Where H is a C function that correctly emulates its input
>>>>>>>>>>>> pair of finite strings of the x86 machine code of function
>>>>>>>>>>>> P and criterion for returning 0 is that the simulated P
>>>>>>>>>>>> would never reach its "ret" instruction.
>>>>>>>>>>>
>>>>>>>>>>> The only reason P "never" reaches its "ret" instruction is
>>>>>>>>>>> because you have introduced an infinite recursion that does
>>>>>>>>>>> not exist in the proofs you are trying to refute, i.e. your
>>>>>>>>>>> H is erroneous.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> For the time being I am only referring to when the C function
>>>>>>>>>> named H determines whether ore not its correct x86 emulation
>>>>>>>>>> of the machine language of P would ever reach the "ret"
>>>>>>>>>> instruction of P in 0 to infinity number of steps of correct
>>>>>>>>>> x86 emulation.
>>>>>>>>>
>>>>>>>>> You can't have it both ways: either H is supposed to be a
>>>>>>>>> decider or it isn't; if it is a decider then it fails at that
>>>>>>>>> as you have introduced an infinite recursion; if it isn't a
>>>>>>>>> decider and is merely a tool for refuting the proofs then it
>>>>>>>>> fails at that too as the proofs you are trying to refute do
>>>>>>>>> not contain an infinite recursion.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> You have to actually stick with the words that I actually said
>>>>>>>> as the basis of any rebuttal.
>>>>>>>>
>>>>>>>> It is an easily verified fact that the correct x86 emulation of
>>>>>>>> the input to H(P,P) would never reach the "ret" instruction of
>>>>>>>> P in 0 to infinity steps of the correct x86 emulation of P by
>>>>>>>> H.
>>>>>>>>
>>>>>>>> When you evaluate what I said according to those exact words
>>>>>>>> instead of rephrasing them as the deception of the strawman
>>>>>>>> error then they are proved to be correct.
>>>>>>>
>>>>>>> You are now merely trying to obfuscate what H is; I wonder why
>>>>>>> you do that? Is it because you realize you are wrong as far as
>>>>>>> the Halting Problem and its proofs are concerned?
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> In software engineering terms:
>>>>>> H(P,P) correctly determines that its input never reaches its
>>>>>> "ret" instruction.
>>>>>
>>>>> As far as I can tell you have only shown that that is the case for
>>>>> the limited scenario that involves you introducing a specious
>>>>> infinite recursion, an infinite recursion not present in the
>>>>> proofs you are attempting to refute.
>>>>
>>>> The concept of a halt decider that determines the halt status of
>>>> its input on the basis of watching the behavior of this input
>>>> while it simulates this input is novel yet not specious.
>>>
>>> Novel? I sincerely doubt that the idea of using a simulator to
>>> attempt to solve the halting problem was your idea. The simulation
>>> approach was always doomed to failure; you think differently due to
>>> your misunderstanding of the proofs you are attempting to refute.
>>>
>>> /Flibble
>>>
>>
>> Linz disregards the simulation ONLY approach on the basis that some
>> inputs never stop running. It never occurs to Linz to simulate the
>> input and compare the behavior of this input to known infinite
>> behavior patterns. To the best of my knowledge this is my brand new
>> idea.
>
> The only pattern you have shown to detect is the erroneous infinite
> recursion that you have yourself introduced;

It is not erroneous infinite recursion it is the actual nested
simulation that does occur when one uses a simulating halt decider.

> there are actually O(2^n)
> patterns (n = machine "memory" size) and you have not shown that you
> have a general solution for detecting every such pattern.
>
> /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

Peter Olcott wrote:
> On 5/24/2022 5:30 PM, Mr Flibble wrote:
>> On Tue, 24 May 2022 17:25:40 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 5/24/2022 5:20 PM, Mr Flibble wrote:
>>>> On Tue, 24 May 2022 17:04:15 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 5/24/2022 4:56 PM, Mr Flibble wrote:
>>>>>> On Tue, 24 May 2022 16:51:50 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
>>>>>>>> On Tue, 24 May 2022 16:34:12 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> All of the recent discussions are simply disagreement with
>>>>>>>>>>>>> an easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>> with a sufficient technical background can easily confirm
>>>>>>>>>>>>> that H(P,P)==0 is correct:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Where H is a C function that correctly emulates its input
>>>>>>>>>>>>> pair of finite strings of the x86 machine code of function
>>>>>>>>>>>>> P and criterion for returning 0 is that the simulated P
>>>>>>>>>>>>> would never reach its "ret" instruction.
>>>>>>>>>>>>
>>>>>>>>>>>> The only reason P "never" reaches its "ret" instruction is
>>>>>>>>>>>> because you have introduced an infinite recursion that does
>>>>>>>>>>>> not exist in the proofs you are trying to refute, i.e. your
>>>>>>>>>>>> H is erroneous.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> For the time being I am only referring to when the C function
>>>>>>>>>>> named H determines whether ore not its correct x86 emulation
>>>>>>>>>>> of the machine language of P would ever reach the "ret"
>>>>>>>>>>> instruction of P in 0 to infinity number of steps of correct
>>>>>>>>>>> x86 emulation.
>>>>>>>>>>
>>>>>>>>>> You can't have it both ways: either H is supposed to be a
>>>>>>>>>> decider or it isn't; if it is a decider then it fails at that
>>>>>>>>>> as you have introduced an infinite recursion; if it isn't a
>>>>>>>>>> decider and is merely a tool for refuting the proofs then it
>>>>>>>>>> fails at that too as the proofs you are trying to refute do
>>>>>>>>>> not contain an infinite recursion.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> You have to actually stick with the words that I actually said
>>>>>>>>> as the basis of any rebuttal.
>>>>>>>>>
>>>>>>>>> It is an easily verified fact that the correct x86 emulation of
>>>>>>>>> the input to H(P,P) would never reach the "ret" instruction of
>>>>>>>>> P in 0 to infinity steps of the correct x86 emulation of P by
>>>>>>>>> H.
>>>>>>>>>
>>>>>>>>> When you evaluate what I said according to those exact words
>>>>>>>>> instead of rephrasing them as the deception of the strawman
>>>>>>>>> error then they are proved to be correct.
>>>>>>>> You are now merely trying to obfuscate what H is; I wonder why
>>>>>>>> you do that? Is it because you realize you are wrong as far as
>>>>>>>> the Halting Problem and its proofs are concerned?
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> In software engineering terms:
>>>>>>> H(P,P) correctly determines that its input never reaches its
>>>>>>> "ret" instruction.
>>>>>>
>>>>>> As far as I can tell you have only shown that that is the case for
>>>>>> the limited scenario that involves you introducing a specious
>>>>>> infinite recursion, an infinite recursion not present in the
>>>>>> proofs you are attempting to refute.
>>>>>
>>>>> The concept of a halt decider that determines the halt status of
>>>>> its input on the basis of watching the behavior of this input
>>>>> while it simulates this input is novel yet not specious.
>>>>
>>>> Novel? I sincerely doubt that the idea of using a simulator to
>>>> attempt to solve the halting problem was your idea.  The simulation
>>>> approach was always doomed to failure; you think differently due to
>>>> your misunderstanding of the proofs you are attempting to refute.
>>>>
>>>> /Flibble
>>>
>>> Linz disregards the simulation ONLY approach on the basis that some
>>> inputs never stop running. It never occurs to Linz to simulate the
>>> input and compare the behavior of this input to known infinite
>>> behavior patterns. To the best of my knowledge this is my brand new
>>> idea.
>>
>> The only pattern you have shown to detect is the erroneous infinite
>> recursion that you have yourself introduced;
>
> It is not erroneous infinite recursion it is the actual nested
> simulation that does occur when one uses a simulating halt decider.

So you're not only a despicable lyer, Peter, you're an idiot too..

Have an happy end-of-life :-)

On 5/24/2022 5:52 PM, Python wrote:
> Peter Olcott wrote:
>> On 5/24/2022 5:30 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 17:25:40 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/24/2022 5:20 PM, Mr Flibble wrote:
>>>>> On Tue, 24 May 2022 17:04:15 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>> On 5/24/2022 4:56 PM, Mr Flibble wrote:
>>>>>>> On Tue, 24 May 2022 16:51:50 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
>>>>>>>>> On Tue, 24 May 2022 16:34:12 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>> All of the recent discussions are simply disagreement with
>>>>>>>>>>>>>> an easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>> with a sufficient technical background can easily confirm
>>>>>>>>>>>>>> that H(P,P)==0 is correct:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Where H is a C function that correctly emulates its input
>>>>>>>>>>>>>> pair of finite strings of the x86 machine code of function
>>>>>>>>>>>>>> P and criterion for returning 0 is that the simulated P
>>>>>>>>>>>>>> would never reach its "ret" instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only reason P "never" reaches its "ret" instruction is
>>>>>>>>>>>>> because you have introduced an infinite recursion that does
>>>>>>>>>>>>> not exist in the proofs you are trying to refute, i.e. your
>>>>>>>>>>>>> H is erroneous.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> For the time being I am only referring to when the C function
>>>>>>>>>>>> named H determines whether ore not its correct x86 emulation
>>>>>>>>>>>> of the machine language of P would ever reach the "ret"
>>>>>>>>>>>> instruction of P in 0 to infinity number of steps of correct
>>>>>>>>>>>> x86 emulation.
>>>>>>>>>>>
>>>>>>>>>>> You can't have it both ways: either H is supposed to be a
>>>>>>>>>>> decider or it isn't; if it is a decider then it fails at that
>>>>>>>>>>> as you have introduced an infinite recursion; if it isn't a
>>>>>>>>>>> decider and is merely a tool for refuting the proofs then it
>>>>>>>>>>> fails at that too as the proofs you are trying to refute do
>>>>>>>>>>> not contain an infinite recursion.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> You have to actually stick with the words that I actually said
>>>>>>>>>> as the basis of any rebuttal.
>>>>>>>>>>
>>>>>>>>>> It is an easily verified fact that the correct x86 emulation of
>>>>>>>>>> the input to H(P,P) would never reach the "ret" instruction of
>>>>>>>>>> P in 0 to infinity steps of the correct x86 emulation of P by
>>>>>>>>>> H.
>>>>>>>>>>
>>>>>>>>>> When you evaluate what I said according to those exact words
>>>>>>>>>> instead of rephrasing them as the deception of the strawman
>>>>>>>>>> error then they are proved to be correct.
>>>>>>>>> You are now merely trying to obfuscate what H is; I wonder why
>>>>>>>>> you do that? Is it because you realize you are wrong as far as
>>>>>>>>> the Halting Problem and its proofs are concerned?
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> In software engineering terms:
>>>>>>>> H(P,P) correctly determines that its input never reaches its
>>>>>>>> "ret" instruction.
>>>>>>>
>>>>>>> As far as I can tell you have only shown that that is the case for
>>>>>>> the limited scenario that involves you introducing a specious
>>>>>>> infinite recursion, an infinite recursion not present in the
>>>>>>> proofs you are attempting to refute.
>>>>>>
>>>>>> The concept of a halt decider that determines the halt status of
>>>>>> its input on the basis of watching the behavior of this input
>>>>>> while it simulates this input is novel yet not specious.
>>>>>
>>>>> Novel? I sincerely doubt that the idea of using a simulator to
>>>>> attempt to solve the halting problem was your idea.  The simulation
>>>>> approach was always doomed to failure; you think differently due to
>>>>> your misunderstanding of the proofs you are attempting to refute.
>>>>>
>>>>> /Flibble
>>>>
>>>> Linz disregards the simulation ONLY approach on the basis that some
>>>> inputs never stop running. It never occurs to Linz to simulate the
>>>> input and compare the behavior of this input to known infinite
>>>> behavior patterns. To the best of my knowledge this is my brand new
>>>> idea.
>>>
>>> The only pattern you have shown to detect is the erroneous infinite
>>> recursion that you have yourself introduced;
>>
>> It is not erroneous infinite recursion it is the actual nested
>> simulation that does occur when one uses a simulating halt decider.
>
> So you're not only a despicable lyer, Peter, you're an idiot too..
>
> Have an happy end-of-life :-)

Your karma will catch up to you.

--
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 5/24/22 10:40 AM, olcott wrote:
> All of the recent discussions are simply disagreement with an easily
> verifiable fact. Any smart software engineer with a sufficient technical
> background can easily confirm that H(P,P)==0 is correct:

This is an incorrect statement, showable by the fact that NO "Smart
Software Engineers" have agreed with you, thus you prove your claim to
be a lie.

It has been shown that it is easy to verify that H(P,P) is NOT correct,
when you actually use the DEFINITIONS that apply, which you fail to do.

>
> Where H is a C function that correctly emulates its input pair of finite
> strings of the x86 machine code of function P and criterion for
> returning 0 is that the simulated P would never reach its "ret"
> instruction.

No, H does NOT correctly emulate its input, as it aborts it before it
reaches its end, so you claim is just a lie, showing that you don't know
what you are talking about.

The fact that YOU have previously posted a CORRECT trace of the input to
H(P,P) showing that it halts, is proof that you are wrong.

>
> (1) Good software engineering proves that H(P,P)==0 is correct.

WHAT "Good software engineering?" Faulty traces?

>
> The only other remaining objection is whether or not a halt decider must
> compute the mapping of its input finite strings to an accept or reject
> state on the basis of the actual behavior actually specified by its
> input OR SOME OTHER MEASURE.

Since the DEFINITION of the behavior of the input to H(P,P), is the
behaior of P(P), which can be verified with UTM(P,P) (and actual correct
emulatior with the same input) shows you are wrong.

>
> A decider must compute the mapping from its inputs finite strings to an
> accept of reject state. A computable function must compute the mapping
> of from inputs finite strings to its corresponding output.
> https://en.wikipedia.org/wiki/Computable_function

Right, and to be a "Something" decider, that mapping must be the
"Something" function, and the Halting FUnction is based the behavior of
a machine applied to an input. The attempted Halt Decider being given a
representation of these to decide on.

>
> (2) Good computer science shows that a halt decider must
> compute the mapping from its input finite strings to an accept or
> reject state on the basis of the actual behavior actually specified by
> its input. Since P(P) is not an input to H(P,P) it is excluded.
>
>

Except that the representation of it IS the input, and the fact that
UTM(P,P) can get the desired behavior show that it can be the behavior
of that input. The problem is that H can do it in finite time, and so
fails to be a decider.

>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>

A bunch of lies and faulty logic.

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 THINK this is established, which shows how little you understand.

Go ahead, write the paper and submit it.

On 5/24/22 5:12 PM, olcott wrote:
> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>> On Tue, 24 May 2022 09:40:02 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> All of the recent discussions are simply disagreement with an easily
>>> verifiable fact. Any smart software engineer with a sufficient
>>> technical background can easily confirm that H(P,P)==0 is correct:
>>>
>>> Where H is a C function that correctly emulates its input pair of
>>> finite strings of the x86 machine code of function P and criterion
>>> for returning 0 is that the simulated P would never reach its "ret"
>>> instruction.
>>
>> The only reason P "never" reaches its "ret" instruction is because you
>> have introduced an infinite recursion that does not exist in the proofs
>> you are trying to refute, i.e. your H is erroneous.
>>
>> /Flibble
>>
>
> For the time being I am only referring to when the C function named H
> determines whether ore not its correct x86 emulation of the machine
> language of P would ever reach the "ret" instruction of P in 0 to
> infinity number of steps of correct x86 emulation.
>
> _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]
>
>

And you P is incomplete, as you haven't include its copy of H.

A proper simulation of this input is an abort at the call 000011a2 for
going to an undefined memory location.

Remember, Computations aren't allowed to depend on ANYTHING other than
their defined input. Thus P gets ONE parameter, the machine it is to
work on.

In YOUR case, you seem to have a second parameter, the function "H" at
address 000011a2, so your P isn't the P of Linz, etc.

You have shown a basic inability to follow the requrements.

On 5/24/22 5:34 PM, olcott wrote:
> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>> On Tue, 24 May 2022 16:12:13 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> All of the recent discussions are simply disagreement with an
>>>>> easily verifiable fact. Any smart software engineer with a
>>>>> sufficient technical background can easily confirm that H(P,P)==0
>>>>> is correct:
>>>>>
>>>>> Where H is a C function that correctly emulates its input pair of
>>>>> finite strings of the x86 machine code of function P and criterion
>>>>> for returning 0 is that the simulated P would never reach its "ret"
>>>>> instruction.
>>>>
>>>> The only reason P "never" reaches its "ret" instruction is because
>>>> you have introduced an infinite recursion that does not exist in
>>>> the proofs you are trying to refute, i.e. your H is erroneous.
>>>>
>>>> /Flibble
>>>
>>> For the time being I am only referring to when the C function named H
>>> determines whether ore not its correct x86 emulation of the machine
>>> language of P would ever reach the "ret" instruction of P in 0 to
>>> infinity number of steps of correct x86 emulation.
>>
>> You can't have it both ways: either H is supposed to be a decider or it
>> isn't; if it is a decider then it fails at that as you have introduced
>> an infinite recursion; if it isn't a decider and is merely a tool for
>> refuting the proofs then it fails at that too as the proofs you are
>> trying to refute do not contain an infinite recursion.
>>
>> /Flibble
>>
>
> You have to actually stick with the words that I actually said as the
> basis of any rebuttal.
>
> It is an easily verified fact that the correct x86 emulation of the
> input to H(P,P) would never reach the "ret" instruction of P in 0 to
> infinity steps of the correct x86 emulation of P by H.

Since you have posted a trace which shows this happening, you know this
is a lie.

Yes, H can't simulate to there, but a CORRECT simulator can.

>
> When you evaluate what I said according to those exact words instead of
> rephrasing them as the deception of the strawman error then they are
> proved to be correct.
>
>

Nope, you are proved to be a liar.

On 5/24/22 6:04 PM, olcott wrote:
> On 5/24/2022 4:56 PM, Mr Flibble wrote:
>> On Tue, 24 May 2022 16:51:50 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
>>>> On Tue, 24 May 2022 16:34:12 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> All of the recent discussions are simply disagreement with an
>>>>>>>>> easily verifiable fact. Any smart software engineer with a
>>>>>>>>> sufficient technical background can easily confirm that
>>>>>>>>> H(P,P)==0 is correct:
>>>>>>>>>
>>>>>>>>> Where H is a C function that correctly emulates its input pair
>>>>>>>>> of finite strings of the x86 machine code of function P and
>>>>>>>>> criterion for returning 0 is that the simulated P would never
>>>>>>>>> reach its "ret" instruction.
>>>>>>>>
>>>>>>>> The only reason P "never" reaches its "ret" instruction is
>>>>>>>> because you have introduced an infinite recursion that does not
>>>>>>>> exist in the proofs you are trying to refute, i.e. your H is
>>>>>>>> erroneous.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> For the time being I am only referring to when the C function
>>>>>>> named H determines whether ore not its correct x86 emulation of
>>>>>>> the machine language of P would ever reach the "ret" instruction
>>>>>>> of P in 0 to infinity number of steps of correct x86 emulation.
>>>>>>
>>>>>> You can't have it both ways: either H is supposed to be a decider
>>>>>> or it isn't; if it is a decider then it fails at that as you have
>>>>>> introduced an infinite recursion; if it isn't a decider and is
>>>>>> merely a tool for refuting the proofs then it fails at that too as
>>>>>> the proofs you are trying to refute do not contain an infinite
>>>>>> recursion.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> You have to actually stick with the words that I actually said as
>>>>> the basis of any rebuttal.
>>>>>
>>>>> It is an easily verified fact that the correct x86 emulation of the
>>>>> input to H(P,P) would never reach the "ret" instruction of P in 0
>>>>> to infinity steps of the correct x86 emulation of P by H.
>>>>>
>>>>> When you evaluate what I said according to those exact words
>>>>> instead of rephrasing them as the deception of the strawman error
>>>>> then they are proved to be correct.
>>>> You are now merely trying to obfuscate what H is; I wonder why you
>>>> do that? Is it because you realize you are wrong as far as the
>>>> Halting Problem and its proofs are concerned?
>>>>
>>>> /Flibble
>>>
>>> In software engineering terms:
>>> H(P,P) correctly determines that its input never reaches its "ret"
>>> instruction.
>>
>> As far as I can tell you have only shown that that is the case for the
>> limited scenario that involves you introducing a specious infinite
>> recursion, an infinite recursion not present in the proofs you are
>> attempting to refute.
>
> The concept of a halt decider that determines the halt status of its
> input on the basis of watching the behavior of this input while it
> simulates this input is novel yet not specious.
>
> H(P,P) correctly determines that its input never reaches its "ret"
> instruction. This is a verified fact that several God damned liars deny.
>

No, it doesn't, because it doesn't use sound logic. It assumes the H
that P calls will never abort, when it will (since this one does)

Olcott is thus proven to be a Liar or an idiot.

> _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]
>
>
>>>
>>> I can translate this to computer science terms yet will not do that
>>> until after the software engineering has been accepted.
>> Weasel words.
>>
>> /Flibble
>>
>
>

On 5/24/2022 8:11 PM, Richard Damon wrote:
> On 5/24/22 5:12 PM, olcott wrote:
>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 09:40:02 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> All of the recent discussions are simply disagreement with an easily
>>>> verifiable fact. Any smart software engineer with a sufficient
>>>> technical background can easily confirm that H(P,P)==0 is correct:
>>>>
>>>> Where H is a C function that correctly emulates its input pair of
>>>> finite strings of the x86 machine code of function P and criterion
>>>> for returning 0 is that the simulated P would never reach its "ret"
>>>> instruction.
>>>
>>> The only reason P "never" reaches its "ret" instruction is because you
>>> have introduced an infinite recursion that does not exist in the proofs
>>> you are trying to refute, i.e. your H is erroneous.
>>>
>>> /Flibble
>>>
>>
>> For the time being I am only referring to when the C function named H
>> determines whether ore not its correct x86 emulation of the machine
>> language of P would ever reach the "ret" instruction of P in 0 to
>> infinity number of steps of correct x86 emulation.
>>
>> _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]
>>
>>
>
> And you P is incomplete, as you haven't include its copy of H.
>

People that are sufficiently technically competent would be able to
understand:

It is an easily verified fact that the correct x86 emulation of the
input to H(P,P) would never reach the "ret" instruction of P in 0 to
infinity steps of the correct x86 emulation of P by H.

This absolutely includes Dennis he is rated in the top 0.04% on Stack
Exchange.

--
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 5/24/2022 8:12 PM, Richard Damon wrote:
>
> On 5/24/22 5:34 PM, olcott wrote:
>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 16:12:13 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>> All of the recent discussions are simply disagreement with an
>>>>>> easily verifiable fact. Any smart software engineer with a
>>>>>> sufficient technical background can easily confirm that H(P,P)==0
>>>>>> is correct:
>>>>>>
>>>>>> Where H is a C function that correctly emulates its input pair of
>>>>>> finite strings of the x86 machine code of function P and criterion
>>>>>> for returning 0 is that the simulated P would never reach its "ret"
>>>>>> instruction.
>>>>>
>>>>> The only reason P "never" reaches its "ret" instruction is because
>>>>> you have introduced an infinite recursion that does not exist in
>>>>> the proofs you are trying to refute, i.e. your H is erroneous.
>>>>>
>>>>> /Flibble
>>>>
>>>> For the time being I am only referring to when the C function named H
>>>> determines whether ore not its correct x86 emulation of the machine
>>>> language of P would ever reach the "ret" instruction of P in 0 to
>>>> infinity number of steps of correct x86 emulation.
>>>
>>> You can't have it both ways: either H is supposed to be a decider or it
>>> isn't; if it is a decider then it fails at that as you have introduced
>>> an infinite recursion; if it isn't a decider and is merely a tool for
>>> refuting the proofs then it fails at that too as the proofs you are
>>> trying to refute do not contain an infinite recursion.
>>>
>>> /Flibble
>>>
>>
>> You have to actually stick with the words that I actually said as the
>> basis of any rebuttal.
>>
>> It is an easily verified fact that the correct x86 emulation of the
>> input to H(P,P) would never reach the "ret" instruction of P in 0 to
>> infinity steps of the correct x86 emulation of P by H.
>
> Since you have posted a trace which shows this happening, you know this
> is a lie.
>
> Yes, H can't simulate to there, but a CORRECT simulator can.

H makes no mistakes in its simulation. Every instruction that H
simulates is exactly what the x86 source-code for P specifies.

The only possible way for a simulator to actually be incorrect is that
its simulation diverges from what the x86 source-code of P specifies.

That Simulate(P,P) does not have the same halting behavior as the
correct simulation of the input to H(P,P) does not mean that either one
of them is incorrect.

In both cases both simulations are correct because they each simulate
exactly what the x86 source-code of P specifies.

>>
>> When you evaluate what I said according to those exact words instead
>> of rephrasing them as the deception of the strawman error then they
>> are proved to be correct.
>>
>>
>
> Nope, you are proved to be a liar.

--
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 5/24/22 9:33 PM, olcott wrote:
> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>
>> On 5/24/22 5:34 PM, olcott wrote:
>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> All of the recent discussions are simply disagreement with an
>>>>>>> easily verifiable fact. Any smart software engineer with a
>>>>>>> sufficient technical background can easily confirm that H(P,P)==0
>>>>>>> is correct:
>>>>>>>
>>>>>>> Where H is a C function that correctly emulates its input pair of
>>>>>>> finite strings of the x86 machine code of function P and criterion
>>>>>>> for returning 0 is that the simulated P would never reach its "ret"
>>>>>>> instruction.
>>>>>>
>>>>>> The only reason P "never" reaches its "ret" instruction is because
>>>>>> you have introduced an infinite recursion that does not exist in
>>>>>> the proofs you are trying to refute, i.e. your H is erroneous.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> For the time being I am only referring to when the C function named H
>>>>> determines whether ore not its correct x86 emulation of the machine
>>>>> language of P would ever reach the "ret" instruction of P in 0 to
>>>>> infinity number of steps of correct x86 emulation.
>>>>
>>>> You can't have it both ways: either H is supposed to be a decider or it
>>>> isn't; if it is a decider then it fails at that as you have introduced
>>>> an infinite recursion; if it isn't a decider and is merely a tool for
>>>> refuting the proofs then it fails at that too as the proofs you are
>>>> trying to refute do not contain an infinite recursion.
>>>>
>>>> /Flibble
>>>>
>>>
>>> You have to actually stick with the words that I actually said as the
>>> basis of any rebuttal.
>>>
>>> It is an easily verified fact that the correct x86 emulation of the
>>> input to H(P,P) would never reach the "ret" instruction of P in 0 to
>>> infinity steps of the correct x86 emulation of P by H.
>>
>> Since you have posted a trace which shows this happening, you know
>> this is a lie.
>>
>> Yes, H can't simulate to there, but a CORRECT simulator can.
>
> H makes no mistakes in its simulation. Every instruction that H
> simulates is exactly what the x86 source-code for P specifies.

Yes, but it doesn't complete the simulation because it INCORRECTLY
decides that the input would be non-halting.

Because of the design of P, this is true for ANY Halt Decider that trys
to decide on the version of P built on it. (Other Halt Deciders can
possibly get it correct).

THe problem is that there is NO rule that H can use to correctly decide
on this input (the P built on this H, being applied to a description of
itself).

>
> The only possible way for a simulator to actually be incorrect is that
> its simulation diverges from what the x86 source-code of P specifies.

Nope, it needs to diverge from the behavior of the PROGRAM given to it,
and the subroutine P is not a "Program".

Either the decider needs to reject P as not a program because it doens't
include a copy of the function H that is calls, or it needs to consider
that function H as part of its input.

If we include that H as part of its input, then that H must have a
SPECIFIC algorithm, and a CORRECT simulation of that input, INCLUDING
THAT H, will ALWAYS Halt if H(P,P) returns 0.

>
> That Simulate(P,P) does not have the same halting behavior as the
> correct simulation of the input to H(P,P) does not mean that either one
> of them is incorrect.

WRONG. It is the EXACT SAME INPUT, so as far as program simuation, they
need to generate the exact same results.

The problem is H doesn't consider its own code correctly, and thus is
INCORRECT.

>
> In both cases both simulations are correct because they each simulate
> exactly what the x86 source-code of P specifies.

the source code of P & H (or it needs to say the P isn't a program)

You just don't seem to understand what a PROGRAM is, it seems.

Are you sure your a programmer?

>
>>>
>>> When you evaluate what I said according to those exact words instead
>>> of rephrasing them as the deception of the strawman error then they
>>> are proved to be correct.
>>>
>>>
>>
>> Nope, you are proved to be a liar.
>
>