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

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.
Thus when computing the behavior that this finite string
specifies no DDD ever halts.
_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]
DDD always has the exact same finite string of machine
code bytes. This requires each HHH to always be at machine
address 000015d2.
The computation is always reporting whether or not DDD
can possibly reach its c3 "ret" instruction at machine
address [00002183].
When DDD is correctly emulated by each HHHₙ then DDD never
reaches its "return" instruction final halt state.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer