Re: HHH maps its input to the behavior specified by it --- key error in all the proofs

On 8/10/24 8:51 PM, olcott wrote:

On 8/10/2024 7:20 PM, Richard Damon wrote:

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

On 8/10/2024 5:47 PM, Richard Damon wrote:

On 8/10/24 6:41 PM, olcott wrote:

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

On 8/10/24 5:37 PM, olcott wrote:

On 8/10/2024 4:33 PM, Richard Damon wrote:

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

On 8/10/2024 3:58 PM, Richard Damon wrote:

On 8/10/24 4:36 PM, olcott wrote:

>
As I have countlessly proven it only requires enough correctly
emulated steps to correctly infer that the input would never
reach is "return" instruction halt state.

>
Except that HHH does't do that, since if HHH decides to abort and return, then the DDD that it is emulating WILL return, just after HHH has stopped its emulation.
>
You just confuse the behavior of DDD with the PARTIAL emulation that HHH does, because you lie about your false "tautology".
>
>

>
Denying a tautology seems to make you a liar. I only
say "seems to" because I know that I am fallible.

>
Claiming a false statement is a tautology only make you a liar.
>
In this case, you lie is that the HHH that you are talking about do the "correct emulation" you base you claim on.
>
That is just a deception like the devil uses, has just a hint of truth, but the core is a lie.
>

>
What I say is provably correct on the basis of the
semantics of the x86 language.

>
Nope.
>
The x86 language says DDD will Halt if HHH(DDD) returns a value.

>
HHH is called by main() there is no directly executed DDD()
any where in the whole computation.
>

>
Except in your requirements, and we can see what it does by adding a call to DDD from main, since nothing in your system calls main.
>

>
All that you need to know is that there is not any
directly executed DDD() anywhere in the computation.

>
But there ccould be, and the behavior of it is what matters.
>

>
The key error of the halting problem proofs all of these
years has been the false assumption that a halt decider
must report on the behavior of the computation that itself
is contained within.

>
But it isn't a false assemption, but an actual requirement.
>
A Halt Decider must be able to correctly answer for ANY Turing Machine represented as its input.
>
ANY includes those that are built from a copy of itself.
>
So, a Halt Decider needs to be able to correctly answer about programs that include copies of itself, even with contrary behavior, which is what makes it impossible to compute.
>
You seem to confuse non-computable with invalid, it seems in part because you don't understand the difference between knowledge and truth.
>

>
Everyone has simply assumed that the behavior of the
input to a decider must exactly match the direct execution
of this input. They only did this because everyone rejected
simulation out-of-hand without review.

>
Because that is the DEFINITION of what it is to decide on.
>
You just don't understand what a requirement is.
>
Since the DEFINITION of "Correct Simulation" that you are trying to use (from a UTM) means a machine the EXACTLY reproduces the behavior of the direct exectution of the machine described by the input, the correct simulation must exactly match the behavior of the direct execution.
>
You can't get out of it by trying to lie about it being different.
>

>
This caused them to never notice that the input simulated
according to its correct semantics does call its own decider
in recursive simulation thus cannot possibly return to its
caller. The Linz proof is sufficiently isomorphic so this equally
applies to the Linz TM proof.

>
Nope, just shows you don't know what "Correct" means.
>
Your proof is NOT "sufficiently isomorphic" since by your own claims it is clearly not even Turing Complete, so no where near isomorphic.
>

>
If HHH were to report on the direct execution of DDD it would
be breaking the definition of a halt decider that only computes
the mapping from its input...

>
Nope. Since the mapping that it is supposed to compute is DEFINED as based on the direct exectut
>

 No it never has been this. I has always been a mapping
from the behavior that the finite string specifies. It
has never been the behavior of the actual computation
that the decider is contained within.

And thatg behavior is specified to be the behavior of the program the input represents. PERIOD.
If the decider thinks it sees any other behavior, the behavior is just computing the wrong mapping.
DEFINITIONS.

 

>
You might not be open-minded or smart enough to understand
this. Mike may be smart enough if he can manage to be
open-minded enough to pay attention to every single detail
of what I said without leaping to the conclusion that I must be
wrong. Ben understood this more deeply than anyone else.
>
>

>
Nope, you are just showing you don't understand what you are talking about.
>

 That no one "believes" the mapping that the finite string
specifies because they never had a slight clue about the
semantics that the x86 language specifies or they do know
this semantics yet don't bother to check the actual trace
because believe that I must be incorrect
DOES NOT MATTER, I AM PROVEN CORRECT EITHER WAY.

No, the behavior of the finite string is DEFINED by the problem statement, and if the decider doesn't generate that, the decider is just wrong.
You keep on getting these things backwards, the decider doesn't get to define the mapping it is computing, it must compute the mapping that has been defined by the problem, which in this case is the halting of the program the input represents.

 

If you want to make any of your claims, PROVE THEM by showing an ACTUAL PROOF starting from the actual definitions and established truths of the field, and then with accepted truth preserving operations show how to combine them to get to your answer.
>

 I did hundreds of times for three years and people are
either clueless or don't want to bother checking that
I am correct.

No, YOU are clueless, because you just refuse to look at the actual provlem statement and understand the basic definition of the field.

 *I am proven correct in that the execution trace of DDD*
*derived by HHH and the simulated HHH exactly matches the*
*x86 source code of DDD*

No, if the trace derived by HHH differs from the direct execution of DDD, then HHH is just INCORRECT.
You keep on claiming it is correct, but you can't show the actual instructin by instruction trace that HHH generates, and then show where it differs from the direct execution.
You just claim that the call to HHH works differently, but it can't, so your claim is just a lie.

 

Your problem is you just don't know any of those basics, so you can't do it, which just makes you into a liar that makes unsubstantiated claims, proving your ignorance.
>

 That you disagree with a tautology makes you necessarily
incorrect even if you do not understand that it is a tautology.

No, I don't disagree with a tautology, you just don't define your terms so it is a tautology.

 

Remember, you are not God, and you don't get to change the rules of the system. That means you need to work within the rules.
>

 I am not changing the rules.

Sure you do, A Halt Decider needs to report if the machine described by its input halts or not.
You say that isn't what it needs to report on, so you are changing the rules.

 

If you want to to try to change the rules, be honest and admit you are working on a new system, and make you definitions and then FORMALLY prove what you can do with such a system. But, since you don't understand the currect system, or it seems even how formal systems work, I don't think that is actually possible for you.

 It has always been that a halt decider computes the mapping
to the behavior that its finite string specifies. It has
never been that a halt decider computes the mapping from
the actual computation that itself is contained within.

And that behavior is the behavior of the actual program the input represents, directly run, and if it reaches the final state.
Anything else is just incorrect and a lie.
That is the DEFININTION.

 No one ever noticed that they could possibly be different
until the notion of a simulating termination analyzer
conclusively proved them to be different on the 100% concrete
basis of the semantics of the x86 language applied to fully
operational code.

Because they CAN'T be.
If you want to show they can, PROVE IT.
This means actually showing the exact trace that HHH is claimed to have made, that exactly emulates each and every instruction of the PROGRAM DDD, which means going into HHH, and then showing the first instruction in that trace where the "Correct Emulation" of DDD by HHH differs from the actual direct execution of DDD.
The fact that you have tried at least 3 times, and keep on producing the WRONG trace, shows that you really don't understand what you need to do.

 That everyone has the same false assumption doesn't make
them correct in the exactly same way of the universal
consensus that the Earth is flat did not make the Earth
non-spherical.
 

No, the fact it is definition, and you can't show why they are wrong, just means YOU are the one with the false assumptions.
PROVE from the formal definitions you point, or you are just showing you don't know what you are talking about,
You have shown that you just don't know enough to prove what you claim, and the fact you can't see that just shows how stupid you are, and that is the worse kind of stupid.