Op 01.aug.2025 om 17:12 schreef olcott:
On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 16:52 schreef olcott:
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
We have told you that the suggestion that these 18 bytes are the
whole input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH
that aborts after a few cycles.
This input specifies a halting program as other correct simulators
and direct execution prove.
Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.
It is an irrelevant change of subject to imagine a hypothetical non-
input that has no abort code.
Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.
No, it shows that HHH fails to reach the final halt state, where a
simulator (even when named HHH) that does not abort,has no problem to
reach the final halt state.
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
As usual a false claim.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.
Illogical, counter-factual and incorrect claim without evidence.
It is exactly the premature abort that causes that the final halt state
is not reached. Of, course the trace of that prematurely aborted
simulation does not show the last part of a correct simulation.
But a comparison with a correct simulation done by e.g. HHH1, shows the exact point where the final halt state is reached and where HHH does the premature abort.
On 8/2/2025 4:30 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 17:12 schreef olcott:
On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 16:52 schreef olcott:
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
We have told you that the suggestion that these 18 bytes are the
whole input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH
that aborts after a few cycles.
This input specifies a halting program as other correct simulators
and direct execution prove.
Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.
It is an irrelevant change of subject to imagine a hypothetical non-
input that has no abort code.
*Not according to the leading author of theory of computation textbooks*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.
No, it shows that HHH fails to reach the final halt state, where a
simulator (even when named HHH) that does not abort,has no problem to
reach the final halt state.
Where the Hell are you getting that from?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Prove your statement on this code.
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
As usual a false claim.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.
Illogical, counter-factual and incorrect claim without evidence.
What do you mean by premature abort?
The actual word "premature" means too early.
If the abort is too early then there is a point
in the execution trace that is not too early.
It is exactly the premature abort that causes that the final halt
state is not reached. Of, course the trace of that prematurely aborted
simulation does not show the last part of a correct simulation.
In other words when DDD calls its own simulator HHH in
recursive simulation this is exactly the same thing as
DDD never calling its own simulator HHH1 in recursive
simulation?
Sounds like 1984 newspeak to me.
https://en.wikipedia.org/wiki/Newspeak
But a comparison with a correct simulation done by e.g. HHH1, shows
the exact point where the final halt state is reached and where HHH
does the premature abort.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,075 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 90:34:33 |
| Calls: | 13,798 |
| Calls today: | 1 |
| Files: | 186,989 |
| D/L today: |
5,329 files (1,535M bytes) |
| Messages: | 2,438,212 |