Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

On 5/10/2025 10:51 AM, 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 models
of computation must transform their input into
outputs according to the specific steps of an
algorithm.
>
_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
>
For example HHH(DDD) only correctly map to the
behavior that its input actually specifies by correctly
emulating DDD according to the rules of the x86 language.
>
This causes the first four instructions of DDD
to be emulated followed by HHH emulating itself
emulating the first three instructions of DDD.
>
It is right at this recursive simulation just
before HHH(DDD) is called again that HHH recognizes
the repeating pattern and rejects DDD.

>
Yes, but you still did not answer the question: Is POOH exactly about HP?
>

>
    >>>>> H(D)=1 if D() halt.
    >>>>> H(D)=0 if D() not halt.
>
Right now it is mostly about proving the
above requirements are is mistaken.
>

>
Why is the requirement invalid?
>
H(D)=1 if D() halt.
H(D)=0 if D() not halt.
>

>

>

The notion that the behavior specified by the finite
string input to a simulating termination analyzer

>
POOH reads(takes) its input as a function, not 'finite string'.
Are you talking about POOH now? There is no POOH that takes
'finite string'.
>

>
It <is> a finite string of x86 bytes.

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

 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.
 

does sometimes differ from the behavior of its direct
execution. It is a provably different sequence of steps.

>

>
This is a verified fact.
The pathological relationship that inputs can have
with their simulating termination analyzer changes
the behavior of these inputs relative to their direct
execution.

>
So, you redefined the halting problem should be about the behavior of D
decided by POOH, not the 'direct' behavior of D?
>

 Not at all. HHH(DDD) reports on the behavior that DDD
actually specifies.

Which is the behavior of the algorithm described by the input, which halts.

All my critics require HHH to report
on behavior that DDD does not actually specify.
 The actual behavior that DDD specifies is measured
by

Executing DDD directly, as per the requirements:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly

int sum(int x, int y) { return x + y ;}
sum must apply the rules of arithmetic to
its inputs thus sum(3,2) cannot correctly
derive the sum of 5 + 7.
 HHH must apply the rules of the x86 language
to its input DDD.

And those rules say that when DDD is actually run on an actual x86 processor that it will halt.

 When HHH1(DDD) applies these same rules to its input
there is no recursive emulation because DDD does
not call HHH1(DDD).