XPost: comp.theory
From: polcott333@gmail.com
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.
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.
>>
>> 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.
> 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".
>
>
>
> Very little of PO's arguments would change : his HHH would still decide
> neverhalts for DD, and DD() would still halt when run directly, same as
> happens with the broken code. All the usual objections raised by
> posters here also continue to apply, so any such "steel-manned"
> arguments are still seen to be just as silly as the non-steel-manned
> versions. So we may well choose to be charitable on this point!
>
We end up at the same place as my above code snippet
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
