Re: Can D simulated by H terminate normally?

On 5/1/24 8:10 PM, Richard Damon wrote:

But you refuse to listen.
 Remember, YOU are the one saying you are needing to change the definition from the classical theory, where we have things well defined.
 YOU have decider that H is just whatever C code you want to write for it, and D is the input proved. (which doesn't actually match the Linz or Sipser proof, but fairly close).
 With THAT set of definitions we have a lot of options that break your incorrectly assumed results.
 The first method has been discussed here by Flibble. While the final answer he got to doesn't fit the requirements, the first part of the method DOES show that it is possible for an H to simulate to past line 3.
 THe basic idea is that if H(M,d) finds that its simulation of M(d) get to a call to H(M,d) then rather that your idea of just saying it will get stuck and declair the input invalid, since there ARE a number of possible inputs that there is a "correct" answer that H can give to match the behavior of the direct execution of M(d), what H does is fork its simulation into two threads.
 Thread 1 continues the simulation assuming that the call to H(M,d) will return a 1, and if that simulation reaches a halting state, then 1 is the answer, and thread 2 can be abandoned.
 Thread 2 continues the simulation assuming that the call to H(M,d) will return a 0, and if that simulation reaches a provable non-halting pattern, then 0 is the answer, and thread 1 can be abandoned.
 It may be the case that BOTH answer could be correct, in which case depending on exactly how the forking works and how long it takes each to get to the answer, either answer might be given, but then, both are correct.
 It may be the case that neither answer can be shown correct, if Thread one can prove that it will be non-halting and Thread 2 halts, then the decider has proven the machine to be "contrary" to it. But it might be the case that it never can figure that out, and it just doesn't answer.
 But, in all cases, it gets past the call to H(M,d), so your criteria, that NO H can get there is not meet.
  The second method uses the fact that you have not restricted what H is allowed to do, and thus H can remember that it is simulating, and if a call to H shows that it is currently doing a simulation, just immediately return 0. Thus, H can actually correct simulate the instruction at the call to H, as they will execute just a few instructions testing that condition and returning, and thus not run into the problem you ran into where H just couldn't simulate itself because it got bogged down.
 In this case it is actually true that the direct execution of D(D) differs from the correct simulation of the input by H, as H is no longer a "Computation" per the rules of Computation Theory, but you have admitted that you are abandoning those, so it doesn't matter (of course that make trying to get your results to apply to something similar harder, but that is why you need to try to come up with some actual definitons.)
 So, by the rules of Compuation Theory, your H is not correct, but by your lack of rules, your conclusion that H can not simulate past the call are incorrect, so you proof is also broken.
 

above is the part of the message where I proved your claim wrong.
Note in particular, the second method.
H just begins with the code:
int H(ptr x, ptr y) {
   static int flag = 0;
   if (flag) return 0;
   flag = 1
/* rest of H as is, but disabling the skipping of the simulation of H itself */
}
Note, This makes H not a "pure function" but that was explicitly NOT a requirement of you claim, only that no C function "H" could simulated the provided D past its call to H.
This H does, and because your structure explicitly puts H in the same execution context as D, they share that static value of flag, so the D call sees the flag as 1 and thus it returns immediately, and then D will reach its end state,
Thus, your claim that this is categorically impossible is disproven, and you are proven to not have sufficent understanding of the semantics of the C programing language, and that you habitually claim as obviously or self-evident truth things that are not, so any such statement from you is likely a LIE.