On 6/27/24 11:25 PM, olcott wrote:
On 6/27/2024 6:34 AM, Richard Damon wrote:
>
That seems to be one of your biggest lies, you claim others are lying to try to disquise your own lies.
>
You can't show one thing that I have said that is FACTUALY INCORRCT (only that you disagre with them).
>
I have shown statements of your that ARE DEFINITIONALLY INCORRECT (even if you want to use a different definition, which just isn't allowed, and thus becomes a lie).
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call H0(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The call from DDD to H0(DDD) when DDD is correctly
emulated by x86 emulator H0 cannot possibly return.
You are still using sloppy definition to spread your deceit.
If by "Correctly Emulate" you means that H0 does a COMPLETE simulation, as the term Correctly Simulate would mean (and H0 is a pure funciton) then yes, then H0(DDD) will never return ANYWHERE. But, we know this isn't what you mean as you claim that H1(DDD) does return, and thus H0(DDD) must return and what you actually are trying to say, but being decietful about it is that H0 does a PARTIAL correct simulaition of its input, and that H0 will not reach the return in its simulation.
Note, The Behavior of DDD, MUST be a property of just DDD, and not anything else, (when DDD is fully defined, which means the H0 it uses is defined, as it must be to talk about its behavior) so that must be using a NON-ABORTED version of the simulation with THIS H0 in it, and that WILL RETURN.
Thus, you claim is only PARTIALLY correct, which means it is WRONG, and shows you are trying to be intentionally decietful (or are really pathologically ignorant of the topic).
Emulation meens to do as something does, to copy the behavior. Adding Correct to make it Correct Emulation intensifies that to imply, especially in the field of programming (which you seem to be a novice in) implies that it is a COMPLETE emulation, exactly reproducing the results of the input.
This is NOT what you seem to mean, and the adjictive you actually want is PARTIAL, allowing the emulator to decide to stop its emulation at some point, perhaps because it thinks it knows enough of the behavior.
Fundamental in PARTIAL emulation, is you do not have a record of what WILL HAPPEN in the future for an actual COMPLETE and CORRECT emulation of that input (but you MAY be able to deduce it if you have seen a full cycle, which you haven't).
Actual Behavior of "The Input" is by definition, only a function of that input and the rules of representation that defined it. IT CAN NOT be a function of who you ask, or your definition of behavior is just incorrect. Since how partial the partial simulation done by H0 is a function of that decider, it CAN NOT be considered the "Behavior" of the input.
WIth your definition of the rule of representation being that the code is x86 assembly, the only definition of "Behavior" that applies is the complete emulation of it, and since H0 is claimed to return from H0(DDD), then the correct behavior of DDD is to return
PERIOD.
Note, you try to misuse the concept of "Stipulation". There are a couple of rules about it.
One, you can not stipulate that something is "correct" or "true" without leaving the realm of logic, as that, with the system you are in, defines what IS Correct or True. You can stipulate that you will assume that something acts correctly, but then you need to be able (without using that stipulation or anything derived from it) that a thing like that does exist. This means you can not just stipulate that your decider just emulates until the input matches a non-halting pattern, and then assume that it will find one, you need to actually prove that such a pattern exists.
Second, you can not stipulate a definition that is in conflict with the system you are claiming to be in. Thus, if you stipulate that the correct answer for a decider is ANYTHING that differs from the behavior of the directly executed machine represented by the input, your decider is NOT a Halt Decider.
Thus, your use of stipulation is just showing that you really aren't working on the Halting Problem, because you just refuse to work within its confines. If you want to try to show there is something wrong about it, you need to do that with the actual definitions of the problem, and not some altered version of them (which means you actually need to learn to understand them).
…