Deutsch   English   Français   Italiano  
<68fb136230c89f4df761d5b84aab1f6ca4f5eebe@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
Subject: Re: DDD correctly emulated by HHH is INcorrectly rejected as
 non-halting.
Date: Sun, 14 Jul 2024 14:22:29 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <68fb136230c89f4df761d5b84aab1f6ca4f5eebe@i2pn2.org>
References: <v6m7si$1uq86$2@dont-email.me> <v6mhc7$20hbo$2@dont-email.me>
 <v6mhr3$20kkr$2@dont-email.me> <v6nts5$2be3m$1@dont-email.me>
 <v6op4h$2fuva$4@dont-email.me> <v6qo1d$2ugov$1@dont-email.me>
 <v6rajl$30qtt$7@dont-email.me> <v6tc75$3gidj$1@dont-email.me>
 <v6tri1$3imib$9@dont-email.me> <v702t1$2lgb$1@dont-email.me>
 <v70mel$61d8$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 14 Jul 2024 18:22:29 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3273011"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v70mel$61d8$2@dont-email.me>
Bytes: 6098
Lines: 128

On 7/14/24 10:13 AM, olcott wrote:
> On 7/14/2024 3:40 AM, Mikko wrote:
>> On 2024-07-13 12:22:24 +0000, olcott said:
>>
>>> On 7/13/2024 3:00 AM, Mikko wrote:
>>>> On 2024-07-12 13:20:53 +0000, olcott said:
>>>>
>>>>> On 7/12/2024 3:03 AM, Mikko wrote:
>>>>>> On 2024-07-11 14:10:24 +0000, olcott said:
>>>>>>
>>>>>>> On 7/11/2024 1:25 AM, Mikko wrote:
>>>>>>>> On 2024-07-10 17:53:38 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
>>>>>>>>>> Op 10.jul.2024 om 17:03 schreef olcott:
>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>
>>>>>>>>>>> void DDD()
>>>>>>>>>>> {
>>>>>>>>>>>    HHH(DDD);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>    HHH(DDD);
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Unneeded complexity. It is equivalent to:
>>>>>>>>>>
>>>>>>>>>>        int main()
>>>>>>>>>>        {
>>>>>>>>>>          return HHH(main);
>>>>>>>>>>        }
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Every time any HHH correctly emulates DDD it calls the
>>>>>>>>> x86utm operating system to create a separate process
>>>>>>>>> context with its own memory virtual registers and stack,
>>>>>>>>> thus each recursively emulated DDD is a different instance.
>>>>>>>>
>>>>>>>> However, each of those instances has the same sequence of 
>>>>>>>> instructions
>>>>>>>> that the x86 language specifies the same operational meaning.
>>>>>>>>
>>>>>>>
>>>>>>> *That is counter-factual*
>>>>>>> When DDD is correctly emulated by HHH according to the
>>>>>>> semantics of the x86 programming language HHH must abort
>>>>>>> its emulation of DDD or both HHH and DDD never halt.
>>>>>>
>>>>>> There is not "must" anywhere in the semantics of the programming 
>>>>>> language.
>>>>>>
>>>>>
>>>>> The semantics of the language specifies the behavior of
>>>>> the machine code thus deriving the must.
>>>>
>>>> How can one derive "must" from the semantics of the machine code?
>>>>
>>>
>>> Deciders are required to (thus must) halt.
>>
>> The semantics of the x86 language does not require that, nor that any of
>> the programs is a decider.
>>
> 
> The subject our our conversion is a simulating termination
> analyzer AKA partial halt decider that accepts a finite string

But a "Termination Analyzer" isn't a "Partial Halt Decider" per standard 
definitions, so you are just admitting you don't understand what you are 
talking about, but just lying by making up meaning for words that sound 
reasonable but don't actually match the real meaning of them.

> of x86 code as specifying halting behavior or rejects this
> finite string. Deciders are required to halt thus must abort
> the emulation of any input that would prevent this.

And the x86 code must be COMPLETE, and thus your input string DDD is 
just INVALID for that purpose.

> 
> *You can comprehend this is a truism or fail to*
> *comprehend it disagreement is necessarily incorrect*
> Any input that must be aborted to prevent the non
> termination of HHH necessarily specifies non-halting
> behavior or it would never need to be aborted.

Right, but "Must be aborted" is tested by giving the EXACT SAME INPUT 
(which must include ALL the code of the input) to an unconditional 
emulatior (at least if you want to try to stay in the field of 
Computation Theory, which I am not sure you can keep in it with you errors)l

> 
> Technically any program that halts is a decider.
> In the early days simply halting was acceptance of the input.
> The input was rejected by getting stuck in an infinite loop.

Any program that halts for ALL INPUTS is a decider.

A program that halts in the acceptance state for a class of inputs, and 
for others either halts in a rejection state or never halts is called a 
recognizer. Some recognizers do not have a rejection final state.

> 
> In computability theory, a decider is a Turing machine that
> halts for every input.
> https://en.wikipedia.org/wiki/Decider_(Turing_machine)
> 
> *Here the the definition that I go by*
> Intuitively, a decider should be a Turing machine that given
> an input, halts and either accepts or rejects, relaying its
> answer in one of many equivalent ways, such as halting at
> an ACCEPT or REJECT state, or leaving its answer on the output
> tape. https://cs.stackexchange.com/questions/84433/what-is-decider
> 

Right.

And, to be an XXX Decider, that Accept/Reject condition needs to match 
the definition of the function/language it is trying to decide on.

Halting, is SPECIFICALLY defined, to be whether the input program+input 
represented by the input to the decider will halt when it is run.

It is NOT whether on not the decider can simulate the input to a final 
state.