Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Latest revision of my paper incorporating feedback --- last
 remaining sticking point FAILED.
Date: Tue, 6 Aug 2024 21:39:02 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <9dadc4e2182207ca5ca9065afb062791e3df7217@i2pn2.org>
References: <v8tcqm$1l0av$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 7 Aug 2024 01:39:02 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1715116"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v8tcqm$1l0av$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5335
Lines: 109

On 8/6/24 10:43 AM, olcott wrote:
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> int main()
> {
>    HHH(DDD);
> }
> 
> Understanding that DDD correctly simulated by HHH cannot
> possibly reach its own "return" instruction is a mandatory
> prerequisite to further discussion.

BUt ONLY the DDD that calls the HHH that ACTUALLY correct simulates it 
input, and thus never aborts.


> 
> I can't imagine that anyone having sufficient understanding
> of C would not agree that DDD correctly simulated by HHH
> cannot possibly reach its own "return" instruction. Several
> C experts already agreed to this two of them having masters
> in computer science: MSCS.

But ONLY for the HHH that ACTUALLY correctly simulates its input, and 
thus does not abort it.

> 
> People are either disagreeing for trollish pleasure or have
> woefully insufficient expertise in the C programming language.
> *Either one of these is a deal killer*

No, just pointing out that you are then trying to CHANGE you HHH to 
break your own definition of what HHH is.

> 
> Once they understand this we need to add one more point
> that the "return" instruction of DDD is its halt state.
> 
> === *Here is the last actual sticking point*
> 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
> 
> A halt decider computes the mapping from an input finite string
> to the behavior that this finite string specifies. No halt decider
> ever reports on the actual behavior of the computation that itself
> is contained within. This has been a very persistent false assumption.

Right, they compute the answer of what the input actually maps to.

For "Halting" that is does the behavior of the ACTUAL PROGRAM 
represented by the input reach its final state.

> 
> For the three years that my work has been extensively reviewed
> this has been the most difficult point for people to understand.

Because you insist that an INCORECT (because it is partial) simulation 
of the input defines what the program does

> 
> Everyone remains convinced that HHH must report on the behavior
> of the computation that itself is contained within and not the
> behavior that its finite string input specifies.

Because that *IS* what its input ask it.

Why shouldn't it answer about what it is asked?

> 
> 
> 
> Simulating Termination Analyzer H is Not Fooled by Pathological Input D
> https://www.researchgate.net/publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
> 

But the input DDD includes the HHH that it calls, or it isn't a full 
description of the program DDD. (As you say, you can't ask about "the 
simulator deciding you" only about a specific decider, which might be 
the one you are given to).

SInce that HHH DOES ABORT, as at the end you claim that is what it 
"correctly" does, then the claim of the repeatitive loop is just 
incorret, as there *IS* a condition in the loop, within the HHH that DDD 
calls. HHH needs to take that into account, which it does not, and thus 
does not CORRECTLY emulate the behavior of DDD>

Rmember, *ONE* mistake, no matter how small, make the anwer incorret, 
and thus HHH isn't if fails to exactly reproduce the actual behavior of 
the input, be it by not actually emulating the code of HHH when DDD 
calls it, or by stopping its emulation, when the behavior of the 
instruction says that execution continues, has made a mistake, and thus 
has given an incorrect answer.

THe fact that the direct exection of DDD calling this HHH, or the actual 
complete emulation of this DDD calling THIS HHH by an emulator that 
doesn't give ups shows that DDD calls HHH that will eventually give up 
and return, shows that DDD *IS* a Halting Computation and thus HHH is 
wrong, and you are nothing but a pathetic ignorant pathological lying 
idiot with a reckless disregard for the truth because you just ignore 
that fact.

Sorry, but you have just killed your reputation by your self imposed 
stupidity.