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 05:57:46 +0800
Organization: A noiseless patient Spider
Lines: 126
Message-ID: <f09964feafdca25ea8efbe546868084bcd9df3a0.camel@gmail.com>
References: <yU0_P.1529838$4AM6.776697@fx17.ams4>
	 <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>
	 <d4b02c8deb6dd72c7bf143b07c2752d93b825b1d.camel@gmail.com>
	 <102crbv$26rt0$1@dont-email.me>
	 <ade2f19a880169bbaf09794b496e585b7eb8b677.camel@gmail.com>
	 <102ctbg$26rt0$2@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 23:57:47 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bf8b8c9575553bac70d62eb9d0221f21";
	logging-data="2318666"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/YHKO0ZTesIxPe9eX4CrUR"
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42)
Cancel-Lock: sha1:OWlEN1bByIeHXfNgnMFvKlHTO5Q=
In-Reply-To: <102ctbg$26rt0$2@dont-email.me>

On Wed, 2025-06-11 at 16:44 -0500, olcott wrote:
> On 6/11/2025 4:23 PM, wij wrote:
> > On Wed, 2025-06-11 at 16:10 -0500, olcott wrote:
> > > On 6/11/2025 3:59 PM, wij wrote:
> > > > 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 o=
f the
> > > > > > > > > > > > > direct execution of D() never noticing that this =
stupidly
> > > > > > > > > > > > > requires H(D) to report on the behavior of its ca=
ller.
> > > > > > > > > > > >=20
> > > > > > > > > > > > If the H above means the H that the HP refers to. T=
he H is required to
> > > > > > > > > > > > report its argument's behavior (ie. by H(D)). But N=
OT required 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=C2=A0=C2=A0 D(); // ca=
lls 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() ha=
lts".
> > > > > > > > > >=20
> > > > > > > > >=20
> > > > > > > > > Which requires H to report on something that it cannot po=
ssibly see.
> > > > > > > >=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 s=
o, we have
> > > > > > to unambiguously pose the problem and the derivation to the con=
clusion.
> > > > > > 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.
> > > >=20
> > > > That is absolutely correct. No such *INPUT* (i.e. D) can possible e=
xit is because
> > > > the H inside D does not exist at all.
> > > > So, if the H is assumed to exist, then D will exist to make H undec=
idable.
> > > >=20
> > >=20
> > > There is no *input* to any termination analyzer
> > > that can do the opposite of whatever value that
> > > this termination analyzer returns
> >=20
> > Your reinterpretation of of HP case is wrong.=20
> > Your D or H is not the case mention in the HP proof.
> >=20
>=20
> There cannot possibly exist any D mine or
> anyone else's that is encoded to do the opposite
> of whatever value that H returns.

Why not? D and H are supposed to be TM (or C function).
If the D cannot do the opposite of whatever value that H returns, then
that D is not powerful enough to be a TM, not an interesting case.

> The HP proof cannot possibly exist. If the HP
> proof cannot possibly exist then it never proves
> anything.
>=20
> Unless you bother to try to define an *INPUT* D
> that does the opposite of whatever value that H
> returns and utterly fail after hundreds of attempts
> you won't see this.
>=20
> > H and D must be in the same set to talk about HP problem.
> > H and D must be both "C/Assembly" functions, or=20
> > executables, or OBJ files (if you like)...etc.
> >=20
> > > thus the HP
> > > proof itself cannot possibly exist.
> >=20
>=20