Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
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 23:49:29 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v5o089$1eli4$3@i2pn2.org>
References: <v45tec$4q15$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> <v5mb0p$3b1p0$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 29 Jun 2024 03:49:29 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1529412"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v5mb0p$3b1p0$2@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 7998
Lines: 153

On 6/28/24 8:40 AM, olcott wrote:
> 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.

So?

> 
> 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.

No, the "behavior" of the input is what the question being asked defines 
it to be.

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

Which, is not a proper definition of the behavior of the input, as it 
depends on more tham just the input, but on the machine the input is 
given to.

Properties of the input for a decider need to be OBJECTIVE properties of 
the input, and not SUBJECTIVE properties, as the mapping is defined to 
be a mapping of JUST THE INPUT, and thus, doesn't include the decider it 
is given to.

> 
> 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.

Right, and since your decider RESOLVES that recursion by aborting and 
return, THAT BEHAIVIOR is part of the behavior of the input, since to 
perform your definition of the input, you needed to include the decider 
it was paired to in the input, that fixes the behavor to what that 
decider did.

> 
>>> 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.

It must go by THE DEFINITION OF THE PROBLEM, if that is from a textbook, 
then yes, the textbook is authorative, and to say otherwise is just a LIE.

The input doesn't encode the problem statement, so can't disagree with it.



> 
>>> 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.

Nope, that is just facts. YOU do not seem to have basic knowledge 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.

And, if H0 is the defined pure function, then so will any correcgtly 
simulated copy of it, and do exactly the same thing.

> 
> <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>
> 
> 

Nope, since no H0 actually does a "Correct Simulation" or a "Correct 
Determination of a Correct Simultion" (by anything) since the only 
defintion he uses of a "Correct Simulation" is a simulation that EXACTLY 
reproduces the results of directly executed machine the input 
represents, which means it will never abort its simulation.

Thus, H0 can NEVER correctly avail itself of the second clause.