Re: HHH maps its input to the behavior specified by it --- partial emulation never reaches its halt state (But DDD itself does) ---natural number mapping

On 8/10/24 8:06 AM, olcott wrote:

On 8/10/2024 6:57 AM, Richard Damon wrote:

On 8/10/24 7:30 AM, olcott wrote:

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*

>
I thopught HHH was a deider?
>

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

>
And only those element of the set that either reach the final state, or simulate forever are "correct" emulators of the whole program, suitable to show halting.
>

 void DDD()
{
   HHH(DDD);
   return;
.
 In other words even though it is dead obvious to
us that a complete simulation of DDD simulated by HHH
will never halt algorithms will forever be ridiculously
more stupid and never be able to see this?
 

But the problem is that you HHH doesn't do a complete simulation. At least not any of the ones that give the INCORRECT answer of not halting.
It seems you just don't understand that you need to look at the program oyou actually have, not th program you thinl you should have or wnt to habe.
YOU are the stupid one.
You need to FIRST define what HHH is, before we can know the program that DDD is, since the program DDD included the HHH that it calls, and thus every different HHH makes a different DDD. (Something you seem to not understand, your input without the code of HHH is just a LIE as it isn't is needed to be decided on as it its actually a program as is needed.
All your HHH that give an answer do so by aborting their emulation, but do so for invalid reasons, as they didn't actully prove that their input is non-halting, but that some OTHER input, that DIFFERS from this one by being built on a DIFFERENT HHH, that acts DIFFERENTLY to itself. Since this HHH(DDD) returns to its call from main, it returns to its call from DDD and thus the actual PROGRAM of DDD, which continues after HHH aborts its PARTIAL simulation of it, will reach the point that HHH decides to abort it, and it will return to DDD and the DDD reaches its final state.
Yes, there is ONE class of HHH, that do never abort their emulation and will never reach a final state in their emulation, showing that their input (which is a DIFFERENT input than above, since it is built on a DIFFERENT HHH than above) is non-halting, but said HHH never gives that answer, and thus proves itself to fail at being a decider at all.
Thus, you have crreated an INFINITE set of machines, that are ALL Wrong, and you claims that they are all right just becomes an INFINITE set of LIES, blowing away your claim that you have never lied.
Sorry, that it just the truth.
Yes, your algorithm is just that stupid to believe that the HHH it is emulating is different than the one that it actually is. Not, this PROVES that your HHH are not actually emulating the HHH that the are given, as all the aborting HHH will see the conditional instructions in the HHH that it is emulating, letting it know that this input might abort and return, and thus it is invalid to assume that it is an unconditional emulation. Only by NOT emulating the instructions, but just being programmed to presume that fact, can you claim the answer might be correct.