Deutsch   English   Français   Italiano  
<3f30fd7f1122987120189ba2c9d342a7d8f9e805@i2pn2.org>

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

Path: ...!eternal-september.org!feeder2.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: The philosophy of computation reformulates existing ideas on a
 new basis ---
Date: Mon, 4 Nov 2024 19:21:15 -0500
Organization: i2pn2 (i2pn.org)
Message-ID: <3f30fd7f1122987120189ba2c9d342a7d8f9e805@i2pn2.org>
References: <vfli1h$fj8s$1@dont-email.me> <vflue8$3nvp8$2@i2pn2.org>
 <vfmd8m$k2m7$1@dont-email.me>
 <bcd82d9f8a987d3884220c0df7b8f7204cb9de3e@i2pn2.org>
 <vfmueh$mqn9$1@dont-email.me>
 <ff039b922cabbb6d44f90aa71a52d8c2f446b6ab@i2pn2.org>
 <vfo95k$11qs1$1@dont-email.me> <vfp8c0$3tobi$2@i2pn2.org>
 <vfpbtq$1837o$2@dont-email.me> <vfq4h9$1fo1n$1@dont-email.me>
 <vfqrro$1jg6i$1@dont-email.me> <vfvnbk$2lj5i$1@dont-email.me>
 <vfvudo$2mcse$5@dont-email.me> <vg2c7p$379h1$1@dont-email.me>
 <vg2hei$37lpn$8@dont-email.me> <vg5030$3oo1p$1@dont-email.me>
 <vg56vn$3pnvp$2@dont-email.me> <vg7pab$bqa3$1@dont-email.me>
 <vg81v7$d0a1$2@dont-email.me> <vgaksg$vp4q$1@dont-email.me>
 <vgalsc$vele$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 5 Nov 2024 00:21:15 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="983619"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vgalsc$vele$2@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4835
Lines: 87

On 11/4/24 9:31 AM, olcott wrote:
> On 11/4/2024 8:14 AM, Mikko wrote:
>> On 2024-11-03 14:39:35 +0000, olcott said:
>>
>>> On 11/3/2024 6:11 AM, Mikko wrote:
>>>>
>>>>
>>>> It is not clear at all unless you specify how those finite
>>>> strings specify the actual behaviour.
>>>
>>> That is why I used to fully defined semantics of the x86
>>> language to make this 100% perfectly unequivocal.
>>
>> It does not add any clarity to the last paragraph before
>> my previous comment.
>>
> 
> I always respond to the immediately preceding paragraph.
> The finite strings specify actual behavior on the basis
> of the semantics of the x86 language.

But to do so, you need ALL the code, and the emulation done (or at least 
looked at) must be non-aborting, or it isn't by the semantics.

> 
>>> A few lines of x86 code express complex algorithms
>>> succinctly enough that human minds are not totally
>>> overwhelmed by far too much tedious detail.
>>>
>>>> It is not pspecified
>>>> in the usual formulation of the problem. Also note that
>>>> the behaviour exists before those strings so "describe"
>>>> should be and usually is used instead of "specify". The
>>>> use of latter may give the false impression that the behaviour
>>>> is determined by those strings.
>>>>
>>>
>>> In order for any machine to compute the mapping from
>>> a finite string it must to so entirely on the basis
>>> of the actual finite string and its specified semantics.
>>>
>>> The finite string input to HHH specifies that HHH
>>> MUST EMULATE ITSELF emulating DDD.
>>>
>>> The finite string input to HHH1 specifies that HHH1
>>> MUST NOT EMULATE ITSELF emulating DDD.
>>>
>>> Unless HHH rejects its input DDD as non halting the
>>> executed DDD never stops running. This itself proves
>>> that HHH is correct and that DDD is not the same
>>> instance as the one that HHH rejected.
>>>
>>>>> It is true that when we construe the halting criteria as
>>>>> requiring taking into account how a pathological relationship
>>>>> changes the behavior of the input instead of simply ignoring
>>>>> this behavior change that pathological inputs become decidable
>>>>> as non-halting.
>>>>
>>>> It is true that doing that means leaving the halting proble unsolved.
>>>>
>>>
>>> The HP proofs are refuted by my work.
>>
>> No. Talking about something else does not refute.
>>
> 
> As long as it is understood that it has always simply been
> incorrect to construe that behavior of the input finite
> string as anything other than the actual behavior that this
> finite string specifies which includes HHH emulating itself
> emulating DDD then I have refuted the original proofs.
> 
> (a) Finite string of x86 machine code DDD +
> (b) The semantics of the x86 language +
> (c) DDD is calling its own termination analyzer
> ∴ HHH is correct to reject its input as non-halting
> 
> We can only get to the behavior of the directly
> executed DDD() by ignoring (b) or (c)
> 
>>> This is not quite the same ting as solving the halting problem.
>>
>> It is very far even from any thinking about the possibility to solve
>> the halting problem.
>>
> 
>