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
Subject: Re: Defining a correct halt decider
Date: Wed, 4 Sep 2024 20:23:33 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <60cf665c19200e8678ac9789bf29b85504cd4a6e@i2pn2.org>
References: <vb4npj$1kg8k$1@dont-email.me> <vb6i8p$39fhi$1@dont-email.me>
 <vb72a4$3b4ub$6@dont-email.me>
 <bcef318ec77a8792164a6626ba6d8a05007311da@i2pn2.org>
 <vb7pig$3evto$1@dont-email.me> <vb9dee$3psb3$4@dont-email.me>
 <vb9pbg$3s1jn$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 5 Sep 2024 00:23:33 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="879726"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vb9pbg$3s1jn$2@dont-email.me>
Bytes: 7056
Lines: 143

On 9/4/24 10:03 AM, olcott wrote:
> On 9/4/2024 5:40 AM, Fred. Zwarts wrote:
>> Op 03.sep.2024 om 21:54 schreef olcott:
>>> On 9/3/2024 1:53 PM, joes wrote:
>>>> Am Tue, 03 Sep 2024 08:17:56 -0500 schrieb olcott:
>>>>> On 9/3/2024 3:44 AM, Mikko wrote:
>>>>>> On 2024-09-02 16:06:11 +0000, olcott said:
>>>>>>
>>>>>>> A correct halt decider is a Turing machine T with one accept 
>>>>>>> state and
>>>>>>> one reject state such that:
>>>>>>> If T is executed with initial tape contents equal to an encoding of
>>>>>>> Turing machine X and its initial tape contents Y, and execution of a
>>>>>>> real machine X with initial tape contents Y eventually halts, the
>>>>>>> execution of T eventually ends up in the accept state and then 
>>>>>>> stops.
>>>>>>> If T is executed with initial tape contents equal to an encoding of
>>>>>>> Turing machine X and its initial tape contents Y, and execution of a
>>>>>>> real machine X with initial tape contents Y does not eventually 
>>>>>>> halt,
>>>>>>> the execution of T eventually ends up in the reject state and then
>>>>>>> stops.
>>>>>> Your "definition" fails to specify "encoding". There is no standard
>>>>>> encoding of Turing machines and tape contents.
>>>>>>
>>>>> That is why I made the isomorphic x86utm system.
>>>>> By failing to have such a concrete system all kinds of false 
>>>>> assumptions
>>>>> cannot be refuted.
>>>> What would those assumptions be?
>>>>
>>>>> The behavior of DDD emulated by HHH** <is> different than the behavior
>>>>> of the directly executed DDD** **according to the semantics of the x86
>>>>> language
>>>> How can the same code have different semantics?
>>>>
>>>
>>> The pathological relationship between DDD and HHH really
>>> cannot be simply ignored as if it does not exist.
>>>
>>>>> HHH is required to report on the behavior tat its finite string input
>>>>> specifies even when this requires HHH to emulate itself emulating DDD.
>>>  > The input specifies an aborting HHH - which you don’t simulate.>
>>>
>>> void DDD()
>>> {
>>>    HHH(DDD);
>>>    OutputString("This code is unreachable by DDD emulated by HHH");
>>> }
>>>
>>>>> DDD never halts unless it reaches its own final halt state. The fact
>>>>> that the executed HHH halts has nothing to do with this.
>>>> Other than that DDD calls HHH?
>>>>
>>>>> HHH is not allowed to report on the computation that itself is 
>>>>> contained
>>>>> within.
>>>> Then it is only partial, and doesn’t even solve the case it was 
>>>> built for.
>>>>
>>>
>>> int sum(int x, int y);
>>> sum(3,4) is not allowed to report on the sum of 5 + 6
>>> for the same reason. HHH(DDD) cannot report on behavior
>>> that it cannot see.
>>
>> Exactly, so it should not report on halting behaviour if its stops the 
>> simulation before the simulation could halt.
> 
> It is very stupid to say that when this proves that DDD emulated by HHH
> cannot possibly reach its final halt state.
> https://github.com/plolcott/x86utm/blob/master/Halt7out.txt

That just proves that you don't know what a "correct emulation" means.

The only correct, per the x86 instuction semantics, emulation of a call 
instruction is the emulation of the instruction addressed by the call.


Sorry, you are just proving that you are nothing but an ignorant liar.

Your LONGER 200 page trace PROVES that DDD would halt, as it shows that 
if we trace starting at DDD we get back to it,



> 
>> If the simulator prevents the simulation to halt, then there is no 
>> reason to report about the halting behaviour.
>>
>>>
>>> HHH cannot correctly report on the AFTER-THE-FACT
>>> behavior that it has aborted its simulation BEFORE-THE-FACT.
>>
>> Olcott seems to forget that the action to abort was programmed already 
>> BEFORE the abort took place. So, the simulated HHH was programmed to 
>> see the 'special condition' and abort, BEFORE the simulating HHH 
>> aborted it.
>> It is incorrect to assume that the abort code that is present BEFORE 
>> the abort takes place, would not be executed in the simulated program, 
>> only because the simulation has not yet reached it.
>>
>> In other words, before-the-fact of the abort, the simulation did not 
>> halt and there is no reason to decide that there is non-halting 
>> behaviour. So, the only reason to decide about the halting behaviour 
>> is found in the code that would be executed after-the-fact. And there 
>> we find the code to see the detection of a 'special condition' and the 
>> abort.
>>
>>>
>>>>> Except for the case of pathological self-reference the behavior of the
>>>>> directly executed machine M is always the same as the correctly
>>>>> simulated finite string ⟨M⟩.
>>>
>>>> That sure sounds like a mistake to me.
>>>>
>>>
>>> THE EXECUTION TRACE HAS ALWAYS PROVED THAT I AM CORRECT
>>> FOR THREE FREAKING YEARS all the way back when it was
>>> P correctly emulated by D.
>>
>> No, it has always shown that the abort was too soon, one cycle before 
>> the simulated HHH would reach the code to see the 'special condition', 
>> after which it would abort and return.
>>
>>
>>>
>>> IT REMAINS A VERIFIED FACT THAT DDD EMULATED BY HHH CANNOT
>>> POSSIBLY REACH ITS OWN FINAL HALT STATE, 
>>
>> Exactly, I have repeated this many times, because it proves that the 
>> simulation is incorrect.
>> HHH cannot possibly simulate itself correctly up to the end. That 
>> there is an end is proved by the direct executions, by the simulations 
>> of the world class simulator and even by HHH1.
>>
>> The meaning of the input, a finite string that describes the program, 
>> is fixed by the semantics of the x86 language. It does not depend on 
>> who or what interprets it.
>> But olcott thinks he can change the meaning of it by using a crippled 
>> simulator that is unable to reach the end of the simulation.
> 
>