Re: Defining a correct simulating halt decider

On 9/8/24 10:16 AM, olcott wrote:

On 9/8/2024 5:05 AM, Fred. Zwarts wrote:

Op 07.sep.2024 om 16:54 schreef olcott:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

>

The directly executed HHH correctly determines that its emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH which is waiting for the next HHH
which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.
>

>
When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.
>

>
Dreaming again of a HHH that does not abort.

 In other words you have no idea what a hypothesis is?

But when you hypothosize about a different HHH, you need to give the the *SAME* input, the DDD that calls the ORIGINAL HHH. To do anything else is just to lie about using a strawman.

 The outermost HHH can either abort it emulation of DDD
or not and either way DDD cannot possibly reach its final
halt state of its "return" instruction and halt.

Right, but the question isn't can HHH emulate the input to the final state, but does the program the input represet reach a final state, and if HHH aborts its emulation and returns, then the program the input represents does, as does the actual correct emulation of the input (that HHH abandoned) also does.

 

HHH does abort, therefore it does not wait long enough, but there is no

 You seem to be intentionally too stupid to understand that
HHH cannot possibly wait. If it was not intentional stupidity
I would not use such harsh terms.

Right, if it waits, it fails by not answering. But, if it aborts, it also fails because it doesn't know the right answer, and then LIES. Normally I wrong answer is worse than no answer, as at least you know that you don't know the supposed answer to the problem.

 If HHH waits then every HHH waits and none of them ever abort
because each HHH has the exact same code at the exact same machine
address. It not your fault if you have a lower IQ. It is your fault
for not paying any attention to my corrections of your false
assumptions.

But your HHH DOES abort, only the hypothetical one doesn't.
The fact that it doesn't wait long enough just shows that its decision to abort must have been based on bad logic. Remember, you are trying to make the claim that a complete emulation of *THIS* input, the one that calls *THIS* HHH, that does exactly like *THIS* HHH does will not halt, not that if this HHH was something different, and thus we have a different DDD, that *THAT* DDD wouldn't halt. THat is just a false Strawman.

 

way to correct it. Waiting longer is not a solution. There is no solution. HHH cannot possibly simulate itself correctly up to the end.
How many times and in how many different way must this be repeated before olcott understands this?