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.
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 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 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 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.
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.
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.
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 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.
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.
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 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 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.
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
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]
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:You are now merely trying to obfuscate what H is; I wonder why you
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.
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]
Weasel words.
I can translate this to computer science terms yet will not do that
until after the software engineering has been accepted.
/Flibble
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.
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.
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
H_Hat((u32)H_Hat);
}
_H_Hat()
[00000b98](01) 55 push ebp
[00000b99](02) 8bec mov ebp,esp
[00000b9c](03) 8b4508 mov eax,[ebp+08]
[00000b9f](01) 50 push eax
[00000ba0](03) 8b4d08 mov ecx,[ebp+08]
[00000ba3](01) 51 push ecx
[00000ba4](05) e88ffdffff call 00000938
[00000ba9](03) 83c408 add esp,+08
[00000bac](03) 8945fc mov [ebp-04],eax
[00000baf](04) 837dfc00 cmp dword [ebp-04],+00
[00000bb3](02) 7402 jz 00000bb7
[00000bb5](02) ebfe jmp 00000bb5
[00000bb7](02) 8be5 mov esp,ebp
[00000bb9](01) 5d pop ebp
[00000bba](01) c3 ret
Size in bytes:(0035) [00000bba]
_main()
[00000bc8](01) 55 push ebp
[00000bc9](02) 8bec mov ebp,esp
[00000bcb](05) 68980b0000 push 00000b98
[00000bd0](05) e8c3ffffff call 00000b98
[00000bd5](03) 83c404 add esp,+04
[00000bd8](02) 33c0 xor eax,eax
[00000bda](01) 5d pop ebp
[00000bdb](01) c3 ret
Size in bytes:(0020) [00000bdb]
===============================
...[00000bc8][001015d4][00000000](01) 55 push ebp ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98 ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98 ...[00000b98][001015c8][001015d4](01) 55 push ebp ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp ...[00000b9b][001015c4][00000000](01) 51 push ecx ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][001015c0][00000b98](01) 50 push eax ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][001015bc][00000b98](01) 51 push ecx ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
Begin Local Halt Decider Simulation at Machine Address:b98 ...[00000b98][00211674][00211678](01) 55 push ebp ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp ...[00000b9b][00211670][00201644](01) 51 push ecx ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0021166c][00000b98](01) 50 push eax ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][00211668][00000b98](01) 51 push ecx ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938 ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp ...[00000b9b][0025c098][0024c06c](01) 51 push ecx ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0025c094][00000b98](01) 50 push eax ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][0025c090][00000b98](01) 51 push ecx ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08 ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00 ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7 ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp ...[00000bba][001015d0][00000b98](01) c3 ret ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04 ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax ...[00000bda][001015d8][00100000](01) 5d pop ebp ...[00000bdb][001015dc][00000098](01) c3 ret
Number_of_User_Instructions(39)
Number of Instructions Executed(26567)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 104:32:46 |
| Calls: | 6,660 |
| Calls today: | 2 |
| Files: | 12,209 |
| Messages: | 5,335,177 |