Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved
 criteria is met
Date: Fri, 28 Jun 2024 07:40:57 -0500
Organization: A noiseless patient Spider
Lines: 109
Message-ID: <v5mb0p$3b1p0$2@dont-email.me>
References: <v45tec$4q15$1@dont-email.me> <v4s9hj$1dnm7$1@dont-email.me>
 <v4sa0h$1dk9i$3@dont-email.me> <v4sci6$1ebce$1@dont-email.me>
 <v4sd35$1eb2f$5@dont-email.me> <v4u3jl$1se49$1@dont-email.me>
 <v4umvh$1vpm0$7@dont-email.me> <v50d8k$2e51s$1@dont-email.me>
 <v50dtp$2e5ij$1@dont-email.me> <v51f4t$2k8ar$1@dont-email.me>
 <v51ge4$2kbbe$2@dont-email.me> <v539bk$329sv$1@dont-email.me>
 <v53upb$35vak$6@dont-email.me> <v575pl$3sg5p$1@dont-email.me>
 <v5767s$3soh6$1@dont-email.me> <v5e28t$11urb$5@i2pn2.org>
 <v5eg03$1ikpr$2@dont-email.me> <v5eho7$24l4$1@news.muc.de>
 <87jzidm83f.fsf@bsb.me.uk> <v5el8c$24l4$4@news.muc.de>
 <v5evoi$1lgoi$1@dont-email.me> <v5frvn$14bcm$6@i2pn2.org>
 <v5ft1p$1uc3o$2@dont-email.me> <v5fu24$14bcn$2@i2pn2.org>
 <v5fuf7$1up2o$1@dont-email.me> <v5gk7m$22b20$1@dont-email.me>
 <v5h3aj$24jbd$5@dont-email.me> <v5j4p0$2ksq3$1@dont-email.me>
 <v5jrrq$2o58l$4@dont-email.me> <v5k0ru$2q29e$1@dont-email.me>
 <v5k5ko$2qsdr$1@dont-email.me> <v5lsba$38t1k$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Jun 2024 14:40:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8e198617313100a552662932ac49ce17";
	logging-data="3508000"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/UjUTAN8bFLhFyIZd0+acg"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:rfru9sTiKVSdF9P44xlkO9P/7Tw=
In-Reply-To: <v5lsba$38t1k$1@dont-email.me>
Content-Language: en-US
Bytes: 6299

On 6/28/2024 3:30 AM, Mikko wrote:
> On 2024-06-27 16:56:56 +0000, olcott said:
> 
>> On 6/27/2024 10:35 AM, Mikko wrote:
>>> On 2024-06-27 14:10:02 +0000, olcott said:
>>>>
>>>> In computability theory and computational complexity theory, a
>>>> decision problem is a computational problem that can be posed as
>>>> a yes–no question of the input values.
>>>> https://en.wikipedia.org/wiki/Decision_problem
>>>
>>> That's right. But that question cannot be presented to the decider.
>>> Only the input values can.
>>>
>> In other words you are saying that Turing machines do not
>> typically understand English.
> 
> I didn't mean it that generally, only about deciders, but yes, typical
> Turing machines do not understand any English. More specifically, the
> specification of a halt decider (or any typical decider) prevents it
> from being asked in any language.
> 

// The question: Is x > y ?
bool GreaterThan(int x, int y) { return (x > y); }

Deciders are always asked a yes/no question of their
inputs in their own native language.

>> None-the-less no-one here understands that every halt decider
>> is only required to report on the behavior that its actual
>> input actually maps to.
> 
> As far as I have seen, most of them do. And not just maps but maps
> in the way specified by the problem statement.
> 
_DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

The call from DDD to H0(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator H0 cannot possibly return.

The behavior of the directly executed DDD() is irrelevant
because that is not the behavior of the input. Deciders
compute the mapping from their actual finite string input
to an output by a sequence of finite string transformations.

In this case the sequence is the line-by-line execution
trace of the behavior of DDD correctly emulated by H0.

The behavior of this input must include and cannot ignore
the recursive emulation specified by the fact that DDD is
calling its own emulator. That people think they can just
pretend that this is not happening is ridiculous.

>> Instead everyone here expects that the halt decider must map
>> to the English description of what the authors of textbooks
>> expect it to map to.
> 
> Your "everyone" is a lie. As far as I have seen, nobody has expressed
> that expectation, and several have said otherwise.
> 
Everyone that states an opinion says that the decider
must go by the textbook definitions of the problem thus
not the problem instance actually encoded by the input.

>> We already agreed that Turing machines do not typically
>> understand English, so this assumption is stupid.
> 
> You may have agreed but you failed to keep that agreement.
> 
>> *DDD correctly simulated by H0 DOES NOT HALT*
> 
> The message where DDD was introduced specifies that DDD halts
> if and only if H0 halts.
> 
That is simply ignorance of the details of software engineering.

>> Everyone here stupidly ignores that the pathological
>> relationship that DDD calls H0(DDD) changes the behavior
>> of DDD.
> 
> If and only if it changes the behaviour of H0, which is possible if
> and only if H0 is not a pure function.
> 
The directly executed H0 always uses this criteria and returns a
correct halt status for every input in its domain.

<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

     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>


-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer