Deutsch English Français Italiano |
<d4b02c8deb6dd72c7bf143b07c2752d93b825b1d.camel@gmail.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: wij <wyniijj5@gmail.com> Newsgroups: comp.theory Subject: Re: Simulation vs. Execution in the Halting Problem Date: Thu, 12 Jun 2025 04:59:56 +0800 Organization: A noiseless patient Spider Lines: 76 Message-ID: <d4b02c8deb6dd72c7bf143b07c2752d93b825b1d.camel@gmail.com> References: <yU0_P.1529838$4AM6.776697@fx17.ams4> <10237ki$3lo0a$1@dont-email.me> <1028lsi$13r5p$1@dont-email.me> <1029nr5$1ah2f$11@dont-email.me> <102bgc0$1soug$1@dont-email.me> <102c3bn$20jl4$8@dont-email.me> <22806dcceb8dbd965792253ecfde0a7f4dc5c793.camel@gmail.com> <102c4g1$20jl4$12@dont-email.me> <b27d3b8f4040ac88721a7b772f675f9e1cbb2c03.camel@gmail.com> <102c5nb$21qj7$2@dont-email.me> <602d915e3a80042ddac7f05fb389837ce3cefc12.camel@gmail.com> <102c7dj$226jq$1@dont-email.me> <0373fc8c6462341f655385edf6d4a0664a35981d.camel@gmail.com> <102ca1c$22pmt$1@dont-email.me> <85f876c4db96fb776dabc80c4208feed6aabc76d.camel@gmail.com> <102cdon$23jal$1@dont-email.me> <2e40a87aeb9e28ce23b5ebf3fcbf23dad6728a9b.camel@gmail.com> <102cg6f$246h5$1@dont-email.me> <822e204898d419545ca400a9088970f0b6a5107f.camel@gmail.com> <102ckje$25dg0$2@dont-email.me> <c5adb4ff9ac0a31da990ff83ab1ef7f242a2f7a7.camel@gmail.com> <102cm0u$25dg0$3@dont-email.me> <610e2a54b66e8576b80bda3a0fe188d025b9798e.camel@gmail.com> <102cp0e$26clp$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Date: Wed, 11 Jun 2025 22:59:57 +0200 (CEST) Injection-Info: dont-email.me; posting-host="bf8b8c9575553bac70d62eb9d0221f21"; logging-data="2318666"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+sWCf1XuIdKhr84vShOWsN" User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) Cancel-Lock: sha1:g9x7Y1sbqpowj4wLyhvSTGtdvyg= In-Reply-To: <102cp0e$26clp$1@dont-email.me> On Wed, 2025-06-11 at 15:30 -0500, olcott wrote: > On 6/11/2025 2:45 PM, wij wrote: > > On Wed, 2025-06-11 at 14:39 -0500, olcott wrote: > > > On 6/11/2025 2:31 PM, wij wrote: > > > > On Wed, 2025-06-11 at 14:14 -0500, olcott wrote: > > > > > On 6/11/2025 1:25 PM, wij wrote: > > > > > > On Wed, 2025-06-11 at 12:59 -0500, olcott wrote: > > > > > > > > >=20 > > > > > > > > > Yes all other people (especially Dennis Bush) are saying > > > > > > > > > that H(D) is required to report on the behavior of the > > > > > > > > > direct execution of D() never noticing that this stupidly > > > > > > > > > requires H(D) to report on the behavior of its caller. > > > > > > > >=20 > > > > > > > > If the H above means the H that the HP refers to. The H is = required to > > > > > > > > report its argument's behavior (ie. by H(D)). But NOT requi= red by simulation. > > > > > > >=20 > > > > > > > It turns out that no one ever noticed that simulating halt > > > > > > > deciders nullify the HP counter-example input in that this > > > > > > > input cannot possibly reach its contradictory part. > > > > > > >=20 > > > > > > > > The HP does not care what D does (simply to say). > > > > > > > >=20 > > > > > > >=20 > > > > > > > Everyone says that H(D) must re[port on the behavior of > > > > > > > the direct execution of D(). > > > > > >=20 > > > > > > That is what the HP asks. > > > > > >=20 > > > > > > > > The HP only requires: H(D)=3D=3D1 iff D() halts > > > > > > > >=20 > > > > > > > >=20 > > > > > > >=20 > > > > > > > int main() > > > > > > > { > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 D(); // calls H(D) > > > > > > > } > > > > > > >=20 > > > > > > > Which requires H(D) to report on the behavior of its > > > > > > > caller instead of reporting on the behavior that its > > > > > > > input actually specifies. > > > > > >=20 > > > > > > That is no problem. H does not care what D does inside (simply = to say). > > > > > > The HP simply asks for a H that "H(D)=3D=3D1 iff D() halts". > > > > > >=20 > > > > >=20 > > > > > Which requires H to report on something that it cannot possibly s= ee. > > > >=20 > > > > On the contrary, what the HP proves is very useful. > > > >=20 > > >=20 > > > I am not talking about the halting problem, I have always > > > been talking about the conventional halting problem proof. > > > THIS PROOF IS WRONG > >=20 > > When talking about proof, we say it is valid or not. By doing so, we ha= ve > > to unambiguously pose the problem and the derivation to the conclusion. > > The HP proof just did that. > >=20 >=20 > It may seem that way if you pay less than 100% > complete attention. >=20 > The HP proof depends on an *INPUT* that does > the opposite of whatever value that H returns > and no such *INPUT* can possibly exist. That is absolutely correct. No such *INPUT* (i.e. D) can possible exit is b= ecause the H inside D does not exist at all. So, if the H is assumed to exist, then D will exist to make H undecidable.