Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <v47g6e$3ipmi$6@i2pn2.org>
Deutsch   English   Français   Italiano  
<v47g6e$3ipmi$6@i2pn2.org>

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

Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.com>
Newsgroups: comp.theory
Subject: Re: Proof that DD correctly simulated by HH has different behavior
 than DD(DD) STEP(1)
Date: Mon, 10 Jun 2024 18:21:02 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <v47g6e$3ipmi$6@i2pn2.org>
References: <v428vv$2no74$2@dont-email.me> <v43ib7$38hnd$1@dont-email.me>
	<v4628o$6ero$1@dont-email.me> <v46na1$3ifov$1@i2pn2.org>
	<v47el8$idkr$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 10 Jun 2024 18:21:02 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3761874"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4070
Lines: 59

Am Mon, 10 Jun 2024 12:54:48 -0500 schrieb olcott:
> On 6/10/2024 6:16 AM, Richard Damon wrote:
>> On 6/10/24 1:17 AM, olcott wrote:
>>> On 6/9/2024 1:33 AM, Fred. Zwarts wrote:
>>>> Op 08.jun.2024 om 20:47 schreef olcott:

>>>>> Try to show how this DD correctly simulated by any HH ever stops
>>>>> running without having its simulation aborted by HH.
>>>>
>>>> Stopping at your first error. So, we can focus on it. Your are asking
>>>> a question that contradicts itself.
>>>> A correct simulation of HH that aborts itself, should simulate up to
>>>> the point where the simulated HH aborts. That is logically
>>>> impossible. So, either it is a correct simulation and then we see
>>>> that the simulated HH aborts and returns, or the simulation is
>>>> incorrect, because it assumes incorrectly that things that happen
>>>> (abort) do not happen.
Why does it need to abort, when its recursive simulation does the same
and thus returns, not needing to be aborted?

>> So, I guess you are admitting that this means that "D correctly
>> simulated by H" is NOT a possible equivalent statement for the behavior
>> of the direct execution of the input as required by the Halting
>> Problem,
>> so you admit you have been LYING every time you imply that it is.
Are you saying that the simulation can be different from the direct
execution?

> The only way for D simulated by H to have the same behavior as the
> directly executed D(D) is for D simulated by H to skip over this call.
Does D(D) skip over this call?

>> Your problem is that it turns out that the only way that a correct
>> simulation by H to be an actual correct simulation that shows halting
>> behavior, it can't answer and be a decider.
> [no answer]

>> But your H DOES ignore the CORRECT behavior of that instruction, as a
>> correct simulation of that instruction (by what ever type of simulation
>> you want to do) must either continue it trace into the function H
>> (which none of your published traces of the results of the simulation H
>> does do) if the simulation instruction level, or it must show the
>> effective behavior of the actual function H, which is to return 0
>> (since you claim you H is correct, and correct to return 0).
>> Neither of these is what your "correct simulation" of the input does,
>> so it can not be a correct simulation of the input. Your H just doesn't
>> "correctly simulate" that call instruction, but does invalid logic to
>> conclude the wrong answer.
>> It seems impossible for you claim that you have looked at the trace of
>> H acually doing the x86 instruction trace of H to show that it was
>> correctly determining what you claim, as your "250 page" trace turns
>> out not to be that trace, and you admit you didn't look at it closely,
>> and you JUST think you figured out how to get such a trace out.
>> 
> There is no need to look at the trace of H correctly simulated by H when
> the trace of D correctly simulated by simulated H is proven to be
> correct.

-- 
joes