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

On 5/23/24 11:06 PM, olcott wrote:

On 5/23/2024 9:41 PM, Richard Damon wrote:

On 5/23/24 10:22 PM, olcott wrote:

On 5/23/2024 8:44 PM, Richard Damon wrote:

On 5/23/24 1:04 PM, olcott wrote:

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

>
Questions:
>
By your definiton of "Correct Simulation", you do realize that you have broken connection between the simulaiton not completing and the program described by the input not halting?
>

>
In other words you are requiring that the x86 instructions of D
(and possibly H) be simulated incorrectly and/or in the wrong order.

>
No, they must be simulated COMPLETELY.
>

 (a) *Clearly you are terrible at reading a spec*
(b) *non terminating computations cannot be simulated completely*

Not by your definition,
D(D) proves you wrong, since it HALTS when run, it terminates.
You may be able to prove that no decider can simulate the "not a machine but a template" that your D is. Since the problem space SHOULD be "programs", you fail at even that point

 

That is the only simulation that Computation Theory recognises as showing halting status.
>

 *Infinite loops need not be simulated completely to show a halt status*

Right, becasue we can prove that the Computaton-Theory-Correct-Simulation will never reach an end,

 

You should know that, so you are just showing you are deflecting.
>

 DUMB MISTAKE ON YOUR PART
*Infinite loops need not be simulated completely to show a halt status*

Right, because we can prove that the Computaiton-Theory-Correct-Simulation will never reach an end.
That doesn't happen for your H/D compinations, the Computation-Theory-correct-simulation of the input to any of the H/D pairs where H returns an answer, will reacn the final state, so the H was wrong about halting.
And so is your logic.

 

>

Also, you do realize that by your requirement on H just being a "pure function" that does NOT say that you H qualified to be the computational equivalent for a Turing Machine?
>

>
That I require it to be a pure function
(a) Disallows you use of static local data.
(b) Does mean that H is Turing computable even if you don't understand this.
>

>
Nope.
>
It is neither suffient or required.
>

 *So you don't even know what a spec is*

Sure I do, you are the one that fails at it.

 

Your H1 being claimed to be a "copy" but giving a different value is a proof of the insufficiency.
>

 THAT IS OFF-TOPIC FOR THE SUBJECT OF THIS THREAD.

Nope, proves the point that "Pure Function" by your definition is insufficient for a program to be a Turing machine equivalent.
I guess you are just conceeding that one.

 

That due to your "strange" definition of what D is, you are putting yourself outside of the grounds of "Computation Theory", as that deals with the behavior of specific PROGRAMS, and not the "Program Templates" like your D, our the "Infinite set of H/D pairs"?
>

>
How you can fail to understand that this <is> such a template?
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

>
Nope, not a "template" as H (from which you built your embedded H) is a SPEICIF (but arbitary) machine that meets that specification, and thus, so is H^.
>

 Arbitrary MEANS template.

Nope.
If I say choose an arbitrary student in a class, and then do something, I mean to choose any one student from the class and do it with them.

 

You don't seem to understand the maning of the terms.
>

 You are the one the directly contradicted yourself
It cannot be {A SPECIFIC MACHINE} and {AN ARBITRARY MACHINE}

Sure it can. Being Arbirary means I am not limiting which one you can choose.
I guess you don't understand the meaning of the words.

 

>

Also, your "templagte D" is NOT built per either the Linz or Sipser rules, as both of those had D built with a COPY of H, which is one of your problems with a "Pure Function" as the equivelent. You have shown that your H fails to meet the requirements of a Turing Machine

>
This post is only talking about the above specified H, you keep
forgetting that.

>
Which my question are trying to confirm exactly what you means by that, and that you understand the implications of it.
>

 My spec if clear and you clearly keep ignoring it.

Nope, and it is clear you don't understand the implications of your oddly defined (for the field) terms.

 

Clearly you don't.
>

>

equivalent, as you can't (or it seems you can't) make equivalent copies, where all copies always give the same answer for the same inputs. This is a fundamental property of Turing Machines, which is why just bing a "Pure Function" isn't good enough.
>

>
For simulator H it is plenty good enough.

>
Nope.
>

 We know that simulation is Turing computable on the basis of UTMs

That is a non-sense sentence.
The existance of Universal Turing Machines (UTM) means that it is possible to make a single Turing Machine that can "simulate" the behavior of any other Turing machine, by giving a description of it as an input. Note, the equivalence of the behavior of the UTM and the machine descirbe only occurs when the UTM never stops until it reaches the final state.
Thus we have the property, that the COMPLETE (and accurate, which is assumed) simulation of the input produces the behavior of the machine described.
If you create a machine that acts sort of like a UTM but stops before it gets there, doesn't say ANYTHING about the behavior of the program described.
You don't seem to understand that the ONLY "simulation" that you get by mentioning UTMs is the complete and correct simulation that a UTM does. There is no such thing as a UTM that stops before it gets to the end, if a machine stop simulating before it reachs a final state, it just never was a UTM.

 Are you going to try and get away with pretending that you don't know this?

Nope, but you seem to be.

 

>

These issus need to be handled or acknowledged, before agreement on your question, as you have shown a history of taking a statement and twisting it (perhaps not intentionally, but because you don't understand what was being communicated) so we need to have a firm understand of what you mean and evidence that you accept the limititation causes by your altered definitions from the problem that you initially claimed to have started on.
>

>
You just claimed that you do not understand that the Linz example is a template. That does not seem like an honest mistake to me.

>
Linz STARTS from a templete, the ^ template (that he introduces later in the proof), and then select a SINGLE (but arbitrary) decider H, and from that he builds (with his template) a single input to give to that decider H^.
>

 SINGLE and arbitrary are mutually exclusive.

Nope.

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 *THIS SEEMS TO HELP YOU PAY BETTER ATTENTION*
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
 Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.

Nope, Just shows you are too dumb to know the meaning of the words being use.
Can you find a definiton where abritrary refers to selecting the WHOLE set, and not a specific element out of the set.
You are confusing the fact that if you can prove a statement true "for each" element of a set, we can show that we have proved it true "for all"
But the x gotten in the phrase "For each x in set Y ..." is just a single value for the following section (but you can repeat the WHOLE SECTION ANEW for every element in the set.
Thus, When we talk about being able to make a D for each H in the set of Halt Decider, and then do Y with it, for the doing Y, we have just a single H/D pair to look at, and only that pair. We don't get to look at OTHER pairs that might come up on a different iteration.
Of course, you logic can't handle trying to do such a proof, so you need to LIE and confuse the logic.

 

That is NOT what you are doing, and the fact you can't see the difference shows your blindness to the truth,
>

>

Of course, it also means that even if/when you get your agreement, you are no closer to your halting proof, as you have shown that you undestand that you conditions actually tell you NOTHING about the actual behavior of halting.
>

>
You just claimed that you do not understand that the Linz example is a template. That does not seem like an honest mistake to me.
>

>
>
It isn't, it is a specific H applied to a specific input showwing that this specific machine could not have been a correct decider.
>
AFTER proving that for the specific machine that it was wrong, he can point out that because he made no assumption about the details of that H, we can select anew, ANY other machine as the H, and do the same thing, and thus NO machine that met the original specification, which includes ANY machine that would claim to be a Halt Decider, can actually be correct.
>

 Likewise for D correctly simulated by pure function H for
every H/D pair Linz specifies every embedded_H/⟨Ĥ⟩ pair.

Nope.
Linz analyzed a SPECIFIC machine with a specific input, and showed it got it wrong.
You just don't understand what you are talking about.

 

You just don't understand the logic of universal categorical logic, even though you try to claim you evented it under a different naem.
>

 No the whole problem seems to be your attention span.

No, the whole problem is you lack of ever learning the meaning of the words you use, and being too stupid to learn.

 

He proves for one SPECIFIC, but arbitary case, using the fact that it IS   a specific case (but not which one) and that he can show he can make an input that disproves that one, he can show that he can make an input for any decider that claims to meet the specification.
>
THAT is valid logic, but yours isn't, as all you show is that in your full set of deciders, each looking at a different input machine (since only machines have behavior, not templates) that particular decider gave up before getting the answer.
>
We can also show that the answer it "gueess" can't  be correct about the halting problem.