Re: Computing the mapping from the input to HHH(DD) --- REFUTES INCORRECT REQUIREMENTS

On 5/11/25 5:42 PM, olcott wrote:

On 5/11/2025 3:15 PM, Richard Damon wrote:

On 5/11/25 12:26 PM, olcott wrote:

On 5/11/2025 4:25 AM, Mikko wrote:

On 2025-05-10 15:25:16 +0000, olcott said:
>

On 5/10/2025 2:33 AM, Mikko wrote:

On 2025-05-09 16:25:12 +0000, olcott said:
>

void DDD()
{
   HHH(DDD);
   return;
}
>
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

>
That one or more statements of DDD are correctly simulated does not
mean that DDD is correctly simulated.
>

>
It is stipulated that when one or more statements
of DDD are correctly simulated that one or more
statements of DDD are correctly simulated.

>
Thera are only two statements in DDD. HHH does not correctly emulate
the first one, which is a call to HHH, and not at all the second one,
which is the final return.
>

>
_DDD()
[0000219e] 55             push ebp
[0000219f] 8bec           mov ebp,esp
[000021a1] 689e210000     push 0000219e // push DDD
[000021a6] e843f4ffff     call 000015ee // call HHH
[000021ab] 83c404         add esp,+04
[000021ae] 5d             pop ebp
[000021af] c3             ret
Size in bytes:(0018) [000021af]
>
There are seven instructions in DDD.
When DDD calls HHH(DDD) then HHH emulates
itself emulating DDD.
>
>

>
Then either HHH is just wrong,

 DDD is emulated by HHH according to the only correct
measure the rules of the x86 language.

No it isn't, as your HHH aborts its simulation, and that isn't allowed by the x86 lannguage.
And it can only do even that if you include HHH in the input, or allow HHH to be a non-pure function.

 

violating the definition of the input, or

 I told you far too many times that HHH and DDD
are in the same memory space. This means that
HHH must emulate itself emulating DDD or it
did not emulate the first 7 instructions of DDD
correctly.
 

Which is IRRELVENT if HHH is a pure function, I guess you just don't understand the meaning of the term you yourself used in your stipulation.
So which lie are you admitting to? (Failure to answer will be presumed to mean ALL of them)?
That the input actually contains the code for HHH, and thus each DDD/HHH pairing is a distinct input, as the code for each HHH is different.
That your HHH isn't a pure funciton, as it looks at data memory that wasn't part of its input (or generated from it) and thus my local static variable hack is also allowed, and thus you are just shown to be a stupid liar about no HHH can do it, when I show how to build an HHH that can do it. (Your comments about needing a better criteria doesn't help until you DO come up with something)
That you are just lying about HHH being a correct emulator, and it sees a call to HHH, and INCORRECTLY assumes that HHH is a correct emulator as claimed when it actually is not (since it does abort), thus showing that you lie in your stipulations.

isn't a pure function, and thus can use my static hack to correct emulate the input to the final state.
>

 Refusing to emulate DDD after one emulation
cannot possibly derive a simulating termination
analyzer, thus this break requirements.

Where?
The requirement to correctly emulate was the requirement on the outer HHH, which it doesn't acutally do.
The queation is can we make a HHH that emulates in input, HHH does that.
This is no different than your false assertion that the outer HHH can abort while the inner one will not abort.

 

Sorry, you are just showing that you are lying by equivocation.