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

On 3/8/2025 10:43 PM, olcott wrote:

On 3/8/2025 9:35 PM, dbush wrote:

On 3/8/2025 9:36 PM, dbush wrote:

On 3/8/2025 9:30 PM, olcott wrote:

On 3/8/2025 7:43 PM, dbush wrote:

On 3/8/2025 8:24 PM, olcott wrote:

On 3/8/2025 6:56 PM, dbush wrote:

On 3/8/2025 7:29 PM, olcott wrote:

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

On 3/8/2025 6:23 PM, olcott wrote:

On 3/8/2025 4:58 PM, dbush wrote:

On 3/8/2025 5:42 PM, olcott wrote:

On 3/8/2025 9:00 AM, dbush wrote:

On 3/8/2025 9:03 AM, olcott wrote:

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

>
Apparently you don't understand that inputs to a termination analyzer, simulating or otherwise, are specified by the specification that is the halting function:
>
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
>
And HHH(DD)==0 fails to meet the above specification

>
*THIS IS A SEMANTIC TAUTOLOGY THUS IMPOSSIBLY FALSE*
Replacing the code of HHH with an unconditional simulator and subsequently running HHH(DD) cannot possibly reach
its own "ret" instruction and terminate normally
because DD calls HHH(DD) in recursive emulation.
>
It is ridiculously stupid to believe that HHH must
report on behavior other than the above behavior.
>

>
It must if it is to be classified as a halt decider or termination analyzer as per the definition.

>
In other words you believe that HHH

>
Is required to map the halting function to meet the requirements to be a halt decider / termination analyzer.
>

>
HHH must map from the input finite string DD
to the behavior that this finite string specifies

>
And what it specifies, to be considered a solution to the halting problem, is given by the specification:
>
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
>
A solution to the halting problem is an algorithm H that computes the following mapping:
>
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
>

>
In the same way that Sum(5,3) == 9
That is misconception is very widely held
does not make it not a misconception.
>

>
In other words, you have no rebuttal to the fact that HHH doesn't meet the requirements to be a solution to the halting problem.

>
If the halting problem actually requires that the "decider"
report on behavior other than what the input specifies
then its notion of a halting decider is not even a decider
in computer science.
>

>
The halting problem requires that the halting function is mapped:
>
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
>
So by this specification, (<X>,Y) specifies the behavior of X(Y) when executed directly.
>
Any algorithm that does not compute this mapping is not a solution to the halting problem.

>
Your copy-paste answer to multiple threads indicates you have no real rebuttal for what others have said.
>

 *This is all you get from me until this point is fully addressed*
   <copy-paste response>
 

In other words, you have no rebuttal.  A copy-paste response is worse than no rebuttal at all.
 >> Unless you respond to this thread, I'll take your lack of response to >> mean that you accept that the above specification is required to be a >> solution to the halting problem.
And as such, by the above, your less-than-a-rebuttal means you accept that a solution to the halting problem is required to perform the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly