Re: Addressing the only rebuttal of my proof in the last two years (correction)

Liste des GroupesRevenir à theory 
Sujet : Re: Addressing the only rebuttal of my proof in the last two years (correction)
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theory sci.logic
Date : 25. May 2024, 22:11:45
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <v2tk6h$22aq0$5@i2pn2.org>
References : 1 2 3 4
User-Agent : Mozilla Thunderbird
On 5/25/24 4:59 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.)
>
 My reply to Mike that I posted to comp.theory responded
at the wrong point in Mike's words thus this V2 version.
*I read and reread what is said to catch any mistakes*
 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
 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 can only talk about Computable Funcitons, and in fact, one of the goals of Computation Theory is figuring out the boundry between Computable and Non-Computable Functions.
I don't know where you get that simulating halt deciders are rejected out-of-hand, as they are one of the standard methods for implementing partial halt deciders, which decide on many simple/normal cases, but are allowed to not answer for the more complicated cases.
They are rejected out of hand as full halt-deciders as it can be proven that there is no such thing. And simulation alone can NOT be the answer, as simulation alone will take unbounded time to decide on a non-halting machine,.
Just repeating your lies doesn't make them more apt to be true.
It just proves that you do not care about the truth and are too stupid to understand how you are wrong.
Not reposonding to your rebuttals just shows that you understand you are wrong, and can't come up with any good lies to try to defend it.

Date Sujet#  Auteur
25 May 24 * Addressing the only rebuttal of my proof in the last two years (correction)2olcott
25 May 24 `- Re: Addressing the only rebuttal of my proof in the last two years (correction)1Richard Damon

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal