Path: ...!Xl.tags.giganews.com!local-1.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 03 Aug 2024 03:11:12 +0000
Subject: Re: Hypothetical possibilities --- Complete Proof
Newsgroups: comp.theory
References: <v7gl30$3j9fi$1@dont-email.me> <v7r040$1onhe$3@dont-email.me>
 <v7vlbj$2ofet$1@dont-email.me> <v80a2u$2rabc$4@dont-email.me>
 <v825jo$39i9l$1@dont-email.me> <v82u9d$3dftr$3@dont-email.me>
 <v8306v$3c7$1@news.muc.de> <v83161$3dftr$11@dont-email.me>
 <v84udt$3rp4t$1@dont-email.me> <v8bc6j$159av$1@dont-email.me>
 <ea673a5b4ed43fbddf938c69bd013b0cf2ca325d@i2pn2.org>
 <v8c6kb$1de3l$1@dont-email.me>
 <9f3112e056ad6eebf35f940c34b802b46addcad4@i2pn2.org>
 <v8cde0$1ecgo$1@dont-email.me> <v8ctgt$1gbu7$4@dont-email.me>
 <v8dkc3$1kii7$3@dont-email.me> <v8e55v$1nrnh$1@dont-email.me>
 <v8e9vu$1oqd7$1@dont-email.me> <v8fftq$22ege$3@dont-email.me>
 <v8fuj5$24rl1$10@dont-email.me> <v8g1j7$24u77$6@dont-email.me>
 <v8g2jl$26d7d$1@dont-email.me> <v8ibf5$2p7ho$1@dont-email.me>
 <s3CdnbweXt8ohDD7nZ2dnZfqn_ednZ2d@brightview.co.uk>
 <a287d1fc2c1fc90d4381e46eae05287b96e801b9@i2pn2.org>
 <-Vednah5VvbtwTD7nZ2dnZfqnPSdnZ2d@brightview.co.uk>
 <449d4de351f2890de028f96a3ab5a758c9ce6e72@i2pn2.org>
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Date: Sat, 3 Aug 2024 04:11:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.17
MIME-Version: 1.0
In-Reply-To: <449d4de351f2890de028f96a3ab5a758c9ce6e72@i2pn2.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <dY-cnYDtsshNAjD7nZ2dnZfqnPSdnZ2d@brightview.co.uk>
Lines: 340
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-zbRhuWV5jYnTLZ2sDlx3/aOS4Ff9UspEFG0ch2K4jJGRanDjeKWydWkXDOr0rnNDzNw5JWl3gcO6o98!3txMt5j1bsGuhqng+CEQPWygtGLt8f2EBQ/A7yCLaAT//5+JQLYwRoNAFxgXTq+I+BhM2s0NecBB!XQsIZDQUHNA77B6aB8RaVRc0T5M=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 21161

On 03/08/2024 00:12, Richard Damon wrote:
> On 8/2/24 6:23 PM, Mike Terry wrote:
>> On 02/08/2024 19:25, Richard Damon wrote:
>>> On 8/2/24 1:39 PM, Mike Terry wrote:
>>>> On 02/08/2024 11:12, Mikko wrote:
>>>>> On 2024-08-01 13:29:24 +0000, olcott said:
>>>>>
>>>>>> On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
>>>>>>> Op 01.aug.2024 om 14:20 schreef olcott:
>>>>>>>> On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
>>>>>>>>> Op 31.jul.2024 om 23:23 schreef olcott:
>>>>>>>>>> On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
>>>>>>>>>>> Op 31.jul.2024 om 17:14 schreef olcott:
>>>>>>>>>>>> On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>> Op 31.jul.2024 om 06:09 schreef olcott:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ��machine�� stack���� stack���� machine��� assembly
>>>>>>>>>>>>>> ��address�� address�� data����� code������ language
>>>>>>>>>>>>>> ��========� ========� ========� =========� =============
>>>>>>>>>>>>>> [00002192][00103820][00000000] 55�������� push ebp
>>>>>>>>>>>>>> [00002193][00103820][00000000] 8bec������ mov ebp,esp
>>>>>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
>>>>>>>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
>>>>>>>>>>>>>> New slave_stack at:1038c4
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We don't show any of HHH and show the execution trace of
>>>>>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This assumption is incorrect if it means that HHH is an unconditional simulator that 
>>>>>>>>>>>>> does not abort.
>>>>>>>>>>>> This algorithm is used by all the simulating termination analyzers:
>>>>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>>>>>>>> ���� *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.
>>>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>>>>>>>
>>>>>>>>>>> So, Sipser only agreed to a correct simulation, not with an incorrect simulation that 
>>>>>>>>>>> violates the semantics of the x86 language by skipping the last few instructions of a 
>>>>>>>>>>> halting program.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> int DD()
>>>>>>>>>> {
>>>>>>>>>> �� int Halt_Status = HHH(DD);
>>>>>>>>>> �� if (Halt_Status)
>>>>>>>>>> ���� HERE: goto HERE;
>>>>>>>>>> �� return Halt_Status;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> �� HHH(DD);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> DD correctly emulated by HHH cannot possibly reach its own
>>>>>>>>>> second line. I switched to DDD correctly emulated by HHH
>>>>>>>>>
>>>>>>>>> But it has been proven that no such HHH exists that simulates itself correctly. So, talking 
>>>>>>>>> about a correct simulation by HHH is vacuous word salad.
>>>>>>>>>
>>>>>>>>>> because only C experts understood the above example and we
>>>>>>>>>> never had any of those here.
>>>>>>>>>
>>>>>>>>> There are many C experts that looked at it, but you only got critic, because you keep 
>>>>>>>>> hiding important properties of HHH, which made the conclusion impossible.
>>>>>>>>
>>>>>>>> The following is all that is needed for 100% complete proof
>>>>>>>> that HHH did emulate DDD correctly according to the semantics
>>>>>>>> of the x86 language and did emulate itself emulating DDD
>>>>>>>> according to these same semantics.
>>>>>>>
>>>>>>> You are repeating the same false claim with out any self-reflection. It has been pointed out 
>>>>>>> that there are many errors in this proof.
>>>>>>> Why repeating such errors?
>>>>>>>
>>>>>>>>
>>>>>>>> _DDD()
>>>>>>>> [00002172] 55�������� push ebp����� ; housekeeping
>>>>>>>> [00002173] 8bec������ mov ebp,esp�� ; housekeeping
>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>>>>>> [0000217f] 83c404���� add esp,+04
>>>>>>>> [00002182] 5d�������� pop ebp
>>>>>>>> [00002183] c3�������� ret
>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>
>>>>>>>> Begin Local Halt Decider Simulation�� Execution Trace Stored at:1138cc
>>>>>>>> [00002172][001138bc][001138c0] 55�������� push ebp����� ; housekeeping
>>>>>>>> [00002173][001138bc][001138c0] 8bec������ mov ebp,esp�� ; housekeeping
>>>>>>>> [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
>>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>>>>>
>>>>>>> The trace stops and hides what happens when 000015d2 is called.
>>>>>>> Olcott is hiding the conditional branch instructions in the recursion.
>>>>>>>
>>>>>>
>>>>>> *Here is the full trace where nothing is hidden*
>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
>>>>>
>>>>> On page 36 of that "trace"
>>>>> ��� [0000128c][0010379f][00000018] e8e6f4ffff call 00000777
>>>>> is not followed by the trace of 00000777. Instead the trace continues
>>>>> with the next instruction after the return without any comment about
>>>>> the omission. Meaning of 00000777 is not told.
>>>>>
>>>>
>>>> 777 is the address of Allocate, which is one of PO's "primative ops" within his "computing 
>>>> model". (Similar to his DebugStep().)
>>>>
>>>> It is implemented inside x86utm.exe (his COFF obj code runner), not in the user code 
>>>> DDD/HHH/etc. in the obj file, and so we would not expect to see any trace entries for its 
>>>> internals.� When the op concludes, rax has the address of the allocated memory, which is 
>>>> consistent with how a normal function would have returned the address.
>>>>
>>>> You can say correctly that PO has not explained this, but then he provided the full trace under 
>>>> protest, so it's understandable that he has not previously explained everything in it.� I'm 
>>>> surprised that his response to your post was both to ignore the question and accuse you of 
>>>> playing sadistic head games, as the question was perfectly sensible.
>>>>
>>>> You can look up the 777 address in the listing at the start of the trace and it's there along 
>>>> with a bunch of other routines which appear to just return without doing anything - those are 
>>>> all PO's primitive ops.� If you feel a need to understand exactly what they do, you'll need to 
>>>> check his source code!� (Although for Allocate there is no big surprise...)
>>>>
>>>>
>>>> So your observation isn't really a problem beyond not being properly explained.� An actual 
>>>> problem seen in his trace data is that the simulation of DDD does not track the behaviour of the 
>>>> unsimulated DDD. I.e. his simulation is incorrect.� (PO knows about that but claims it doesn't 
>>>> matter, although on other occasions he still claims the simulation is correct.)
>>>>
>>>>
>>>> Mike.
>>>>
>>>
>>> But the bigger error that totally negates this trace is if you at where it begins, it is at 
>>> program address 00002197, which just the page before is shown to be the address of _main.
>>>
>>> Since HHH was not given the address of main to start with, this can not be the trace that HHH 
>>> itself is generating and looking at, but is instead the trace of the running of that top level HHH.
>>
>> Well, all PO's trace logs start with main!� Something has to set up the required computation [aka 
>> the required TM + input tape].� That could be HHH(DDD), or maybe DDD() or whatever.� PO might have 
>> done this through extra invocation arguments to x86utm.exe, and then there would have been no need 
>> to code a main() in his halt7.c user code file.� But that would be decidedly fiddly, so having a 
>> fixed entry function main() is an ok convenience I'd say.� The main() is not really part of his 
>> computation model, but x86utm traces the lot.
>>
>> Normally when PO gives code snippets, he includes the main() routine. In this case it is main 
>> calling HHH(DDD), so HHH as you say is the outer level HHH.� (Later on in the trace we see 
>> simulated HHH entries...)
>>
>>> Since that shows the trace isn't what he claims it is, nothing it says means anything for his 
>>> argument.
>>
>> I can't see what PO claims the trace to be.� That trace was taken and published some weeks ago, 
>> and doesn't match up exactly with todays partial trace - e.g. the addresses of HHH/DDD don't match 
>> and so on.� If it's just wrong through being out of date, or because it has the main() trace on 
>> the front, that's not the worst of crimes...
========== REMAINDER OF ARTICLE TRUNCATED ==========