Re: Can D simulated by H terminate normally? Message_ID Provided V2

On 5/1/2024 7:10 PM, Richard Damon wrote:
typedef int (*ptr)();  // ptr is pointer to int function
00 int H(ptr p, ptr i);
01 int D(ptr p)
02 {
03   int Halt_Status = H(p, p);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 int main()
10 {
11   H(D,D);
12   return 0;
13 }
In the above case a simulator is an x86 emulator that correctly emulates at least one of the x86 instructions of D in the order specified by the x86 instructions of D.
This may include correctly emulating the x86 instructions of H in the order specified by the x86 instructions of H thus calling H(D,D) in recursive simulation.
For every H/D pair of the above template D correctly simulated by
*pure function* H cannot possibly reach its own final state at
line 06 and halt.
<snip so that Message ID links to whole message>
We can use my unique time/date stamp as an alternative.

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

That D is calling H does not prove recursive simulation.
That D is calling H with its same parameters does seem
to prove non-halting recursive simulation.
My new H that is a pure function of its inputs uses that
as its basis.

match the behavior of the direct execution of M(d), what H does is fork its simulation into two threads.
 

We already know that D correctly simulated by H cannot possibly
reach its own simulated final state at line 06 and halt in 1 to ∞
steps of correct simulation.
We can't monkey around with illegal communication from the
executed simulator to its simulated versions of itself.
The current H does not do that and does not need to do that.

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

It has always been the case that the actual H must be a pure function
so that it can be a computable function. There were too many discussions
on this for you not to be aware that this was always a requirement. That
it was not a written requirement in my spec you saw as a loophole. It
is good that you caught this. I don't want any loopholes.

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.
 

There is no way that pure function H can tell its simulated versions
to do this.

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.)

*That is a whole other sequence of hundreds and hundreds of messages* *and replies that cannot be mixed in to this point to divert attention* *away from this point until we have complete closure on this point*
*That is a whole other sequence of hundreds and hundreds of messages* *and replies that cannot be mixed in to this point to divert attention* *away from this point until we have complete closure on this point*
*That is a whole other sequence of hundreds and hundreds of messages* *and replies that cannot be mixed in to this point to divert attention* *away from this point until we have complete closure on this point*

 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.
 

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer