Re: HHH maps its input to the behavior specified by it --- never reaches its halt state ---

Op 14.aug.2024 om 15:47 schreef olcott:

On 8/14/2024 2:41 AM, Mikko wrote:

On 2024-08-13 13:21:32 +0000, olcott said:
>

On 8/13/2024 6:08 AM, Mikko wrote:

On 2024-08-11 11:45:18 +0000, olcott said:
>

On 8/11/2024 1:30 AM, Mikko wrote:

On 2024-08-10 11:30:34 +0000, olcott said:
>

On 8/10/2024 3:29 AM, Mikko wrote:

On 2024-08-09 14:51:51 +0000, olcott said:
>

On 8/9/2024 4:03 AM, Mikko wrote:

On 2024-08-08 13:18:34 +0000, olcott said:
>

void DDD()
{
   HHH(DDD);
   return;
}
>
Each HHH of every HHH that can possibly exist definitely
*emulates zero to infinity instructions correctly* In
none of these cases does the emulated DDD ever reach
its "return" instruction halt state.

>
The ranges of "each HHH" and "every HHH" are not defined above
so that does not really mean anything.

>
Here is something that literally does not mean anything:
"0i34ine ir m0945r (*&ubYU  I*(ubn)I*054 gfdpodf["

>
Looks like encrypted text that might mean something.
>

"Colorless green ideas sleep furiously"

>
This could be encrypted text, too, or perhaps refers to some
inside knowledge or convention.
>

I defined an infinite set of HHH x86 emulators.

>
Maybe somewnete but not in the message I commented.
>

I stipulated that each member of this set emulates
zero to infinity instructions of DDD.

>
That doesn't restrict much.
>

*I can't say it this way without losing 90% of my audience*
Each element of this set is mapped to one element of the
set of non-negative integers indicating the number of
x86 instructions of DDD that it emulates.

>
It is easier to talk about mapping if is given a name.
>

*This one seems to be good*
Each element of this set corresponds to one element of
the set of positive integers indicating the number of
x86 instructions of DDD that it emulates.

>
That would mean that only a finite number (possibly zero) of
instructions is emulated. But the restriction to DDD does not
seem reasonable.
>

>
*The set of HHH x86 emulators are defined such that*
>
Each element of this set corresponds to one element of
the set of positive integers indicating the number of
x86 instructions of DDD that it correctly emulates.

>
As we onece observed, this would be clearer with incdices.
No journal woth of consideration will accept an article
that uses the same name for a specific program and a set.
>
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
None-the-less it is clear that of the above specified infinite
set DDD correctly emulated by each element of that set never
reaches its own "return" instruction halt state.

>
To emulate an infinite set of DDD by infintely manu emulators
is too much to actually do. However, one may pick a HHHᵤ and
DDDᵥ so that HHHᵤ(DDDᵥ) correctly determines that DDDᵥ halts.

>
Through something like mathematical induction we can directly
see that DDD correctly emulated by any HHH cannot possibly
reach its "return" instruction final halt state.

>
No, we don't see, at least as long as you don't show.
>

 _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]
 The impossibility of DDD emulated by HHH
(according to the semantics of the x86 language)
to reach its own machine address [00002183] is
compete proof.
 We don't even need an actual HHH we only need
to imagine that HHH is a pure x86 emulator and
then anyone with sufficient expertise in the x86
language can see that DDD correctly emulated by
HHH never reaches machine address [00002183].
 

Which proves that the simulation is incomplete, because it aborted one cycle too soon. This makes the simulation incorrect.
HHH cannot possibly simulate *itself* correctly.