On 8/2/25 10:33 AM, olcott wrote:

On 8/2/2025 4:33 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 19:28 schreef olcott:

On 8/1/2025 12:19 PM, Richard Damon wrote:

On 8/1/25 12:58 PM, olcott wrote:

On 8/1/2025 11:51 AM, Mr Flibble wrote:

On Fri, 01 Aug 2025 11:33:51 -0500, olcott wrote:

On 8/1/2025 11:29 AM, Mr Flibble wrote:

On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:

On 8/1/2025 11:03 AM, joes wrote:

Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When
people make
sure to fail to notice the key elements of my key

points it has been proven that these key elements must be >>>>>>>>>>> repeated
until someone bothers to pay attention.

That's not how it works. I skim over repetitions.

When I tell Richard the exact same thing 500 times he continues to >>>>>>>>> respond as it I never said it.

I kept telling Richard the HHH does simulate an instance itself >>>>>>>>> emulating an instance of DDD and can do this because HHH and >>>>>>>>> DDD are
in the same global memory space of Halt7.obj.

Richard keeps saying That HHH cannot simulate an instance of >>>>>>>>> itself
because it does not have access to this memory. I corrected him 20 >>>>>>>>> times on this and he still does not get it.

DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides >>>>>>>> (given HHH' must halt with a decision because HHH must halt with a >>>>>>>> decision).

/Flibble

Yet that makes the details more difficult to understand.
We must do that in the Linz proof. Whereas with my DDD/HHH proof >>>>>>> any C
programmer knowing what recursion is can see the repeating pattern. >>>>>>

There isn't a repeated pattern because there isn't any recursion:
DDD can
*analyse* HHH without *executing* HHH because it can use a COPY of >>>>>> HHH
using whatever representation it deems appropriate.

/Flibble

One of the problems with static analysis of code
is that it may not ignore unreachable code.

Analysis by a simulating halt decider never even
sees this unreachable code. It only pays attention
to the code in its actual execution trace.

But the code isn't "unreachable", only not reached by the partial
simulation that the decider did.

Anyone with slight C programming experience can see
the repeating pattern that cannot possibly reach its
own simulated final halt state.

As usual incorrect claims without evidence.
Only somebody with no understanding will say so. Every competent C
programmer sees that when HHH returns, DDD halts and that if HHH
cannot reach that point, it fails due to a premature abort.

void DDD()
{
  HHH(DDD);
  return;
}

_DDD()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6892210000 push 00002192  // push DDD
[0000219a] e833f4ffff call 000015d2  // call HHH
[0000219f] 83c404     add esp,+04
[000021a2] 5d         pop ebp
[000021a3] c3         ret
Size in bytes:(0018) [000021a3]

For the infinite set of HHH/DDD pairs where N instructions
of DDD are correctly emulated by each HHH, no instruction
of DDD is outside the set of the first four instructions of DDD.
*WHEN I DARE YOU TO SHOW OTHERWISE YOU CHANGE THE SUBJECT*
Changing the subject is cheating.

So, How did you correctly simulate the CALL HHH instruction, since the
x86 langague specifications says that the execution proceeds to the
address instuction, which isn't present in your input.

You are just showing you don't know the proper meaning of your words.

IF the above is ALL of what you call "DDD", then it isn't a program, and
thus is a CATEGORY ERROR to apply to a halt decider, whose input is
required to be the representation of a PROGRAM.

I guess you are just proving AGAIN that you whole logic is based on LYING.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)