Deutsch   English   Français   Italiano  
<v2e7up$1g2n9$13@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: Can D simulated by H terminate normally? Message_ID Provided V2
Date: Sun, 19 May 2024 21:10:49 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v2e7up$1g2n9$13@i2pn2.org>
References: <v0k4jc$laej$1@dont-email.me> <v0l11u$ussl$1@dont-email.me>
 <v0lh24$123q3$1@dont-email.me> <v0lic7$2g492$3@i2pn2.org>
 <v0lkas$12q0o$3@dont-email.me> <v0loq2$2g493$1@i2pn2.org>
 <v0lq7d$14579$2@dont-email.me> <v0ls98$2g492$7@i2pn2.org>
 <v0m29q$166o1$1@dont-email.me> <v0m37e$2gl1e$1@i2pn2.org>
 <v0m3v5$16k3h$1@dont-email.me> <v0m55t$2gl1f$3@i2pn2.org>
 <v0m5sn$172p4$1@dont-email.me> <v0m7em$2gl1f$5@i2pn2.org>
 <v0m7tq$17dpv$1@dont-email.me> <v0m8g9$2gl1e$6@i2pn2.org>
 <v0m978$17k7o$3@dont-email.me> <v0mko6$2hf3s$2@i2pn2.org>
 <v0n59h$1h98e$1@dont-email.me> <v0o037$2j1tu$3@i2pn2.org>
 <v0oc65$1q3aq$3@dont-email.me> <v0p9ts$2ki5r$6@i2pn2.org>
 <v0q1rk$2a3u1$1@dont-email.me> <v0qkti$2m1nf$1@i2pn2.org>
 <v0r4a3$2hb7o$6@dont-email.me> <v0rsbr$2m1nf$6@i2pn2.org>
 <v0segm$2v4oq$1@dont-email.me> <v0t8o9$2p3ri$2@i2pn2.org>
 <v0tpjf$3881i$5@dont-email.me> <v0ulma$2qov4$1@i2pn2.org>
 <v2e45j$3kf2k$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 20 May 2024 01:10:49 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1575657"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v2e45j$3kf2k$1@dont-email.me>
Content-Language: en-US
Bytes: 11748
Lines: 242

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.

========== REMAINDER OF ARTICLE TRUNCATED ==========