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

On 8/12/24 12:52 PM, olcott wrote:

On 8/12/2024 11:42 AM, olcott wrote:

On 8/12/2024 11:10 AM, Richard Damon wrote:

On 8/12/24 11:34 AM, olcott wrote:

On 8/12/2024 10:05 AM, Richard Damon wrote:

On 8/12/24 9:16 AM, olcott wrote:

On 8/12/2024 8:04 AM, Richard Damon wrote:

On 8/12/24 8:43 AM, olcott wrote:

On 8/11/2024 12:06 PM, Richard Damon wrote:

On 8/11/24 8:40 AM, olcott wrote:

On 8/11/2024 6:08 AM, Richard Damon wrote:

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

On 8/10/2024 9:21 PM, Richard Damon wrote:

On 8/10/24 9:43 PM, olcott wrote:

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

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

>
That has never been true. It is always the case that every
decider of any kind only computes the mapping from its input
finite string and never gives a rat's ass about anything else
anywhere else.

>
No, you are confusing capability with requirements.
>
A "Foo Decider" has ALWAYS been required to compute the "Foo" mapping, as that mapping is defined.
>
The "Halting" mapping is defined as the behavior of the machine/ input represented by the input, so the input needs to be a representation of the program and input and the decider tries to compute the mapping of that representation to the behavior that program represents.
>
How that isn't the "mapping" of the input to a Halt Decider seems to put a big hole in your argument.
>
So, the behavior of the program the input describes *IS* the mapping that HHH needs to try to compute to be a halt decider, as that is the mapping that Halting defines.
>
Now, it is only CAPABLE of computing a computable mapping, like a finite length emulation of the input, and since it has been shown that Halting is NOT a computable mapping, there will be some inputs (like H^) that the decider WILL get wrong. That doesn't say the problem is wrong, or specifies the wrong mapping, just that the problem can't be done with a computation.
>
Your HHH may be a decider, if it ALWAYS halts for any input give to it, but since the answer it gives doesn't always match the Halting mapping, it just isn't a Halt Decider.
>
>

>
Ben should have known this. He didn't. People here that pretend
to know computer science should know that. That they don't proves
that they are (to some degree) fakers.

>
What make you think they don't know it.
>
After all, the mapping of the finite string that completely represents the program and input to be decided to whether that program and input that it represents will halt when run is a perfectly defined mapping.
>

>
The semantics of my 100% fully specified concrete example
conclusively proves that the behavior of DDD correctly emulated
by HHH is a different sequence that the directly executed DDD().

>
Nope, since you have never shown the requested output, you have no grounds to claim that you HHH does a correct x86 emulation of the input.
>
Remember, that means the trace is of what HHH does, so starts with is emulating the beginnig of DDD(), and then following the call to HHH that it makes into HHH, all the way until the emulator decides to stop.
>
Then you need to point out what instruction that it correctly emulated differed from what the actually directly executed machine would have done, and explain WHY its difference is correct.
>
>

>
Even a pretty stupid person can see that each HHH does emulate
its input correctly even if it does this by wild guess. They
*merely have to bother to pay attention that the emulated lines*
*are the same lines as the x86 source code of DDD*
>

>
No, each HHH CONDITIONALLY emulates the input it is given, and will abort its emulation and return to its caller if it decides the input isn't going to halt. As such, to prove infinite recursion you have to show that NONE of the emulated HHHs will abort their emulations and return, which, since they are the same HHH as deciding, means your top level HHH can't do that either, so it fails to be a decider.
>

That after three years no one has bothered to do that can't seem
to have any plausible explanation besides playing sadistic trollish
head games.

>
No, the fact that you can't prove that the "correct emulation" differs from the Direct Execution means your claim that they differ is a lie, and thus HHH is just wrong about it deciding that DDD will not halt, when it does.
>

>
_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]
>
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec

>
Note, this is NOT a correct emulation, and is just your way to try to LIE.
>
We need to see the instruction of HHH here.
>

>
In other words you cannot see that the following code exactly
matches the x86 source-code of DDD thus proving that the second
HHH did emulate it input correctly?
>

>
Your problem is that that is not the COMPLETE x86 source code of the PROGRAM DDD, as that needs the code for HHH included in it.
>
A correct x86 emulation of DDD includes the correct emulation of HHH.
>

>
It does do this yet mixing in the 200 pages of other code
makes it too difficult to see the execution trace of DDD.
>

>
No, to make a claim, you need to provide the actual proof.
>

>
Four expert C programmers (two with masters degrees in
computer science) agree that DDD correctly simulated by
HHH does not halt.
>

>
But your HHH doesn't "Correctly Simulate" DDD by the same definition that makes that true.
>
So, you are just showing you are a liar.
>

>
When I state verified facts I am definitely not a liar
even when I do not make this verification available
to others.

>
And when you claim facts that are not true, you are a liar.
>

>

>
Also, "4 experts" don't make a proof, just a logical fallacy, which just also prove you don't know what you are talking about, but are just a pathological liar.
>

>
It has always been a tautology.
I conclusively proved that with the execution trace that
you are persistently trying to get way with ignoring.
>
>

>
Nope, depends on the meaning you give the words.
>

>
This algorithm is used by all the simulating termination analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then
>
You know that you have only been playing head games on this.

>
And since the D that H has been simulating (that is what its simulated D means) will Halt when we look at its full behavior, the condition is not true.
>
You just don't understand the difference between the D (that H is simulating) and the simulation that H does of that D.
>
Perhaps this is too fine of a detail for someone who has decided not to actually study the theory, or perhaps it is just related to your confusion of Truth and Knowledge.
>
The input D has its actual behavior whether we know it or not, so that behavior exists before we ever run or simulate the program. We only know that behavior by actually running or simulating the program, and conclusivel seeing what it does, or being able to correct prove that behavior.
>
Since your H *DOES* abort its simulation and return to its caller (the other Hs, like the one that doesn't return are only hypotheticals, not the one you are proposing as the ONE that main calls and returns your claimed right answer, then the behavior of the PROGRAM D is to call H, and then H *WILL* return to it, and then D will return.
>
The fact that H can't simulate to that point is irrelevent for the behavior of D, only for the knowledge of H.
>

>

Since you call a partial simulation as being a "Correct Simulation", if HHH does a partial simulation of DDD and returns to its call, then the DDD that this DDD that HHH has only partially simulated and returned to an instance of will be halting and reach that final instruciton.
>
Thus, by the definitions you are trying to use, it is not true.
>
*IF* you accept that the only correct simulation is a complete simulation, then it is a tautology, but your HHH that answers doesn't do one, and is given a DIFFERENT DDD then the one built on the HHH that does one (since the code of HHH is part of the code of the PROGRAM DDD, which is what the input represents) so you can't use the "tautology" to say HHH is right, and thus those claims are just, again, LIES.
>
You "execution trace" just proves tha that you don't understand the question, as it is NOT a "x86 simulation" of the input DDD, as HHH clearly doesn't trace through all the code of HHH. So, your claim is just a lie.

>
Right and you never see the word "UNTIL" even if I repeat
it 10,000 times because you are only playing head games.

>
But the CONDITION isn't that it won't halt until aborted, but it will not halt EVER.
>

>
When you insist on disagreeing with the semantics of the x86
language an many times as you have it is unreasonably implausible
to construe this as any sort of honest mistake.
>
>

>
I am absolutely shocked that Mike disagrees though.
>
When we reasonably assume that Mike is honest and from this
assumption assume that the either knows the x86 langugae or
would have said that he doesn't. That does not leave much
else.
>
That he will not point out any divergence of the x86
execution trace of DDD emulated by HHH from the semantics
of the x86 language is significant indication seems quite
telling that he is wrong.
>
>

 No, the problem is you are just a totally stupid lying individual.
 YOU don't understand the rules of the x86 code, or don't care if you are wrong, as NOTHING in the x86 language allows the leaving of the direct exectuion thread and into showing the code the simulator being simulated is simulating. The ONLY correct answer is showing it doing the simulating.
 

I HAVE pointed out the exact point you "correct emulation" deviates from the x86 requirments, > and you only answer seems to be that the x86 model of simulation gets too long. In other words, you logic system allows people to just LIE if they want to.