Liste des Groupes | Revenir à theory |
On 11/14/24 8:22 AM, olcott wrote:An emulating termination analyzer / simulating halt deciderOn 11/14/2024 2:56 AM, joes wrote:And thus the contents of the memory are ALSO part of the "input" and thus not changable without changing the input.Am Wed, 13 Nov 2024 17:11:30 -0600 schrieb olcott:>On 11/13/2024 4:58 AM, Mikko wrote:>On 2024-11-12 13:58:03 +0000, olcott said:On 11/12/2024 1:12 AM, joes wrote:Am Mon, 11 Nov 2024 10:35:57 -0600 schrieb olcott:It is not the same DDD as the DDD under test.On 11/11/2024 10:25 AM, joes wrote:>Am Mon, 11 Nov 2024 08:58:02 -0600 schrieb olcott:On 11/11/2024 4:54 AM, Mikko wrote:On 2024-11-09 14:36:07 +0000, olcott said:On 11/9/2024 7:53 AM, Mikko wrote:When DDD calls a simulator that aborts, that simulator returns toDDD emulated by HHH does not reach its "return" instruction finalThe actual computation itself does involve HHH emulating itselfWhich is what you are doing: you pretend that DDD calls some other
emulating DDD. To simply pretend that this does not occur seems
dishonest.
HHH that doesn’t abort.
halt state whether HHH aborts its emulation or not.
DDD, which then halts.
What, then, is the DDD "under test"?
The machine code address that is passed to HHH on the stack
is the input to HHH thus the code under test. It specifies
that HHH emulates itself emulating DDD.
>
HHH is required to abort the emulation of any input thatNo, HHH does what it does, and, to be a halt decider must determine if the program described halts or not.
would otherwise result in its own non-termination. DDD
is such an input.
Les messages affichés proviennent d'usenet.