XPost: comp.theory, comp.lang.c++
From: dbush.mobile@gmail.com
On 11/19/2025 12:08 AM, olcott wrote:
> On 11/18/2025 10:52 PM, Kaz Kylheku wrote:
>> On 2025-11-19, olcott wrote:
>>> On 11/18/2025 10:31 PM, Kaz Kylheku wrote:
>>>> On 2025-11-19, olcott wrote:
>>>>> On 11/18/2025 8:53 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-19, olcott wrote:
>>>>>>> On 11/18/2025 7:01 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-11-18, olcott wrote:
>>>>>>>>> On 11/18/2025 3:21 PM, Kaz Kylheku wrote:
>>>>>>>>>> On 2025-11-18, olcott wrote:
>>>>>>>>>>> If you ask a decider to determine if my
>>>>>>>>>>> sister's name is "Sally" and I don't tell
>>>>>>>>>>> it who I am then the information contained
>>>>>>>>>>> in the input is insufficient. This does not
>>>>>>>>>>> in any way limit computation itself.
>>>>>>>>>>
>>>>>>>>>> The problem is that UTM(D) can work out the fact that
>>>>>>>>>> D halts. Why is it that UTM knows that D's sister's
>>>>>>>>>> name is Sally, but H does not?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> UTM(D) is answering a different question.
>>>>>>>>> (a) It is not providing any answer at all.
>>>>>>>>
>>>>>>>> Well, of course, by "UTM" we mean a /decider/ that purely
>>>>>>>> simulates:
>>>>>>>>
>>>>>>>> bool UTM(ptr P) {
>>>>>>>> sim S = sim_create(P);
>>>>>>>> sim_step_exhaustively(S);
>>>>>>>> return true;
>>>>>>>> }
>>>>>>>>
>>>>>>>> All deciders applied to D are tasked with answering exactly the
>>>>>>>> same
>>>>>>>> question.
>>>>>>>>
>>>>>>>> Pretending that a different question was asked is nonproductive;
>>>>>>>> the answer will be interpreted to the original question.
>>>>>>>>
>>>>>>>> All the information needed to answer is positively contained in D.
>>>>>>>>
>>>>>>>> It is just too complex relative to H.
>>>>>>>>
>>>>>>>
>>>>>>> What The F does UTM decide when DD calls UTM(DD)?
>>>>>>
>>>>>> That doesn't happen; DD calls HHH(DD).
>>>>>>
>>>>>> A diagonal functon set against UTM, call it DDUTM,
>>>>>> cannot be decided by UTM(DDUTM).
>>>>>>
>>>>>> That call simply does not return.
>>>>>>
>>>>>
>>>>> Yes, and the other one does return proving the
>>>>> whole point that I have been making for three
>>>>> years that everyone (besides Ben) was too damned
>>>>> dishonest to acknowledge has been true all along.
>>>>
>>>> What "other one"? Is that referring to HHH(DD)?
>>>>
>>>> HHH(DD) returns; UTM(DDUTM) does not return.
>>>>
>>>> That's four functions; HHH isn't UTM; DD isn't DDUTM.
>>>>
>>>> HHH and DDUTM are unrelated; UTM and DD are unrelated.
>>>>
>>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> A simulating termination analyzer that must
>>> abort the interpretation of the above ASCII
>>> string to prevent its own non-termination
>>> has different behavior than a simulating
>>> termination analyzer that need not abort
>>> its interpretation of the above exact same
>>> ASCII string.
>>
>> 1. Up to that abort point, UTM(DDD) and HHH(DDD) conduct an
>> absolutely identical simulation. The only difference is
>> that the simulation continues under UTM, and is abandoned
>> under HHH.
>>
>
> No that is counter-factual please try again.
On 6/16/2025 12:58 PM, olcott wrote:
> Baseless dogmatic statements that are utterly bereft of any
> supporting reasoning at all DO NOT COUNT AS REBUTTALS.
It is factual as proven by Kaz's code, *and* the side by side trace
posted by Mike, *and* by your repeated failure to show which x86
instruction is emulated differently by HHH and UTM.
>
>> 2. This is not a difference attributable to DDD. DDD is the same in
>> both cases. Not continuing the simulation fo DDD doesn't redefine what
>> DDD is. It is not possible to redefine what DDD is; it is the
>> agreed-upon procedure above.
>>
>
>
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
