Liste des Groupes | Revenir à theory |
On 5/12/2025 9:17 PM, Mike Terry wrote:Right, so the behavior of the partial emulation done by HHH is wrong.On 12/05/2025 02:25, Richard Heathfield wrote:When "correctly" means to report on behavior besidesOn 12/05/2025 01:38, Mike Terry wrote:>On 11/05/2025 18:11, Richard Heathfield wrote:>On 11/05/2025 17:44, olcott wrote:>Any yes/no question where both yes and no are the>
wrong answer is an incorrect polar question.
Either DD stops or it doesn't (once it's been hacked around to get it to compile and after we've leeched out all the dodgy programming).
Done that.
And you still had code left?
>It still stops.>
Okay.
>>If the computer cannot correctly decide whether or not DD halts,>
The decider says it doesn't stop..
I said "cannot >>>correctly<<< decide".
There are infinitely many deciders that could be given the input. Some of them decide that particular input correctly, and some incorrectly.
>
PO's HHH is one of the ones that decide incorrectly.
>
that behavior that the input actually specifies then
it is wrong.
When 2 + 3 = 5 this is determined by the rulesBut the behavior that the input specifies by those rules is HALTING, as that is what the actual sequence of the actual instructions of what you consider to be the input (The DDD calling the HHH that is at that location, which is the HHH that aborts and returns 0)'
of arithmetic.
When the behavior that the input specifies according
to the rules of the x86 language is non-halting then
HHH must report on this behavior.
HHH cannot compute the mapping from its input toSo? That is its problem, that *IS* the behavior of the input that it must report on.
the behavior of the directly executed DD() for the
same reason that
int sum(int x, int y) { return x + y; }Right, the input DDD calls the HHH that aborts and returns 0, and thus is haltig.
sum(3,2) can not compute any mapping to sum 5 + 7.
THE INPUT SPECIFIES SOMETHING ELSE.
Les messages affichés proviennent d'usenet.