Re: Indirect Reference Changes the Behavior of DDD() relative to DDD emulated by HHH

On 9/6/24 7:31 AM, olcott wrote:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

>
HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE.

>
And the outer one, when aborting after two cycles , misses the behaviour of the inner one in the next cycle, where the inner one would see the 'special condition', abort, return to DDD, which would halt as well.
That HHH misses the last part of the behaviour of the program, does not change the fact that this is the behaviour that was coded in the program
>

>
If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

>
The infinite chain exists only in your dream. In fact there are only two recursions, so never more that a chain of three HHH in the simulation.
HHH is incorrect in assuming the there is an infinite chain, but this incorrect assumption makes that it aborts and halts. This applies both to the simulating and the simulated HHH.

 The way it is encoded now there are only two recursions.
 If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...
 

No, HHH does what it is coded to do. No matter how far it emulates, it will NEVER get to the needed point to know what is to happen.
That means the algorithm you are proposing just fails to be able to get the correct answer, it doesn't mean that it will simulate longer, only that it SHOULD HAVE to get the right answer.
This concept seems to be beyond what you ignorant mind can handle, making you just decide to tell LIES about what HHH actually does.
You description is of the HHH that choses not to decide, and thus nevef answers.
Sorry, that is just the facts, HHH does what it does and it will never be enough, because it turns out the full problem is non-computable.
For THIS DDD, it turns out that a smarted decider could get the right answer, it just needs to adopt the flibble method of seeing the call to HHH in DDD, and try the two possible future paths to see if either is correct. SInce one is in this case, since DDD is NOT "pathological" there can be a decider that gets this template decided, just not the pathological one that defeats even the Flibble decider.