Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt

On 5/20/24 10:25 PM, olcott wrote:

On 5/20/2024 7:57 PM, Richard Damon wrote:

On 5/20/24 2:03 PM, olcott wrote:

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

On 5/19/24 11:22 PM, olcott wrote:

On 5/19/2024 10:11 PM, Richard Damon wrote:

On 5/19/24 10:52 PM, olcott wrote:

On 5/19/2024 8:10 PM, Richard Damon wrote:

On 5/19/24 8:06 PM, olcott wrote:

On 5/1/2024 7:10 PM, Richard Damon wrote:
>
typedef int (*ptr)();  // ptr is pointer to int function
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 }
>
In the above case 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.
>
For every H/D pair of the above template D correctly simulated by
*pure function* H cannot possibly reach its own final state at
line 06 and halt.
>

>
Ok, so adding that H is a pure function, that means that since your outer H(D,D) is going to return 0, all logic must be compatible with the fact that EVERY call to H(D,D) will also eventually return 0.
>
>
Remember also, THIS D is defined to call THIS H, that does exactly the same as the H that is deciding it.
>

>
OK, good.

>
Right, so it doesn't matter what any other D does, it matters what THIS D does, and this D calls aths H.
>
Remember, you reinstated the Computation model by enforcing Pure Functions.
>

>

>
<snip so that Message ID links to whole message>
We can use my unique time/date stamp as an alternative.
>

Remember, YOU are the one saying you are needing to change the definition from the classical theory, where we have things well defined.
>
YOU have decider that H is just whatever C code you want to write for it, and D is the input proved. (which doesn't actually match the Linz or Sipser proof, but fairly close).
>
With THAT set of definitions we have a lot of options that break your incorrectly assumed results.
>
The first method has been discussed here by Flibble. While the final answer he got to doesn't fit the requirements, the first part of the method DOES show that it is possible for an H to simulate to past line 3.
>
THe basic idea is that if H(M,d) finds that its simulation of M(d) get to a call to H(M,d) then rather that your idea of just saying it will get stuck and declair the input invalid, since there ARE a number of possible inputs that there is a "correct" answer that H can give to

>
That D is calling H does not prove recursive simulation.
That D is calling H with its same parameters does seem
to prove non-halting recursive simulation.

>
Nope. Try to actuall PROVE it.
>

>
That is off-topic for this post.
All that we need know is that no D simulated by any H
ever reaches its own line 06 and halts.

>
Nope. Make a claim, you need to prove it.
>

>
*In other different post not this one*
>
I am using categorically exhaustive reasoning that can work
through every possibility that can possibly exist in a feasible
amount of time as long as the category is very very narrow.

>
But you can't PRECISELY define the category, or what you want to reason about, so your logic is worthless as it is baseless.
>

>
*POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>
typedef int (*ptr)();  // ptr is pointer to int function
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 }
>
In the above case 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);
>
keeps repeating (unless aborted)
Line 01:
Line 02:
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
Simulation invariant:
D correctly simulated by H cannot possibly reach past its own line 03.
>
For every H/D pair of the above template D correctly simulated by pure function (thus computable function) H cannot possibly reach its own final state at line 06 and halt.
>

>
Which thus doesn't correct simulate the call to H

 *Counter-factual, try again*
We are not talking about any of your misconceptions the term:
"simulate" is expressly defined.

And how did your H "Correctly" simulate the call to H?

 This is the only post about this subject that I will respond
to from you. I have to paint half of my house and empty my
garage within about a week.
 If you can find some source that conclusively proves that
not all pure functions are computable functions I would like
to see it. All of the experts that I could find seem to agree
that all pure functions in C would be computable functions
by a Turing machine.

So, you just don't understand that "Computable Function" is a Term-of-the-art to talk about the mathematical mapping, an NOT the algorithm that shows the mapping is computable.
One key point that make "Pure Functions" not necessarily equivalent to a Turing Machine is the ability to get "hidden inputs" from things like their own program address, something a Turing Machine doesn't have.
This is what made your H and H1, even though "exact copies" of each other (by using x86 instructions that access this otherwise hidden information in a way that make it not obvious), act differently, when two identical copies of Turing Machines ALWAYS act the same for the same input.
So, YOU YOURSELF have provided the counter-example, but were too stupid to understand it.

 I skimmed the rest of your posts and they were mostly
trying to get away with changing the subject to divert
attention away from the point at hand in this subject line.
 I will not discuss and theory of computation stuff with you
until after you quit playing head games with the subject
of this post.
 *THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
*THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
*THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
 On 5/19/2024 12:17 PM, Richard Damon wrote:
 > On 5/19/24 9:59 AM, olcott wrote:
 >> Richard has stated that he thinks that an example of
 >> {D never simulated by H} ∈ {every D simulated by H}
 >
 > No, the H that didn't simulate its input shows that
 > *once you allow H to not be required to be correct*,
 > that we can then have a trivial function that is
 > "just as correct" (since wrong answers were allowed).
 I am glad to see that it turned out that you were not a liar.
That was very reassuring. Seems to be a liar to me until I see
proof otherwise is not the same thing as calling you a liar.

Which just makes you a pathological liar, because you have a reckless disregard for the truth, PRESUMING without the need of evidence.
Note, you positively claimed for two weeks that I did not say what I claimed to. Since I showed that I did, that you PROVES you LIED for those two weeks, and you just admitted that you were doing so.
Note, "Honest Mistake" does not ignore what someone says.

 If you think it is fun to endlessly talk in circles then
you will get very little dialogue with me.