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: ChatGPT refutes the key rebuttal of my work
Date: Wed, 16 Oct 2024 20:06:10 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <6480286d1baf912ed5c7284d7049ab9d38d7e177@i2pn2.org>
References: <vegfro$lk27$9@dont-email.me> <veimqs$14que$1@dont-email.me>
 <veipf3$15764$1@dont-email.me>
 <36ecdefcca730806c7bd9ec03e326fac1a9c8464@i2pn2.org>
 <vejcoj$1879f$1@dont-email.me>
 <034767682966b9ac642993dd2fa0d181c21dfffc@i2pn2.org>
 <vekj4q$1hrgd$1@dont-email.me>
 <f8a15594bf0623a229214e2fb62ce4f4a2bd7116@i2pn2.org>
 <velpm2$1n3gb$6@dont-email.me>
 <8f12bccec21234ec3802cdb3df63fd9566ba9b07@i2pn2.org>
 <vemc30$1q255$1@dont-email.me>
 <3b7102e401dc2d872ab53fd94fc433841caf3170@i2pn2.org>
 <vemhn0$1qqfr$2@dont-email.me>
 <bfa96cc6bd41f1351cf3c47ec5712b7fc3803f6d@i2pn2.org>
 <vemo4j$1roph$1@dont-email.me>
 <82cb937f8012d3353dde47aa2d8565883d10a92a@i2pn2.org>
 <veof7v$284qn$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 17 Oct 2024 00:06:10 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2363984"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <veof7v$284qn$3@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 7917
Lines: 142

On 10/16/24 9:31 AM, olcott wrote:
> On 10/16/2024 1:33 AM, joes wrote:
>> Am Tue, 15 Oct 2024 16:51:15 -0500 schrieb olcott:
>>> On 10/15/2024 4:24 PM, joes wrote:
>>>> Am Tue, 15 Oct 2024 15:01:36 -0500 schrieb olcott:
>>>>> On 10/15/2024 2:33 PM, joes wrote:
>>>>>> Am Tue, 15 Oct 2024 13:25:36 -0500 schrieb olcott:
>>>>>>> On 10/15/2024 10:17 AM, joes wrote:
>>>>>>>> Am Tue, 15 Oct 2024 08:11:30 -0500 schrieb olcott:
>>>>>>>>> On 10/15/2024 6:35 AM, Richard Damon wrote:
>>>>>>>>>> On 10/14/24 10:13 PM, olcott wrote:
>>>>>>>>>>> On 10/14/2024 6:50 PM, Richard Damon wrote:
>>>>>>>>>>>> On 10/14/24 11:18 AM, olcott wrote:
>>>>>>>>>>>>> On 10/14/2024 7:06 AM, joes wrote:
>>>>>>>>>>>>>> Am Mon, 14 Oct 2024 04:49:22 -0500 schrieb olcott:
>>>>>>>>>>>>>>> On 10/14/2024 4:04 AM, Mikko wrote:
>>>>>>>>>>>>>>>> On 2024-10-13 12:53:12 +0000, olcott said:
>>>>>>
>>>>>>>>>>> https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e
>>>>>>>>>>> When you click on the link and try to explain how HHH must be
>>>>>>>>>>> wrong when it reports that DDD does not terminate because DDD
>>>>>>>>>>> does terminate it will explain your mistake to you.
>>>>>>>>>> I did that, and it admitted that DDD halts, it just tries to
>>>>>>>>>> justify why a wrong answer must be right.
>>>>>>>>> It explains in great detail that another different DDD (same
>>>>>>>>> machine code different process context) seems to terminate only
>>>>>>>>> because the recursive emulation that it specifies has been aborted
>>>>>>>>> at its second recursive call.
>>>>>>>> Yes! It really has different code, by way of the static Root
>>>>>>>> variable.
>>>>>>>> No wonder it behaves differently.
>>>>>>> There are no static root variables. There never has been any "not a
>>>>>>> pure function of its inputs" aspect to emulation.
>>>>>> Oh, did you take out the check if HHH is the root simulator?
>>>>> There is some code that was obsolete several years ago.
>>>> I don't follow your repo. Can you point me to the relevant commit?
>>>> It doesn't seem to have happened this year.
>>> https://github.com/plolcott/x86utm Halt7.c was updated last month.
> 
>> Nope, still there: https://github.com/plolcott/x86utm/blob/master/
>> Halt7.c#L502
>>
> 
> https://github.com/plolcott/x86utm/blob/master/Halt7.c#L502
> shows: u32 H(ptr P, ptr I)  // 2024-09-15 was HH
> and edit on line 643
> 
> The repository indicates that it was updated: "last month"
> 
>>>>>>> Every termination analyzer that emulates itself emulating its input
>>>>>>> has always been a pure function of this input up to the point where
>>>>>>> emulation stops.
>>>>>> That point can never come in the complete simulation of a non-
>>>>>> terminating input, because it is infinite.
>>>>> You and Richard never seemed to understand this previously.
>>>> You seemed to not understand that a simulation may be nonterminating.
>>> Sure yet only when the input is non-terminating.
> 
>> Sure.
>>
> 
> Therefore if HHH even guesses that its input is non-termination
> then HHH is correct.
> 
>>>>>>>>> You err because you fail to understand how the same C/x86 function
>>>>>>>>> invoked in a different process context can have different
>>>>>>>>> behavior.
>>>>>>>> Do explain how a pure function can change.
>>>>>>> Non-terminating C functions do not ever return, thus cannot possibly
>>>>>>> be pure functions.
>>>>>> By "pure" I mean having no side effects. You mean total vs. partial.
>>>>> You may be half right. Only the analyzer must be pure.
>>>>> The input is free to get stuck in an infinite loop.
>>>> Sure. How can a function without side effects have different behaviour?
>>> DDD is free to be totally screwed up every which way.
>>> It is only HHH that must be a pure function.
> 
>> In which way is DDD screwed up that it is both free of side effects and
>> referentially intransparent?
>>
> 
> In other words you don't have a clue that an input to a
> termination analyzer can be non-terminating thus violating
> the (1) criteria of pure functions shown below.

Nothing in the definition actually requires the "pure function" to 
return, it just must always not return every time it is given identical 
arguements.

> 
> void Infinite_Recursion()
> {
>    Infinite_Recursion();
>    OutputString("Can't possibly get here!");
> }
> 
> (1) *the function return values are identical for identical arguments*
> (no variation with local static variables, non-local variables, mutable
> reference arguments or input streams, i.e., referential transparency), and
> (2) the function has no side effects (no mutation of local static
> variables, non-local variables, mutable reference arguments or input/
> output streams). https://en.wikipedia.org/wiki/Pure_function
> 
> When-so-ever any input to a termination is non-terminating
> analyzer is non-terminating for any reason then this input
> is not a pure function.

By what?

Always not-returning is having the same return value for every identical 
arguement.

This is part of the problem of using non-formal sources.

> 
> Terminating C functions must reach their "return" statement.
> Failing to reach their "return" statement proves non-termination.

Right, and every DDD that calls and HHH that returns 0 from the call to 
HHH(DDD) is proven to terminate, and thus that HHH is just incorrect.

Partial emulations do not determine final behavior, which is just a fact 
you don't seem to understand and try to avoid by using equivocation.

> 
>>>>>>> HHH is a pure function of its input the whole time that it is
>>>>>>> emulating.
>>>>>>> DDD has no inputs and is allowed to be any finite string of x86
>>>>>>> code.
>>>>>>> Inputs to HHH are by no means required to ever return AT ALL.
>>>>>> I thought DDD was fixed to only call HHH(DDD)?
>>>>> Inputs are not required to be pure functions.
>>>> Weren't we discussing the halting DDD(){HHH(DDD);} before?
>>> For many months now I have been talking about the termination analyzer
>>> HHH applied to input DDD.
>>> I am not aware of ever referring to HHH as a halt decider. When I talk
>>> about halt deciders I talk about the Linz proof.
> 
>> I am, as of a couple months back. This is still related to the Linz 
>> proof.
>>
>