Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <v2tjq0$22aq1$11@i2pn2.org>
Deutsch   English   Français   Italiano  
<v2tjq0$22aq1$11@i2pn2.org>

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

Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: Addressing the only rebuttal of my proof in the last two years
Date: Sat, 25 May 2024 17:05:04 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v2tjq0$22aq1$11@i2pn2.org>
References: <v2ns85$1rd65$1@dont-email.me> <v2s46t$2pj9q$2@dont-email.me>
 <HOGdnVr9MpKtlc_7nZ2dnZfqn_qdnZ2d@brightview.co.uk>
 <v2tho2$31cch$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 25 May 2024 21:05:04 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2173761"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v2tho2$31cch$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 9376
Lines: 190

On 5/25/24 4:29 PM, olcott wrote:
> On 5/25/2024 10:48 AM, Mike Terry wrote:
>> On 25/05/2024 08:32, Fred. Zwarts wrote:
>>> Op 23.mei.2024 om 18:52 schreef olcott:
>>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>>> 00       int H(ptr p, ptr i);
>>>> 01       int D(ptr p)
>>>> 02       {
>>>> 03         int Halt_Status = H(p, p);
>>>> 04         if (Halt_Status)
>>>> 05           HERE: goto HERE;
>>>> 06         return Halt_Status;
>>>> 07       }
>>>> 08
>>>> 09       int main()
>>>> 10       {
>>>> 11         H(D,D);
>>>> 12         return 0;
>>>> 13       }
>>>>
>>>> The above template refers to an infinite set of H/D pairs where D is
>>>> correctly simulated by pure function H. This was done because many
>>>> reviewers used the shell game ploy to endlessly switch which H/D was
>>>> being referred to.
>>>>
>>>> *Correct Simulation Defined*
>>>> This is provided because every reviewer had a different notion of
>>>> correct simulation that diverges from this notion.
>>>>
>>>> In the above case a simulator is an x86 emulator that correctly 
>>>> emulates
>>>> at least one of the x86 instructions of D in the order specified by the
>>>> x86 instructions of D.
>>>>
>>>> This may include correctly emulating the x86 instructions of H in the
>>>> order specified by the x86 instructions of H thus calling H(D,D) in
>>>> recursive simulation.
>>>>
>>>> *Execution Trace*
>>>> Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, and 
>>>> 03 of
>>>> D. This invokes H(D,D) again to repeat the process in endless recursive
>>>> simulation.
>>>>
>>>
>>> Olcott's own words are that the simulation of D never reaches past 
>>> line 03. So the lines following line 03 do not play a role and, 
>>> therefore, can be removed without changing the claim. This leads to:
>>>
>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>> 00       int H(ptr p, ptr i);
>>> 01       int D(ptr p)
>>> 02       {
>>> 03         return H(p, p);
>>> 04       }
>>> 05
>>> 06       int main()
>>> 07       {
>>> 08         H(D,D);
>>> 09         return 0;
>>> 10       }
>>>
>>
>> Correct - as far as this specific thread is concerned.  But PO's H and 
>> P are intended to be part of a larger argument supposedly refuting the 
>> standard halting problem (HP) proof (that no TM is a halt decider), 
>> e.g. as covered in the Linz book.  PO has created an extract of that 
>> proof as a PDF that he sometimes links to.
>>
>> Also note that PO's claim (in this specific thread) is that the 
>> *simulation* of D never reaches past line 03.  That is not saying that 
>> the *computation* D(D) never proceeds past line 3 or that D(D) never 
>> halts.  (This is important in the wider HP proof context.  PO is 
>> deeply confused on this point.)
>>
>>>
>>> What we see is that the only property of D that is used is that it is 
>>> a parameter duplicator. (Is that why it is called D?). H needs 2 
>>> parameters, but it can be given only one input parameter, so the 
>>> parameter duplicator is required to allow H to decide about itself.
>>
>> Yes, but the rest of D is the key to its role in the HP proof - again, 
>> not relevant for this specific thread.  [In HP proof, D's role is to 
>> calculate H's decision on whether D(D) halts and then behave in the 
>> opposite fashion, providing a counterexample to the claim that H 
>> correctly decides the halting behaviour of /all/ inputs (P,I).  I.e. 
>> it shows that H gets it wrong for the case P=I=D.]
>>
>>>
>>>
>>>
>>> Of the infinite set of H that simulate at least one step, none of 
>>> them, when simulated by H, halts, because none of them reaches its 
>>> final state. Olcott's claim is equivalent to the claim of non-halting 
>>> behaviour of H.
>>
>> No - note my remarks above about the distinction between the behaviour 
>> of the *computation* D(D) and the (partial) *simulation* of that 
>> computation by H.  H can simply choose to discontinue that simulation 
>> at any point [aka "abort" the simulation, in PO's terms], but then H 
>> would continue and halt.
>>
>> PO is pretty clueless about everything involved, and I believe he is 
>> quite incapable of abstract thought, including what people would 
>> generally regard as "logical reasoning", so there really is no point 
>> in arguing with him.  (I mean Really...)
>>
>> Mike.
>>
> 
> 
> On 5/25/2024 2:41 PM, olcott wrote:
> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv2tesk%2430u1r%241%40dont-email.me%3E
> 
> I read and reread what Mike said several times to make sure that I
> get the exact meaning of exactly what Mike said. *I missed it this time*
> 
> Since *Mike is my most important reviewer* and this one key point
> has been the only basis for any rebuttal in the last two years I
> am addressing it here. *Followups have been sent to comp.theory*
> 
> I must diverge a tad bit from the pure semantics of the c programming
> language to address an error by my reviewers regarding the theory of
> computation notion of computable function.
> 
> *Computable functions* are the basic objects of study in computability
> theory. Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function is
> computable if there exists an algorithm that can do the job of the
> function, i.e. given an input of the function domain it can return the
> corresponding output. https://en.wikipedia.org/wiki/Computable_function
> 
> When computable function H reports on the behavior of its input it must
> report on:
> 
> D correctly simulated by pure function H cannot possibly reach its own 
> line 06

Which has yet to be establish.

> 
> Computable functions ARE STRICTLY NOT ALLOWED TO REPORT ON THE BEHAVIOR
> NON-INPUTS. Computable functions ARE NEVER ALLOWED TO REPORT ON THE
> BEHAVIOR OF THE COMPUTATION THAT THEY THEMSELVES ARE CONTAINED WITHIN.

Right, but if the input fully describes a program, it can report on the 
behaivor of that program, as all actual computatation have a description 
that can be fully described.

> 
> In technical terms this means that Turing machines are never allowed
> to report on the behavior of Turing machines. They are only allowed
> to report on the behavior specified by a finite string Turing machine
> description.

Nope. They can report on the Turing Machine which is described to them.

That finite string description of the Turing Machine fully defines all 
the behavior of that Machine, and thus that behavior is allowed to be 
what the Function answers about.

> 
> Crucially this is one level of indirect reference away from the behavior
> of the actual Turing machine. This never makes any difference except
> in the case of pathological self-reference such as D correctly simulated
> by pure function H. No one ever noticed this before because simulating
> termination analyzers were always rejected out-of-hand without review.
> 

But it FULLY DEFINES it.  Even for the pathological self-reference case, 
because in the Mathematical realm, infinite operations are allowed, so 
the Mathematic Function CAN ask if the UTM simulation of the input will 
never halt, and if not, return 0.

The issue becomes converting that into a Computation to show that the 
function is a Computable Function. Nothing in Computation Theory says we 
========== REMAINDER OF ARTICLE TRUNCATED ==========