Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sat, 10 May 2025 10:43:38 -0500
Organization: A noiseless patient Spider
Lines: 160
Message-ID: <vvns7a$3in62$8@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me> <vvlnad$2uvnf$5@dont-email.me>
 <vvlnpj$30vce$1@dont-email.me> <vvlsp5$31vqc$1@dont-email.me>
 <vvlv04$32kt3$1@dont-email.me> <87r00xchn5.fsf@nosuchdomain.example.com>
 <23a27379d226b7b3b9f8c303a492f66edc9019ff.camel@gmail.com>
 <vvmgtr$3a34p$7@dont-email.me>
 <1020d30c2c5b5a7cce584777131d5ce414b480ea.camel@gmail.com>
 <vvmk29$3atmt$3@dont-email.me>
 <0323d5ca6d757a1e35d7e4cf5eb4fc8f41bc866a.camel@gmail.com>
 <vvmlk0$3blcs$1@dont-email.me>
 <c6904fbe42c4ad1eb3d1dcc50d18e6e75f159d75.camel@gmail.com>
 <vvmmtd$3bqvb$1@dont-email.me>
 <9f5774bfb493325652f97d72f760ad98442c333d.camel@gmail.com>
 <vvmnl5$3c2gn$1@dont-email.me>
 <f430dde2c5313bf6657c11b7a9eca183e2432291.camel@gmail.com>
 <vvmou2$3cac3$1@dont-email.me>
 <84b09a0d53d77e2a8fddf567226d05c0d65e60c0.camel@gmail.com>
 <vvmqdo$3ce48$1@dont-email.me>
 <235107421488220fb79fa83cbe8bf44709f6445a.camel@gmail.com>
 <vvnp62$3in62$3@dont-email.me>
 <83120a5793367c0231c0ecef701f26c51d35055b.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 10 May 2025 17:43:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7be348abb5bc2ec0a70724586a3ca680";
	logging-data="3759298"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18GK3DkKbe2JYLXPihoXMLY"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:kPsgRYFY2nGRfVxCsTVY3trKttg=
X-Antivirus-Status: Clean
Content-Language: en-US
X-Antivirus: Norton (VPS 250510-2, 5/10/2025), Outbound message
In-Reply-To: <83120a5793367c0231c0ecef701f26c51d35055b.camel@gmail.com>
Bytes: 7681

On 5/10/2025 10:14 AM, wij wrote:
> On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
>> On 5/10/2025 1:19 AM, wij wrote:
>>> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
>>>> On 5/10/2025 1:00 AM, wij wrote:
>>>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
>>>>>> On 5/10/2025 12:27 AM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 12:13 AM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
>>>>>>>>>> When mathematical mapping is properly understood
>>>>>>>>>> it will be known that functions computed by models
>>>>>>>>>> of computation must transform their input into
>>>>>>>>>> outputs according to the specific steps of an
>>>>>>>>>> algorithm.
>>>>>>>>>>
>>>>>>>>>> _DDD()
>>>>>>>>>> [00002172] 55         push ebp      ; housekeeping
>>>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping
>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
>>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>>>>>>>> [0000217f] 83c404     add esp,+04
>>>>>>>>>> [00002182] 5d         pop ebp
>>>>>>>>>> [00002183] c3         ret
>>>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>>>
>>>>>>>>>> For example HHH(DDD) only correctly map to the
>>>>>>>>>> behavior that its input actually specifies by correctly
>>>>>>>>>> emulating DDD according to the rules of the x86 language.
>>>>>>>>>>
>>>>>>>>>> This causes the first four instructions of DDD
>>>>>>>>>> to be emulated followed by HHH emulating itself
>>>>>>>>>> emulating the first three instructions of DDD.
>>>>>>>>>>
>>>>>>>>>> It is right at this recursive simulation just
>>>>>>>>>> before HHH(DDD) is called again that HHH recognizes
>>>>>>>>>> the repeating pattern and rejects DDD.
>>>>>>>>>
>>>>>>>>> Yes, but you still did not answer the question: Is POOH exactly about HP?
>>>>>>>>>
>>>>>>>>
>>>>>>>>      >>>>> H(D)=1 if D() halt.
>>>>>>>>      >>>>> H(D)=0 if D() not halt.
>>>>>>>>
>>>>>>>> Right now it is mostly about proving the
>>>>>>>> above requirements are is mistaken.
>>>>>>>>
>>>>>>>
>>>>>>> Why is the requirement invalid?
>>>>>>>
>>>>>>> H(D)=1 if D() halt.
>>>>>>> H(D)=0 if D() not halt.
>>>>>>>
>>>>>>
>>>>>
>>>>>> The notion that the behavior specified by the finite
>>>>>> string input to a simulating termination analyzer
>>>>>
>>>>> POOH reads(takes) its input as a function, not 'finite string'.
>>>>> Are you talking about POOH now? There is no POOH that takes
>>>>> 'finite string'.
>>>>>
>>>>
>>>> It <is> a finite string of x86 bytes.
>>>
>>> Disagree.
>>> The D in Halt7.c (I just saw once) does not treat H as 'finite string',
>>> D calls H. H also does not treat D as 'finite string'.
>>>
>>
>> HHH and DDD and DD are the most recent functions.
>> HHH does emulate its finite strings of x86 machine code
>> according to the rules of the x86 language.
> 
> This is from a copy of Halt7.c:
> 
> void P(ptr x)
> {
>    int Halt_Status = H(x, x);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return;
> }
> 
> int main()
> {
>    Output("Input_Halts = ", H(P, P));
> }
> 
> H reads a *pointer*.
> In P, P *calls* H.
> 
> Both do not process 'finite string'.
> 

What it is it a pointer to a box of chocolates?
finite strings are passed as pointers to finite
string in C.

>>>>>> does sometimes differ from the behavior of its direct
>>>>>> execution. It is a provably different sequence of steps.
>>>>>
>>>>
>>>> This is a verified fact.
>>>> The pathological relationship that inputs can have
>>>> with their simulating termination analyzer changes
>>>> the behavior of these inputs relative to their direct
>>>> execution.
>>>
>>> So, you redefined the halting problem should be about the behavior of D
>>> decided by POOH, not the 'direct' behavior of D?
>>>
>>
>> Not at all. HHH(DDD) reports on the behavior that DDD
>> actually specifies. All my critics require HHH to report
>> on behavior that DDD does not actually specify.
>>
>> The actual behavior that DDD specifies is measured
>> by HHH emulating DDD according to the rules of the
>> x86 language. My critics insist on ignoring these
>> rules because it does not derive the behavior that
>> they expect.
> 
>  From this reply and others before. Can we conclude that POOH is
> about the pathological relationship inputs to the halting decider H.
> IOW, POOH computes the function: POOH(D)=1 iff D is pathological.
> 
> POOH is not about the 'incorrect' problem HP: POOH(D)=1 iff D() halt?
> 

Once we have the extra detail about how models
of computation computing functions must compute
the mapping from their actual inputs to the
behaviors that these inputs actually specify

then we can see that I corrected a mistake in
the theory of computation.

>> I proved that these expectations are incorrect.
>>
>> int sum(int x, int y) { return x + y ;}
>> sum must apply the rules of arithmetic to
>> its inputs thus sum(3,2) cannot correctly
>> derive the sum of 5 + 7.
>>
>> HHH must apply the rules of the x86 language
>> to its input DDD. This results in DDD calling
>> HHH(DDD) in recursive emulation.
>>
>> When HHH1(DDD) applies these same rules to its input
>> there is no recursive emulation because DDD does
>> not call HHH1(DDD).
>>
> 
> 


========== REMAINDER OF ARTICLE TRUNCATED ==========