Re: DD correctly emulated by HHH --- Totally ignoring invalid rebuttals ---PSR---

On 3/8/25 10:52 AM, olcott wrote:

On 3/8/2025 7:54 AM, Richard Damon wrote:

On 3/7/25 9:21 PM, olcott wrote:

On 3/7/2025 8:00 PM, Richard Damon wrote:

On 3/7/25 8:49 PM, olcott wrote:

On 3/7/2025 10:25 AM, Fred. Zwarts wrote:

Op 07.mrt.2025 om 16:17 schreef olcott:

On 3/7/2025 2:59 AM, Fred. Zwarts wrote:

Op 06.mrt.2025 om 21:13 schreef olcott:

On 3/6/2025 3:13 AM, Fred. Zwarts wrote:

Op 06.mrt.2025 om 04:53 schreef olcott:

On 3/5/2025 9:31 PM, dbush wrote:

On 3/5/2025 10:17 PM, olcott wrote:

On 3/5/2025 7:10 PM, dbush wrote:

>
In other words, you know that what you're working on has nothing to do with the halting problem, but you don't care.

>
In other words I WILL NOT TOLERATE ANY BULLSHIT DEFLECTION.
You have proven that you know these things pretty well SO QUIT THE SHIT!
>

>
You want people to accept that HHH(DD) does in fact report that changing the code of HHH to an unconditional simulator and running HHH(DD) will not halt.
>

>
DD correctly emulated by HHH cannot possibly
reach its own "ret" instruction and terminate normally.

>
Yes, we agree that HHH fails to reach the 'ret' instruction,

>
Despicably dishonest attempt at the straw-man deception.
>

>
No rebuttal. So, we agree that HHH fails to reach the 'ret' instruction.

>
Not at all. Trying to get away with changing the subject
WILL NOT BE TOLERATED.
>

If you do not agree that HHH fails to reach the 'ret' instruction (that world-class simulators do reach, just as the direct execution does), show how it reaches the 'ret' instruction.

>
*set X*
When-so-ever any input to any simulating termination
analyzer calls the simulator that is simulating itself
>
*result of set X*
this input cannot possibly reach its own final state
and terminate normally because it remains stuck in
recursive emulation.

>
But the failure of the PARTIAL emulatipon done by the termination analyzer doesn't show that the input is non-haltiong
>

>
That is stupidly wrong and you know it.
>
>

>
What is wrong with it?
>

 A proof is anything and everything that shows a
statement is necessarily true and impossibly false.

And to be SHOWN, it must be finite in length,

 The code 100% perfectly proves exactly what it does,
making any disagreements with what it does necessarily
incorrect.

Nope, because everything in the argument is based on LIES.
For instance, By definution, a "program" contains *ALL* the code it uses, so for DD to be a program we need to include with it the full definition of HHH, which you do not.

 Apparently you don't understand that inputs to a
simulating termination analyzer specifying infinite
recursion or recursive emulation cannot possibly
reach their own final state and terminate normally.

But the input isn't even a valid program, so you start with a lie,

 It is ridiculously stupid to expect a simulating
termination analyzer to continue to simulate an
input that specifies it cannot possibly reach its
own final state and terminate normally.

Not if that is what is needed to get the right answer.
Of course, part of your problem is that you "logic" is based on the FRAUD of trying to redefine the "right answer".
There is no requirement that the analyzer do a correct simulation, just that it report based on what a correct emulation would be. If it doesn't do one, then the phrase "correct simulation by HHH" is just an impossible statement, and thus an invalid problem.

 When anyone says that DD emulated by HHH according to
the semantics of the x86 language can possibly reach
its own"ret" instruction and terminate normally they are
conclusively proven wrong.
 

Except that criteria is just a FRAUD, the actual criteria is whether DD correctly emuluated according to the semanitc of the x86 language will reach its own "ret" instruction, or fail to meet that after an unbounded number of steps.
Since HHH1 shows that *THE* correct emulation of the input (and there is only one) reaches the final state, the answer is YES, and HHH is just wrong.
Your FRAUD of claiming that there are multiple "correct emulation" just shows your stupidity. You have demonstartated that you understand that can't actually be right (even though you insist on it) because you know that if it was true, you could show the first instruction where those correct emulations differ (for the exact same full program input).
Your failure to do that, proves you are just a fraud.