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.
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.
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.
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...
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.
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:HHH is called by main() there is no directly executed DDD()
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. >>>>>>>
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.
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.
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.
*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*
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.
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.
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.
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.
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.
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:HHH is called by main() there is no directly executed DDD()
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. >>>>>>>>>
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.
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.
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().
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*
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.
_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
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
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".
Claiming a false statement is a tautology only make you a >>>>>>>>>>>>>> liar.
Denying a tautology seems to make you a liar. I only >>>>>>>>>>>>>>> say "seems to" because I know that I am fallible. >>>>>>>>>>>>>>
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?
That people have not bothered to look at this for three years
is far too disingenuous to be called merely disingenuous.
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
And, HH may hve decided this, but that isn't a true determination.
Again, more of your lies.
Sorry, your "logic" just proves your stupidity, and the fact you can't
see that just proves how stupid you are, and that is the worse kind of
stupid.
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".
Claiming a false statement is a tautology only make you >>>>>>>>>>>>>>>> a liar.
Denying a tautology seems to make you a liar. I only >>>>>>>>>>>>>>>>> say "seems to" because I know that I am fallible. >>>>>>>>>>>>>>>>
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.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
I now have the first four instructions of HHH highlighted
in red proving that they were correctly emulated.
The code trace for HHH emulating itself emulating DDD
has always been way beyond the capacity of the human mind
unless each instruction of all of the functions in 200
pages is highlighted in its own color.
*THIS WAS NEVER EVER NEEDED IN THE LAST THREE YEARS*
It is dead obvious that HHH must have been emulated correctly
or it could not emulated DDD correctly. I show the trace of
each instance of DDD being emulated correctly.
I do prove that each instance of HHH does derive the correct
execution trace of DDD, thus the trace is valid even if
each HHH does this by wild guess.
HHH saying that HHH doesn't return is not a correct emulation of HHH,
since HHH does return,
You just don't understand what a PROGRAM is, or what CORRECT means.
HHH and DDD are C functions. they have never been programs.
I already called you out on this and your ADD forgot.
That people have not bothered to look at this for three years
is far too disingenuous to be called merely disingenuous.
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
And, HH may hve decided this, but that isn't a true determination.
Again, more of your lies.
Sorry, your "logic" just proves your stupidity, and the fact you
can't see that just proves how stupid you are, and that is the worse
kind of stupid.
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:
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. >>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>
You just confuse the behavior of DDD with the PARTIAL >>>>>>>>>>>>>>>>>> emulation that HHH does, because you lie about your >>>>>>>>>>>>>>>>>> false "tautology".
Claiming a false statement is a tautology only make >>>>>>>>>>>>>>>>>> you a liar.
Denying a tautology seems to make you a liar. I only >>>>>>>>>>>>>>>>>>> say "seems to" because I know that I am fallible. >>>>>>>>>>>>>>>>>>
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.
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:But there ccould be, and the behavior of it is what matters. >>>>>>>>>>>>>>
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:
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.
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. >>>>>>>>>>>>>>>>>>>>
You just confuse the behavior of DDD with the >>>>>>>>>>>>>>>>>>>> PARTIAL emulation that HHH does, because you lie >>>>>>>>>>>>>>>>>>>> about your false "tautology".
Claiming a false statement is a tautology only make >>>>>>>>>>>>>>>>>>>> you a liar.
Denying a tautology seems to make you a liar. I only >>>>>>>>>>>>>>>>>>>>> say "seems to" because I know that I am fallible. >>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>
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.
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.
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(). >>>>>>>>
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.
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.
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:But there ccould be, and the behavior of it is what >>>>>>>>>>>>>>>> matters.
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 correctlyExcept 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.
emulated steps to correctly infer that the input >>>>>>>>>>>>>>>>>>>>>>> would never
reach is "return" instruction halt state. >>>>>>>>>>>>>>>>>>>>>>
You just confuse the behavior of DDD with the >>>>>>>>>>>>>>>>>>>>>> PARTIAL emulation that HHH does, because you lie >>>>>>>>>>>>>>>>>>>>>> about your false "tautology".
Claiming a false statement is a tautology only >>>>>>>>>>>>>>>>>>>>>> make you a liar.
Denying a tautology seems to make you a liar. I only >>>>>>>>>>>>>>>>>>>>>>> say "seems to" because I know that I am fallible. >>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>
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.
Nope, since you have never shown the requested output, you >>>>>>>>>> have no grounds to claim that you HHH does a correct x86
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(). >>>>>>>>>>
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.
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.
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
*until* H correctly determines that its simulated D would never
*until* H correctly determines that its simulated D would never
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:But there ccould be, and the behavior of it is what >>>>>>>>>>>>>>>>>> matters.
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 correctlyExcept 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.
emulated steps to correctly infer that the >>>>>>>>>>>>>>>>>>>>>>>>> input would never
reach is "return" instruction halt state. >>>>>>>>>>>>>>>>>>>>>>>>
You just confuse the behavior of DDD with the >>>>>>>>>>>>>>>>>>>>>>>> PARTIAL emulation that HHH does, because you lie >>>>>>>>>>>>>>>>>>>>>>>> about your false "tautology".
Claiming a false statement is a tautology only >>>>>>>>>>>>>>>>>>>>>>>> make you a liar.
Denying a tautology seems to make you a liar. I >>>>>>>>>>>>>>>>>>>>>>>>> only
say "seems to" because I know that I am fallible. >>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>
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.
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:But there ccould be, and the behavior of it is what >>>>>>>>>>>>>>>>>>> matters.
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 correctlyExcept 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.
emulated steps to correctly infer that the >>>>>>>>>>>>>>>>>>>>>>>>>> input would never
reach is "return" instruction halt state. >>>>>>>>>>>>>>>>>>>>>>>>>
You just confuse the behavior of DDD with the >>>>>>>>>>>>>>>>>>>>>>>>> PARTIAL emulation that HHH does, because you >>>>>>>>>>>>>>>>>>>>>>>>> lie about your false "tautology". >>>>>>>>>>>>>>>>>>>>>>>>>
Claiming a false statement is a tautology only >>>>>>>>>>>>>>>>>>>>>>>>> make you a liar.
Denying a tautology seems to make you a liar. >>>>>>>>>>>>>>>>>>>>>>>>>> I only
say "seems to" because I know that I am fallible. >>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>
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.
On 8/12/24 1:32 PM, olcott wrote:
On 8/12/2024 12:12 PM, Richard Damon wrote:
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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
But there ccould be, and the behavior of it is >>>>>>>>>>>>>>>>>>>>>> what matters.Nope.As I have countlessly proven it only >>>>>>>>>>>>>>>>>>>>>>>>>>>>> requires enough correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulated steps to correctly infer that the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> input would neverExcept 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
reach is "return" instruction halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>
Because that is the DEFINITION of what it is to >>>>>>>>>>>>>>>>>>>> decide on.
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. >>>>>>>>>>>>>>>>>>>>
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 showed the first four lines of this code
highlighted in red and you ignored it.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, you ignored my comments.
First, that isn't a trace generated by HHH emulating DDD, but by x86UTM emulating HHH, so your claim is just a type error.
Then when I look at this emulation, we see that HHH *ONLY* emulates
those first 4 instructions of HHH and no more, that it doesn't simulate
what happens in HHH after the jmp 000015e7 instruction, and thus you
claim is still a LIE.
It says that you have HHH simulate the first *8* instructions of the
program DDD, and then stop doing a correct x86 emulation, and switches
to an INCORRECT functional emulation, since it doesn't note that this emulation is CONDITIONAL.
Sorry, you are still caught in your lie, and making it clear it is a DELIBERATE lie.
Proofs based on LIES are not proofs but are just lies.
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.
On 8/12/2024 12:12 PM, Richard Damon wrote:
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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>But there ccould be, and the behavior of it is what >>>>>>>>>>>>>>>>>>>>> matters.
Nope.As I have countlessly proven it only >>>>>>>>>>>>>>>>>>>>>>>>>>>> requires enough correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>> emulated steps to correctly infer that the >>>>>>>>>>>>>>>>>>>>>>>>>>>> input would neverExcept 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>
reach is "return" instruction halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>
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 showed the first four lines of this code
highlighted in red and you ignored it. https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
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.
On 8/12/2024 1:16 PM, Richard Damon wrote:
On 8/12/24 1:32 PM, olcott wrote:
On 8/12/2024 12:12 PM, Richard Damon wrote:
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 showed the first four lines of this code
highlighted in red and you ignored it.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, you ignored my comments.
First, that isn't a trace generated by HHH emulating DDD, but by
x86UTM emulating HHH, so your claim is just a type error.
Then when I look at this emulation, we see that HHH *ONLY* emulates
those first 4 instructions of HHH and no more,
That is counter factual.
that it doesn't simulate what happens in HHH after the jmp 000015e7
instruction, and thus you claim is still a LIE.
That is counter factual.
It says that you have HHH simulate the first *8* instructions of the
program DDD, and then stop doing a correct x86 emulation, and switches
to an INCORRECT functional emulation, since it doesn't note that this
emulation is CONDITIONAL.
Sorry, you are still caught in your lie, and making it clear it is a
DELIBERATE lie.
Proofs based on LIES are not proofs but are just lies.
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.
On 8/12/2024 4:13 PM, Richard Damon wrote:
On 8/12/24 2:25 PM, olcott wrote:
On 8/12/2024 1:16 PM, Richard Damon wrote:
On 8/12/24 1:32 PM, olcott wrote:
On 8/12/2024 12:12 PM, Richard Damon wrote:
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 showed the first four lines of this code
highlighted in red and you ignored it.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
First a few comments about this file.
It has clearlly changed over time without notice, you said you added
highlighting, but it also has had content changes.
It really needs to be date-stamped and version controlled. I can not
say if the copy I look at today is the same as I looked at the other day.
Second, it is NOT the trace you keep on claiming but is the trace that
x86UTM makes of running main, with the trace that the levels of HHH do
inserted (WITHOUT COMMENT) into the listing, making the trace that HHH
generats hard to find.
The length of the wrong trace starts on page 38, so there are only
about 160 pages of trace (the rest is an assembly listing of the
program, useful to understand the trace, but not part of the trace
itself) and there are only 1 to 2 lines from HHH per page, so a trace
of just what HHH does would be only about 200-300 LINES long, not 200
pages, and not beyond what many people can handle, especially when you
remove the cruft of having to wade through all the other junk that
isn't the trace that HHH makes.
There are also clearly functions that are not even correctly listed in
the assembly listings, nor traced, that seem to be hooks to make OS
calls. That isn't totally unreasonable, but not clearly marked as such.
No, you ignored my comments.
First, that isn't a trace generated by HHH emulating DDD, but by
x86UTM emulating HHH, so your claim is just a type error.
Then when I look at this emulation, we see that HHH *ONLY* emulates
those first 4 instructions of HHH and no more,
That is counter factual.
Looking closer, I may have gotten confused by the changing file by the
same name
I do see the simulation continuing into HHH, but ...
One thing I do note is that the trace sees conditional jump
instructions in the trace, but your "rule" is that there can be no
conditional instructions see in the full loop, so something is wrong.
One instruction I see is:
Page 79, simulated the JNZ 00001335 at address 000012f8
Why wasn't this counted as a conditional instruction in the trace?
(That means the recursion isn't unconditional)
So, mybe it is a correct partial emulation, but just ignores some of
the meaning, so that conditional recursion is incorrectly considered
to be infinite recursion. Perhaps you just failed to test you code to
see that it correctly detects conditional jump instructions.
Note, examining your code, your code also VIOLATES your requirement to
be a pure functikon.
First, in Init_Halts_HH you detect if you are the "root" decider by
look to see it the stack is at the initial prefilled value, and if so
make yourself the "root" and setup a trace buffer, and record that we
are the "Root"
Then in Decides_Halting_HH you test that Root flag, and only the
"Root" decider actually does halt deciding, thus the copy of HHH that
DDD calls performs a DIFFERENT set of actions to the ones that the one
called by main does.
Thus, You are proven to be a liar that you code ACTUALLY acts as a
pure function. The static memory isn't just a way for the lower
emulator to have its results seen by the higher emulator, but the
emulators actually change from Halt Deciders to pure emulators when
they are nes
that it doesn't simulate what happens in HHH after the jmp 000015e7
instruction, and thus you claim is still a LIE.
That is counter factual.
Maybe it is recording but not looking at those instructions. Why else
is it ignoring the conditional instructions?
I proved that your statements were counter-factual.
Instead of admitting whoops I goofed you are trying
to get away with changing the subject.
The subject is ONLY HHH does correct emulate itself
emulated DDD.
I am about to forever give up on you.
I finally found a group of tens of thousands of
people that totally understand what I am saying.
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 8/12/2024 4:13 PM, Richard Damon wrote:Absolutely.
On 8/12/24 2:25 PM, olcott wrote:
On 8/12/2024 1:16 PM, Richard Damon wrote:
On 8/12/24 1:32 PM, olcott wrote:
On 8/12/2024 12:12 PM, Richard Damon wrote:
It has clearlly changed over time without notice, you said you added
highlighting, but it also has had content changes.
It really needs to be date-stamped and version controlled. I can not
say if the copy I look at today is the same as I looked at the other
day.
If you can colourcode it, you can do so right in the source.Second, it is NOT the trace you keep on claiming but is the trace that
x86UTM makes of running main, with the trace that the levels of HHH do
inserted (WITHOUT COMMENT) into the listing, making the trace that HHH
generats hard to find.
Yes, one only needs the one level.The length of the wrong trace starts on page 38, so there are only
about 160 pages of trace (the rest is an assembly listing of the
program, useful to understand the trace, but not part of the trace
itself) and there are only 1 to 2 lines from HHH per page, so a trace
of just what HHH does would be only about 200-300 LINES long, not 200
pages, and not beyond what many people can handle, especially when you
remove the cruft of having to wade through all the other junk that
isn't the trace that HHH makes.
Ah, but we know that HHH is correct! Haha.One thing I do note is that the trace sees conditional jump
instructions in the trace, but your "rule" is that there can be no
conditional instructions see in the full loop, so something is wrong.
Page 79, simulated the JNZ 00001335 at address 000012f8 Why wasn't this
counted as a conditional instruction in the trace? (That means the
recursion isn't unconditional)
So, mybe it is a correct partial emulation, but just ignores some of
the meaning, so that conditional recursion is incorrectly considered to
be infinite recursion. Perhaps you just failed to test you code to see
that it correctly detects conditional jump instructions.
This is where I lose track. HHH is not simulating itself.Note, examining your code, your code also VIOLATES your requirement to
be a pure functikon.
First, in Init_Halts_HH you detect if you are the "root" decider by
look to see it the stack is at the initial prefilled value, and if so
make yourself the "root" and setup a trace buffer, and record that we
are the "Root"
Then in Decides_Halting_HH you test that Root flag, and only the "Root"
decider actually does halt deciding, thus the copy of HHH that DDD
calls performs a DIFFERENT set of actions to the ones that the one
called by main does.
Thus, You are proven to be a liar that you code ACTUALLY acts as a pure
function. The static memory isn't just a way for the lower emulator to
have its results seen by the higher emulator, but the emulators
actually change from Halt Deciders to pure emulators when they are nes
Above I see only your claim. What is simulated after that jump?I proved that your statements were counter-factual.that it doesn't simulate what happens in HHH after the jmp 000015e7That is counter factual.
instruction, and thus you claim is still a LIE.
Maybe it is recording but not looking at those instructions. Why else
is it ignoring the conditional instructions?
Instead of admitting whoops I goofed you are trying to get away withNah, you are evading questions.
changing the subject.
I am about to forever give up on you.Please tell where they are.
I finally found a group of tens of thousands of people that totally understand what I am saying.
On 8/12/2024 11:42 AM, olcott wrote:This is just too funny.
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:
When I state verified facts I am definitely not a liar even when I >>>>>> do not make this verification available to others.But your HHH doesn't "Correctly Simulate" DDD by the sameFour expert C programmers (two with masters degrees in computer >>>>>>>> science) agree that DDD correctly simulated by HHH does not halt. >>>>>>>>No, to make a claim, you need to provide the actual proof.It does do this yet mixing in the 200 pages of other code makes >>>>>>>>>> it too difficult to see the execution trace of DDD.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.
definition that makes that true.
QFTAlso, "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.
Have you ever clarified what the disagreement is about?But the CONDITION isn't that it won't halt until aborted, but it willWhen you insist on disagreeing with the semantics of the x86 language
not halt EVER.
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.Shocked, I say!
That he will not point out any divergence of the x86 execution trace ofThe divergence is that the simulation is aborted, i.e. the following instructions are not simulated. Preemptively: of course a nonterminating program can't be simulated in finite time.
DDD emulated by HHH from the semantics of the x86 language is
significant indication seems quite telling that he is wrong.
On 8/12/2024 1:16 PM, Richard Damon wrote:It doesn't simulate the following call.
On 8/12/24 1:32 PM, olcott wrote:That is counter factual.
On 8/12/2024 12:12 PM, Richard Damon wrote:
YOU don't understand the rules of the x86 code, or don't care if youI showed the first four lines of this code highlighted in red and 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.
ignored it. https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
No, you ignored my comments.
First, that isn't a trace generated by HHH emulating DDD, but by x86UTM
emulating HHH, so your claim is just a type error.
Then when I look at this emulation, we see that HHH *ONLY* emulates
those first 4 instructions of HHH and no more,
Where does it jump to?that it doesn't simulate what happens in HHH after the jmp 000015e7That is counter factual.
instruction, and thus you claim is still a LIE.
It says that you have HHH simulate the first *8* instructions of the
program DDD, and then stop doing a correct x86 emulation, and switches
to an INCORRECT functional emulation, since it doesn't note that this
emulation is CONDITIONAL.
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.
On 8/12/2024 11:10 AM, Richard Damon wrote:Richard, get a life.
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:
Now if only you would recognise this.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.
Spot on.But it isn't a false assemption, but an actual >>>>>>>>>>>>>>>> requirement.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.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 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.
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.
A "decider" that returns the wrong result is no good.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.
Yet somehowSince 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.
The recursion has nothing to do with it. The correct answer is "does notThis 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.
And that string specifies the behaviour of the containing computation.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.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
"100% fully specified concrete" yeah, I believe it.No, you are confusing capability with requirements.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.
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.
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.
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().
*crickets*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.
"this margin is too small"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.
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.
It does do this yet mixing in the 200 pages of other code makes >>>>>>>>> it too difficult to see the execution trace of DDD.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 correctNote, 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?
emulation of HHH.
You are not definitely speaking the truth. I also have a dragon in myBut your HHH doesn't "Correctly Simulate" DDD by the sameWhen I state verified facts I am definitely not a liar even when I
definition that makes that true.
do not make this verification available to others.
What the shit was this exchangeThis algorithm is used by all the simulating termination analyzers:It has always been a tautology.Nope, depends on the meaning you give the words.
I conclusively proved that with the execution trace that you are
persistently trying to get way with ignoring.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
That is to say, H doesn't (correctly) simulate D.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.
And simulation doesn't change that behaviour.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.
Which he has confusingly implemented with the static Root.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
Of course an aborted simulation halts. It should then return "halting".But the CONDITION isn't that it won't halt until aborted, but it willthat 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.
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.
On 8/12/2024 5:31 PM, joes wrote:
Am Mon, 12 Aug 2024 16:23:30 -0500 schrieb olcott:
On 8/12/2024 4:13 PM, Richard Damon wrote:Absolutely.
On 8/12/24 2:25 PM, olcott wrote:
On 8/12/2024 1:16 PM, Richard Damon wrote:
On 8/12/24 1:32 PM, olcott wrote:
On 8/12/2024 12:12 PM, Richard Damon wrote:
It has clearlly changed over time without notice, you said you added
highlighting, but it also has had content changes.
It really needs to be date-stamped and version controlled. I can not
say if the copy I look at today is the same as I looked at the other
day.
If you can colourcode it, you can do so right in the source.Second, it is NOT the trace you keep on claiming but is the trace that >>>> x86UTM makes of running main, with the trace that the levels of HHH do >>>> inserted (WITHOUT COMMENT) into the listing, making the trace that HHH >>>> generats hard to find.
Yes, one only needs the one level.The length of the wrong trace starts on page 38, so there are only
about 160 pages of trace (the rest is an assembly listing of the
program, useful to understand the trace, but not part of the trace
itself) and there are only 1 to 2 lines from HHH per page, so a trace
of just what HHH does would be only about 200-300 LINES long, not 200
pages, and not beyond what many people can handle, especially when you >>>> remove the cruft of having to wade through all the other junk that
isn't the trace that HHH makes.
Ah, but we know that HHH is correct! Haha.One thing I do note is that the trace sees conditional jump
instructions in the trace, but your "rule" is that there can be no
conditional instructions see in the full loop, so something is wrong.
Page 79, simulated the JNZ 00001335 at address 000012f8 Why wasn't this >>>> counted as a conditional instruction in the trace? (That means the
recursion isn't unconditional)
So, mybe it is a correct partial emulation, but just ignores some of
the meaning, so that conditional recursion is incorrectly considered to >>>> be infinite recursion. Perhaps you just failed to test you code to see >>>> that it correctly detects conditional jump instructions.
Note, examining your code, your code also VIOLATES your requirement to >>>> be a pure functikon.
First, in Init_Halts_HH you detect if you are the "root" decider by
look to see it the stack is at the initial prefilled value, and if so
make yourself the "root" and setup a trace buffer, and record that we
are the "Root"
Then in Decides_Halting_HH you test that Root flag, and only the "Root" >>>> decider actually does halt deciding, thus the copy of HHH that DDD
calls performs a DIFFERENT set of actions to the ones that the one
called by main does.
Thus, You are proven to be a liar that you code ACTUALLY acts as a pure >>>> function. The static memory isn't just a way for the lower emulator to >>>> have its results seen by the higher emulator, but the emulators
actually change from Halt Deciders to pure emulators when they are nes
This is where I lose track. HHH is not simulating itself.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Anyone that is a c expert and understands operating systems
design can easily tell that HHH emulates DDD which calls
HHH(DDD) such that the directly executed HHH does emulate
itself emulating DDD.
It looks like not a single person here in the last four years
has ever had that level technical competence.
Anyone with a modicum of expertise in the x86 language can
determine this same thing from the half-page execution trace
of the two emulations of DDD.
It looks like everyone here for the last two years is
trying to get away with the pure bluster of faking this
competence.
Above I see only your claim. What is simulated after that jump?I proved that your statements were counter-factual.that it doesn't simulate what happens in HHH after the jmp 000015e7 >>>>>> instruction, and thus you claim is still a LIE.That is counter factual.
Maybe it is recording but not looking at those instructions. Why else
is it ignoring the conditional instructions?
Instead of admitting whoops I goofed you are trying to get away withNah, you are evading questions.
changing the subject.
I am about to forever give up on you.Please tell where they are.
I finally found a group of tens of thousands of people that totally
understand what I am saying.
On 8/12/24 2:25 PM, olcott wrote:
On 8/12/2024 1:16 PM, Richard Damon wrote:
On 8/12/24 1:32 PM, olcott wrote:
On 8/12/2024 12:12 PM, Richard Damon wrote:
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 showed the first four lines of this code
highlighted in red and you ignored it.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
First a few comments about this file.
It has clearlly changed over time without notice, you said you added highlighting, but it also has
had content changes.
It really needs to be date-stamped and version controlled. I can not say if the copy I look at today
is the same as I looked at the other day.
Second, it is NOT the trace you keep on claiming but is the trace that x86UTM makes of running main,
with the trace that the levels of HHH do inserted (WITHOUT COMMENT) into the listing, making the
trace that HHH generats hard to find.
The length of the wrong trace starts on page 38, so there are only about 160 pages of trace (the
rest is an assembly listing of the program, useful to understand the trace, but not part of the
trace itself) and there are only 1 to 2 lines from HHH per page, so a trace of just what HHH does
would be only about 200-300 LINES long, not 200 pages, and not beyond what many people can handle,
especially when you remove the cruft of having to wade through all the other junk that isn't the
trace that HHH makes.
There are also clearly functions that are not even correctly listed in the assembly listings, nor
traced, that seem to be hooks to make OS calls. That isn't totally unreasonable, but not clearly
marked as such.
No, you ignored my comments.
First, that isn't a trace generated by HHH emulating DDD, but by x86UTM emulating HHH, so your
claim is just a type error.
Then when I look at this emulation, we see that HHH *ONLY* emulates those first 4 instructions of
HHH and no more,
That is counter factual.
Looking closer, I may have gotten confused by the changing file by the same name
I do see the simulation continuing into HHH, but ...
One thing I do note is that the trace sees conditional jump instructions in the trace, but your
"rule" is that there can be no conditional instructions see in the full loop, so something is wrong.
One instruction I see is:
Page 79, simulated the JNZ 00001335 at address 000012f8
Why wasn't this counted as a conditional instruction in the trace?
(That means the recursion isn't unconditional)
So, mybe it is a correct partial emulation, but just ignores some of the meaning, so that
conditional recursion is incorrectly considered to be infinite recursion. Perhaps you just failed to
test you code to see that it correctly detects conditional jump instructions.
Note, examining your code, your code also VIOLATES your requirement to be a pure functikon.
First, in Init_Halts_HH you detect if you are the "root" decider by look to see it the stack is at
the initial prefilled value, and if so make yourself the "root" and setup a trace buffer, and record
that we are the "Root"
Then in Decides_Halting_HH you test that Root flag, and only the "Root" decider actually does halt
deciding, thus the copy of HHH that DDD calls performs a DIFFERENT set of actions to the ones that
the one called by main does.
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:
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. >>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>
You just confuse the behavior of DDD with the PARTIAL >>>>>>>>>>>>>>>>>> emulation that HHH does, because you lie about your >>>>>>>>>>>>>>>>>> false "tautology".
Claiming a false statement is a tautology only make >>>>>>>>>>>>>>>>>> you a liar.
Denying a tautology seems to make you a liar. I only >>>>>>>>>>>>>>>>>>> say "seems to" because I know that I am fallible. >>>>>>>>>>>>>>>>>>
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.
On 8/12/2024 10:09 PM, Mike Terry wrote:
On 12/08/2024 22:13, Richard Damon wrote:
On 8/12/24 2:25 PM, olcott wrote:
On 8/12/2024 1:16 PM, Richard Damon wrote:
On 8/12/24 1:32 PM, olcott wrote:
On 8/12/2024 12:12 PM, Richard Damon wrote:
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 showed the first four lines of this code
highlighted in red and you ignored it.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
First a few comments about this file.
It has clearlly changed over time without notice, you said you added
highlighting, but it also has had content changes.
It really needs to be date-stamped and version controlled. I can not
say if the copy I look at today is the same as I looked at the other
day.
Second, it is NOT the trace you keep on claiming but is the trace
that x86UTM makes of running main, with the trace that the levels of
HHH do inserted (WITHOUT COMMENT) into the listing, making the trace
that HHH generats hard to find.
The length of the wrong trace starts on page 38, so there are only
about 160 pages of trace (the rest is an assembly listing of the
program, useful to understand the trace, but not part of the trace
itself) and there are only 1 to 2 lines from HHH per page, so a trace
of just what HHH does would be only about 200-300 LINES long, not 200
pages, and not beyond what many people can handle, especially when
you remove the cruft of having to wade through all the other junk
that isn't the trace that HHH makes.
There are also clearly functions that are not even correctly listed
in the assembly listings, nor traced, that seem to be hooks to make
OS calls. That isn't totally unreasonable, but not clearly marked as
such.
No, you ignored my comments.
First, that isn't a trace generated by HHH emulating DDD, but by
x86UTM emulating HHH, so your claim is just a type error.
Then when I look at this emulation, we see that HHH *ONLY* emulates
those first 4 instructions of HHH and no more,
That is counter factual.
Looking closer, I may have gotten confused by the changing file by
the same name
I do see the simulation continuing into HHH, but ...
One thing I do note is that the trace sees conditional jump
instructions in the trace, but your "rule" is that there can be no
conditional instructions see in the full loop, so something is wrong.
One instruction I see is:
Page 79, simulated the JNZ 00001335 at address 000012f8
Why wasn't this counted as a conditional instruction in the trace?
(That means the recursion isn't unconditional)
PO's rule is that there must be no conditional branch instructions
*WITHIN DDD*. Conditional branch instructions in HHH are simulated,
and with suitable compilation options [I think it is the
TRACE_USER_CODE_ONLY pre-processing symbol that needs to be undefined]
those instructions will also be LOGGED. Well, you're seeing the
result of that on page 79 of the PDF file.
Distinction between what is LOGGED (by x86utm.exe), and what goes into
the global trace table examined by HHH: The former is an x86utm
("supervisor?") concept. The latter is HHH application logic - HHH
implements the tests for "non-halting" patterns, and only needs to
capture trace entries needed to apply its rules. For example, since
the rules explicitly ignore trace entries from HHH, HHH doesn't need
to capture them. You can see those trace entries in the x86utm LOG,
which is why the log is the way to go, when working out what's going
on and why.
Just to be 100% clear for PO's benefit, when I say HHH "only needs to
capture trace entries needed to apply its rules" I am not suggesting
those rules are correct - just that from a coding perspective, there's
no point in a program capturing data that is irrelevent for it's later
processing. As an example here, PO adds trace entries to his global
trace table which are of no interest to any of his rules! Really, he
is only interested in branches, calls, and the likes, but he captures
everything DDD does like "mov ebp,esp" or whatever which his rules all
ignore... Not an issue in practice because his trace captures [given
other filtering] are tiny. Might become important for capacity
reasons if PO wanted to include HHH entries, but he doesn't.
Now, anyone thinking sensibly at this point is going to ask *WHY* does
PO's rule
*exclude conditional branches within HHH* when they are obviously
critical to halting? PO will never explain that.
*I have always explained that and everyone ignores my explanation*
On 8/2/2024 11:32 PM, Jeff Barnett wrote:
...In some formulations, there are specific states
defined as "halting states" and the machine only
halts if either the start state is a halt state...
...these and many other definitions all have
equivalent computing prowess...
Now I have the same basis that I have repeated many
times that cannot be so easily rejected out-of-hand.
void DDD()
{
HHH(DDD);
return;
}
*DDD correctly emulated by HHH cannot possibly reach its*
*own "return" instruction final halt state, thus never halts*
On 8/13/2024 6:23 AM, Richard Damon wrote:
On 8/12/24 11:45 PM, olcott wrote:
On 8/12/2024 10:09 PM, Mike Terry wrote:
On 12/08/2024 22:13, Richard Damon wrote:
On 8/12/24 2:25 PM, olcott wrote:
On 8/12/2024 1:16 PM, Richard Damon wrote:
On 8/12/24 1:32 PM, olcott wrote:
On 8/12/2024 12:12 PM, Richard Damon wrote:
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 showed the first four lines of this code
highlighted in red and you ignored it.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
First a few comments about this file.
It has clearlly changed over time without notice, you said you
added highlighting, but it also has had content changes.
It really needs to be date-stamped and version controlled. I can
not say if the copy I look at today is the same as I looked at the
other day.
Second, it is NOT the trace you keep on claiming but is the trace
that x86UTM makes of running main, with the trace that the levels
of HHH do inserted (WITHOUT COMMENT) into the listing, making the
trace that HHH generats hard to find.
The length of the wrong trace starts on page 38, so there are only
about 160 pages of trace (the rest is an assembly listing of the
program, useful to understand the trace, but not part of the trace
itself) and there are only 1 to 2 lines from HHH per page, so a
trace of just what HHH does would be only about 200-300 LINES long,
not 200 pages, and not beyond what many people can handle,
especially when you remove the cruft of having to wade through all
the other junk that isn't the trace that HHH makes.
There are also clearly functions that are not even correctly listed
in the assembly listings, nor traced, that seem to be hooks to make
OS calls. That isn't totally unreasonable, but not clearly marked
as such.
No, you ignored my comments.
First, that isn't a trace generated by HHH emulating DDD, but by >>>>>>> x86UTM emulating HHH, so your claim is just a type error.
Then when I look at this emulation, we see that HHH *ONLY*
emulates those first 4 instructions of HHH and no more,
That is counter factual.
Looking closer, I may have gotten confused by the changing file by
the same name
I do see the simulation continuing into HHH, but ...
One thing I do note is that the trace sees conditional jump
instructions in the trace, but your "rule" is that there can be no
conditional instructions see in the full loop, so something is wrong. >>>>>
One instruction I see is:
Page 79, simulated the JNZ 00001335 at address 000012f8
Why wasn't this counted as a conditional instruction in the trace?
(That means the recursion isn't unconditional)
PO's rule is that there must be no conditional branch instructions
*WITHIN DDD*. Conditional branch instructions in HHH are simulated,
and with suitable compilation options [I think it is the
TRACE_USER_CODE_ONLY pre-processing symbol that needs to be
undefined] those instructions will also be LOGGED. Well, you're
seeing the result of that on page 79 of the PDF file.
Distinction between what is LOGGED (by x86utm.exe), and what goes
into the global trace table examined by HHH: The former is an
x86utm ("supervisor?") concept. The latter is HHH application logic
- HHH implements the tests for "non-halting" patterns, and only
needs to capture trace entries needed to apply its rules. For
example, since the rules explicitly ignore trace entries from HHH,
HHH doesn't need to capture them. You can see those trace entries
in the x86utm LOG, which is why the log is the way to go, when
working out what's going on and why.
Just to be 100% clear for PO's benefit, when I say HHH "only needs
to capture trace entries needed to apply its rules" I am not
suggesting those rules are correct - just that from a coding
perspective, there's no point in a program capturing data that is
irrelevent for it's later processing. As an example here, PO adds
trace entries to his global trace table which are of no interest to
any of his rules! Really, he is only interested in branches, calls,
and the likes, but he captures everything DDD does like "mov
ebp,esp" or whatever which his rules all ignore... Not an issue in
practice because his trace captures [given other filtering] are
tiny. Might become important for capacity reasons if PO wanted to
include HHH entries, but he doesn't.
Now, anyone thinking sensibly at this point is going to ask *WHY*
does PO's rule
*exclude conditional branches within HHH* when they are obviously
critical to halting? PO will never explain that.
*I have always explained that and everyone ignores my explanation*
On 8/2/2024 11:32 PM, Jeff Barnett wrote:
...In some formulations, there are specific states
; defined as "halting states" and the machine only
; halts if either the start state is a halt state...
...these and many other definitions all have
; equivalent computing prowess...
Now I have the same basis that I have repeated many
times that cannot be so easily rejected out-of-hand.
void DDD()
{
HHH(DDD);
return;
}
*DDD correctly emulated by HHH cannot possibly reach its*
*own "return" instruction final halt state, thus never halts*
Which is only correct if HHH actuallly does a complete and correct
emulation, or the behavior DDD (but not the emulation of DDD by HHH)
will reach that return.
A complete emulation of a non-terminating input has always
been a contradiction in terms.
HHH correctly predicts that a correct and unlimited emulation
of DDD by HHH cannot possibly reach its own "return" instruction
final halt state.
<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
H has never ever been required to do an unlimited emulation of
a non-halting input. H has only ever been required to correctly
predict what the behavior of a unlimited emulation would be.
On 8/13/2024 6:23 AM, Richard Damon wrote:
On 8/12/24 11:45 PM, olcott wrote:
On 8/12/2024 10:09 PM, Mike Terry wrote:
On 12/08/2024 22:13, Richard Damon wrote:
On 8/12/24 2:25 PM, olcott wrote:
On 8/12/2024 1:16 PM, Richard Damon wrote:
On 8/12/24 1:32 PM, olcott wrote:
On 8/12/2024 12:12 PM, Richard Damon wrote:
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 showed the first four lines of this code
highlighted in red and you ignored it.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
First a few comments about this file.
It has clearlly changed over time without notice, you said you added >>>>> highlighting, but it also has had content changes.
It really needs to be date-stamped and version controlled. I can not >>>>> say if the copy I look at today is the same as I looked at the other >>>>> day.
Second, it is NOT the trace you keep on claiming but is the trace that >>>>> x86UTM makes of running main, with the trace that the levels of HHH do >>>>> inserted (WITHOUT COMMENT) into the listing, making the trace that HHH >>>>> generats hard to find.
The length of the wrong trace starts on page 38, so there are only
about 160 pages of trace (the rest is an assembly listing of the
program, useful to understand the trace, but not part of the trace
itself) and there are only 1 to 2 lines from HHH per page, so a trace >>>>> of just what HHH does would be only about 200-300 LINES long, not 200 >>>>> pages, and not beyond what many people can handle, especially when you >>>>> remove the cruft of having to wade through all the other junk that
isn't the trace that HHH makes.
There are also clearly functions that are not even correctly listed in >>>>> the assembly listings, nor traced, that seem to be hooks to make OS
calls. That isn't totally unreasonable, but not clearly marked as such. >>>>>
No, you ignored my comments.
First, that isn't a trace generated by HHH emulating DDD, but by x86UTM >>>>>>> emulating HHH, so your claim is just a type error.
Then when I look at this emulation, we see that HHH *ONLY* emulates >>>>>>> those first 4 instructions of HHH and no more,
That is counter factual.
Looking closer, I may have gotten confused by the changing file by the >>>>> same name
I do see the simulation continuing into HHH, but ...
One thing I do note is that the trace sees conditional jump
instructions in the trace, but your "rule" is that there can be no
conditional instructions see in the full loop, so something is wrong. >>>>>
One instruction I see is:
Page 79, simulated the JNZ 00001335 at address 000012f8
Why wasn't this counted as a conditional instruction in the trace?
(That means the recursion isn't unconditional)
PO's rule is that there must be no conditional branch instructions
*WITHIN DDD*. Conditional branch instructions in HHH are simulated,
and with suitable compilation options [I think it is the
TRACE_USER_CODE_ONLY pre-processing symbol that needs to be undefined] >>>> those instructions will also be LOGGED. Well, you're seeing the result >>>> of that on page 79 of the PDF file.
Distinction between what is LOGGED (by x86utm.exe), and what goes into >>>> the global trace table examined by HHH: The former is an x86utm
("supervisor?") concept. The latter is HHH application logic - HHH
implements the tests for "non-halting" patterns, and only needs to
capture trace entries needed to apply its rules. For example, since
the rules explicitly ignore trace entries from HHH, HHH doesn't need to >>>> capture them. You can see those trace entries in the x86utm LOG, which >>>> is why the log is the way to go, when working out what's going on and
why.
Just to be 100% clear for PO's benefit, when I say HHH "only needs to
capture trace entries needed to apply its rules" I am not suggesting
those rules are correct - just that from a coding perspective, there's >>>> no point in a program capturing data that is irrelevent for it's later >>>> processing. As an example here, PO adds trace entries to his global
trace table which are of no interest to any of his rules! Really, he
is only interested in branches, calls, and the likes, but he captures
everything DDD does like "mov ebp,esp" or whatever which his rules all >>>> ignore... Not an issue in practice because his trace captures [given >>>> other filtering] are tiny. Might become important for capacity reasons >>>> if PO wanted to include HHH entries, but he doesn't.
Now, anyone thinking sensibly at this point is going to ask *WHY* does >>>> PO's rule
*exclude conditional branches within HHH* when they are obviously
critical to halting? PO will never explain that.
*I have always explained that and everyone ignores my explanation*
On 8/2/2024 11:32 PM, Jeff Barnett wrote:
...In some formulations, there are specific states
; defined as "halting states" and the machine only
; halts if either the start state is a halt state...
...these and many other definitions all have
; equivalent computing prowess...
Now I have the same basis that I have repeated many
times that cannot be so easily rejected out-of-hand.
void DDD()
{
HHH(DDD);
return;
}
*DDD correctly emulated by HHH cannot possibly reach its*
*own "return" instruction final halt state, thus never halts*
Which is only correct if HHH actuallly does a complete and correct
emulation, or the behavior DDD (but not the emulation of DDD by HHH)
will reach that return.
A complete emulation of a non-terminating input has always
been a contradiction in terms.
HHH correctly predicts that a correct and unlimited emulation
of DDD by HHH cannot possibly reach its own "return" instruction
final halt state.
On 8/14/2024 2:30 AM, Mikko wrote:
On 2024-08-13 13:30:08 +0000, olcott said:
On 8/13/2024 6:23 AM, Richard Damon wrote:
On 8/12/24 11:45 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
*DDD correctly emulated by HHH cannot possibly reach its*
*own "return" instruction final halt state, thus never halts*
Which is only correct if HHH actuallly does a complete and correct
emulation, or the behavior DDD (but not the emulation of DDD by HHH)
will reach that return.
A complete emulation of a non-terminating input has always
been a contradiction in terms.
HHH correctly predicts that a correct and unlimited emulation
of DDD by HHH cannot possibly reach its own "return" instruction
final halt state.
That is not a meaningful prediction because a complete and unlimited
emulation of DDD by HHH never happens.
A complete emulation is not required to correctly
predict that a complete emulation would never halt.
On 8/14/2024 2:30 AM, Mikko wrote:
On 2024-08-13 13:30:08 +0000, olcott said:
On 8/13/2024 6:23 AM, Richard Damon wrote:
On 8/12/24 11:45 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
*DDD correctly emulated by HHH cannot possibly reach its*
*own "return" instruction final halt state, thus never halts*
Which is only correct if HHH actuallly does a complete and correct
emulation, or the behavior DDD (but not the emulation of DDD by HHH)
will reach that return.
A complete emulation of a non-terminating input has always
been a contradiction in terms.
HHH correctly predicts that a correct and unlimited emulation
of DDD by HHH cannot possibly reach its own "return" instruction
final halt state.
That is not a meaningful prediction because a complete and unlimited
emulation of DDD by HHH never happens.
A complete emulation is not required to correctly
predict that a complete emulation would never halt.
On 8/15/2024 3:46 AM, Mikko wrote:
On 2024-08-14 13:42:33 +0000, olcott said:
On 8/14/2024 2:30 AM, Mikko wrote:
On 2024-08-13 13:30:08 +0000, olcott said:
On 8/13/2024 6:23 AM, Richard Damon wrote:
On 8/12/24 11:45 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
*DDD correctly emulated by HHH cannot possibly reach its*
*own "return" instruction final halt state, thus never halts*
Which is only correct if HHH actuallly does a complete and correct >>>>>> emulation, or the behavior DDD (but not the emulation of DDD by HHH) >>>>>> will reach that return.
A complete emulation of a non-terminating input has always
been a contradiction in terms.
HHH correctly predicts that a correct and unlimited emulation
of DDD by HHH cannot possibly reach its own "return" instruction
final halt state.
That is not a meaningful prediction because a complete and unlimited
emulation of DDD by HHH never happens.
A complete emulation is not required to correctly
predict that a complete emulation would never halt.
Nice to see that you don't disagree.
In other words you agree with the first two of these?
A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 163:18:53 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,510 |