Sujet : Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theory sci.logicDate : 03. Jun 2024, 05:13:32
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <v3jccs$2qu72$19@i2pn2.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
User-Agent : Mozilla Thunderbird
On 6/2/24 10:54 PM, olcott wrote:
On 6/2/2024 9:24 PM, Richard Damon wrote:
On 6/2/24 9:45 PM, olcott wrote:
On 6/2/2024 6:45 PM, Richard Damon wrote:
On 6/2/24 6:44 PM, olcott wrote:
On 6/2/2024 5:20 PM, Richard Damon wrote:
On 6/2/24 6:05 PM, olcott wrote:
On 6/2/2024 4:43 PM, Richard Damon wrote:
On 6/2/24 5:25 PM, olcott wrote:
On 6/2/2024 3:58 PM, Richard Damon wrote:
On 6/2/24 4:50 PM, olcott wrote:
*We can see that the following DD cannot possibly halt*
>
Unless the HH(DD,DD) aborts its simulation and returns 0, then DD(DD) will ALWAYS halt when directly called, which is the definition of "Halting".
>
Not your LIE that it pertains to partial simulations.
>
*when correctly simulated by every HH that can possibly exist*
>
Except for EVERY HH that aborts its simulation and returns 0
>
>
This may be an ADD thing.
For every HH that aborts its simulation and returns 0
DD correctly simulated by this HH *DID NOT HALT AND NEVER WILL HALT*
>
Except you mental problems are getting in YOUR way.
>
You said that "DD Can not halt" NOT "the simulation by H of DD can not Halt"
>
>
*I said neither of those things so it may be an ADD problem*
>
I guess your medication is making you blind.
>
Read the top line quoted from you on 6/2/24 4:50 PM
>
You said:
"*We can see that the following DD cannot possibly halt*"
>
>
*Deceitfully taking things out of context*
>
On 6/2/2024 3:50 PM, olcott wrote:
> *We can see that the following DD cannot possibly halt*
> *when correctly simulated by every HH that can possibly exist*
>
But the second line doesn't change the meaning of the first line, as Halting ALWAYS (unless clearly modified) refers to the behavior of the machine.
>
>
I was wrong to call you deceitful on this, I sincerely apologize.
The above two lines are the same single sentence that I wanted
to make bold. Putting a period at the end or not breaking it up
into two lines makes bold not work.
>
It just qualifies which DD we might be talking about.
>
Just like the sentence:
>
>
My whole point has ALWAYS been DD correctly simulated by HH.
>
Which means NOTHING, as your definition of "correctly Simulated" doesn't meet the requirements to talk about the behavior of the machine described by the input.
>
IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE IN[UT SPECIFIES.
That you did get confused by the Linz text proves that you do
get confused. Previously it looked just like willful deception.
Which is, for a Halt Decider, exactly and only the behavior of the Turing Machine the input describes.
PERIOD.
Anything else is just a LIE.
You don't seem to understand that you can't just "redefine" the system to meet your desires.
>
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.
No, Running DD(DD) and seeing that it will never, after an unbounded number of steps, indicate it is non-halting.
DEFINITION.
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.
Right, and the input is a representation of a Turing Machine and its input, whose behavior the decider is to decide on.
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.
And that is the machine the input describes.
ANYTHING ELSE IS JUST A LIE.
You can't get away with implicitly saying that you
just don't "believe in" UTMs.
I do, and a UTM is DEFINED as a machine that exactly reproduces the behavior of the machine described by its input.
You can't get away with implicitly saying that you
just don't "believe in" UTMs.
Right, but it seems you don't, as you think something that doesn't meet the minimum requirement to be one could be one.
You can't get away with implicitly saying that you
just don't "believe in" UTMs.
I don't, you just don't understand what they are, because you just don't understand what a Turing machine is.
Key point, there is NO requirement that a UTM simulate thorough an exact sequence of equivalent states of the machine it is "simulating". The ONLY requirement is that its output exactly match the output of the described machine.
That is why all you are actually talking about is POOP.
>
DD specifies non-halting behavior to the simulator/UTM aspect
of DD. DD(DD) has different behavior that decider HH is not
actually held accountable for. HH is ONLY held accountable
for the behavior that DD specifies to its simulator/UTM aspect.
>
Then it just isn't a Halt Decider. PERIOD, and your whole arguement fails, and is based on just lying.
>
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.
Nope.
A decide compute the mapping from their inputs to the corresponding value of the function they are computing.
A Halt Decider is computing the results of the Halts Function, which indicates if the described machine will halt or not when run.
THus H(D,D) NEEDS to generate the results of Halts(D,D) which will be true if D(D) will eventually halt in a finite number of steps, or false if D(D) will never reach a final state after even an unbounded number of states.
SInce D(D) Does Halt if H(D,D) returns 0, H(D,D) returning 0 is NEVER a correct answer.
You can't get away with implicitly saying that you
just don't "believe in" UTMs.
I don't, you are just impuing a LIE, becaue you don't understand what they actually are.
As I have pointed out, by your definitions, a triial decider can just declare that virtual all input are non-halting and be "just as correct", since the logic you try to use is just invalid.
>
>
We can see that the house was red when the ball went through the window.
>
The ball going through the window doesn't affect the color attribute of the house. It might qualify the WHEN (but Halting of a machine isn't dependent on time) or which house we are talking about (so it clearly makes it a DD that it paired to an HH), but it doesn't affect the color.
>
Just like the fact that you have given the description of this DD to HH, doesn't affect the behavior of that instance of DD, it only might indicate that it HAS been paired with such an HH and not some other thing.
>
>
Remember, Halting is defined as the MACHINE reaching a fianl state, so trying to qualify it with a partial simulation is an irrelevent qualification.
>
>
>
Those are DIFFERENT statements.
>
DD WILL Halt.
>
Your claim, that I will neither confirm or deny (until you can show why I should), is that the simulation by H can never reach the statement after the call instruction.
>
>
*Still not quite what I said*
>
But you did in your message from 3:54 today earier in the thread:
>
DD correctly emulated by HH with an x86 emulator cannot possibly
reach past its own machine instruction [00001c2e]
>
>
If you get my words 99.99999% perfectly then you screwed up
far too much, thus 80% is not in the ballpark.
>
So, if you ever slightm
>
>
*We can see that the following DD cannot possibly halt*
*when correctly simulated by every HH that can possibly exist*
>
Nope ABSOLUTE LIE.
>
>
*If it was even incorrect then you could show a counter-example*
>
>
D(D) is the counter example.
Liar Liar Pants ON Fire
Then why does it halt when run?
*We can see that the following DD cannot possibly halt when*
*correctly simulated by every HH that can possibly exist*
But the question isn't about it being simulated, but being run.
Guess you are just showing how stupid you are.
So, whose pants are on fire?
*We can see that the following DD cannot possibly halt when*
*correctly simulated by every HH that can possibly exist*
Just repeating the lie doesn't make it more true.
*We can see that the following DD cannot possibly halt when*
*correctly simulated by every HH that can possibly exist*
Third time is the charm, proves it wasn't a honest mistake, here comes the lake of fire for you.
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int HH(ptr p, ptr i);
01 int DD(ptr p)
02 {
03 int Halt_Status = HH(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
_DD()
[00001c22] 55 push ebp
[00001c23] 8bec mov ebp,esp
[00001c25] 51 push ecx
[00001c26] 8b4508 mov eax,[ebp+08]
[00001c29] 50 push eax ; push DD 1c22
[00001c2a] 8b4d08 mov ecx,[ebp+08]
[00001c2d] 51 push ecx ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; call HH
[00001c33] 83c408 add esp,+08
[00001c36] 8945fc mov [ebp-04],eax
[00001c39] 837dfc00 cmp dword [ebp-04],+00
[00001c3d] 7402 jz 00001c41
[00001c3f] ebfe jmp 00001c3f
[00001c41] 8b45fc mov eax,[ebp-04]
[00001c44] 8be5 mov esp,ebp
[00001c46] 5d pop ebp
[00001c47] c3 ret
Size in bytes:(0038) [00001c47]