XPost: comp.theory
From: dbush.mobile@gmail.com

On 10/27/2025 11:18 PM, olcott wrote:
> On 10/27/2025 9:24 PM, Mike Terry wrote:
>> On 28/10/2025 00:37, Kaz Kylheku wrote:
>>> On 2025-10-27, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>>> On 2025-10-27, dbush  wrote:
>>>>> On 10/27/2025 4:48 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-27, dbush  wrote:
>>>>>>>> I am only referring to these fifteen lines
>>>>>>>>
>>>>>>>> A straight forward sequence of steps that any
>>>>>>>> C programmer can easily determine:
>>>>>>>>
>>>>>>>> int D()
>>>>>>>> {
>>>>>>>>      int Halt_Status = H(D);
>>>>>>>>      if (Halt_Status)
>>>>>>>>        HERE: goto HERE;
>>>>>>>>      return Halt_Status;
>>>>>>>> }
>>>>>>>>
>>>>>>>
>>>>>>> Then you have nothing as this is incomplete and cannot be run.
>>>>>>
>>>>>> When I posted the git repo several days ago, Olcott immediately
>>>>>> called me dishonest and replied with the above nonsense.
>>>>>>
>>>>>> He has been repeating it ever since.
>>>>>>
>>>>>> Basically a meltdown, of sorts.
>>>>>>
>>>>>
>>>>> Oh yeah, he's thrashing.  He knows he's been beat and doesn't dare
>>>>> look
>>>>> at your code, lest he has to admit he wasted the last 21 years.
>>>>
>>>> But I explained that the code can help you validate that your cheats
>>>> are
>>>> working. If you want to say that DDD simulated by HHH does not halt,
>>>> and
>>>> not be lying, you can now test that actual claim. If the simulated DDD
>>>> halts, and you would like it not to, you have something to iterate
>>>> against to get that fixed.
>>>>
>>>> Every engineer would be happy to have an easy, ready-made way to test
>>>> the property of their system that they want to believe to be true.
>>>>
>>>> Instead of thank you, we get a childish tantrum.
>>>
>>> Unfortunately, it is not that rosy. The problem is that Olcott has not
>>> only been claiming that various D's do not terminate when simulated
>>> by various H's. He's been claiming that the D's do not terminate because
>>> they never reach the "do the opposite" logic at all.
>>>
>>> For instance, I ran a test on an old Halt.obj pulled from the git
>>> history, and found that when its simulation of the abandoned DD is
>>> continued, it soon hits an infinite loop.
>>>
>>> While, for that .obj file, it confirms the claim that the simulated DD
>>> doesn't terminate, the problem is that the simulated DD in that
>>> situation fails to terminate due to getting into the infinite loop,
>>> which is only possible because the simulated HHH(DD) returned non-zero
>>> to simulated DD.
>>>
>>> Thus the simulated HHH says, about the doubly-simulated DD, that the
>>> doubly-simulated DD halts A bug or cheat has been exposed in the
>>> machine; it is contradicting itself.
>>
>> Right.  To be overly charitable to PO, I don't believe PO coded things
>> this way with any intent at "cheating".  Firstly, he just didn't see
>> how to do it "properly", but if he had he'd have probably done it that
>> way. [Cleaner code without the global data misuse would be fewer lines
>> of code than what PO ended up with!]  Secondly, I think he sees what
>> he did as a kind of "optimisation" rather than a cheat.  He realised
>> that it would be the outer HHH that always spotted the abort pattern,
>> and that pattern was not affected by whether the inner HHH's actually
>> performed the checks, so "no harm" if he just misses them out on the
>> inner HHH's!
>
> Yes that is correct.
>
>> He just wasn't thinking ahead to your RECK resumption of abandoned
>> emulations!
>
> int D()
> {
>    int Halt_Status = H(D);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }
>
> H simulates D
> that calls H(D) to simulate D
> that calls H(D) to simulate D
> that calls H(D) to simulate D
> that calls H(D) to simulate D
> that calls H(D) to simulate D
> until H sees this repeating pattern.

At which point H(D) reports on this non-input:

int D()
{
   int Halt_Status = UTM(D);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

>
> Once H has correctly determines that its simulated
> D cannot possibly reach its own simulated "return"
> instruction final halt state it is nutty to do
> anything else besides abort and reject the input.
>

But it hasn't shown that as Kaz's code conclusively proves.

>>>
>>> Olcott knows that continuing the abandoned simulation uncovers
>>> damning evidence against his contraption, regardless of whether it
>>> halts or not.
>>>
>>> ne way to continue to defend it is via the following preposterous
>>> argument: all the odd-numbered simulation levels of DD are
>>> non-terminating, whereas the even-numbered levels (including zero,
>>> directly exedcuted) are terminating. And insist that this is correct.
>>>
>>> That narrative is possibly too far-fetched even for the prime
>>> minister of far-fetched land himself.
>>>
>> We've always known that PO's implementation of HHH/DD is broken,
>> through the misuse of global data to communicate across emulation
>> levels and to alter the behaviour of emulations depending on emulation
>> depth.  Until that issue is fixed, anything PO claims is /proved/ by
>> his C code is nonsense.  PO can only argue his code /proves/
>> something, if that code is actually correct!
>>
>
> I just exhaustively proved my whole proof again
> with the above snippet.

You proved that H is reporting on a non-input.

>
>> Unfortunately, until the global data issue is resolved, anything your
>> RECK code shows about the behaviour of PO's abandoned emulations is
>> effectively commenting more on the fickle behaviour of PO's global
>> data interactions than anything else.  A kind of nonsense-in-nonsense
>> out! (Not your fault in the slightest.)
>>
>> I don't think PO is capable of fixing his code, and I won't be helping
>> him on that front.  [I did once start explaining exactly what PO
>> needed to do, code-wise, but he just ignored that and continued
>> replying as usual, accusing me of not paying attention and lacking
>> basic competence etc., and that moment has passed!]
>>
>
> Starting over with an embedded C interpreter could work
> if it was not made moot by the above code snippet.
>
>> Meanwhile, we sometimes kind of pretend that PO has fixed the problem,
>> and people discuss what his code /WOULD/ do /assuming/ that basic
>> issue had been resolved.  That is being charitable to PO, and is
>> sometimes referred to as "steel-manning".
>>
>>    
>>

[continued in next message]

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)