Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.org>
Newsgroups: comp.theory
Subject: Re: ChatGPT refutes the key rebuttal of my work
Date: Wed, 16 Oct 2024 06:33:11 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <82cb937f8012d3353dde47aa2d8565883d10a92a@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 16 Oct 2024 06:33:11 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2247835"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5680
Lines: 80

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

>>>>> 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.

>>>>>>> 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?

>>>>> 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.

-- 
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.