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

On 5/19/24 8:06 PM, olcott wrote:

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.
 

Ok, so adding that H is a pure function, that means that since your outer H(D,D) is going to return 0, all logic must be compatible with the fact that EVERY call to H(D,D) will also eventually return 0.
Remember also, THIS D is defined to call THIS H, that does exactly the same as the H that is deciding it.

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

Nope. Try to actuall PROVE it.
Remember in your proof that if ANY H abort its simulation and returns 0, by your restrictions ALL H will eventually abort its simulation and return 0.

 My new H that is a pure function of its inputs uses that
as its basis.

But it isn't true.
Your logic ignores that since the outer H aborts its simulation and returns 0, each simulation of H will also eventually (if simulated long enough) abort its simulation and return 0.
Thus, H can not use the fact that D(D) calls H(D,D) to prove non-halting recursive simulation.

 

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.

Only if you break your rules and make H not a pure function, as some of your H never return while others return 0 in finite time.
ILLEGAL.
Thus, you infinite set needs to be trimmed, and that removes the one case where you could actual show that THAT D was non-halting, and try to foist it off as the answer to all the others.

 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.

But uses illegal logic looking at not-this-H machines looking at not-this-D inputs, which just shows that an H that aborts its simulation before it reaches a final state doesn't reach a final state.
That does NOT prove non-halting.
And since for EVERY input of that set, we could simulate the H/D pair with an actual UTM to determine that it WILL Halt, and in how many steps of simulation by H, all we have shown is that every D runs for a finite number of step larger than the finite number of steps that its corresponding H simulated. So as a class, we can prove that all will halt, but none will simulate to the final state.
(remember the non-aborting machine must be eliminated from the set, as it fails the "Pure Function" definition with respect to the original H)

 

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.

H can not be a "Computable Function" as NO PROGRAM IS A MATHEMATICAL FUNCTION and you prove your logic is built on type errors.
I guess you C programs aren't C programs and you whole world is just a lie.
Note also, the first method, the one based on the "Flibble" method, does NOT violate the definiton of a "pure function", and if we presume the ability to identify that D(D) is calling H(D,D) as your design needs (even if this is impossible as actual Turing Equivalent machines for the actual halting problem)

 

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.

Why not? You create a second copy of the execution context, that you will by some method eventually simulate both copies of.
In one, you simulate the CALL H(D,D) as if H just returned 0, and in the second as if H just returned 1.
This is not conceptually any harder than your current method of having the CALL H(D,D) create a new execution frame and start simulating a new D(D).

 

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*

Why?
Yes, if you add the H must be a pure function, then you can eleminate this path, but you also must elminate your logic that comes up with an impossible answer, that one instance of the pure function H(D,D) creates non-halting infinite simulation while another returns 0.
This is why you needed to drop the Turing Equivalence rules (like your Pure Function rule) it shows that your logic MUST be wrong.
You never ever were able to prove that H sees an actual pattern that actually proves non-halting behavior. It can't, as the actual behavior of D(D) is to Halt.
Your whole logic is based on trying to convince people that D(D) can be some how correctly decider to be non-halting when it halts, which just proves that your logic is based on LIES.

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