Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met

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.