Deutsch   English   Français   Italiano  
<vvnscb$3in62$10@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: What it would take...
Date: Sat, 10 May 2025 10:46:19 -0500
Organization: A noiseless patient Spider
Lines: 119
Message-ID: <vvnscb$3in62$10@dont-email.me>
References: <vvm948$34h6g$2@dont-email.me>
 <d722a8886c52df233453d5e8f0d493f63399b3d3@i2pn2.org>
 <vvnq2o$3in62$4@dont-email.me>
 <43f51e2fd015e856f4d1cb29a3bb0b3f824f6099.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 10 May 2025 17:46:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7be348abb5bc2ec0a70724586a3ca680";
	logging-data="3759298"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/FQ74JwLTn67V4Kk2DbL7o"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Ue72Eg44GShEO9l8CwslG4Rxef8=
X-Antivirus-Status: Clean
Content-Language: en-US
X-Antivirus: Norton (VPS 250510-2, 5/10/2025), Outbound message
In-Reply-To: <43f51e2fd015e856f4d1cb29a3bb0b3f824f6099.camel@gmail.com>
Bytes: 6471

On 5/10/2025 10:35 AM, wij wrote:
> On Sat, 2025-05-10 at 10:07 -0500, olcott wrote:
>> On 5/9/2025 9:18 PM, Richard Damon wrote:
>>> On 5/9/25 9:11 PM, Richard Heathfield wrote:
>>>> The HHH code doesn't exactly invite confidence in its author, and his
>>>> theory is all over the place, but a thought experiment suggests itself.
>>>>
>>>> If we were not all wasting our time bickering with a career
>>>> bickerer... if we were to really /really/ try, could we patch up his
>>>> case and send him on to his Turing Award? And if so, how?
>>>>
>>>> ISTR that there is suspected to be a theoretical window for him, so I
>>>> suppose what I'm asking is what sort of boathook we would need to poke
>>>> that window a little wider.
>>>>
>>>> Can he even get there from here? Evidence would suggest that
>>>> simulation is a dead end unless he can find a way to get the simulated
>>>> program to include its own simulation in its behaviour, which he has
>>>> not yet managed to do - but /is/ there a way?
>>>>
>>>> Or could he abandon simulation completely and instead write a TM
>>>> parser that builds an AST and walks it looking for evidence of
>>>> terminating or looping? If he could, would that turn the trick?
>>>>
>>>> Or do we have a latter day Cantor waiting in the wings to close the
>>>> window once and for all?
>>>>
>>>> Is there, in short, any way of putting out this un-halting flame war
>>>> and turning this group to better use?
>>>>
>>>
>>> If he was willing to include the code for HHH in the input representing
>>> DDD, then HHH would be able to atempt to correctly emulate this input.
>>>
>>
>> DDD and HHH have always been in the same memory space.
>> DDD is the program under test and HHH is the test program.
>>
>>> There have been methods put forward, that given an acceptace of the
>>> detectability of DDD calling HHH, which can only be done it seems if we
>>> make the system non-turing complete by saying that the input program and
>>> the decider are put into the same memory space, and we are not allowed
>>> to "copy" an algorithm to make a new copy, but only call the origianal
>>> version so HHH can detect the recursion by reference to that address
>>> that some versions of programs that do this "recursive simulation" can
>>> be correctly decider (but not all, like the pathological version).
>>>
>>
>> HHH is essentially a UTM thus EVERYTHING is in the memory space
>> of its UTM tape.
>>
>>> In this method, the Decider detecting the recursion, tries emulating the
>>> code in two parrallel branches based on both possible answers, and if
>>> one branch matches the behavior of the answer, it can return that answ3er.
>>>
>>
>> We can emulate a branch as if a conditional expression
>> was true and as if it was false. HHH determines the
>> behavior of DDD on the basis of what would happen if
>> HHH never aborted.
>>
>> <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
>>
>>> Thus, inputs like DDD() that always halt on the return of HHH(DDD) will
>>> be correctly determined to be halting, and a varient that just goes into
>>> an infinite loop can be such detected by well know procedures as non-
>>> halting.
>>>
>>
>> When HHH continues to emulate DDD until HHH sees the
>> repeating pattern that would prevent DDD from ever
>> terminating
>>
>>       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>
>>
>>> The pathological DD() is detected as pathological, and we can perhaps
>>> extend the definition to allow it to respiond with an "I give up, I
>>> don't know the answer" response, but such an extention explicitly does
>>> NOT meet the requirements, but is better than not answering or giving a
>>> wrong answer.
>>>
>>> The problem is this result doesn't meet Peter's Goal, as it isn't really
>>> the Halting Problem that he has his major problem with, but the fact
>>> that Turings Proof became the basis for a number of broader proofs of
>>> incompleteness and undeciability that fills formal logic.
>>>
>>> This is what he can't handle, and this is because he just doesn't really
>>> understand how all of the works because his mental models of logic is
>>> just way to small and simple.
>>
>> Dodge and weave is all you know.
>>
>> int DD()
>> {
>>     int Halt_Status = HHH(DD);
>>     if (Halt_Status)
>>       HERE: goto HERE;
>>     return Halt_Status;
>> }
>>
>> It is a verified fact that DD correctly emulated
>> by any simulating termination analyzer HHH specifies
>> a non-terminating sequence of configurations.
>>
> 
> Nope.
> POOH is intended to decide whether the input D is "impossible" input or not.
> 

counter-factual.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer