Liste des Groupes | Revenir à theory |
On 7/7/2025 5:39 PM, Richard Damon wrote:But they can take the finite-stringt encoding of those machines.On 7/7/25 9:32 AM, olcott wrote:That Turing machines cannot take directly executing TuringOn 7/7/2025 6:19 AM, Richard Damon wrote:>On 7/6/25 11:12 PM, olcott wrote:>On 7/6/2025 9:09 PM, Richard Damon wrote:>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.
>
Sure it is, there isn't a "law" that prohibits wrong answer, it just makes it not correct.
>
Sure in the same way that reporting the square root
of a rotten egg is incorrect.
>
Really, so that is the best you can do, ad hominems and irrevency.
>
I guess you are just admitting that you POOPS can't support UTMS, whcih means it can't actually have simulators, and thus no simulating halt deciders.,
>
Your whole "logic" system is built on lies
>>>And, since the input to a halt decider is supposed to be a representation/description (as a term-of-art word) of a Turing Machine, and the behavior that this input specifies is defined as the behavior of directly running that machine,>
That has always been incorrect.
No, that is just you lying.
>
I quoted a source with the statement of what a Halt Decider is, which says it is that,
>
What source do you have for your claims?
>
NOTHING, because you are just a pathological liar.
>
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.
That you cannot understand that is a truism is only yourBut it isn't a truism, it is just a stupid lie that ignores that almost everything done with programs is via an "encoding" for the input.
own lack of understanding.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdfWhich is just an admission of your lying strawman, as the question is NOT about the (partial) simulation done by your H / embedded_H, but about the direct execution of the input H^ (H^) as that is what the input to H is encoding.
*Here is the Linz proof corrected to account for that*
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩
Les messages affichés proviennent d'usenet.