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: Functions computed by Turing Machines MUST apply finite string
 transformations to inputs
Date: Sat, 3 May 2025 12:07:49 -0500
Organization: A noiseless patient Spider
Lines: 148
Message-ID: <vv5ih6$3vfls$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 03 May 2025 19:07:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b43009eaccf0df9143009b2b43dae7eb";
	logging-data="4177596"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18IOlSDxuO68ODhOsI7T2jk"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:cWcItvAcmbZmcJhHcQeRCITdMQg=
In-Reply-To: <-GOdnZvgEPn-84j1nZ2dnZfqn_SdnZ2d@brightview.co.uk>
Content-Language: en-US
X-Antivirus: Norton (VPS 250503-4, 5/3/2025), Outbound message
X-Antivirus-Status: Clean
Bytes: 7504

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.

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

-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer