XPost: sci.logic, comp.theory, comp.software-eng
On 2/14/23 10:55 AM, olcott wrote:
001 int h(x, y); // suppose the detail of h(x, y) is in a library.
002
003 int c(x) {
004 int halt_status = h(x, x)
005 if (h(halt_status != 0) {
006 while(TRUE) {
007 ;
008 }
009 }
010 return halt_status;
011 }
012
013 main() {
014 Output("Input_Halts = ", h(c, c));
015 Output("Input_Halts = ", c(c));
016 }
*Simulating halt deciders applied to the halting theorem*
Because c simulated by h would continue to call h(c,c) never reaching
its own "if" statement h aborts it simulation of c and returns 0 to main
on line 014.
Because c simulated by h would continue to call h(c,c) never reaching
its own "if" statement h aborts it simulation of c and returns 0 to the executed c on line 004.
No, because H(c,c) will return 0 by your logic, c(c) will Halt.
Since the DEFINITION of the correct answer of the Halting Problem is
what the ACTUAL machine will do when given the input, the correct answer
is HALTING, and thus H is WRONG.
You have "claimed" that H called by c behaves differently than H called
by main, but have been unable to actually show that, showing that the
claim is just a blatant pathological LIE.
The fact that you think an answer difffernt than the correct answer can
be "correct" show you are stupid.
Note, the fact that H can't correctly simulate the input and give an
answer is NOT a valid "excuse" for H to give a wrong answr.
Note, a fundamental problem with your logic is you don't seem to
understand that a program will do EXACTLY as it is programmed, even if
that doesn't match its supposed specification, so you can't just assume
it will act per its specification.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)