Re: Can you see that D correctly simulated by H remains stuck in recursive simulation?

On 5/25/24 12:28 AM, olcott wrote:

On 5/24/2024 6:20 PM, Richard Damon wrote:

On 5/24/24 6:20 PM, olcott wrote:

On 5/24/2024 4:39 PM, olcott wrote:

On 5/24/2024 4:03 PM, Richard Damon wrote:

On 5/24/24 4:01 PM, olcott wrote:

On 5/24/2024 12:25 PM, Richard Damon wrote:

On 5/24/24 1:10 PM, olcott wrote:

On 5/24/2024 2:37 AM, Fred. Zwarts wrote:

Op 23.mei.2024 om 19:04 schreef olcott:

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }
>
The above template refers to an infinite set of H/D pairs where D is
correctly simulated by pure function H. This was done because many
reviewers used the shell game ploy to endlessly switch which H/D pair
was being referred to.
>
*Correct Simulation Defined*
    This is provided because every reviewer had a different notion of
    correct simulation that diverges from this notion.
>
    A simulator is an x86 emulator that correctly emulates at least one
    of the x86 instructions of D in the order specified by the x86
    instructions of D.
>
    This may include correctly emulating the x86 instructions of H in
    the order specified by the x86 instructions of H thus calling H(D,D)
    in recursive simulation.
>
*Execution Trace*
    Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, and 03
    of D. This invokes H(D,D) again to repeat the process in endless
    recursive simulation.
>

>
Of course this depends very much on the exact meaning of 'correct simulation', or 'correctly emulating'.

>
Not when these are defined above.
>

E.g., take the call to H(p, p). If H recognizes that it is a call to a H with the same algorithm as is it using itself, and it knows that itself returns a certain integer value K, than it can be argued that it is a correct emulation to substitute the call to H with this integer value K, which is assigned to Halt_Status. Then the simulation of D can proceed to line 04.
What we need is an exact definition of 'correct simulation', in this

>
No, you simply need to pay complete attention to the fact that this
has already been provided.
>
I have been over the exact same issue with dozens and dozen of people
though hundreds and hundreds of messages over two years.

>
Excpet that we have two contradictory definitions present,

>
Yes you have a definition of simulation where the x86 machine
language of D is simulated incorrectly or in the wrong order.

>
Nope. The UTM definition still simulates EVERY x86 machine language instruction of D simulated correctly in the exact order. The added requirement is that we look at a simulation that is never aborted.

>
H is a pure function that always returns 56 at some point other
than that H is isomorphic to a UTM.
>

>
I have learned from decades as a software engineer that complexity
is only manageable when it is isolated and minimized.
>
It is impossible to correctly understand termination analyzer H until
after one first has 100% perfectly complete and total understanding of
pure function simulator H/D pairs.
>

>
>
So, do you agree with my comments about what you actual definitons are, and what they imply?
>

 No I only agree that you are doing everything that you can to derail
an honest dialogue and it cannot possibly succeed against the basis
of my raw facts basis.

So it iYOUR choice to not define what you actually

 

That you H, by just needing to be a "Pure Funtion" is not necessarily the computatinal eqivalent of a Turing Machine.
>

 Totally moot for the subject line.

Nope, ESSENTINTIAL. I am not asking you to change your definition, just accept its consequences.
or, are you planning on lying?

 

That your definition of "Correct Simulation" differs from that used in Computation Theory,

 Totally moot for the subject line.

Nope, ESSENTINTIAL. I am not asking you to change your definition, just accept its consequences.
or, are you planning on lying?

 

and thus the fact that H does abort its simulation means it is NOT a "UTM equivalent" and that your aborted correct simulation not reaching a final state is not =, by itself, proof that the machine represented by the input is non-halting.
>

 The easily verified fact that for the infinite set of H/D pairs
where D is correctly simulated by pure function H that no D ever
reaches its own line 06 and halts.

And the question is what do you mean by "no D ever reaches its onw line 06"?
This is clearly false if we talk about the actual execution of D, which is what the final words imply, if you clarify by saying that no D is ever simulated to its onw line 06, you might be right, which seems to be what you want to mean here. The problem is your past indicates that given agreement to the later, you will re-interpret that to mean the former as a LIE.

 It is like I say red cars are red in color and you disagree by saying blue cars are not red in color.

Nope. It is more like saying "She was blue", and not clarifying if that was the color of her skin, or her emotional state.

 

That you definition of "Correct Simulation" means that H actually simulated a call to H by going into H and looking at those instructions,

 *YOU KEEP READING THINGS INTO MY SPEC THAT ARE JUST NOT THERE*
*YOU KEEP READING THINGS INTO MY SPEC THAT ARE JUST NOT THERE*
*YOU KEEP READING THINGS INTO MY SPEC THAT ARE JUST NOT THERE*

So, either clarify that I have interpreted your specification wrong, or accept that the conditions in your spec do imply the results I state.
Of H isn't required to be the compuational equivalent of a Turing Machine, just accept that coming up with an H that meets your specification doesn't imply that you can find an equivalent t

 H is exactly a UTM except that it eventually halts and returns
56 even on non-halting inputs. Think of each H as counting the
number of instructions that it simulates and then stopping.

Which is just like saying a cat is a 10 story office building with a few minor changes.
The fact you don't understand that shows your utter stupidity.

 

and not switch to looking at the machine the simulation being simulated is simulating.
>
I will also add, that you agree that if you get the agreement that if H can do this, then you will produce an actual H that meets the requirements, and not just claim that it must be trivial to write, and such example program actually gives the claimed answer.
>

 Until you understand that D correctly simulated by pure function H
never halts we can never get to the next step.

So, define what you are actually measuring.
DO you mean that such a D can never be simulated by that decider to the end, or that D, when run, can never get to the end.
Clairify that you mean ONLY that no H can simulated the D that calls that H to that H to a final state.
Of course, that doesn't mean a lot.

 

You agree that your funky "Infinite set of H/D pairs" is NOT what Linz or Sipser were using in their proof, and that you H and D are not built fully in conformance to the sample machines in the proofs.
>

 Once you understand that H is correct about D proving that embedded_H
is correct about ⟨Ĥ⟩ is easy. Until then it remains impossible

But you need to clarify the question it is answering.
If you won't do that, it seems you just are planning on being deceitful.

 

>
If you don't agree to these interpreations, a necessary precondition to coming to an agreement on what H sees, is to reach the agreement on what hte conditions imply and what those conditions actually are.

 

And repeating this, If you won't agree to what you are actually saying, and accept the repercussions of that, you aren't actually saying anything, but are just admitting you are trying to set up a lie.