Re: Can D simulated by H terminate normally?

On 5/1/2024 7:10 PM, Richard Damon wrote:

On 5/1/24 12:11 PM, olcott wrote:

On 5/1/2024 6:23 AM, Richard Damon wrote:

On 4/30/24 11:56 PM, olcott wrote:

On 4/30/2024 5:46 PM, Richard Damon wrote:

On 4/30/24 11:55 AM, olcott wrote:

On 4/30/2024 6:33 AM, Richard Damon wrote:

On 4/30/24 2:07 AM, olcott wrote:

On 4/29/2024 6:19 PM, Richard Damon wrote:

On 4/29/24 10:51 AM, olcott wrote:

On 4/29/2024 6:25 AM, Richard Damon wrote:

On 4/28/24 11:48 PM, olcott wrote:

On 4/28/2024 6:05 PM, Richard Damon wrote:

On 4/28/24 3:48 PM, olcott wrote:

On 4/28/2024 2:36 PM, Richard Damon wrote:

On 4/28/24 3:26 PM, olcott wrote:

On 4/28/2024 2:18 PM, Richard Damon wrote:

On 4/28/24 2:52 PM, olcott wrote:

On 4/28/2024 1:39 PM, Richard Damon wrote:

On 4/28/24 2:19 PM, olcott wrote:

On 4/28/2024 1:06 PM, Richard Damon wrote:

On 4/28/24 1:50 PM, olcott wrote:

On 4/28/2024 11:08 AM, Richard Damon wrote:

On 4/28/24 11:33 AM, olcott wrote:

On 4/28/2024 10:08 AM, Richard Damon wrote:

On 4/28/24 9:52 AM, olcott wrote:

On 4/28/2024 8:19 AM, Richard Damon wrote:

On 4/28/24 8:56 AM, olcott wrote:

On 4/28/2024 3:23 AM, Mikko wrote:

On 2024-04-28 00:17:48 +0000, olcott said:
>

Can D simulated by H terminate normally?

>
One should not that "D simulated by H" is not the same as
"simulation of D by H". The message below seems to be more
about the latter than the former. In any case, it is more
about the properties of H than about the properties of D.
>

>
D specifies what is essentially infinite recursion to H.
Several people agreed that D simulated by H cannot possibly
reach past its own line 03 no matter what H does.

>
Nope, it is only that if H fails to be a decider.
>

>
*We don't make this leap of logic. I never used the term decider*
*We don't make this leap of logic. I never used the term decider*
*We don't make this leap of logic. I never used the term decider*
*We don't make this leap of logic. I never used the term decider*

>
>
You admit that people see that as being a claim about the Halting Problem, and thus the implied definitons of the terms apply.
>

>
The only way to get people to understand that I am correct
and thus not always ignore my words and leap to the conclusion
that I must be wrong is to insist that they review every single
detail of all of my reasoning one tiny step at a time.
>
>

>
No, the way to get people to understand what you are saying is to use the standard terminology, and start with what people will accept and move to what is harder to understand.
>
People have no obligation to work in the direction you want them to.
>
Yes, when you speak non-sense, people will ignore you, because what you speak is non-sense.
>
You are just proving that you don't understand how to perform logic, or frame a persuasive arguement.
>
That fact that as far as we can tell, your "logic" is based on you making up things and trying to form justifications for them, just makes people unwilling to attempt to "accept" your wild ideas to see what might make sense.
>

>
Linguistic determinism is the concept that language and its structures
limit and determine human knowledge or thought, as well as thought
processes such as categorization, memory, and perception.
https://en.wikipedia.org/wiki/Linguistic_determinism

>
So? Since formal logic isn't based on Linguistics, it doesn't directly impact it. IT might limit the forms we
>

>
Some of the technical "terms of the art" box people into misconceptions
for which there is no escape. Some of the technical "terms of the art"
I perfectly agree with.
>
*Important technical "term of the art" that I totally agree with*
Computable functions are the formalized analogue of the intuitive notion
of algorithms, in the sense that a function is computable if there
exists an algorithm that can do the job of the function, i.e. given an
input of the function domain it can return the corresponding output. https://en.wikipedia.org/wiki/Computable_function

>
But you seem to miss that Halting isn't a "Computable Function", as Turing Proved.
>

>
Even the term "halting" is problematic.
For 15 years I thought it means stops running for any reason.

>
And that shows your STUPIDITY, not an error in the Theory.
>

Now I know that it means reaches the final state. Half the
people here may not know that.

>
No, I suspect most of the people here are smarter than that.
>

>
Yet again only rhetoric wit no actual reasoning.
Do you believe:
(a) Halting means stopping for any reason.
(b) Halting means reaching a final state.
(c) Neither.
>

>
In Computation Theory, which is the context of the discussion, Halting means reaching a final state.
>
The key is that NOT HALTING, means that the machine does NOT reach a final state after an unbounded number of steps of operation.
>
An aborted simulation does not determine, by itself, if the machine being simulated is halting or not. This seems to be a fact you don't understand.
>
Halting is strictly a property of the direct execution of the machine, or things that are actually proven to be equivalent, like the (unaborted) simulation by a UTM.

>
OK that is complete agreement with my correct understanding of the conventional notion of halting.
>
When we come up with a brand new idea such as a simulating termination
analyzer that simulates its input until it matches a non halting
behavior pattern your notion of halting simply ignores this altogether.
>

>
Nope, it means that a correct "non-halting behavior pattern" will be a pattern that when seen in the simulation means that unconditionally the program, when directly run or simulated by an actual UTM, will not halt, per the definition.
>

>
Show me anywhere in the conventional terms of the art where
a simulating termination analyzer is defined exactly that way.
>
>

>
But we weren't talking about the UNDEFINED term of a a Simulating Termination Analyzer, but about the Halting Theorem.
>
After all, we were talking about the definition of HALTING, and thus what the two answers mean.
>
As I have said, you really need to stop trying to misuse words, as all it is doing is making you whole concept incompatible with your final goal.
>
Halting means Halting, so non-haling means non-halting, and that only means that the machine will not stop after an unbounded number of steps.
>
If you want to have some other meaning, use some other word to make it clear.
>
And, you will need to publish the actual DEFINITIONS of your terms, not just make people try to guess by context.

>
int H(ptr x, ptr y); // ptr is pointer to int function
>
01 int D(ptr x)
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11   H(D,D);
12 }
>
Simulating termination analyzer H determines whether or not
D(D) simulated by H can possibly reach its final state at its
own line 06 and halt whether or not H aborts its simulation.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
>
(a) It is a verified fact that D(D) simulated by H cannot
possibly reach past line 03 of D(D) simulated by H whether H
aborts its simulation or not.
>
*The above is your opportunity for me to get more specific*
>

>
So, you think just repeating your same description provides better definitions for the words?
>
By such an unlimited definition, your claim is clearly wrong as the H that D calls could detect it being called by D, and just immediately

>
Your lack of understanding that D simulated by H cannot possibly reach
past its own line 03 is your error here. We can go through the software
engineering details of exactly why you are wrong.

>
>
So, what was wrong with the example I gave here?
>
You refused to define the rules on H, so that H is allowed.
>
>
So, you are just proven to be a LIAR.

This is your mistake.
When executed H(D,D) aborts its simulated input the whole recursive
chain immediately stops no matter where it is. None of its functions
return to their callers. There is empirical proof of this.
>

>
No, you confuse context.
>
If Main calls H(D,D) that then simulates D(D) and that simulation of D(D) calls a simulated H(D,D) that sees that it is being simulated and immediately returns 0, then the simulated D(D) will then reach that line and you claim is proven wrong.
>

>
The actual fully operational code proves that you are wrong about this.
We can go over the details of how and why you are wrong.

>
Really?
>
The fact that ONE program doesn't get there doesn't prove that NO program can get there.
>
I have described TWO different program designes that make that arguement fail.
>
Your refusal to deal with this just shows that you are not really interested in honest dialog, but
>

>
We can go into every single detail of this until we have complete
closure.
>
(1) It must be the directly executed outermost H that aborts
the simulation of its simulated D.
>
(2) When the outermost H aborts its simulated D then this simulated
D no longer calls its simulated H thus the whole recursive chain immediately stops with no function returning to its caller.
>
When you try to show otherwise I will step-by-step detail by
detail point out each error.
>

>
But I *have* described (two different ways) how a "Directly Executed Outermost H" can do a simulation of its "Simulated D" that reached that point in its simulation, so it never needed to get to (2).
>

>
I can't even understand what you are claiming and you provide
no basis for this claim.

 Why? are you THAT stupid?
 You have edited them out of posts, so you have seen them and not commented on them.
 To me, that is an acceptance.
 

That is not acceptance. I will quit editing your posts yet
that may make it more difficult to find my one line response.
I do not carefully examine every word that you say because
you say stuff that is way way beyond the one point that
I will focus on:
(a) It is a verified fact that D(D) simulated by H cannot
possibly reach past line 03 of D(D) simulated by H whether H
aborts its simulation or not.
*IT IS CATEGORICALLY IMPOSSIBLE THAT YOU EVER CORRECTLY SHOWED THIS*
 >>> But I *have* described (two different ways) how a "Directly Executed
 >>> Outermost H" can do a simulation of its "Simulated D" that reached
 >>> that point in its simulation, so it never needed to get to (2).
Since that is related to my one point I will review it again
when you post it again.

>

I HAVE shown how to do this, and you have not done what you claim you "will" do, so obviously that claim is just a lie.
>

>
*Provide all of the details and I will point out your mistake*
It is a software engineering mistake that can be empirically proven false.

 A really detail answer, as it seems you are trying to ask for will require a billing agreement and payment.
 I will attempt a brief description, (see below) but if that isn't good enough, you need to figure out what YOU really want to do. It isn't my job to help your understand where you are wrong, and I surely don't want you help you prove a false statement, and have no interest in helping you prove a statement that because it is so disconnected from the real problem that it is meaningless.
 

My point is categorically true so giving me the gist of your
rebuttal should be easy to refute.

>

>
IF H is correct that D will never stop running just by aborting it, then

>
That seems to be nonsense to me.
A computer that keeps on running after you yank the power cord?

 What power cord?
 

THIS JUST SEEMS CRAZY TO ME.
 >>> D will never stop running just by aborting it

You don't seem to understand the nature of Computation theory.
 

I do but we cannot begin to talk about that until after we
have mutual agreement on this.
(a) It is a verified fact that D(D) simulated by H cannot
possibly reach past line 03 of D(D) simulated by H whether H
aborts its simulation or not.
I am going to simply assume the the rest of what you say
does not directly or indirectly pertain to the above point.

The Computation engines described are pure mathematical formulation, that run just on ideas.
 Those physical machines we use to see the result are just embodiment of simulators.
 

>

a "correct" solution includes the trivial H that just immediately "aborts" its simulation and returns 0.
>
>
Until you refine your current non-existant definitions of the terms, you have the problem described.
>

>
I can't have any idea what you are saying until you fill in
all of the details of your baseless claims.
>

 But you refuse to listen.
 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 match the behavior of the direct execution of M(d), what H does is fork its simulation into two threads.
 Thread 1 continues the simulation assuming that the call to H(M,d) will return a 1, and if that simulation reaches a halting state, then 1 is the answer, and thread 2 can be abandoned.
 Thread 2 continues the simulation assuming that the call to H(M,d) will return a 0, and if that simulation reaches a provable non-halting pattern, then 0 is the answer, and thread 1 can be abandoned.
 It may be the case that BOTH answer could be correct, in which case depending on exactly how the forking works and how long it takes each to get to the answer, either answer might be given, but then, both are correct.
 It may be the case that neither answer can be shown correct, if Thread one can prove that it will be non-halting and Thread 2 halts, then the decider has proven the machine to be "contrary" to it. But it might be the case that it never can figure that out, and it just doesn't answer.
 But, in all cases, it gets past the call to H(M,d), so your criteria, that NO H can get there is not meet.
  The second method uses the fact that you have not restricted what H is allowed to do, and thus H can remember that it is simulating, and if a call to H shows that it is currently doing a simulation, just immediately return 0. Thus, H can actually correct simulate the instruction at the call to H, as they will execute just a few instructions testing that condition and returning, and thus not run into the problem you ran into where H just couldn't simulate itself because it got bogged down.
 In this case it is actually true that the direct execution of D(D) differs from the correct simulation of the input by H, as H is no longer a "Computation" per the rules of Computation Theory, but you have admitted that you are abandoning those, so it doesn't matter (of course that make trying to get your results to apply to something similar harder, but that is why you need to try to come up with some actual definitons.)
 So, by the rules of Compuation Theory, your H is not correct, but by your lack of rules, your conclusion that H can not simulate past the call are incorrect, so you proof is also broken.
 

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer