Given olcott's code,
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
and olcott's assertion that H is a pure function and H(P,P) == 0,
then, P should halt as H should also return 0 to P (pure functions
ALWAYS return the same result for the same arguments with no side
effects). P doesn't halt so H is erroneous; olcott, it's really that
simple.
/Flibble
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of people's
posts. Your H is erroneous.
/Flibble
On 6/16/2022 12:17 PM, Mr Flibble wrote:
Given olcott's code,
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
and olcott's assertion that H is a pure function and H(P,P) == 0,
then, P should halt as H should also return 0 to P (pure functions
ALWAYS return the same result for the same arguments with no side
effects). P doesn't halt so H is erroneous; olcott, it's really that simple.
/Flibble
_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]
Any competent software engineer will see that the correct and
complete x86 emulation of the input to H(P,P) will never reach its
"ret" instruction (the final state of P).
When H(P,P) aborts the x86 emulation of its input on this basis and
returns 0 to main competent software engineers will know that this
does not cause P to reach its "ret" instruction.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of people's
posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is only
an x86 emulator that the correctly emulated P never reaches its "ret" instruction it remains stuck in repeated cycles of emulation.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report
this.
(3) When the halt status criteria is defined as correctly determining
whether or not an x86 emulated input would ever reach its "ret"
instruction then it becomes an easily verified fact H(P,P) could
correctly reject its input as non-halting.
Correct deductive inference proves that all of these things are true
without any need what-so-ever to see either the source-code or the
execution trace of H.
The one thing that is not proved is whether or not an actual encoded
H(P,P) does indeed correctly determine that its input would never
reach its "ret" instruction as a pure function of its inputs.
On Thu, 16 Jun 2022 13:07:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of people's
posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is only
an x86 emulator that the correctly emulated P never reaches its "ret"
instruction it remains stuck in repeated cycles of emulation.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report
this.
(3) When the halt status criteria is defined as correctly determining
whether or not an x86 emulated input would ever reach its "ret"
instruction then it becomes an easily verified fact H(P,P) could
correctly reject its input as non-halting.
Correct deductive inference proves that all of these things are true
without any need what-so-ever to see either the source-code or the
execution trace of H.
The one thing that is not proved is whether or not an actual encoded
H(P,P) does indeed correctly determine that its input would never
reach its "ret" instruction as a pure function of its inputs.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
On 6/16/2022 1:11 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:07:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of
people's posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is
only an x86 emulator that the correctly emulated P never reaches
its "ret" instruction it remains stuck in repeated cycles of
emulation.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report
this.
(3) When the halt status criteria is defined as correctly
determining whether or not an x86 emulated input would ever reach
its "ret" instruction then it becomes an easily verified fact
H(P,P) could correctly reject its input as non-halting.
Correct deductive inference proves that all of these things are
true without any need what-so-ever to see either the source-code
or the execution trace of H.
The one thing that is not proved is whether or not an actual
encoded H(P,P) does indeed correctly determine that its input
would never reach its "ret" instruction as a pure function of its
inputs.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
Competent software engineers would understand that H(P,P)==0 is
correct and be unable to find any software engineering mistakes.
It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H cannot possibly reach its "ret" instruction.
Since this is the criterion measure for returning 0 then H(P,P)==0
has been proven to be correct on the basis of software engineering.
On 6/16/2022 1:22 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:21:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:11 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:07:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of
people's posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is
only an x86 emulator that the correctly emulated P never reaches
its "ret" instruction it remains stuck in repeated cycles of
emulation.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct
and complete x86 emulation of its input would never each its
"ret" instruction that H could abort its emulation and return 0
to report this.
(3) When the halt status criteria is defined as correctly
determining whether or not an x86 emulated input would ever reach
its "ret" instruction then it becomes an easily verified fact
H(P,P) could correctly reject its input as non-halting.
Correct deductive inference proves that all of these things are
true without any need what-so-ever to see either the source-code
or the execution trace of H.
The one thing that is not proved is whether or not an actual
encoded H(P,P) does indeed correctly determine that its input
would never reach its "ret" instruction as a pure function of its
inputs.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
Competent software engineers would understand that H(P,P)==0 is
correct and be unable to find any software engineering mistakes.
It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H cannot possibly reach its
"ret" instruction.
Since this is the criterion measure for returning 0 then H(P,P)==0
has been proven to be correct on the basis of software
engineering.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
People that are not competent software engineers and people that
prefer rebuttal to truth will avoid addressing the above irrefutably
correct reasoning.
On Thu, 16 Jun 2022 13:21:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:11 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:07:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of
people's posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is
only an x86 emulator that the correctly emulated P never reaches
its "ret" instruction it remains stuck in repeated cycles of
emulation.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report
this.
(3) When the halt status criteria is defined as correctly
determining whether or not an x86 emulated input would ever reach
its "ret" instruction then it becomes an easily verified fact
H(P,P) could correctly reject its input as non-halting.
Correct deductive inference proves that all of these things are
true without any need what-so-ever to see either the source-code
or the execution trace of H.
The one thing that is not proved is whether or not an actual
encoded H(P,P) does indeed correctly determine that its input
would never reach its "ret" instruction as a pure function of its
inputs.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
Competent software engineers would understand that H(P,P)==0 is
correct and be unable to find any software engineering mistakes.
It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H cannot possibly reach its "ret"
instruction.
Since this is the criterion measure for returning 0 then H(P,P)==0
has been proven to be correct on the basis of software engineering.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
On 6/16/2022 1:30 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:26:25 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:22 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:21:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:11 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:07:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of
people's posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is
only an x86 emulator that the correctly emulated P never
reaches its "ret" instruction it remains stuck in repeated
cycles of emulation.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct
and complete x86 emulation of its input would never each its
"ret" instruction that H could abort its emulation and return 0
to report this.
(3) When the halt status criteria is defined as correctly
determining whether or not an x86 emulated input would ever
reach its "ret" instruction then it becomes an easily verified
fact H(P,P) could correctly reject its input as non-halting.
Correct deductive inference proves that all of these things are
true without any need what-so-ever to see either the
source-code or the execution trace of H.
The one thing that is not proved is whether or not an actual
encoded H(P,P) does indeed correctly determine that its input
would never reach its "ret" instruction as a pure function of
its inputs.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
Competent software engineers would understand that H(P,P)==0 is
correct and be unable to find any software engineering mistakes.
It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H cannot possibly reach its
"ret" instruction.
Since this is the criterion measure for returning 0 then
H(P,P)==0 has been proven to be correct on the basis of software
engineering.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
People that are not competent software engineers and people that
prefer rebuttal to truth will avoid addressing the above
irrefutably correct reasoning.
Your reasoning is incorrect. If H(P,P) == 0 then P should halt.
/Flibble
Which one of these are you:
People that are not competent software engineers and people that
prefer rebuttal to truth will avoid addressing the above irrefutably
correct reasoning.
On Thu, 16 Jun 2022 13:26:25 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:22 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:21:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:11 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:07:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of
people's posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is
only an x86 emulator that the correctly emulated P never reaches
its "ret" instruction it remains stuck in repeated cycles of
emulation.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct
and complete x86 emulation of its input would never each its
"ret" instruction that H could abort its emulation and return 0
to report this.
(3) When the halt status criteria is defined as correctly
determining whether or not an x86 emulated input would ever reach
its "ret" instruction then it becomes an easily verified fact
H(P,P) could correctly reject its input as non-halting.
Correct deductive inference proves that all of these things are
true without any need what-so-ever to see either the source-code
or the execution trace of H.
The one thing that is not proved is whether or not an actual
encoded H(P,P) does indeed correctly determine that its input
would never reach its "ret" instruction as a pure function of its
inputs.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
Competent software engineers would understand that H(P,P)==0 is
correct and be unable to find any software engineering mistakes.
It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H cannot possibly reach its
"ret" instruction.
Since this is the criterion measure for returning 0 then H(P,P)==0
has been proven to be correct on the basis of software
engineering.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
People that are not competent software engineers and people that
prefer rebuttal to truth will avoid addressing the above irrefutably
correct reasoning.
Your reasoning is incorrect. If H(P,P) == 0 then P should halt.
/Flibble
On Thu, 16 Jun 2022 13:31:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:30 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:26:25 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:22 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:21:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:11 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:07:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of
people's posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is >>>>>>>> only an x86 emulator that the correctly emulated P never
reaches its "ret" instruction it remains stuck in repeated
cycles of emulation.
(2) It is an easily verified fact that if H has been adapted to >>>>>>>> correctly detect (in a finite number of steps) that the correct >>>>>>>> and complete x86 emulation of its input would never each its
"ret" instruction that H could abort its emulation and return 0 >>>>>>>> to report this.
(3) When the halt status criteria is defined as correctly
determining whether or not an x86 emulated input would ever
reach its "ret" instruction then it becomes an easily verified >>>>>>>> fact H(P,P) could correctly reject its input as non-halting.
Correct deductive inference proves that all of these things are >>>>>>>> true without any need what-so-ever to see either the
source-code or the execution trace of H.
The one thing that is not proved is whether or not an actual
encoded H(P,P) does indeed correctly determine that its input
would never reach its "ret" instruction as a pure function of
its inputs.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
Competent software engineers would understand that H(P,P)==0 is
correct and be unable to find any software engineering mistakes.
It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H cannot possibly reach its
"ret" instruction.
Since this is the criterion measure for returning 0 then
H(P,P)==0 has been proven to be correct on the basis of software
engineering.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
People that are not competent software engineers and people that
prefer rebuttal to truth will avoid addressing the above
irrefutably correct reasoning.
Your reasoning is incorrect. If H(P,P) == 0 then P should halt.
/Flibble
Which one of these are you:
People that are not competent software engineers and people that
prefer rebuttal to truth will avoid addressing the above irrefutably
correct reasoning.
Your reasoning is incorrect. If H(P,P) == 0 then P should halt.
/Flibble
On 6/16/2022 1:32 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:31:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:30 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:26:25 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:22 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:21:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:11 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:07:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of >>>>>>>>> people's posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H >>>>>>>> is only an x86 emulator that the correctly emulated P never
reaches its "ret" instruction it remains stuck in repeated
cycles of emulation.
(2) It is an easily verified fact that if H has been adapted >>>>>>>> to correctly detect (in a finite number of steps) that the
correct and complete x86 emulation of its input would never
each its "ret" instruction that H could abort its emulation
and return 0 to report this.
(3) When the halt status criteria is defined as correctly
determining whether or not an x86 emulated input would ever
reach its "ret" instruction then it becomes an easily
verified fact H(P,P) could correctly reject its input as
non-halting.
Correct deductive inference proves that all of these things
are true without any need what-so-ever to see either the
source-code or the execution trace of H.
The one thing that is not proved is whether or not an actual >>>>>>>> encoded H(P,P) does indeed correctly determine that its input >>>>>>>> would never reach its "ret" instruction as a pure function of >>>>>>>> its inputs.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
Competent software engineers would understand that H(P,P)==0 is
correct and be unable to find any software engineering
mistakes.
It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H cannot possibly reach its
"ret" instruction.
Since this is the criterion measure for returning 0 then
H(P,P)==0 has been proven to be correct on the basis of
software engineering.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
People that are not competent software engineers and people that
prefer rebuttal to truth will avoid addressing the above
irrefutably correct reasoning.
Your reasoning is incorrect. If H(P,P) == 0 then P should halt.
/Flibble
Which one of these are you:
People that are not competent software engineers and people that
prefer rebuttal to truth will avoid addressing the above
irrefutably correct reasoning.
Your reasoning is incorrect. If H(P,P) == 0 then P should halt.
/Flibble
Since my reasoning is trivially proven to be correct:
It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H cannot possibly reach its
"ret" instruction.
H returns 0 whenever the complete and correct x86 emulation of its
input would never reach the "ret" instruction of this input.
Every possible rebuttal is simultaneously proven to be incorrect.
On Thu, 16 Jun 2022 13:45:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:32 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:31:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:30 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:26:25 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:22 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:21:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:11 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 13:07:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of >>>>>>>>>>> people's posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H >>>>>>>>>> is only an x86 emulator that the correctly emulated P never >>>>>>>>>> reaches its "ret" instruction it remains stuck in repeated >>>>>>>>>> cycles of emulation.
(2) It is an easily verified fact that if H has been adapted >>>>>>>>>> to correctly detect (in a finite number of steps) that the >>>>>>>>>> correct and complete x86 emulation of its input would never >>>>>>>>>> each its "ret" instruction that H could abort its emulation >>>>>>>>>> and return 0 to report this.
(3) When the halt status criteria is defined as correctly
determining whether or not an x86 emulated input would ever >>>>>>>>>> reach its "ret" instruction then it becomes an easily
verified fact H(P,P) could correctly reject its input as
non-halting.
Correct deductive inference proves that all of these things >>>>>>>>>> are true without any need what-so-ever to see either the
source-code or the execution trace of H.
The one thing that is not proved is whether or not an actual >>>>>>>>>> encoded H(P,P) does indeed correctly determine that its input >>>>>>>>>> would never reach its "ret" instruction as a pure function of >>>>>>>>>> its inputs.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
Competent software engineers would understand that H(P,P)==0 is >>>>>>>> correct and be unable to find any software engineering
mistakes.
It is an easily verified fact that the correct and complete x86 >>>>>>>> emulation of the input to H(P,P) by H cannot possibly reach its >>>>>>>> "ret" instruction.
Since this is the criterion measure for returning 0 then
H(P,P)==0 has been proven to be correct on the basis of
software engineering.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
People that are not competent software engineers and people that
prefer rebuttal to truth will avoid addressing the above
irrefutably correct reasoning.
Your reasoning is incorrect. If H(P,P) == 0 then P should halt.
/Flibble
Which one of these are you:
People that are not competent software engineers and people that
prefer rebuttal to truth will avoid addressing the above
irrefutably correct reasoning.
Your reasoning is incorrect. If H(P,P) == 0 then P should halt.
/Flibble
Since my reasoning is trivially proven to be correct:
It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H cannot possibly reach its
"ret" instruction.
H returns 0 whenever the complete and correct x86 emulation of its
input would never reach the "ret" instruction of this input.
Every possible rebuttal is simultaneously proven to be incorrect.
Nope. If H(P,P) == 0 then P should halt.
/Flibble
Mr Flibble <flibble@reddwarf.jmc> writes:
Given olcott's code,
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
and olcott's assertion that H is a pure function and H(P,P) == 0,
then, P should halt as H should also return 0 to P
You mean P(P) should halt, and it does. PO does not dispute this fact.
Not only has he posted a trace of P(P) halting, he has clearly stated
that H(P,P) == 0 "is the correct answer even though P(P) halts".[1]
(pure functions
ALWAYS return the same result for the same arguments with no side
effects). P doesn't halt so H is erroneous; olcott, it's really that
simple.
Except that he is now just asserting that H(P,P) == 0 is correct about something else (the "correct simulation of the input to H(P,P)") and the mistakes in that irrelevant statement are keeping him supplied with the attention he craves. You might consider not giving him what he wants.
[1] Message-ID: <c8idnbFAF6C8QuP8nZ2dnUU7-avNnZ2d@giganews.com>
On 6/16/2022 12:17 PM, Mr Flibble wrote:
Given olcott's code,
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
and olcott's assertion that H is a pure function and H(P,P) == 0,
then, P should halt as H should also return 0 to P (pure functions
ALWAYS return the same result for the same arguments with no side
effects). P doesn't halt so H is erroneous; olcott, it's really that
simple.
/Flibble
_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]
Any competent software engineer will see that the correct and complete
x86 emulation of the input to H(P,P) will never reach its "ret"
instruction (the final state of P).
When H(P,P) aborts the x86 emulation of its input on this basis and
returns 0 to main competent software engineers will know that this does
not cause P to reach its "ret" instruction.
computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
On 6/16/2022 1:02 PM, Mr Flibble wrote:
On Thu, 16 Jun 2022 12:40:19 -0500
olcott <NoOne@NoWhere.com> wrote:
It would be better if you actually addressed the content of people's
posts. Your H is erroneous.
/Flibble
Competent software engineers will agree that
the following proves that H(P,P)==0 is correct.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is only an
x86 emulator that the correctly emulated P never reaches its "ret" instruction it remains stuck in repeated cycles of emulation.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report this.
(3) When the halt status criteria is defined as correctly determining
whether or not an x86 emulated input would ever reach its "ret"
instruction then it becomes an easily verified fact H(P,P) could
correctly reject its input as non-halting.
Correct deductive inference proves that all of these things are true
without any need what-so-ever to see either the source-code or the
execution trace of H.
The one thing that is not proved is whether or not an actual encoded
H(P,P) does indeed correctly determine that its input would never reach
its "ret" instruction as a pure function of its inputs.
On 6/16/2022 2:15 PM, Ben Bacarisse wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Given olcott's code,
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
and olcott's assertion that H is a pure function and H(P,P) == 0,
then, P should halt as H should also return 0 to P
You mean P(P) should halt, and it does. PO does not dispute this fact.
Not only has he posted a trace of P(P) halting, he has clearly stated
that H(P,P) == 0 "is the correct answer even though P(P) halts".[1]
(pure functions
ALWAYS return the same result for the same arguments with no side
effects). P doesn't halt so H is erroneous; olcott, it's really that
simple.
Except that he is now just asserting that H(P,P) == 0 is correct about
something else (the "correct simulation of the input to H(P,P)") and the
mistakes in that irrelevant statement are keeping him supplied with the
attention he craves. You might consider not giving him what he wants.
[1] Message-ID: <c8idnbFAF6C8QuP8nZ2dnUU7-avNnZ2d@giganews.com>
When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects that its correct and complete simulation
of its input would never reach the final state of this input that all
inputs (including pathological inputs) are decided correctly.
*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 121:12:05 |
| Calls: | 6,662 |
| Files: | 12,212 |
| Messages: | 5,334,487 |