Groups | Search | Server Info | Login | Register
| Subject | Re: Refutation of the Ben Bacarisse Rebuttal |
|---|---|
| Newsgroups | comp.theory, sci.logic, comp.ai.philosophy |
| References | <u6qell$25lfs$1@dont-email.me> |
| From | Richard Damon <Richard@Damon-Family.org> |
| Message-ID | <rE6kM.5962$zcM5.3620@fx11.iad> (permalink) |
| Organization | Forte - www.forteinc.com |
| Date | 2023-06-19 20:45 -0400 |
Cross-posted to 3 groups.
On 6/19/23 4:43 PM, olcott wrote:
> The behavior of the directly executed P(P) is different than the
> behavior of P(P) correctly simulated by H because in the first case H
> has already aborted its simulation of its input and in the second case
> this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the direct
execution of the machine, so all you are saying that H has shut its eyes
and said "I don't see it, so it didn't happen".
That is just FALSEHOOD.
>
> I now refer to P(P) as D(D).
>
> Can D correctly simulated by H terminate normally?
> No it cannot see the details below.
Which is not the question being asked. The fact that it is impossible to
design an H that can correctly simulate its input to a halting state
just proves that H can not correctly decider that its input is Halting.
This does NOT mean that the input can't be Halting, just that H can
never prove it.
IF H doesn't ever abort its simulation, then yes, the D built on that H
is non-halting, but that H never gives that answer, so it is still wrong.
Each H gets a DIFFERENT D, since they include the H that the
"pathological test" is to be performed on, so the behavior of one D
built on a different H doesn't apply, and for correct reasoning, you
really need to give each one a different name. Reusing the same name for
different machine, and then trying to confuse which one is which is just
a sign of being intentionally deceptive to try to tell a LIE.
>
> The x86utm operating system based on an open source x86 emulator. This
> system enables one C function to execute another C function in debug
> step mode. When H simulates D it creates a separate process context for
> D with its own memory, stack and virtual registers. H is able to
> simulate D simulating itself, thus the only limit to recursive
> simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code space with
H, which means it fails to be truely distinctly, like a Turing Machine
would be.
It is NOT a full "separate process context" as all the contexts share
code space.
>
> // The following is written in C
> //
> 01 typedef int (*ptr)(); // pointer to int function
> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
> 03
> 04 int D(ptr x)
> 05 {
> 06 int Halt_Status = H(x, x);
> 07 if (Halt_Status)
> 08 HERE: goto HERE;
> 09 return Halt_Status;
> 10 }
> 11
> 12 void main()
> 13 {
> 14 D(D);
> 15 }
>
> D correctly simulated by H cannot possibly terminate normally by
> reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at least as long
as you are using an H that answer H(D,D) as 0, as you claim.
Thus, you H never DOES a correct simulation, so it answering based on a
false premise.
>
> We can easily fix what Ben has misconstrued as a contradiction by
> defining the return value of 0 from H as meaning:
> (a) the input does not halt <or>
ANd thus admit that you are lying about working on the Halting Problem,
since that doesn't have a (b) term, PERIOD.
> (b) the input is defined to have a pathological relationship to H.
Which you can't define in a way that you H actually handles.
>
> Since it is true that D was defined to do the opposite of whatever
> Boolean value that H returns H is correct to return 0.
>
> *Termination Analyzer H is Not Fooled by Pathological Input D*
> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>
>
FAIL.
Back to comp.theory | Previous | Next — Previous in thread | Next in thread | Find similar
Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-19 15:43 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-19 20:45 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-19 20:02 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <news.x.richarddamon@xoxy.net> - 2023-06-19 21:13 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-19 22:46 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 07:19 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 10:02 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 11:48 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 12:46 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 14:20 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 13:33 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 16:32 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 15:38 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 16:46 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 16:27 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 17:56 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 17:19 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 18:52 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 17:59 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 20:41 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 20:36 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 22:32 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 21:59 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-21 07:38 -0400
Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-21 12:32 -0500
Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-21 19:01 -0400
Re: Refutation of [nothing] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-06-20 12:48 +0100
Ben Bacarisse specifically targets my posts to discourage honest dialogue ... olcott <polcott2@gmail.com> - 2023-06-20 10:03 -0500
Re: Refutation of [nothing] (Ben Bacarisse lies about this see below) olcott <polcott2@gmail.com> - 2023-06-22 13:00 -0500
Re: Refutation of [nothing] (Peter Olcott lies about this see below) Richard Damon <Richard@Damon-Family.org> - 2023-06-22 21:06 -0400
csiph-web