Sujet : Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)
De : dbush.mobile (at) *nospam* gmail.com (dbush)
Groupes : comp.theoryDate : 10. May 2025, 17:55:47
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vvo0ei$3judg$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
User-Agent : Mozilla Thunderbird
On 5/10/2025 12:44 PM, olcott wrote:
On 5/10/2025 11:21 AM, wij wrote:
On Sat, 2025-05-10 at 11:15 -0500, olcott wrote:
On 5/10/2025 11:00 AM, wij wrote:
On Sat, 2025-05-10 at 10:43 -0500, olcott wrote:
On 5/10/2025 10:14 AM, wij wrote:
On Sat, 2025-05-10 at 09:51 -0500, 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.
>
This is from a copy of Halt7.c:
>
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
>
int main()
{
Output("Input_Halts = ", H(P, P));
}
>
H reads a *pointer*.
In P, P *calls* H.
>
Both do not process 'finite string'.
>
>
What it is it a pointer to a box of chocolates?
finite strings are passed as pointers to finite
string in C.
>
Nope. I don't believe it is a pointer to chocolates, even if you say so.
It is about the code of D/H itself. They do not process string, the fact says
the author of the program does not intend to process 'string'.
>
>
The input to HHH(DDD) is a pointer to a finite string
of machine code. HHH applies an x86 emulator to this
finite string.
>
Do you read English? Do D/H read and process 'finite string'?
>
Like I have always said... DD, and DDD are finite
strings of x86 machine code and HHH emulates these
according to the x86 language.
A lie, as you have admitted to the contrary:
On 5/5/2025 8:24 AM, dbush wrote:
> On 5/4/2025 11:03 PM, dbush wrote:
>> On 5/4/2025 10:05 PM, olcott wrote:
>>> On 5/4/2025 7:23 PM, Richard Damon wrote:
>>>> But HHH doesn't correct emulated DD by those rules, as those rules
>>>> do not allow HHH to stop its emulation,
>>>
>>> Sure they do you freaking moron...
>>
>> Then show where in the Intel instruction manual that the execution of
>> any instruction other than a HLT is allowed to stop instead of
>> executing the next instruction.
>>
>> Failure to do so in your next reply, or within one hour of your next
>> post on this newsgroup, will be taken as you official on-the-record
>> admission that there is no such allowance and that HHH does NOT
>> correctly simulate DD.
>
> Let the record show that Peter Olcott made the following post in this
> newsgroup after the above message:
>
> On 5/4/2025 11:04 PM, olcott wrote:
> > D *WOULD NEVER STOP RUNNING UNLESS*
> > indicates that professor Sipser was agreeing
> > to hypotheticals AS *NOT CHANGING THE INPUT*
> >
> > You are taking
> > *WOULD NEVER STOP RUNNING UNLESS*
> > to mean *NEVER STOPS RUNNING* that is incorrect.
>
> And has made no attempt after over 9 hours to show where in the Intel
> instruction manual that execution is allowed to stop after any
> instruction other than HLT.
>
> Therefore, as per the above criteria:
>
> LET THE RECORD SHOW
>
> That Peter Olcott
>
> Has *officially* admitted
>
> That DD is NOT correctly simulated by HHH