Re: Can D simulated by H terminate normally?

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

 

Since there exist some H that can do it, it is incorrect to asset that no H can do it, so your criteria to aborts seem to fail.
>

 Not only does my H not do it that way I can also show all of the software engineering details of how no H can possibly do it that way.

So, what fails for the two methods I have described?
You seem to have blinders that you ignore anything that disagrees with you. That just shwos tha tyou are not really interested in honest dialog, and are really just a pathological liar that doesn't understand what the nature of what truth actually is.

 

If you just mean that THIS H will not reach that point, then we can show that you definition is a trivial toy as an H that just always "aborts its simulation" (by not starting one) and returns 0 is "Correct" and thus ALL inputs are non-halting.
>
Your problem is you don't seem to actaully read answers and continue just making your same mistakes, proving that you are not interested in an honest dialog, and are just being your normal pathological liar.
>

>

>

>

return 0, while the H called by main just continues simulating through that call and sees the return and the final halting.
>
You are just proving how STUPID you are and how you just don't understand how logic and specifications work.

>

>

>

>