Liste des Groupes | Revenir à theory |
Op 07.jul.2025 om 15:23 schreef olcott:100% *complete proof is provided above*On 7/7/2025 2:36 AM, Fred. Zwarts wrote:As usual repeated claims without evidence.Op 07.jul.2025 om 05:12 schreef olcott:>On 7/6/2025 9:09 PM, Richard Damon wrote:And HHH does not do that. The input specifies a halting program, because it includes the abort code.On 7/6/25 4:06 PM, olcott wrote:>On 7/6/2025 12:00 PM, Richard Damon wrote:>On 7/6/25 11:19 AM, olcott wrote:>>>
void DDD()
{
HHH(DDD);
return;
}
>
*EVERY BOT FIGURES THIS OUT ON ITS OWN*
No, it just isn't smart enough to detect that you lied in your premise.
>There is no way that DDD simulated by HHH (according>
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.
And there is no way for HHH to correctly simulate its input and return an answer
>
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
>
What the F is wrong with you?
>
It seems you don't understand those words.
>
I don't say that the decider needs to simulate the input to completion, but that it needs to be able to actually PROVE that if this exact input WAS given to a correct simultor (which won't be itself, since it isn't doing the complete simulation) will run for an unbounded number of steps.
>
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
>
>
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]
>
That does have an effect on DDD emulated by HHH according
to the semantics of the x86 language stopping running.
It has no effect on this DDD every reaching its final halt
state. I have corrected your error on this too many times
you don't seem to want an honest dialogue.
It is a pity that you ignore or do not understand the corrections that have been pointed out to you. Not understanding something is not stupid, but resistance against learning from errors is.DDD correctly simulated by HHH calls HHH(DDD)
We have pointed out already many times that this cannot be the whole input. At 0000219a there is a call to 000015d2 , but the code at 000015d2 is not specified.https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
We have to take it from another source, your Halt7.c. There we see that HHH is a function that returns with a value 0 with this input. So, a correct simulation will then continue at 0000219fDDD simulated by HHH according to the semantics of the x86
with this value and even a beginner sees that the simulation will then reach a natural end.*DDD simulated by HHH NEVER REACHES ITS FINAL HALT STATE*
This is the full specification of the input.--
This is also proven when exactly the same input is used in direct execution, or by world-class simulators, even by HHH1.
So, the following still holds:
>If HHH does not see the full specification, it does not change the specification. It only illustrates the failure of the simulation to complete.But HHH gives up before it reaches that part of the specification and the final halt state.
There is nothing wrong with aborting a simulation, because it is known that simulation is not always the correct tool to determine halting/non- halting behaviour. In such cases other tools are needed to determine halting/non-halting behaviour.
Les messages affichés proviennent d'usenet.