Sujet : Re: Ben Bacarisse fails understand that deciders compute the mapping from inputs
De : polcott333 (at) *nospam* gmail.com (olcott)
Groupes : comp.theoryDate : 27. Aug 2024, 14:04:26
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vakisq$302rl$3@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
User-Agent : Mozilla Thunderbird
On 8/27/2024 12:45 AM, joes wrote:
Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:
On 8/26/2024 7:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/08/2024 22:07, Ben Bacarisse wrote:
We don't really know what context Sipser was given. I got in touch
at the time so I do know he had enough context to know that PO's
ideas were "wacky" and that had agreed to what he considered a "minor
remark". Since PO considers his words finely crafted and key to his
so-called work I think it's clear that Sipser did not take the "minor
remark" he agreed to to mean what PO takes it to mean! My own take
if that he (Sipser) read it as a general remark about how to
determine some cases, i.e. that D names an input that H can partially
simulate to determine it's halting or otherwise. We all know or
could construct some such cases.
>
Exactly my reading. It makes Sipser's agreement natural, because it
is both correct [with sensible interpretation of terms], and moreover
describes an obvious strategy that a partial decider might use that
can decide halting for some specific cases. No need for Sipser to be
deceptive or misleading here, when the truth suffices. (In particular
no need to employ "tricksy" vacuous truth get out clauses just to get
PO off his back as some have suggested.)
>
Yes, and it fits with his thinking it a "trivial remark".
That aside, it's such an odd way to present an argument: "I managed to
trick X into saying 'yes' to something vague". In any reasonable
collegiate exchange you'd go back and check: "So even when D is
constructed from H, H can return based on what /would/ happen if H did
not stop simulating so that H(D,D) == false is correct even though D(D)
halts?". Just imagine what Sipser would say to that!
Is this an accurate phrasing, pete?
Deciders never compute the mapping of the computation
that they themselves are contained within.
Everyone has been flat out fraudulent when the imply
that the input to HHH(DDD) halts.
Academic exchange thrives on clarity. Cranks thrive on smoke and
mirrors.
Try to point to the tiniest lack of clarity in this fully specified
concrete example.
Ben was talking about your Sipser quote.
But for one, HHH isn’t defined.
HHH is sufficiently defined and has zero ambiguity.
Ben is trying to get away with saying that HHH is
insufficiently defined yet there is zero evidence of that.
If HHH was insufficiently defined then he would not have
admitted that its criteria has been met.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
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
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
...
> But H determines (correctly) that D would not halt if it
> were not halted. That much is a truism.
*It is only the second half of the quote that Ben has trouble with*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
HHH does compute the mapping from its input finite string of DDD
to the behavior that DDD specified by emulating DDD including
emulating HHH emulating DDD according to the semantics of the x86 language.
*THIS IS THE KEY MISTAKE WHY THE HALTING PROBLEM HAS NEVER BEEN SOLVED*
It is only the behavior that HHH(DDD) computes for its input
that counts. HHH is not allowed to compute that mapping for
the computation that itself is contained within.
The direct execution of int main() { DDD(); } is the behavior
that HHH is not allowed to compute.
-- Copyright 2024 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer