Re: How do computations actually work?

Op 30.mei.2025 om 17:58 schreef olcott:

On 5/30/2025 4:05 AM, Richard Heathfield wrote:

On 30/05/2025 08:47, Mikko wrote:

On 2025-05-29 16:41:26 +0000, Richard Heathfield said:
>

On 29/05/2025 16:27, Fred. Zwarts wrote:

The actual input is halting, the non-halting input is only in your dreams. There is no need to halt artificially a halting program.

>
Doesn't that rather depend on how long it will take to halt? After all, your user wants a report, and he might not have all day.

>
If the user can't wait until the report is delivered then he
must find out what to do without the report.

>
That's one option. Or he could use a better termination analyst, one that doesn't suffer from the fatal flaw inherent in simulation.
>
Unfortunately, he then runs up against the /other/ fatal flaw, which is that what he wants can't be done.
>

 The fact that DDD correctly emulated by HHH cannot
possibly stop running unless aborted and cannot
possibly reach its own "ret" instruction final halt
state conclusively proves that the input to HHH(DDD)
specifies a non-halting sequence of configurations.
 

But that is not a fact, it is a dream without any logical support. The verified fact is that the input to HHH is DDD, which in turn specifies addresses of functions it calls, including the code that aborts and halts the program.
So, there is no 'cannot possibly stop running unless aborted'.
World-class simulators, without the bug in HHH, show that exactly the same input when simulated has a natural end and reached the final 'ret' instruction. That is what the input specifies.
That HHH cannot possibly reach its own 'ret' instruction, only shows the weakness of HHH in particular, and of using a simulator in general, to analyse the behaviour. No simulator is able to simulate itself correctly up to the end. No DDD is needed to prove that.
This weakness in HHH does not change the specification of the input in any way, as every competent programmer understands.