XPost: comp.theory, sci.logic
From: F.Zwarts@HetNet.nl
Op 23.jul.2025 om 15:31 schreef olcott:
> On 7/23/2025 3:24 AM, Fred. Zwarts wrote:
>> Op 23.jul.2025 om 06:05 schreef olcott:
>>> On 7/22/2025 9:32 PM, Richard Damon wrote:
>>>>
>>>> No, YOU changed the subject of the problem from the OBJECTIVE
>>>> behavior of the execution of DDD, to the SUBJECTIVE criteria of what
>>>> HHH sees.
>>>>
>
> It is always the case that every halt decider is
> only accountable for the behavior that its actual
> input specifies and not accountable for the behavior
> of any non-inputs. The textbooks don't do it this
> way proves that textbooks are wrong.
As usual irrelevant claim without evidence
Up to now you could not point to any textbook that is wrong.
>
> Textbooks incorrectly assume that the behavior specified
> by the finite string machine description of ⟨M⟩ is always
> the same as the behavior of machine M. That is not the
> case when M calls its own termination analyzer.
As usual repeated claims without any evidence.
The behaviour specified in the description of the input does not depend
on who analyses it. When some analysers are unable to see the whole
specification, that is an error in the analyser, it does not change the
specification.
>
> Turing machine halt deciders compute the mapping from
> their input finite strings to the behavior that these
> finite strings specify.
Exactly.
And when a halting behaviour is specified, but the analyser is unable to
see that, the analyser is wrong. It should not compute the behaviour of
a hypothetical non-halting non-input.
>
>>>
>>> *Its been three years now and you can't remember*
>>>
>>> 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.
>>>
>>>
>>>
>>
>> Repeating the agreement with a vacuous statement is no rebuttal.
>> Since there is no H that correctly simulates D until it correctly
>> detects that its D would never stop unless aborted', the conclusion is
>> irrelevant.
>>
>
> _DD()
> [00002162] 55 push ebp
> [00002163] 8bec mov ebp,esp
> [00002165] 51 push ecx
> [00002166] 6862210000 push 00002162 // push DD
> [0000216b] e862f4ffff call 000015d2 // call HHH
> [00002170] 83c404 add esp,+04
> [00002173] 8945fc mov [ebp-04],eax
> [00002176] 837dfc00 cmp dword [ebp-04],+00
> [0000217a] 7402 jz 0000217e
> [0000217c] ebfe jmp 0000217c
> [0000217e] 8b45fc mov eax,[ebp-04]
> [00002181] 8be5 mov esp,ebp
> [00002183] 5d pop ebp
> [00002184] c3 ret
> Size in bytes:(0035) [00002184]
You have been told many times that these 35 bytes are not the complete
input. In fact they are the least interesting part of the input. DD is
completely irrelevant. What is relevant is that HHH must simulate itself.
int main() {
return HHH(main);
}
Here is no DD, and your own words are that HHH returns and reports that
it does not halt.
This clearly shows that HHH is unable to analyse its own behaviour and
produces false negative when it tries to do so.
>
> Counter-factual.
> That you do not understand the semantics of the
> x86 language well enough to understand that this
> is true is less than no rebuttal at all.
As usual counter-factual claims.
We have pointed out that world class simulators (and direct execution)
are very well able to follow the x86 language up to the final halt
state. HHH fails to follow the same semantics of the x86 language up to
the end if it cannot reproduce that for exactly the same input.
>
> In the several years that I have presenting this
> not one person has come up with a single correct
> rebuttal to the statement that DD emulated by HHH
> (according to the semantics of the x86 language)
> would ever stop running of not aborted.
We all see that the simulating HHH does not need to erroneously abort,
because the simulated HHH already erroneously aborts.
>
> All of the rebuttals either used the strawman
> deception to change the subject or were merely
> a statement that my statement was really really
> disbelieved. No one ever pointed out any actual error.
As usual counter factual claims.
Closing your eyes for all errors pointed out to you, does not make them
disappear. That is childish. But it seems to belong to your logic. If
HHH does not see the final halt state, you think it is a proof that that
final halt state does not exists. Same logic.
>
>> D halts even when not aborted,
>
> Neither DD simulated by HHH, HHH nor DD()
> halts unless HHH aborts its simulation of DD.
As usual irrelevant claim.
The point is: HHH does abort. What happens in your dream with another
HHH is irrelevant. World class simulators show that DD halts when not
aborted according to the semantics of the x86 language, because the
simulated HHH aborts. So indeed:
> Disagreement is merely a failure to understand.
>
>> because it calls a function H that aborts and halts. The simulation of
>> an aborting H has no need to be aborted.
>> Unless you change the input, but that is cheating.
>
> Alternatively DD emulated by HHH cannot possibly
> reach its own "ret" instruction and halt no matter
> what HHH does.
>
Reaching the final halt state is a proof of halting.
The opposite is not true. Failing to reach the final halt state is not a
proof of non-halting. If it were, any simulator aborting after one
instruction could proof non-halting for most program, with the incorrect
reasoning that non-halting was specified for *this* simulator.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
