Liste des Groupes | Revenir à theory |
On 7/9/2025 8:37 AM, joes wrote:Thank you for your understanding.Am Wed, 09 Jul 2025 08:02:16 -0500 schrieb olcott:On 7/9/2025 3:58 AM, Fred. Zwarts wrote:Op 08.jul.2025 om 17:17 schreef olcott:On 7/8/2025 6:18 AM, Richard Damon wrote:On 7/7/25 10:52 PM, olcott wrote:On 7/7/2025 9:24 PM, Richard Damon wrote:Shut it. Nobody is advancing that view.An actual rebuttal requires proving that Turing machines can take
directly executing Turing machines (that are not finite string
encodings) as inputs.
Yes. That is not the halting function. I have another program here thatIt is a matter of verified fact that HHH does correctly determine that*If you have enough knowledge then that is self evident*It matters more what they map it to, i.e. which mapping they compute.
All Turing machine deciders only compute the mapping from their actual
inputs. This entails that they never compute any mapping from
non-inputs.
HHH does not compute the halting function.
DDD correctly emulated by HHH cannot possibly reach its own emulated
final halt state.
The abort could, if you hadn't botched it with static variables.None of the code in HHH can possibly help DDD correctly emulated by HHHabort and stop running *IS NOT THE SAME THING AS*How could HHH abort and not halt?
abort and halt That you keep ignoring this is not my mistake.
to reach its own emulated final halt state.
Yes, what a processor does - turning code into behaviour - is clearlybut HHH is unable to reach that part. This failure of HHH does not
make the specification any different. It only shows that this
simulating decider is not the right tool for this input.
The behavior that the input to HHH(DDD) actually specifies is the only
behavior that any decider can possibly report on.
That anyone believes that HHH is required to report on the behavior of a
non-input merely proves a lack of sufficient understanding of how Turing
machine deciders work.
Les messages affichés proviennent d'usenet.