Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD

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.
You don't seem to understand that you can't just "redefine" the system to meet your desires.
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.
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.
D(D) Halts if H(D,D) returns 0.
The fact you want the question to be different doesn't make it different.
Remember, adding the condition of "When Correctly simulated by evdry HH that can possible exist" doesn't change the meaning of the first line to refer to the actual machine, which is what the term Halting will refer to. It just might qualify what DD we are talking about
You might be able to make the claim that no simulation of DD can possible reach a final state of the simulated DD ...
I won't verify that to be correct, but that seems to be the statement you want to make, but then it doesn't make it sound like you are solving the halting problem.

That it is categorically impossible to show a counter-example
conclusively proves that it is correct. I really hope that you are
merely confused about this. I really hope you are not risking your
salvation.

But the fact the counter example HAS been shown just shows you to be a liar.

 

Hlating is a property of the MACHINE  /  PROGRAM, not the simulation.
>
DD(DD) WILL HALT as long as HH(DD,DD) returns 0, and any HH(DD,DD) that doesn't return 0 fails to meet your requirement that HH be a decider, so we can automatically filter those out.
>

 My whole point has ALWAYS been DD correctly simulated by HH.
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.

But that just points out that you are just being deceptive.
Halting is ALWAYS about the actual behavior of the machine.
And, your HH is NOT a UTM if it aborts its simulatin, no matter how much you want to try to claim it to be, as if FUNDAMENTALLY breaks the definition.
It is like taking an electric car, and remove the electric motors and replace with a gas engine, and then trying to say you still have an electric car, because that is what you started with until you "enhanced it".

 

You not understanding what your words mean is YOUR problem.
>
And you are just proving that you have a reckless disregard for the truth, showing that you are just an ignorant pathologial liar.
>

 I really hope that you are  merely confused about this.
I really hope you are not risking your salvation.

I know I am not, but your repeated deceptions make it clear you never had one.

 

You MIGHT be able to claim that the SIMULATION of DD when correctly performed by HH can never reach a final state. That is the claim you seem to be working on, which i will neither confirm nor deny until we handle this issue.,
>

 *DD simulated by HH cannot possibly halt*
Saying the opposite way makes it looks like HH is not a good
enough simulator. HH is a perfectly correct simulator of its N
steps of correct simulation. After N steps of correct simulation
HH correctly recognizes that DD cannot possibly halt no matter
how many steps are simulated.

But as I have said, DD does halt.
And the problem is that HH ISN'T a good enough simulator to be able to use its result to decide halting, because partial simulation never prove non-halting behavior.
The problem is you forget that HH is what HH is, and thus it can't argue that ir it was something different than what it actually is, and in a why that changes the contents of the input give to it (which includes the HH that DD calls) without invoking invalid logic.
SO, since HH DOES abort its simulation, its logi must be consistant with that behavior, and not think about the non-existant case where the input is based on a different machine.
That just proves your ignorance and deceptive nature.

 

Your statement about HALTING is just incorrect.
>

 Not at all. It has always been correct and you have denied the
verified facts. If this is through confusion then there is no
risk to your salvation. I really hope it is because of confusion.
I don't want you to lose your salvation.

Nope. You just don't understand what you are talking about,
Your facts are NOT verified, but are just your own fabrications.
The problem is you seem to have

 

Try to PROVE your statement
>
Quote ACTULAL Definitions and accepted scholarly publish works in the field.
>
So far, it is just "Olcott says" and Olcott has been proven to LIE and is often mistaken, so not a reliable source.
>

 For the last few months I HAVE ONLY BEEN TALKING ABOUT
SOFTWARE ENGINEERING AND YOU HAVE CONSISTENTLY DENIED
THE VERIFIED SOFTWARE ENGINEERING FACTS.

But your "facts" are not Software Engineering facts.
Can you actually quote a SOURCE for your claims?
SOmething accepted by the general community?
I don't think you actually know what that is, and you think that anything you think up and seems right to you is a "verified fact"
That just shows how much of a pathological liar you are.
 From what I have seen, you are little more than a hack programmer who doesn't understand the basic princples of Software Engineering.

 There is no HH that can possibly exist such that DD correctly
simulated by HH can possibly reach past its own line 03.

That might be true, and I will refuse to confirm or deny that fact, because it is meaningless.
The error comes when you rephrase that to say that DD doesn't Halt. and THAT is just a blantant lie.

 

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

>