Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory Subject: Re: ChatGPT agrees that HHH refutes the standard halting problem proof method Date: Tue, 1 Jul 2025 21:31:27 -0400 Organization: i2pn2 (i2pn.org) Message-ID: References: <103jmr5$3h0jc$1@dont-email.me> <103k0sc$2q38$1@news.muc.de> <103k1mc$3j4ha$1@dont-email.me> <103lfn1$ml0$1@dont-email.me> <103m813$6dce$1@dont-email.me> <103ol2u$raq9$1@dont-email.me> <103onmp$rq7e$1@dont-email.me> <103r0ce$1esb9$1@dont-email.me> <103rhf6$1hc53$8@dont-email.me> <0c50a8ee4efb36cef4271674792a090125187f9d@i2pn2.org> <5e7f84c84b4ed51e195dd33afd9ed7eca89be454@i2pn2.org> <103vduo$2flaf$2@dont-email.me> <3450596833f3ad346985a13713de09470d2abdd3@i2pn2.org> <1040ibu$2ql69$5@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 2 Jul 2025 01:31:52 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2962761"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird Content-Language: en-US X-Spam-Checker-Version: SpamAssassin 4.0.0 In-Reply-To: <1040ibu$2ql69$5@dont-email.me> On 7/1/25 7:55 AM, olcott wrote: > On 7/1/2025 6:32 AM, Richard Damon wrote: >> On 6/30/25 9:34 PM, olcott wrote: >>> On 6/30/2025 8:12 PM, Richard Damon wrote: >>>> On 6/30/25 2:30 PM, Mr Flibble wrote: >>>>> On Sun, 29 Jun 2025 22:39:10 -0400, Richard Damon wrote: >>>>> >>>>>> On 6/29/25 3:51 PM, Mr Flibble wrote: >>>>>>> On Sun, 29 Jun 2025 15:00:35 -0400, Richard Damon wrote: >>>>>>> >>>>>>>> Remember, the simulator must be simulating the INPUT, and thus >>>>>>>> to go >>>>>>>> past the call HHH instruction, the code must be part of the >>>>>>>> input, and >>>>>>>> the input needs to be a constant. >>>>>>> No. If HHH is simulating DDD then HHH can detect a call to itself >>>>>>> being >>>>>>> passed DDD within DDD and can assert at that point that the input is >>>>>>> non- >>>>>>> halting. >>>>>>> >>>>>>> /Flibble >>>>>> >>>>>> And thus isn't simu;ating THE INPUT, and that the input isn't a >>>>>> PROGRAM. >>>>>> >>>>>> Also, what if DDD is using a copy of HHH, as per the proof program, >>>>>> which might have variations in the code. >>>>>> >>>>>> Sorry, just shows you don't understand the problem. >>>>> >>>>> No. A simulator does not have to run a simulation to completion if >>>>> it can >>>>> determine that the input, A PROGRAM, never halts. >>>>> >>>>> /Flibble >>>> >>>> Right, but the program of the input DOES halt. >>>> >>> >>> The directly executed DDD() *IS NOT AN INPUT* >> >> Then you are lying about having followed the proof. >> > > Because TM's only take finite string inputs > and no directly executed TM is a finite string > no TM's take directly executed TMs as inputs. Right, but finite stings can represent Turing Macines. I guess you also must claim that Turing Machine (and thus computers) can't actually do arithmatic, as NUMBERS are not finite string, they only have finite strig representations. You have been told this many times, and you are just proving that you don't understand this simple abstractions. You problem seems to be that you think the string "10" *IS* the number ten, and not just a representation of it, which just shows your primative understanding of mathematics. > >>> Directly executed Turing machines have always been >>> outside of the domain of any function computed by >>> a Turing machine therefore directly executed Turing >>> machines have never contradicted the decision of >>> any halt decider. >> >> Nope, which shows your stupidity. >> >> By that logic, Simple mathematics is outside the domain of any >> function computed by a Turing Machine, as numbers themselves are not >> finite strings, just representable by them. >> >> Your failure to rebute this just proves that you have no idea what you >> are talking about. >> >> How do Turing Machines do math via representations, but can't handle >> programs via representations. >> >> Your comments about the "vagueness" of representations just shows that >> the issue isn't actually in the representations, but your own >> understand of it, becuase you just don't understand the concepts. >> >>> >>> Halt deciders compute the mapping from the behavior >>> that their finite string inputs actually specifies. >>> >>> >> >> Right, which specify a representation of a program, and thus the >> mapping needed is derived from the behavior of that program. >> >> > >