Re: DDD incorrectly emulated by HHH is incorrectly rejected as non-halting.

On 7/15/24 9:21 AM, olcott wrote:

On 7/15/2024 2:52 AM, Mikko wrote:

On 2024-07-14 14:44:27 +0000, olcott said:
>

On 7/14/2024 3:48 AM, Mikko wrote:

On 2024-07-13 12:19:36 +0000, olcott said:
>

On 7/13/2024 2:55 AM, Mikko wrote:

On 2024-07-12 13:28:15 +0000, olcott said:
>

On 7/12/2024 3:27 AM, Mikko wrote:

On 2024-07-11 14:02:52 +0000, olcott said:
>

On 7/11/2024 1:22 AM, Mikko wrote:

On 2024-07-10 15:03:46 +0000, olcott said:
>

typedef void (*ptr)();
int HHH(ptr P);
>
void DDD()
{
   HHH(DDD);
}
>
int main()
{
   HHH(DDD);
}
>
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language. By this
measure when 1 to ∞ steps of DDD are correctly emulated by
each pure function x86 emulator HHH (of the infinite set
of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.

>
For every instruction that the C compiler generates the x86 language
specifies an unambiguous meaning, leaving no room for "can".
>

>
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.

>
As I already said, there is not room for "can". That means there is
no room for "cannot", either. The x86 semantics of the unshown code
determines unambigously what happens.
>

>
Of an infinite set behavior X exists for at least one element
or behavior X does not exist for at least one element.
Of the infinite set of HHH/DDD pairs zero DDD elements halt.

>
That is so far from the Common Language that I can't parse.
>

>
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of
0000216b and halts thus proving that every HHH is correct to
reject its input DDD as non-halting.

>
Here you attempt to use the same name for a constant programs and univesally
quantifed variable with a poorly specified range. That is a form of a well
known mistake called the "fallacy of equivocation".

>
I incorporated your suggestion in my paper.
DDD is a fixed constant finite string that calls its
HHH at the same fixed constant machine address.

>
That does not make sense. Which HHH does that DDD call? Which HHH
is at that fixed machine address?
>

 HHH₁ to HHH∞ forming an infinite set of HHH/DDD pairs
 HHH₁/DDD₁ to HHH∞/DDD∞ is another way to specify this
infinite set of HHH/DDD pairs.

And DDD₁ for all finitei i will halt when run or fully simulated since it calls an HHH₁ which aborts its simulation after i steps and returns, so HHH₁ saying non-halting is just wrong.
HHH∞ never gives an answer.

 

When we examine the infinite set of every HHH/DDD pair such that:
HHH₁ one step of DDD is correctly emulated by HHH.
HHH₂ two steps of DDD are correctly emulated by HHH.
HHH₃ three steps of DDD are correctly emulated by HHH.
...
HHH∞ The emulation of DDD by HHH never stops running.

>
It is not possible to execute more steps than there are, so you add that
the emulation may terminate earlier if the input halts. Unless you
only want to prove that those programs don't halt unless the halt.
>

 Of the infinite set of HHH/DDD pairs no DDD ever halts thus
every HHH that halts is necessarily correct to reject its DDD
as non-halting.
 

No, EVERY DDD₁ where i is finite halts. What you seem to be trying to say but using the wrong words (to be deciptive) is that HHH₁'s simulation never gets to that point.
But then, partial simulations by there nature do not fully reveal, by themselves, the full behavior of the input.