Re: H(D,D) cannot even be asked about the behavior of D(D) V2

On 6/16/24 2:50 PM, olcott wrote:

On 6/16/2024 1:33 PM, Richard Damon wrote:

On 6/16/24 2:10 PM, olcott wrote:

On 6/16/2024 1:06 PM, Richard Damon wrote:

On 6/16/24 1:44 PM, olcott wrote:

On 6/16/2024 10:02 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 6/16/2024 9:16 AM, joes wrote:

Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:

On 6/16/2024 2:50 AM, Mikko wrote:

>

Whenever a decider is run it answers the question it is made to answer.

Not necessarily. Just because everyone falsely assumes that D correctly
simulated by H must have the same behavior as the directly executed D(D)
does not make this false assumption true.

>

You still need to explain how you can call a simulation that differs from
the behaviour of its input "correct".

>
Indeed, you do.
>

I have proven it many times and this proof is simply over
everyone's heads.

>
Nonsense!  How about, instead of "proving", actually explaining?  If a
simulation differs from its original, it's not a simulation; it's just a
random program.
>

When I ask what your C programming skill level is, this *is not* a
rhetorical question.

>
The question has nothing to do with C programming.
>

>
typedef void (*ptr)(); // pointer to void function
int H(ptr P, ptr I);
>
int D(int (*x)())
{
   int Halt_Status = H(x, x);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
Unless I make every single detail 100% explicit false
assumptions always slip though the cracks. The ONLY way
to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
programming language.
>
There cannot possibly be any H that correctly emulates
the x86 machine code of D according to the semantics
of the x86 programming language such that the emulated
D ever reaches its own emulated final state at machine
address [00001f58].
>

>
Which is just a strawman, as the requirement on H is NOT to answer about "D correctly simulated by H" but about "the program represented by the input directly executed", or equivalently, simulated by an actual UTM, which is a simulator that NEVER stops until it reaches a final state.
>

>
This is simply over-your-head.
I am very glad of that because the alternative would
possibly condemn your soul to Hell.

>
Whats over my head? That the definition of a Halt Decider beihg that it decides on the behavior of the program represented by the input halting when run?
>

 void DD0()
{
   HH0(DD0);
}
 int main()
{
   HH0(DD0);
}
 That the machine language finite string input DD0
to any simulating halt decider HH0(DD0) cannot
possibly even ask about the behavior of DD0().
 

Because it doesn't NEED to.
By being called a "Halt Decider", HH0 DEFINES what question it is being asked, the only question are the parameters of the question, which is What is the Program and input to decide on.
You are just showing you are absoluting IGNORANT of what you talk about, and have been just LYING about it for years.
I'm sorry, but I think your "license to do logic" has been revoked, and you are being punished for attempted murder on logic.