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

On 5/21/24 10:22 AM, olcott wrote:

On 5/21/2024 7:03 AM, Richard Damon wrote:

On 5/21/24 1:18 AM, olcott wrote:

On 5/20/2024 9:39 PM, Richard Damon wrote:

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

>
That does not matter as long as it is not impossible.

>
But since you claim you did it, you need to show what you did.
>

 I cannot show the behavior of every element of an infinite set
a c function pairs.

So, didn't you say that needing infinite operations to evaluate made something not a truth beared?

 

The problem is you don't seem to understand that somethings ARE impossible.
>

 It is certainly not impossible for pure function H to correctly
simulate D.

No, but it is impossible for a pure function H to correctly simulate this D built on that H by the definition of Computation Theory AND provide an answer.

 

Like building a Turing Machine that always correctly determines if another Turing Machine/Input combination will halt.
>
Your claims that you make one that answers the proof case, is just proven to be a lie, and your proof is based on first assuming it is possible and then using that "fact" to try to prove your answer, which is just the thing you claim you are not allowed to do.
>

 In the last two years I have not even exaggerated.
Lets call a truce on accusations of lying you eventually
proved that you were not lying about this key point and I
updated my spec to address the issue that you raised.

Really, how many times did you say that I did not provide a counter example?

 I made sure to not call you a liar on this. I said that until
proved otherwise I will assume that you are a liar and then
you proved otherwise.

But you continued to assert a statement that was untrue, even though it was proved incorrect, you LATER changed your definition to try to get around my answer,
You still haven't refuted the first method.

 

Thus, it is proven that you whole concept is just built on inconsistant lies.
>

>

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

>
Pure functions <are> Turing computable functions until you
conclusively prove otherwise.

>
So, you still don't understand the meaning of the words.
>

  Try and point out the specific error and I will correct any
mistake that you find. Until you provide a basis I will assume
that your claim is baseless.

"Correct Simulation" to show something about non-termination, must be per the methods of Computation Theory, which means like a UTM, which means it does not stop.
A "Computable Function" isn't a program, but a mathematical concept of a mapping from the input set to the output set for which there exists an finite algoritm that computes it. (The program is that algorithm, not the Function).
Note also, a "Pure Function" and this algorithm are NOT exactly equivalent. Pure Function might take a hidden input that makes copies of the function not equivalent, breaking them form being the requirements of an algorithm, which is a bit stricter, as it requires that ALL COPIES return the same answer for the same inputs.
Also, it is possible for an algorithm to violate the definiton of a "Pure Function" in certain limited manners, and still be a proper algorithm, the key is that the definition of an algorithm is a strictly Input to Output relationship, and doesn't talk about how the answer is given.

 

Your claim is like saying that cats are 10 story office building.
>

>

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

>
*That is irrelevant to the current post*
*You can always look at the title and see if you went off topic*

>
No, you keep making the error, and thus destroy your arguement.
>

 Since I am only responding to you via this single thread I
don't have to cut off the first divergence from the title.
 

>
>
*This boiler plate will be the only reply*
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.
>
Enlarge the category a tiny little bit and then the time
becomes infeasible.
>
The tiniest little divergence from the title of this
thread and I totally ignore and erase everything else
that you say.
>
>

>
And if you can't actually define your category or the thing to be analyzied you are just wasting your time, as if you don't know where you are going, it is hard to find the path.
>

 The way I see it I defined it correctly and completely and you
are simply pretending otherwise. Until you prove otherwise I
will continue to assume this.

But since you can't clearly state it, it means we can't help you.

 You seem to favor baseless rhetoric because you know that baseless
rhetoric with ad hominem mixed in is very convincing for gullible fools.
Gullible fools are outside of my target audience.
 

Nope, your deception seems to be an attempt to go after gullible fools.
If you where honest, you could post you whole arguement and let it be worked on.
 From your past, the reason you need to break the arguement into pieces is you need to seperate to logic to allow a change of definition between the sections.
For instance, you definition here of correct simulation means your results can not be used to show non-halting.
My guess is in a later section, you will pull out the rule that if a correct simulation doesn't reach a final state, the input is non-halting, which is just a LIE because you have changed definition mid proof.
This has been your history.