Deutsch   English   Français   Italiano  
<f5e2f5b132c0cc465ae86538af91dd12185999e3.camel@gmail.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sun, 11 May 2025 00:21:38 +0800
Organization: A noiseless patient Spider
Lines: 130
Message-ID: <f5e2f5b132c0cc465ae86538af91dd12185999e3.camel@gmail.com>
References: <vv97ft$3fg66$1@dont-email.me> <vvlv04$32kt3$1@dont-email.me>
	 <87r00xchn5.fsf@nosuchdomain.example.com>
	 <23a27379d226b7b3b9f8c303a492f66edc9019ff.camel@gmail.com>
	 <vvmgtr$3a34p$7@dont-email.me>
	 <1020d30c2c5b5a7cce584777131d5ce414b480ea.camel@gmail.com>
	 <vvmk29$3atmt$3@dont-email.me>
	 <0323d5ca6d757a1e35d7e4cf5eb4fc8f41bc866a.camel@gmail.com>
	 <vvmlk0$3blcs$1@dont-email.me>
	 <c6904fbe42c4ad1eb3d1dcc50d18e6e75f159d75.camel@gmail.com>
	 <vvmmtd$3bqvb$1@dont-email.me>
	 <9f5774bfb493325652f97d72f760ad98442c333d.camel@gmail.com>
	 <vvmnl5$3c2gn$1@dont-email.me>
	 <f430dde2c5313bf6657c11b7a9eca183e2432291.camel@gmail.com>
	 <vvmou2$3cac3$1@dont-email.me>
	 <84b09a0d53d77e2a8fddf567226d05c0d65e60c0.camel@gmail.com>
	 <vvmqdo$3ce48$1@dont-email.me>
	 <235107421488220fb79fa83cbe8bf44709f6445a.camel@gmail.com>
	 <vvnp62$3in62$3@dont-email.me>
	 <83120a5793367c0231c0ecef701f26c51d35055b.camel@gmail.com>
	 <vvns7a$3in62$8@dont-email.me>
	 <6c1097059277dfa8e34acb2e607242a5d6e9d707.camel@gmail.com>
	 <vvnu2o$3k258$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sat, 10 May 2025 18:21:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c665478d8699930ce63ac26f3a79e21a";
	logging-data="3801142"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/k19InY7o5GQ72snM8S8Uh"
User-Agent: Evolution 3.54.3 (3.54.3-1.fc41)
Cancel-Lock: sha1:iK4G+XZvLs5ZQxtY0bKoB0HEbXE=
In-Reply-To: <vvnu2o$3k258$1@dont-email.me>
Bytes: 7562

On Sat, 2025-05-10 at 11:15 -0500, olcott wrote:
> On 5/10/2025 11:00 AM, wij wrote:
> > On Sat, 2025-05-10 at 10:43 -0500, olcott wrote:
> > > On 5/10/2025 10:14 AM, wij wrote:
> > > > On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
> > > > > On 5/10/2025 1:19 AM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
> > > > > > > On 5/10/2025 1:00 AM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
> > > > > > > > > On 5/10/2025 12:27 AM, wij wrote:
> > > > > > > > > > On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
> > > > > > > > > > > On 5/10/2025 12:13 AM, wij wrote:
> > > > > > > > > > > > On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
> > > > > > > > > > > > > When mathematical mapping is properly understood
> > > > > > > > > > > > > it will be known that functions computed by model=
s
> > > > > > > > > > > > > of computation must transform their input into
> > > > > > > > > > > > > outputs according to the specific steps of an
> > > > > > > > > > > > > algorithm.
> > > > > > > > > > > > >=20
> > > > > > > > > > > > > _DDD()
> > > > > > > > > > > > > [00002172] 55=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 push ebp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; housekeeping
> > > > > > > > > > > > > [00002173] 8bec=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 mov ebp,esp=C2=A0=C2=A0 ; housekeeping
> > > > > > > > > > > > > [00002175] 6872210000 push 00002172 ; push DDD
> > > > > > > > > > > > > [0000217a] e853f4ffff call 000015d2 ; call HHH(DD=
D)
> > > > > > > > > > > > > [0000217f] 83c404=C2=A0=C2=A0=C2=A0=C2=A0 add esp=
,+04
> > > > > > > > > > > > > [00002182] 5d=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 pop ebp
> > > > > > > > > > > > > [00002183] c3=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 ret
> > > > > > > > > > > > > Size in bytes:(0018) [00002183]
> > > > > > > > > > > > >=20
> > > > > > > > > > > > > For example HHH(DDD) only correctly map to the
> > > > > > > > > > > > > behavior that its input actually specifies by cor=
rectly
> > > > > > > > > > > > > emulating DDD according to the rules of the x86 l=
anguage.
> > > > > > > > > > > > >=20
> > > > > > > > > > > > > This causes the first four instructions of DDD
> > > > > > > > > > > > > to be emulated followed by HHH emulating itself
> > > > > > > > > > > > > emulating the first three instructions of DDD.
> > > > > > > > > > > > >=20
> > > > > > > > > > > > > It is right at this recursive simulation just
> > > > > > > > > > > > > before HHH(DDD) is called again that HHH recogniz=
es
> > > > > > > > > > > > > the repeating pattern and rejects DDD.
> > > > > > > > > > > >=20
> > > > > > > > > > > > Yes, but you still did not answer the question: Is =
POOH exactly about HP?
> > > > > > > > > > > >=20
> > > > > > > > > > >=20
> > > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>>> H(D)=3D1 if=
 D() halt.
> > > > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>>> H(D)=3D0 if=
 D() not halt.
> > > > > > > > > > >=20
> > > > > > > > > > > Right now it is mostly about proving the
> > > > > > > > > > > above requirements are is mistaken.
> > > > > > > > > > >=20
> > > > > > > > > >=20
> > > > > > > > > > Why is the requirement invalid?
> > > > > > > > > >=20
> > > > > > > > > > H(D)=3D1 if D() halt.
> > > > > > > > > > H(D)=3D0 if D() not halt.
> > > > > > > > > >=20
> > > > > > > > >=20
> > > > > > > >=20
> > > > > > > > > The notion that the behavior specified by the finite
> > > > > > > > > string input to a simulating termination analyzer
> > > > > > > >=20
> > > > > > > > POOH reads(takes) its input as a function, not 'finite stri=
ng'.
> > > > > > > > Are you talking about POOH now? There is no POOH that takes
> > > > > > > > 'finite string'.
> > > > > > > >=20
> > > > > > >=20
> > > > > > > It <is> a finite string of x86 bytes.
> > > > > >=20
> > > > > > Disagree.
> > > > > > The D in Halt7.c (I just saw once) does not treat H as 'finite =
string',
> > > > > > D calls H. H also does not treat D as 'finite string'.
> > > > > >=20
> > > > >=20
> > > > > HHH and DDD and DD are the most recent functions.
> > > > > HHH does emulate its finite strings of x86 machine code
> > > > > according to the rules of the x86 language.
> > > >=20
> > > > This is from a copy of Halt7.c:
> > > >=20
> > > > void P(ptr x)
> > > > {
> > > > =C2=A0=C2=A0=C2=A0 int Halt_Status =3D H(x, x);
> > > > =C2=A0=C2=A0=C2=A0 if (Halt_Status)
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HERE: goto HERE;
> > > > =C2=A0=C2=A0=C2=A0 return;
> > > > }
> > > >=20
> > > > int main()
> > > > {
> > > > =C2=A0=C2=A0=C2=A0 Output("Input_Halts =3D ", H(P, P));
> > > > }
> > > >=20
> > > > H reads a *pointer*.
> > > > In P, P *calls* H.
> > > >=20
> > > > Both do not process 'finite string'.
> > > >=20
> > >=20
> > > What it is it a pointer to a box of chocolates?
> > > finite strings are passed as pointers to finite
> > > string in C.
> >=20
> > Nope. I don't believe it is a pointer to chocolates, even if you say so=
..
> > It is about the code of D/H itself. They do not process string, the fac=
t says
> > the author of the program does not intend to process 'string'.
> >=20
>=20
> The input to HHH(DDD) is a pointer to a finite string
> of machine code. HHH applies an x86 emulator to this
> finite string.

Do you read English? Do D/H read and process 'finite string'?