Re: My reviewers think that halt deciders must report on the behavior of their caller

Liste des GroupesRevenir à s logic 
Sujet : Re: My reviewers think that halt deciders must report on the behavior of their caller
De : noreply (at) *nospam* example.org (joes)
Groupes : comp.theory
Date : 10. Jul 2025, 11:12:44
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <c74920a0e6e73da1eb8a57b10e7ebf930af8fd88@i2pn2.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
User-Agent : Pan/0.145 (Duplicitous mercenary valetism; d7e168a git.gnome.org/pan2)
Am Wed, 09 Jul 2025 11:06:03 -0500 schrieb olcott:
On 7/9/2025 10:42 AM, joes wrote:
Am Wed, 09 Jul 2025 09:06:42 -0500 schrieb olcott:
On 7/9/2025 8:37 AM, joes wrote:
Am Wed, 09 Jul 2025 08:02:16 -0500 schrieb olcott:
On 7/9/2025 3:58 AM, Fred. Zwarts wrote:

All Turing machine deciders only compute the mapping from their
actual inputs. This entails that they never compute any mapping from
non-inputs.
It matters more what they map it to, i.e. which mapping they compute.
HHH does not compute the halting function.
It is a matter of verified fact that HHH does correctly determine that
DDD correctly emulated by HHH cannot possibly reach its own emulated
final halt state.
Yes. That is not the halting function.
Yes it is the halting function.
The actual question posed to HHH is:
Does your input specify behavior that cannot reach its own final halt
state?
Yes, that is not the mathematical function that pairs encodings of
programs with their halting state.

I have another program here that (tautologically) determines that it
cannot simulate ANY code (according to x86 semantics) to a halting
state - by simulating zero steps :-) That tells me nothing about
whether the input halts when executed.
That changes the words of the question thus becomes the strawman error.
No, it answers the same question as HHH: does the simulation halt?

How can your beloved Aprove even say anything about its inputs?
Since programs are not in its domain...

How could HHH abort and not halt?
None of the code in HHH can possibly help DDD correctly emulated by
HHH to reach its own emulated final halt state.
The abort could, if you hadn't botched it with static variables.
DDD emulated by HHH according to the semantics of the x86 language
continues to emulate the first four instructions of DDD in recursive
emulation until HHH aborts its emulation immediately killing every DDD
before any of them reach their own "ret" instruction.
Or before they reach the abort.

I keep asking for your credentials because you seem to not have enough
technical knowledge about ordinary programming.
Doesn't sound like a degree would convince you.

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.
Yes, what a processor does - turning code into behaviour - is clearly
uncomputable.
I'll take that as agreement.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

Date Sujet#  Auteur
13 Jul 25 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal