Path: news.eternal-september.org!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: Functions computed by Turing Machines MUST apply finite string
 transformations to inputs
Date: Sat, 3 May 2025 17:47:48 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <664a8c9fd8edbd4ebd52c18d42061364779a6cdc@i2pn2.org>
References: <TuuNP.2706011$nb1.2053729@fx01.ams4>
 <87cyd5182l.fsf@nosuchdomain.example.com> <vu6lnf$39fls$2@dont-email.me>
 <vugddv$b21g$2@dont-email.me> <vui4uf$20dpc$1@dont-email.me>
 <vuivtb$2lf64$3@dont-email.me> <vungtl$2v2kr$1@dont-email.me>
 <vuoaac$3jn5n$5@dont-email.me> <vuq81v$1hjka$1@dont-email.me>
 <vutefq$gmbi$3@dont-email.me>
 <991dde3a60e1485815b789520c7149e7842d18f2@i2pn2.org>
 <vuti3c$jq57$1@dont-email.me> <vutmr6$nvbg$2@dont-email.me>
 <vutv7r$v5pn$4@dont-email.me> <vuu73m$151a8$3@dont-email.me>
 <vuuej8$1cqp7$1@dont-email.me> <vuur2n$1qe3m$2@dont-email.me>
 <vv0352$2ur4q$1@dont-email.me> <vv0kpi$3djh5$1@dont-email.me>
 <vv13ro$3r3ei$1@dont-email.me> <vv160a$3smj7$1@dont-email.me>
 <vv18s7$3uer0$1@dont-email.me> <vv1b03$4a4k$2@dont-email.me>
 <vv1bav$3ra6l$7@dont-email.me> <vv1frt$97hp$1@dont-email.me>
 <vv1gfu$3ra6l$8@dont-email.me> <vv1js4$d4ik$1@dont-email.me>
 <-GOdnZvgEPn-84j1nZ2dnZfqn_SdnZ2d@brightview.co.uk>
 <vv5ih6$3vfls$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 3 May 2025 21:48:05 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3010306"; 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: <vv5ih6$3vfls$1@dont-email.me>
Content-Language: en-US

On 5/3/25 1:07 PM, olcott wrote:
> On 5/2/2025 8:16 PM, Mike Terry wrote:
>> On 02/05/2025 06:06, Richard Heathfield wrote:
>>> On 02/05/2025 05:08, dbush wrote:
>>>> On 5/1/2025 11:57 PM, olcott wrote:
>>>>> On 5/1/2025 9:40 PM, dbush wrote:
>>>
>>> <snip>
>>>
>>>>>> So you changed the input.  Changing the input is not allowed.
>>>>>>
>>>>>
>>>>> I never changed the input.
>>>>
>>>> Yes you did.  You hypothesize changing the code of HHH, and HHH is 
>>>> part of the input. So you changed the input.
>>>
>>>
>>> Agreed.
>>>
>>>> Changing the input is not allowed.
>>>
>>> Wweellll...
>>>
>>> I have a very minor objection to that view, an objection that I've 
>>> wrapped up into a thought experiment.
>>>
>>> Let us hypothesise the paradoxical existence of U, a universal 
>>> decider. If we pass it an arbitrary P and an arbitrary D, it can defy 
>>> Turing (we're just hypothesising, remember) and produce a correct 
>>> result. Cool, right? The snag is that it's a black box. We can't see 
>>> the code.
>>>
>>> We set it to work, and for years we use it to prove all manner of 
>>> questions - PvNP, Collatz, Goldbach, Riemann, the lot - and it turns 
>>> out always to be right. That's good, right?
>>>
>>> But then one fine day in 2038 we are finally allowed to see the 
>>> source code for U, which is when we discover that the algorithm 
>>> >>>changes the input<<< in some small way. Does that invalidate the 
>>> answers it has been providing for over a decade, thousands of answers 
>>> that have / all/ been verified?
>>
>> Nobody would suggest that TMs aren't allowed to write to their tape!  
>> Of course, that's part of how they work, and is not what posters mean 
>> by PO "changing the input".
>>
>>>
>>> I would argue that it doesn't. Provided U(P,D) correctly reports on 
>>> the behaviour a P(D) call would produce, I would argue that that's 
>>> all that matters, and the fact that U twiddles with the P and D tapes 
>>> and turns them into P' and D' is irrelevant, as long as the result we 
>>> get is that of P(D), not P'(D').
>>
>> Right.  What you're describing is business as usual for TMs.
>>
>>>
>>> Let me show this graphically using a much simpler example - addition:
>>>
>>> D: 1111111111+1111111
>>> P: add 'em up
>>>
>>> P(D)!
>>>
>>> D': 11111111111111111
>>>
>>> P has changed its input by changing the + to a 1 and erasing the last 
>>> 1, and D' now holds the correct answer to the question originally 
>>> posed on D.
>>>
>>> I would argue that this is /perfectly fine/, and that there is 
>>> nothing in Turing's problem statement to forbid it. But of course we 
>>> must be careful that, even if U does change its inputs to P' and D', 
>>> it must still correctly answer the question P(D).
>>
>> Nothing wrong with that.
>>
>> BTW all the stuff above about universal deciders turns out to be 
>> irrelevant to your argument!  (It just seems a bit odd to choose a 
>> non- existant TM as an example when any other (existant) TM would do 
>> the job more clearly...)
>>
>>>
>>> Of course, Mr Olcott's change is rather different, because by 
>>> changing his HHH he's actually changing the behaviour of his DD - 
>>> i.e. specifying a new U - but I see no reason why he can't do that / 
>>> provided/ he can show that he always gets the correct answer. He has 
>>> so far failed to do this with the original HHH, and now he has 
>>> doubled his workload by giving himself another HHH to defend.
>>
>> Right - PO's H is free to rewrite the tape in whatever way it likes, 
>> provided in the end it gets the right answer.
>>
>> The "you're not allowed to change the input" charge means something 
>> quite different.
>>
>> TLDR:  Your talking about TMs writing to their tape as part of their 
>> normal operation.  Nothing wrong with that.  PO is effectively talking 
>> about changing the meaning of D [the input to H] half way through the 
>> Sipser quote.
>>
>> -----------------------------------------------------------------------------
>> NTLFM:
>>
>> PO is trying to interpret Sipser's quote:
>>
>> --- Start Sipser quote
>>       If simulating halt decider H correctly simulates its input D
>>       until H correctly determines that its simulated D would never
>>       stop running unless aborted then
>>
>>       H can abort its simulation of D and correctly report that D
>>       specifies a non-halting sequence of configurations.
>> --- End Sipser quote
>>
>> The following interpretation is ok:
>>
>>      If H is given input D, and while simulating D gathers enough
>>      information to deduce that UTM(D) would never halt, then
>>      H can abort its simulation and decide D never halts.
>>
> 
> That is the same way that ChatGPT understands it.
> 
> *ChatGPT Analyzes Simulating Termination Analyzer*
> https://www.researchgate.net/ 
> publication/385090708_ChatGPT_Analyzes_Simulating_Termination_Analyzer
> 
> For DD/HHH
> 
> int DD()
> {
>    int Halt_Status = HHH(DD);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }
> 
> HHH determines whether or not DD would halt
> if HHH would have been a pure simulator.

But HHH is NOT a pure simulator, so that doesn't matter, at that HHH 
never answers

Remember the input DD depend on the code of the decider it is defined to 
call, so your input changes.

It seems, you are just so stupid as to not understand what a program 
actually is.

> 
> ChatGPT DOES understand hypothetical possibilities
> and does understand that HHH computes the termination
> status of its input on the basis of these hypothetical
> possibilities.
> 

No, it just shows that it is as stupid as you, and believes (or pretends 
to in order to make you happy) your lies.