Path: ...!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: DDD specifies recursive emulation to HHH and halting to HHH1
Date: Tue, 1 Apr 2025 07:01:05 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <737b0e3578df516ddccaf95564b4a3bb720db843@i2pn2.org>
References: <vrfuob$256og$1@dont-email.me> <vs9t45$2f6n5$1@dont-email.me>
 <9f2ff3ab9b99a7bb6dfa0885f9757f810ce52e66@i2pn2.org>
 <vsaam4$2sfhq$1@dont-email.me> <vsbi7e$1hblk$1@dont-email.me>
 <vsc6qi$27lbo$2@dont-email.me>
 <8a3e7e93e6cad20b29d23405a0e6dbd497a492ac@i2pn2.org>
 <vscegq$2fv3s$2@dont-email.me>
 <26f33bb039fda7d28ae164cfc4d0f582d4698f31@i2pn2.org>
 <vsclsb$2n4jc$1@dont-email.me>
 <36a4c76730b23cf78ddde73c723116b5380973a1@i2pn2.org>
 <vsctnm$2ub5m$2@dont-email.me>
 <72d003704b5bacf77110750e8c973d62869ad204@i2pn2.org>
 <vsf402$1crun$4@dont-email.me> <vsf49v$1adee$1@dont-email.me>
 <vsf520$1crun$5@dont-email.me> <vsf6fp$1adee$2@dont-email.me>
 <vsf8pp$1i673$1@dont-email.me> <vsfbp9$1l8n5$1@dont-email.me>
 <vsfdji$1m8qr$1@dont-email.me> <vsfe0c$1l8n5$2@dont-email.me>
 <vsffcj$1m8qr$5@dont-email.me> <vsfg3q$1l8n5$3@dont-email.me>
 <vsfi2t$1r8rb$1@dont-email.me> <vsfisi$1l8n5$4@dont-email.me>
 <vsfjj1$1s8b0$1@dont-email.me> <vsfk61$1l8n5$5@dont-email.me>
 <vsfkn6$1s8b0$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 1 Apr 2025 11:06:46 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2664280"; 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: <vsfkn6$1s8b0$2@dont-email.me>
Content-Language: en-US
Bytes: 5280
Lines: 100

On 3/31/25 10:57 PM, olcott wrote:
> On 3/31/2025 9:48 PM, dbush wrote:
>> On 3/31/2025 10:38 PM, olcott wrote:
>>>
>>> HHH must report on the behavior that its input
>>> actually specifies. 
>>
>> And the input specifies an algorithm that halts when executed directly.
>>
> 
> Which is NOT how it is executed.
> It IS executed with recursive emulation.

But of COURSE that is how it is executed.

That is what the actual problem statement says to do.

Your problem is you got on your strawman chain so long ago you forget 
the meaning of the actual problem.

Or maybe your problem is that you don't understand the concept of 
directly executiong things, as that is like "Reality", but you only 
think in the realm of imagination, which is more like simulation, 
particularly when you don't require the simulation to be strictly "correct"

> 
>>> This seems way too difficult
>>> for people that can only spout off words that
>>> they learned by rote, with no actual understanding
>>> of the underlying principles involved.
>>>
>>> Every actual computation can only transform input
>>> finite strings into outputs. HHH does do this.
>>
>> But not as per the requirements:
>>
> 
>>
>> Given any algorithm (i.e. a fixed immutable sequence of instructions) 
>> X described as <X> with input Y:
>>
>> A solution to the halting problem is an algorithm H that computes the 
>> following mapping:
>>
>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed 
>> directly
>>
>>
>>>
>>> The "requirements" that you mindlessly spout off
>>
>> Which would make all true statements provable if they could be met.
>>
>>> violate this foundational principle of functions
>>> computed by Turing machines.
>>
>> Which just says that no Turing machine satisfies those requirements, 
>> as Linz and others proved.
>>
>>>
>>> int sum(int x, int y)
>>> {
>>>    return 5;
>>> }
>>>
>>> sum(2,3) does not compute the sum of 2 + 3.
>>>
>>
>>
>> It absolutely does.  There are *NO* requirements on the 
>> implementation, only the result.
> 
> Unless and algorithm transforms its inputs
> into its outputs it is not a Turing computable
> function.
> 

But the problem is to try to FIND an algorithm. No algorithm has been 
given, just a problem. There is no presumption that the problem has a 
solution as a Turing Computable function.

Problems are not stated as algorithms, but by mappings to try to find an 
algorithm that computes it.

We are not playing Jeopardy where they give the answer and we need to 
determine the question.

The Halting problem STARTS with a problem definition, to try to compute 
the mapping of a full description of a algorithm and its input, to 
whether that algorith will halt on that input when it is run.

The input needs to be a full algorithm, and thus your DDD needs to 
include as part of it, the HHH that it calls, and everything that HHH calls.

When you do that, the mapping of that particular algorithm to the answer 
is possible.

The problem is that your decider, which had to have been defined before 
we built that input, because the algorithm used to build it had that as 
a dependency, just returns the wrong answer.