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

On 10/20/24 11:32 AM, olcott wrote:

On 10/20/2024 6:46 AM, Richard Damon wrote:

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:

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

 That is the problem. Because it is too informally stated
it can be misunderstood. No one ever intended for any
termination analyzer to ever report on anything besides
the behavior that its input actually specifies.

What is "informal" about the actual problem.
The informality is that it comes from a non-academic source, so doesn't use the formal terminology, which you just wouldn't understand.
What is to be misunderstood?
Given that you start with a program, which is defined as the fully detailed set of deterministic steps that are to be performed, and that such a program, will do exactly one behavior for any given input given to it, says that there is, BY DEFINITIOH a unique and specific answer that the analysize must give to be correct.
The requirement says that the user needs to, by the rules defined by the analyszer, describe that program, and if the analyzer is going to be able to qualify, must define at least one way (but could be multiple) of creating the proper description of that input program, and that an given input that meets that requirement will exactly represent only a singe equivalence set of programs (an equivalence set of programs is a set of programs that all members always produce the same output results for every possible input). Thus, there must exist a unique mapping from each input to such an equivalence set to a correct answer.
Thus, it is THAT BEHAVIOR, the behavior of the full program that *IS* the behavior that its input actually specifies.
WHAT IS WRONG WITH THAT?
Now, this does point out that you claim of what could be the "finite-string input" for you HHH, can't possible be such a correct input,

 

So, DDD is the COMPUTER PROGRAM to be decided on,

 No not at all. When DDD is directly executed it specifies a
different sequence of configurations than when DDD is emulated
by HHH according to the semantics of the x86 language.

And what step actually correctly emulated created the first difference in sequence?
You have been asked this many times, and just fail to answer, because your claim has just been proven to be a *LIE*, so of course you can't find a proof for it,

 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.

But that is just admitting that your HHH isn't answering the HALTING PROBLEM, but the POOP problem, which has a different domain

 That everyone has always believed that a termination analyzer
must report on behavior that it does not see is the same sort
of mistake as believing that a set can be a member of itself.
Eliminate the false assumption and the issue is resolved.

There was NEVER a requirement that the termination analyser be able to "see" the answer. That is part of the question. If it COULD always see the behavior in question, then the question would be computable.
The fact that it is impossible to build a decider, like H that can actually see the correct answer for D, is what shows that Halting is non-computable.
Flibble has shown a method that you could use to build an HHH that is given the DDD that calls it, and correctly determines the answer, by dividing the problem into two cases and see if either of them work out.
Thus DDD is not a "pathological input" for a smart enough termination analyzer, working in the non-turing complete space defined by your environment structure, but that case is "computable".
It is only when we go to the original D/P that does the opposite of what H returns, that we find that we can not answer, and at least that machine was able to figure that case out as being unsolvable.

 

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

 Then it is the same error as a set defined as a member of itself.
The ZFC resolution to Russell's Paradox sets the precedent that
discarding false assumptions can be a path to a solution.
 

Nope. While a turing machine can not contain a "copy" of itself within it (as that would lead to an infinite machine from the nesting), there is no problem with giving a machine as an input a description of a machine that contains a copy of itself.
This is part of what leads to uncomputable questions, but that isn't the same type of error as the illogical contradictions from the rules allowing sets to contain themselves.
There is no "false assumption" to be discarded, and you have done NOTHING to attempt to try to show one.

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

 Sure and if everyone stuck with the "we have always done it that way
therefore you can't change it" ZFC would have been rejected out-of-hand
and Russell's Paradox would remain unresolved.

Which means you just don't understand how Formal Systems work.
The Halting Problem is PROVEN to be uncomputable in the Computation Theory of Turing Complete computations.
If you want to try to define your own different system, you have been invited to do so, but that also comes with the requirement that you need to first FULLY define what you system is going to use as its initial truths and rules (and while you can add new truths or rules, you can't change an existing one) and then show what you can do with that set.
I appears that the biggest problem with this is that you just don't understand logic well enough to actually do that step, so you need to work in systems already built, which means you need to follow those systems rules, which means you need to learn them.
You don't seem to understand, that you can't just imagine a different rule, without looking to see what that affects, and you want to change fundamentals, which have the possibility of totally changing the field, but you have no idea how to figure out what will happen.

 

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

 Much more generically at the philosophical foundations of logic
level all logic systems merely apply finite string transformation
rules to finite strings. Formal mathematical systems apply truth
preserving operations to finite strings having the Boolean value
of true.

So?
The key is that formal system define that there *IS* a pre-defined set of initial known truths and rules, and everyone working in that system needs to use that exact same set of rules.
If you want a different set of known truths and rules, you create a DIFFERENT Formal System and work in that, and you can't claim that something shown is system B applies to system A, because they are different.

 

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

 ZFC did the same thing and successfully rejected the false assumption
that a set can be a member of itself.

No, they defined a *NEW* set theory that used a different set of fundamental truths and rules and then showed what they could do with those truths and rules (something that you could attempt for your ideas if you were smart enough) and that fixed the problems seen, so the "default" system was changed by the comunity to that.

 

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

 The actual barest essence for formal systems and computations
is finite string transformation rules applied to finite strings.

So, show what you can do with that.
Note, WHAT the rules can be is very important, and seems to be beyond you ability to reason about.
After all, all a Turing Machine is is a way of defining a finite stting transformation computation.

 The next minimal increment of further elaboration is that some
finite strings has an assigned or derived property of Boolean
true. At this point of elaboration Boolean true has no more
semantic meaning than FooBar.

And since you can't do the first step, you don't understand what that actually means.

 Some finite strings are assigned the FooBar property and other
finite string derive the FooBar property by applying FooBar
preserving operations to the first set.

But, since we have an infinite number of finite strings to be assigned values, we can't just enumerate that set.

 Once finite strings have the FooBar property we can define
computations that apply Foobar preserving operations to
determine if other finite strings also have this FooBar property.
 

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

 The actual First Principles are as I say they are: Finite string
transformation rules applied to finite strings. What you are
referring to are subsequent principles that have added more on
top of the actual first principles.
>

But it seems you never actually came up with actual "first Principles' about what could be done at your first step, and thus you have no idea what can be done at each of the later steps.
Also, you then want to talk about fields that HAVE defined what those mean, but you don't understand that, so your claims about what they can do are just baseless.
All you have done is proved that you don't really understand what you are talking about, but try to throw around jargon that you don't actually understand either, which makes so many of your statements just false or meaningless.