Re: I have always been correct about emulating termination analyzers --- PROOF

On 10/19/24 11:20 PM, olcott wrote:

On 10/19/2024 9:27 PM, Richard Damon wrote:

On 10/19/24 8:13 PM, olcott wrote:

On 10/19/2024 4:53 PM, Richard Damon wrote:

On 10/19/24 7:26 AM, olcott wrote:

On 10/19/2024 6:21 AM, Richard Damon wrote:

On 10/18/24 11:19 PM, olcott wrote:

On 10/18/2024 9:49 PM, Richard Damon wrote:

On 10/18/24 8:52 PM, olcott wrote:

On 10/18/2024 6:06 PM, Richard Damon wrote:

On 10/18/24 10:10 AM, olcott wrote:

On 10/18/2024 6:17 AM, Richard Damon wrote:

On 10/17/24 11:47 PM, olcott wrote:

On 10/17/2024 10:27 PM, Richard Damon wrote:

On 10/17/24 9:47 PM, olcott wrote:

On 10/17/2024 8:13 PM, Richard Damon wrote:

On 10/17/24 7:31 PM, olcott wrote:

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
>
When DDD is correctly emulated by HHH according
to the semantics of the x86 language DDD cannot
possibly reach its own machine address [00002183]
no matter what HHH does.
>
+-->[00002172]-->[00002173]-->[00002175]-->[0000217a]--+
+------------------------------------------------------+
>
That may not line up that same way when view
>
>
>
>
https://en.wikipedia.org/wiki/State_diagram
>

>
>
Except that 0000217a doesn't go to 00002172, but to 000015d2
>

>
IS THIS OVER YOUR HEAD?
What is the first machine address of DDD that HHH
emulating itself emulating DDD would reach?
>

>
Yes, HHH EMULATES the code at that address,

>
Which HHH emulates what code at which address?
>

>
Everyone, just once, which you should know, but ignore.
>
The Emulating HHH sees those addresses at its begining and then never again.
>
Then the HHH that it is emulating will see those addresses, but not the outer one that is doing that emulation of HHH.
>
Then the HHH that the second HHH is emulating will, but neither of the outer 2 HHH.
>
And so on.
>
Which HHH do you think EVER gets back to 00002172?
>
What instruction do you think that it emulates that would tell it to do so?
>
It isn't the call instruction at 0000217a, as that tells it to go into HHH.
>
At best the trace is:
>
00002172
00002173
00002175
0000217a
conditional emulation of 00002172
conditional emulation of 00002173
conditional emulation of 00002175
conditional emulation of 0000217a
CE of CE of 00002172
...
>

>
OK great this is finally good progress.
>

The "state" never repeats, it is alway a new state,

>
Every emulated DDD has an identical process state at every point
in its emulation trace when adjusting for different top of stack values.

>
>
Nope, remember, each of those levels are CONDITIONAL,

>
*There are THREE different questions here*
(1) Can DDD emulated by HHH according to the semantics
     of the x86 language possibly reach its machine address
     [00002183] no matter what HHH does?
>

>
Ambiguouse question, as pointed out previously.
>
A) Do you mean the behavior of the PROGRAM DDD, that HHH has emulated a copy of.
>
In that case, the answer is, if HHH aborts its emulation and return, YES, if HHH never aborts its emulation, and thus doesn't ever return an answer to anyone NO.
>
B) If you mean, does the emulation done by HHH ever reach that place, no.
>

>
We are not asking if the code of HHH reaches inside
the code of DDD. Of course it doesn't this is stupid.
>
We are asking does any DDD of any DDD/HHH pair of the
infinite set of pairs such that DDD is emulated by HHH
according to the semantics of the x86 language reach its
own return instruction?
>

>

(2) Does HHH correctly detect and report the above?

>
No, because that isn't what you claim HHH is doing, so it can't be correct about that.
>

>
In other words you fail to comprehend that DDD failing
to reach its "return" instruction is isomorphic to:
>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
 > ... PO really /has/ an H
 > (it's trivial to do for this one case) that correctly determines
 > that P(P) *would* never stop running *unless* aborted.
>

We need to look at the two possible interpreations to question 1.
>
If you means A, then since HHH says no but the correct answer is yes, it is wrong.
>
If you mean B, and you mean your question is can HHH predict that it can't reach the final state, but only needs to be right for this one input, then the problem is the question has become trivial, if it doesn't need to actually know anything about the input, it can just be programmed to say no.
>

>
I mean that the execution trace of DDD proves that HHH is correct
to reject DDD as impossibly reaching its own "return" instruction
even if it just guesses.
>

Also, we can make a trivial HHH, that just does the absolute minimum, then aborts and returns no unconditionally to be correct, showing your problem isn't interesting.
>
Or, your "problem" has left the domain of Program Theory, becuause you don't consider DDD to be an actual program, at which point it also becomes much less interesting.
>

>
(3) Does HHH do (2) it as a Turing computable function?
>

>
No, because the method your HHH uses isn't possible to be expressed as a Turing Machine with a seperate input tape with the full representatation of the program DDD.
>

>
Yet again you are not answering the question that
was asked. This must be your ADD.
>
The summation is the DDD does not halt and HHH
does correctly report this even if HHH as it is
currently implemented is not a Turing computable
function.

>
But the Program DDD DOES halt,

>
*Try and tell that to ChatGPT and it will make a fool of you*
https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e
>
>
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

>
>
Ignore any false information about the definiton of a termination analyzer, and recall that the correct answer to a question given to a termination analyzer is that it must report about the actual behavior of the program that it has been given,

>
You are directly contradicting the verified fact that DDD
emulated by HHH according to the semantics of the x86 language
cannot possibly reach its own "return" instruction and halt.
>

>
But that isn't what the question being asked

 Sure it is. You are just in psychological denial as proven by
the fact that all attempted rebuttals (yours and anyone else's)
to the following words have been baseless.
 Does the input DDD to HHH specify a halting computation?

Which it isn't, but is a subtle change of the actual question.
The actual question (somewhat informally stated, but from the source you like to use) says:
In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever.
So, DDD is the COMPUTER PROGRAM to be decided on, and is converted to a DESCRIPTION of that program to be the input to the decider, and THAT is the input.
So, the question has ALWAYS been about the behavior of the program (an OBJECTIVE standard, meaning the same to every decider the question is posed to).

(where a halting computation is defined as)
 DDD emulated by HHH according to the semantics of the x86
language reaches its own "return" instruction final state.

Except that isn't the definition of halting, as you have been told many times, but apparently you can't undetstand.
Halting is a property of the PROGRAM. It is the property, as described in the question, of will the program reach a final state if it is run, or will it never reach such a final state.
DDD emulated by HHH is a standing for that only if HHH never aborts its emulation. But, since your HHH that answer must abort its emulation, your criteria is just a bunch of meaningless gobbledygook.
It seems that a major part of the problem is you CHOSE to be ignorant of the rules of the system, but learned it by what you call "First Principles" (but you don't understand the term) by apparently trying to derive the core principles of the system on your own. This is really a ZERO Principle analysis, and doesn't get you the information you actually need to use.
A "First Principles" approach that you refer to STARTS with an study and understanding of the actual basic principles of the system. That would be things like the basic definitions of things like "Program", "Halting" "Deciding", "Turing Machine", and then from those concepts, sees what can be done, without trying to rely on the ideas that others have used, but see if they went down a wrong track, and the was a different path in the same system.
It seems you never even learned the First Principles of Logic Systems, bcause you don't understand that Formal Systems are built from their definitions, and those definitions can not be changed and let you stay in the same system.
Since you like to break THAT rule, you put yourself outside of the domain of Formal Logic completely, and thus LIE when you claim to be working on a problem that is only actually defined in a specific system.

 

is, it is (or you claim it to be) about Termination, which is about the behavior of the PROGRAM / FUNCITON (with all its used code) not about a partial emulation of it.
>
Your statement is just an equivocation trying to confuse the idea of comnplete correct emulations showing actual behavior, while a partial, but correct, only shows partial behavior, not final behavior.
>
The VERIFIED FACT, is that what is defined as the BEHAVIOR of DDD, which is what a termination analyser (or Halt Decider) has been determined to be halting for the actual HHH you have provided.
>
Your claim tries to refer to the behavior of an only partial emuation and claim that it shows non-termination, which it doesn't.
>
You are just proving that you are nothing but a stupid liar.
>
Your "Verified Fact" is just your LIE based on equivocation, as you have been told, but don't seem to be able to understand it.
>
Sorry, you claimed no one could persuade the AI that you were wrong, and I did it with ONE try.
>
How many attempts did it take you to get the answer you wanted out of Chat GPT?

 I only ever tried twice, once several months ago and
it got confused and this time. You can see all of the
details of this time.

SO, you don't even understand what I mean by "once".
I thought a bit, then typed ONE STATEMET into your ChatGPT and got that answer. I didn't need to try other options.

 I explained everything just once at the beginning.
Then I challenged it with your rebuttal several
times in several ways. Every time that I did this
it explained your mistake in great detail.

But it sure sounds like you tried several times in one "session" at the keyboard.

 https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e
This is the most powerful free version it is full 4.0.
You don't need to login.
 

So?
AI is not the source of the defintions. The definitions established in the original logic system is.
You are just showing you don't undertstand the basic nature of how to use logic.
Sorry, you are just proving yourself to be a stupid idiodic pathological liar.