Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Men of peace usually are [brave]. -- Spock, "The Savage Curtain", stardate 5906.5


computers / comp.ai.philosophy / Re: Are my reviewers dishonest or technically incompetent ?

SubjectAuthor
* Are my reviewers dishonest or technically incompetent ?olcott
+* Re: Are my reviewers dishonest or technically incompetent ?Mr Flibble
|`* Re: Are my reviewers dishonest or technically incompetent ?olcott
| `* Re: Are my reviewers dishonest or technically incompetent ?Mr Flibble
|  `- Re: Are my reviewers dishonest or technically incompetent ?olcott
+* Re: Are my reviewers dishonest or technically incompetent ?Richard Damon
|`* Re: Are my reviewers dishonest or technically incompetent ?olcott
| `* Re: Are my reviewers dishonest or technically incompetent ?Richard Damon
|  +* Re: Are my reviewers dishonest or technically incompetent ?Richard Damon
|  |`* Re: Are my reviewers dishonest or technically incompetent ?olcott
|  | `- Re: Are my reviewers dishonest or technically incompetent ?Richard Damon
|  +- Re: Are my reviewers dishonest or technically incompetent ?olcott
|  `* Re: Are my reviewers dishonest or technically incompetent ?olcott
|   `- Re: Are my reviewers dishonest or technically incompetent ?Python
`* Re: Are my reviewers dishonest or technically incompetent ?olcott
 `- Re: Are my reviewers dishonest or technically incompetent ?Richard Damon

1
Are my reviewers dishonest or technically incompetent ?

<4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8895&group=comp.ai.philosophy#8895

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.lang.c comp.lang.c++
Followup: comp.theory,comp.ai.philosophy,comp.software-eng,sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 May 2022 13:00:32 -0500
Date: Sun, 22 May 2022 13:00:31 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Newsgroups: comp.theory,comp.ai.philosophy,comp.lang.c,comp.lang.c++
Content-Language: en-US
Followup-To: comp.theory,comp.ai.philosophy,comp.software-eng,sci.logic
From: NoO...@NoWhere.com (olcott)
Subject: Are my reviewers dishonest or technically incompetent ?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 219
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-CSVKCR8kwJb1+jmwqqAUAbGUqnr6OGu48P5Pg0UYY6gWIHUmvi1wHAxN6zN6GN17ZjzPD1oGki1lY5K!DsU0gNNoqn5wk+iq4L2JTD0e2KIN4nA2ZoPAQgY3Td947tA5n+4TJn0kWt/qs+i2+fj6ibI5Ge4=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 10972
 by: olcott - Sun, 22 May 2022 18:00 UTC

That H(P,P)==0 is easily verified as correct by reverse engineering what
the behavior of the input to H(P,P) would be if we assume that H
performs a pure x86 emulation of its input. The x86 source-code of P
specifies everything that we need to know to do this.

It is dead obvious that when H(P,P) correctly emulates its input that
the first 7 instructions of P are emulated.

It is also dead obvious that when P calls H(P,P) that H emulates the
first 7 instructions of P again.

This makes it dead obvious that the correct x86 emulation of the input
to H(P,P) never reaches its last instruction and halts.

Because all of my reviewers have consistently denied this easily
verified fact for six months it seems unreasonable to believe that this
is an honest mistake.

This is an explanation of a key new insight into the halting problem
provided in the language of software engineering. Technical computer
science terms are explained using software engineering terms.

To fully understand this paper a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level. No knowledge of the halting problem is
required.

The computer science term “halting” means that a Turing Machine
terminated normally reaching its last instruction known as its “final
state”. This is the same idea as when a function returns to its caller
as opposed to and contrast with getting stuck in an infinite loop or
infinite recursion.

In computability theory, the halting problem is the problem of
determining,
from a description of an arbitrary computer program and an input,
whether
the program will finish running, or continue to run forever. Alan
Turing proved
in 1936 that a general algorithm to solve the halting problem for
all possible
program-input pairs cannot exist.

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

Technically a halt decider is a program that computes the mapping from a
pair of input finite strings to its own accept or reject state based on
the actual behavior specified by these finite strings. In other words
it determines whether or not its input would halt and returns 0 or 1
accordingly.

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

The most definitive way to determine the actual behavior of the actual
input is to simply simulate this input and watch its behavior. This is
the ultimate measure of the actual behavior of the input. A simulating
halt decider (SHD) simulates its input and determines the halt status of
this input on the basis of the behavior of this correctly simulated of
its input.

The x86utm operating system was created so that all of the details of
the the halting problem counter-example could be examined at the much
higher level of abstraction of the C/x86 computer languages. It is based
on a very powerful x86 emulator.

The function named P was defined to do the opposite of whatever H
reports that it will do. If H(P,P) reports that its input halts, P
invokes an infinite loop. If H(P,P) reports that its input is
non-halting, P immediately halts.

The technical computer science term "halt" means that a program will
reach its last instruction technically called its final state. For P
this would be its machine address [0000136c].

H simulates its input one x86 instruction at a time using an x86
emulator. As soon as H(P,P) detects the same infinitely repeating
pattern (that we can all see), it aborts its simulation and rejects its
input.

Anyone that is an expert in the C programming language, the x86
programming language, exactly how C translates into x86 and what an x86
processor emulator is can easily verify that the correctly simulated
input to H(P,P) by H specifies a non-halting sequence of configurations.

Software engineering experts can reverse-engineer what the correct x86
emulation of the input to H(P,P) would be for one emulation and one
nested emulation thus confirming that the provided execution trace is
correct. They can do this entirely on the basis of the x86 source-code
for P with no need to see the source-code or execution trace of H.

The function named H continues to simulate its input using an x86
emulator until this input either halts on its own or H detects that it
would never halt. If its input halts H returns 1. If H detects that its
input would never halt H returns 0.

#include <stdint.h>
#define u32 uint32_t

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion (infinitely nested simulation) non-halting behavior pattern.

....[00001384][0010229e][00000000] 83c408 add esp,+08
....[00001387][0010229a][00000000] 50 push eax
....[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
....[00001392][0010229e][00000000] 83c408 add esp,+08
....[00001395][0010229e][00000000] 33c0 xor eax,eax
....[00001397][001022a2][00100000] 5d pop ebp
....[00001398][001022a6][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(15892) = 237 pages

The correct simulation of the input to H(P,P) and the direct execution
of P(P) are not computationally equivalent thus need not have the same
halting behavior.


Click here to read the complete article
Re: Are my reviewers dishonest or technically incompetent ?

<20220522190556.000035ba@reddwarf.jmc>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8896&group=comp.ai.philosophy#8896

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx01.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.logic
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Message-ID: <20220522190556.000035ba@reddwarf.jmc>
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 12
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 22 May 2022 18:05:55 UTC
Date: Sun, 22 May 2022 19:05:56 +0100
X-Received-Bytes: 1206
 by: Mr Flibble - Sun, 22 May 2022 18:05 UTC

On Sun, 22 May 2022 13:00:31 -0500
olcott <NoOne@NoWhere.com> wrote:
> H sees that P is calling the same function from the same machine
> address with identical parameters, twice in sequence. This is the
> infinite recursion (infinitely nested simulation) non-halting
> behavior pattern.

The proofs you are attempting to refute doe not have any infinite
recursion thus you continue to bark up the wrong tree.

/Flibble

Re: Are my reviewers dishonest or technically incompetent ?

<m_WdneJRE78I4hf_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8897&group=comp.ai.philosophy#8897

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 May 2022 13:23:17 -0500
Date: Sun, 22 May 2022 13:23:16 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.logic
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<20220522190556.000035ba@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220522190556.000035ba@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <m_WdneJRE78I4hf_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 30
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-rI9JENfbyYLxE6qZkY7J6Ii/qXm4MEt5nqUyAgh45QsXQQnWXAJi7ZVD7G2+LAjsJKWSLaebVT6xoM6!q6xBtC3qykT4NjUjV1nvWEX4LahTK7Q8cKUB96MEWSYsI7iF96C7WhcfxGEr0HktPlyQblEB8yA=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2418
 by: olcott - Sun, 22 May 2022 18:23 UTC

On 5/22/2022 1:05 PM, Mr Flibble wrote:
> On Sun, 22 May 2022 13:00:31 -0500
> olcott <NoOne@NoWhere.com> wrote:
>> H sees that P is calling the same function from the same machine
>> address with identical parameters, twice in sequence. This is the
>> infinite recursion (infinitely nested simulation) non-halting
>> behavior pattern.
>
> The proofs you are attempting to refute doe not have any infinite
> recursion thus you continue to bark up the wrong tree.
>
> /Flibble
>

So you simply guess that you must be correct and totally ignore my proof
that you are not. My paper shows how every conventional HP proof is
refuted on the basis that the input to H(P,P) (and its TM equivalents)
specifies infinitely nested simulation to its halt decider.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

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

Re: Are my reviewers dishonest or technically incompetent ?

<20220522192659.00001bc9@reddwarf.jmc>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8898&group=comp.ai.philosophy#8898

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx01.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.logic
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Message-ID: <20220522192659.00001bc9@reddwarf.jmc>
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<20220522190556.000035ba@reddwarf.jmc>
<m_WdneJRE78I4hf_nZ2dnUU7_8zNnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 28
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 22 May 2022 18:26:59 UTC
Date: Sun, 22 May 2022 19:26:59 +0100
X-Received-Bytes: 1784
 by: Mr Flibble - Sun, 22 May 2022 18:26 UTC

On Sun, 22 May 2022 13:23:16 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/22/2022 1:05 PM, Mr Flibble wrote:
> > On Sun, 22 May 2022 13:00:31 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >> H sees that P is calling the same function from the same machine
> >> address with identical parameters, twice in sequence. This is the
> >> infinite recursion (infinitely nested simulation) non-halting
> >> behavior pattern.
> >
> > The proofs you are attempting to refute doe not have any infinite
> > recursion thus you continue to bark up the wrong tree.
> >
> > /Flibble
> >
>
> So you simply guess that you must be correct and totally ignore my
> proof that you are not. My paper shows how every conventional HP
> proof is refuted on the basis that the input to H(P,P) (and its TM
> equivalents) specifies infinitely nested simulation to its halt
> decider.

But they don't though: it is YOU who is introducing the idea of an
erroneous infinitely nested simulation.

/Flibble

Re: Are my reviewers dishonest or technically incompetent ?

<WiviK.2811$vAW9.2803@fx10.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8899&group=comp.ai.philosophy#8899

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx10.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.1
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 350
Message-ID: <WiviK.2811$vAW9.2803@fx10.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 22 May 2022 14:30:14 -0400
X-Received-Bytes: 15363
 by: Richard Damon - Sun, 22 May 2022 18:30 UTC

On 5/22/22 2:00 PM, olcott wrote:
> That H(P,P)==0 is easily verified as correct by reverse engineering what
> the behavior of the input to H(P,P) would be if we assume that H
> performs a pure x86 emulation of its input. The x86 source-code of P
> specifies everything that we need to know to do this.

So, you are doing an analysis based on the assumption that an H CAN
correct simulate its input AND answer at the same time?

Until your prove that such an H can exist, you need to be very careful
what you derive from this analysis.

>
> It is dead obvious that when H(P,P) correctly emulates its input that
> the first 7 instructions of P are emulated.
>
> It is also dead obvious that when P calls H(P,P) that H emulates the
> first 7 instructions of P again.
>

But that wouldn't actually happen!!!

P calls H, so H needs to emulate the code of H since that is what is
actually executing.

THAT is a "Correct Simulation".

Only an H that wasn't actually a computation, but somehow collesed calls
to itself in its simulation would do anyting like that, but that means
that H fails to be an actual computation itself, and thus not eligable
to be a decider.

> This makes it dead obvious that the correct x86 emulation of the input
> to H(P,P) never reaches its last instruction and halts.

Starting from an incorrect definition of a "Correct Trace" leads to garbage.

>
> Because all of my reviewers have consistently denied this easily
> verified fact for six months it seems unreasonable to believe that this
> is an honest mistake.

Because what you claim isn't what actually happens. At least not in the
space that you claim to be working in.

You just repeat the claims, you never actually show that the rebutals
are incorrect. That just proves your own ignorance.

>
> This is an explanation of a key new insight into the halting problem
> provided in the language of software engineering. Technical computer
> science terms are explained using software engineering terms.

Then actually provide the actual definition of the term you are claiming
make things clear.

>
> To fully understand this paper a software engineer must be an expert in:
> the C programming language, the x86 programming language, exactly how C
> translates into x86 and the ability to recognize infinite recursion at
> the x86 assembly language level. No knowledge of the halting problem is
> required.
>

> The computer science term “halting” means that a Turing Machine
> terminated normally reaching its last instruction known as its “final
> state”. This is the same idea as when a function returns to its caller
> as opposed to and contrast with getting stuck in an infinite loop or
> infinite recursion.

Ok. since P(P) Halts, why is H(P,P) == 0 not wrong, since H(P,P) is
supposed to be asking about the PROGRAM P, not some mythical behavior of
the input.

>
>      In computability theory, the halting problem is the problem of
> determining,
>      from a description of an arbitrary computer program and an input,
> whether
>      the program will finish running, or continue to run forever. Alan
> Turing proved
>      in 1936 that a general algorithm to solve the halting problem for
> all possible
>      program-input pairs cannot exist.

Right, H(P,P) is to determine if P(P) Halts.

Since P(P) Halts, the answer H(P,P) == 0 must be incorrect.

>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem

Yep, that is the proof that you can't make an actual decider compute the
Halting Function.

>
> Technically a halt decider is a program that computes the mapping from a
> pair of input finite strings to its own accept or reject state based on
> the actual behavior specified by these finite strings.  In other words
> it determines whether or not its input would halt and returns 0 or 1
> accordingly.

Right, an Arbitrary decide just needs to always halt on all input to
create a mapping of input to outputs.

To be a "Something" Decider, that mapping must match the "Something"
function as defined.

>
>      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
>
> The most definitive way to determine the actual behavior of the actual
> input is to simply simulate this input and watch its behavior. This is
> the ultimate measure of the actual behavior of the input. A simulating
> halt decider (SHD) simulates its input and determines the halt status of
> this input on the basis of the behavior of this correctly simulated of
> its input.

Ok, but if the correct simulation of the input takes longer that the SHD
allows, it doesn't get the data it needs to make the decision.

It has been shown that if you SHD runs until it can actually PROVE that
it has the right answer, it will NEVER halt on the input P,P where P is
built on this "contrary" pattern.

You haven't even TRIED to prove that you can will reach an answer in
finite time.

>
> The x86utm operating system was created so that all of the details of
> the the halting problem counter-example could be examined at the much
> higher level of abstraction of the C/x86 computer languages. It is based
> on a very powerful x86 emulator.

Ok.
>
> The function named P was defined to do the opposite of whatever H
> reports that it will do. If H(P,P) reports that its input halts, P
> invokes an infinite loop. If H(P,P) reports that its input is
> non-halting, P immediately halts.

Right, which shows that H was wrong.

The only way that H(P,P) == 0 is correct, is if P(P) runs forever and
never halts.

The fact that it halt, PROVES that H was wrong.

>
> The technical computer science term "halt" means that a program will
> reach its last instruction technically called its final state. For P
> this would be its machine address [0000136c].

Which it does, for an ACTUALLY RUN P.

There is NO requriement that H be able to simulate to that point.

>
> H simulates its input one x86 instruction at a time using an x86
> emulator. As soon as H(P,P) detects the same infinitely repeating
> pattern (that we can all see), it aborts its simulation and rejects its
> input.

And there is NO finite pattern that exists that proves that fact.

ANY pattern you claim is such a pattern, when programmed into H, makes
the actual execution of P(P) Halt, and thus is incorret.

>
> Anyone that is an expert in the C programming language, the x86
> programming language, exactly how C translates into x86 and what an x86
> processor emulator is can easily verify that the correctly simulated
> input to H(P,P) by H specifies a non-halting sequence of configurations.

Nope. It is easy to verify that if H(P,P) is defined to return 0 after a
finite time, that P(P) will Halt.

>
> Software engineering experts can reverse-engineer what the correct x86
> emulation of the input to H(P,P) would be for one emulation and one
> nested emulation thus confirming that the provided execution trace is
> correct. They can do this entirely on the basis of the x86 source-code
> for P with no need to see the source-code or execution trace of H.

Ok, so we have the trace of the first emulation, and a trace of the
second, both of them show that P(P) calls H(P,P) and is waiting for an
answer.

>
> The function named H continues to simulate its input using an x86
> emulator until this input either halts on its own or H detects that it
> would never halt. If its input halts H returns 1. If H detects that its
> input would never halt H returns 0.

So you have the contradiction. If H returns 0, it shows that ALL the
P(P)'s will Halt.

If H doesn't return 0, it shows that it doesn't answer for that input,
and thus fails.

It is invalid logic to use a different H for doing the actual decision
an to build P from, they need to be EXACT copies and actual
computations, thus ALL copies do the same thing.

>
> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352 // push P
> [0000137a](05)  6852130000      push 00001352 // push P
> [0000137f](05)  e81efeffff      call 000011a2 // call H
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55         push ebp
> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H


Click here to read the complete article
Re: Are my reviewers dishonest or technically incompetent ?

<kPOdncUWZ7z9HBf_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8900&group=comp.ai.philosophy#8900

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 May 2022 13:30:56 -0500
Date: Sun, 22 May 2022 13:30:55 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.logic
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<20220522190556.000035ba@reddwarf.jmc>
<m_WdneJRE78I4hf_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220522192659.00001bc9@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220522192659.00001bc9@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <kPOdncUWZ7z9HBf_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 60
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-PZBnWegsGfbEYxJzKEPlSVMc8NSbiHZFAygkOSaam5y3aZNqeaJ2v1X0NZywkUemNpwM8A5Zbt/AjmE!Opv6KalDzcEY2LQ31g9QASivYiU3TTj5us6EJ7T3pPkl4S6n7Ssh6V4VtAhoooHkLqkQeGHxpnM=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3453
 by: olcott - Sun, 22 May 2022 18:30 UTC

On 5/22/2022 1:26 PM, Mr Flibble wrote:
> On Sun, 22 May 2022 13:23:16 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/22/2022 1:05 PM, Mr Flibble wrote:
>>> On Sun, 22 May 2022 13:00:31 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>> H sees that P is calling the same function from the same machine
>>>> address with identical parameters, twice in sequence. This is the
>>>> infinite recursion (infinitely nested simulation) non-halting
>>>> behavior pattern.
>>>
>>> The proofs you are attempting to refute doe not have any infinite
>>> recursion thus you continue to bark up the wrong tree.
>>>
>>> /Flibble
>>>
>>
>> So you simply guess that you must be correct and totally ignore my
>> proof that you are not. My paper shows how every conventional HP
>> proof is refuted on the basis that the input to H(P,P) (and its TM
>> equivalents) specifies infinitely nested simulation to its halt
>> decider.
>
> But they don't though: it is YOU who is introducing the idea of an
> erroneous infinitely nested simulation.
>
> /Flibble
>

It is an easily verifiable fact that the C function H does correctly
determine that the C function named P would never reach its last
instruction when correctly emulated by H.

That you would disagree with verified facts makes you either technically
incompetent or a liar.

It is dead obvious that when H(P,P) correctly emulates its input that
the first 7 instructions of P are emulated.

It is also dead obvious that when P calls H(P,P) that H emulates the
first 7 instructions of P again.

This makes it dead obvious that the correct x86 emulation of the input
to H(P,P) never reaches its last instruction and halts.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

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

Re: Are my reviewers dishonest or technically incompetent ?

<sJmdnbZKbOK5GRf_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8901&group=comp.ai.philosophy#8901

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 May 2022 13:42:44 -0500
Date: Sun, 22 May 2022 13:42:43 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<WiviK.2811$vAW9.2803@fx10.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <WiviK.2811$vAW9.2803@fx10.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <sJmdnbZKbOK5GRf_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 367
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-B0f4cLW8RTaZotW2JOqAqJVrwaGNW++tVdxSNHLnzfW7zu0YID/SOwugWw//riq203GFyMLGfXUmoLj!KMN5GVxWCVdP+lkkI7F8Jx0EAeK8xc3EQNfqfsoCvQp6b7qh3qygNndUHbePkRX2MfRNjQrZnfA=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 16509
 by: olcott - Sun, 22 May 2022 18:42 UTC

On 5/22/2022 1:30 PM, Richard Damon wrote:
> On 5/22/22 2:00 PM, olcott wrote:
>> That H(P,P)==0 is easily verified as correct by reverse engineering
>> what the behavior of the input to H(P,P) would be if we assume that H
>> performs a pure x86 emulation of its input. The x86 source-code of P
>> specifies everything that we need to know to do this.
>
> So, you are doing an analysis based on the assumption that an H CAN
> correct simulate its input AND answer at the same time?
>
> Until your prove that such an H can exist, you need to be very careful
> what you derive from this analysis.
>
>>
>> It is dead obvious that when H(P,P) correctly emulates its input that
>> the first 7 instructions of P are emulated.
>>
>> It is also dead obvious that when P calls H(P,P) that H emulates the
>> first 7 instructions of P again.
>>
>
> But that wouldn't actually happen!!!
>
> P calls H, so H needs to emulate the code of H since that is what is
> actually executing.
>
> THAT is a "Correct Simulation".
>

Yes that is true, none-the-less we don't need to actually see the 237
pages of the emulation of H to know that this H must also emulate the
first 7 instructions of P.

> Only an H that wasn't actually a computation, but somehow collesed calls
> to itself in its simulation would do anyting like that, but that means
> that H fails to be an actual computation itself, and thus not eligable
> to be a decider.
>
>> This makes it dead obvious that the correct x86 emulation of the input
>> to H(P,P) never reaches its last instruction and halts.
>
> Starting from an incorrect definition of a "Correct Trace" leads to
> garbage.
>
>>
>> Because all of my reviewers have consistently denied this easily
>> verified fact for six months it seems unreasonable to believe that
>> this is an honest mistake.
>
>
> Because what you claim isn't what actually happens. At least not in the
> space that you claim to be working in.
>
> You just repeat the claims, you never actually show that the rebutals
> are incorrect. That just proves your own ignorance.
>
>>
>> This is an explanation of a key new insight into the halting problem
>> provided in the language of software engineering. Technical computer
>> science terms are explained using software engineering terms.
>
> Then actually provide the actual definition of the term you are claiming
> make things clear.
>
>>
>> To fully understand this paper a software engineer must be an expert
>> in: the C programming language, the x86 programming language, exactly
>> how C translates into x86 and the ability to recognize infinite
>> recursion at the x86 assembly language level. No knowledge of the
>> halting problem is required.
>>
>
>
>
>> The computer science term “halting” means that a Turing Machine
>> terminated normally reaching its last instruction known as its “final
>> state”. This is the same idea as when a function returns to its caller
>> as opposed to and contrast with getting stuck in an infinite loop or
>> infinite recursion.
>
> Ok. since P(P) Halts, why is H(P,P) == 0 not wrong, since H(P,P) is
> supposed to be asking about the PROGRAM P, not some mythical behavior of
> the input.
>
>>
>>       In computability theory, the halting problem is the problem of
>> determining,
>>       from a description of an arbitrary computer program and an
>> input, whether
>>       the program will finish running, or continue to run forever.
>> Alan Turing proved
>>       in 1936 that a general algorithm to solve the halting problem
>> for all possible
>>       program-input pairs cannot exist.
>
> Right, H(P,P) is to determine if P(P) Halts.
>
> Since P(P) Halts, the answer H(P,P) == 0 must be incorrect.
>
>>
>>       For any program H that might determine if programs halt, a
>> "pathological"
>>       program P, called with some input, can pass its own source and
>> its input to
>>       H and then specifically do the opposite of what H predicts P
>> will do. No H
>>       can exist that handles this case.
>> https://en.wikipedia.org/wiki/Halting_problem
>
> Yep, that is the proof that you can't make an actual decider compute the
> Halting Function.
>
>>
>> Technically a halt decider is a program that computes the mapping from
>> a pair of input finite strings to its own accept or reject state based
>> on the actual behavior specified by these finite strings.  In other
>> words it determines whether or not its input would halt and returns 0
>> or 1 accordingly.
>
> Right, an Arbitrary decide just needs to always halt on all input to
> create a mapping of input to outputs.
>
> To be a "Something" Decider, that mapping must match the "Something"
> function as defined.
>
>>
>>       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
>>
>> The most definitive way to determine the actual behavior of the actual
>> input is to simply simulate this input and watch its behavior. This is
>> the ultimate measure of the actual behavior of the input. A simulating
>> halt decider (SHD) simulates its input and determines the halt status
>> of this input on the basis of the behavior of this correctly simulated
>> of its input.
>
> Ok, but if the correct simulation of the input takes longer that the SHD
> allows, it doesn't get the data it needs to make the decision.
>
> It has been shown that if you SHD runs until it can actually PROVE that
> it has the right answer, it will NEVER halt on the input P,P where P is
> built on this "contrary" pattern.
>
> You haven't even TRIED to prove that you can will reach an answer in
> finite time.
>
>>
>> The x86utm operating system was created so that all of the details of
>> the the halting problem counter-example could be examined at the much
>> higher level of abstraction of the C/x86 computer languages. It is
>> based on a very powerful x86 emulator.
>
> Ok.
>>
>> The function named P was defined to do the opposite of whatever H
>> reports that it will do. If H(P,P) reports that its input halts, P
>> invokes an infinite loop. If H(P,P) reports that its input is
>> non-halting, P immediately halts.
>
> Right, which shows that H was wrong.
>
> The only way that H(P,P) == 0 is correct, is if P(P) runs forever and
> never halts.
>
> The fact that it halt, PROVES that H was wrong.
>
>>
>> The technical computer science term "halt" means that a program will
>> reach its last instruction technically called its final state. For P
>> this would be its machine address [0000136c].
>
> Which it does, for an ACTUALLY RUN P.
>
> There is NO requriement that H be able to simulate to that point.
>
>>
>> H simulates its input one x86 instruction at a time using an x86
>> emulator. As soon as H(P,P) detects the same infinitely repeating
>> pattern (that we can all see), it aborts its simulation and rejects
>> its input.
>
> And there is NO finite pattern that exists that proves that fact.
>
> ANY pattern you claim is such a pattern, when programmed into H, makes
> the actual execution of P(P) Halt, and thus is incorret.
>
>>
>> Anyone that is an expert in the C programming language, the x86
>> programming language, exactly how C translates into x86 and what an
>> x86 processor emulator is can easily verify that the correctly
>> simulated input to H(P,P) by H specifies a non-halting sequence of
>> configurations.
>
> Nope. It is easy to verify that if H(P,P) is defined to return 0 after a
> finite time, that P(P) will Halt.
>
>
>>
>> Software engineering experts can reverse-engineer what the correct x86
>> emulation of the input to H(P,P) would be for one emulation and one
>> nested emulation thus confirming that the provided execution trace is
>> correct. They can do this entirely on the basis of the x86 source-code
>> for P with no need to see the source-code or execution trace of H.
>
> Ok, so we have the trace of the first emulation, and a trace of the
> second, both of them show that P(P) calls H(P,P) and is waiting for an
> answer.
>
>>
>> The function named H continues to simulate its input using an x86
>> emulator until this input either halts on its own or H detects that it
>> would never halt. If its input halts H returns 1. If H detects that
>> its input would never halt H returns 0.
>
> So you have the contradiction. If H returns 0, it shows that ALL the
> P(P)'s will Halt.
>
> If H doesn't return 0, it shows that it doesn't answer for that input,
> and thus fails.
>
> It is invalid logic to use a different H for doing the actual decision
> an to build P from, they need to be EXACT copies and actual
> computations, thus ALL copies do the same thing.
>
>>
>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> void P(u32 x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> _P()
>> [00001352](01)  55              push ebp
>> [00001353](02)  8bec            mov ebp,esp
>> [00001355](03)  8b4508          mov eax,[ebp+08]
>> [00001358](01)  50              push eax      // push P
>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>> [0000135c](01)  51              push ecx      // push P
>> [0000135d](05)  e840feffff      call 000011a2 // call H
>> [00001362](03)  83c408          add esp,+08
>> [00001365](02)  85c0            test eax,eax
>> [00001367](02)  7402            jz 0000136b
>> [00001369](02)  ebfe            jmp 00001369
>> [0000136b](01)  5d              pop ebp
>> [0000136c](01)  c3              ret
>> Size in bytes:(0027) [0000136c]
>>
>> _main()
>> [00001372](01)  55              push ebp
>> [00001373](02)  8bec            mov ebp,esp
>> [00001375](05)  6852130000      push 00001352 // push P
>> [0000137a](05)  6852130000      push 00001352 // push P
>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>> [00001384](03)  83c408          add esp,+08
>> [00001387](01)  50              push eax
>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>> [00001392](03)  83c408          add esp,+08
>> [00001395](02)  33c0            xor eax,eax
>> [00001397](01)  5d              pop ebp
>> [00001398](01)  c3              ret
>> Size in bytes:(0039) [00001398]
>>
>>      machine   stack     stack     machine    assembly
>>      address   address   data      code       language
>>      ========  ========  ========  =========  =============
>> ...[00001372][0010229e][00000000] 55         push ebp
>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>
>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> And this is the error.
>
> The top level simulation NEVER sees this below, and thus this is a FALSE
> trace.
>
> You just are proving you don't understand what a trace is supposed to show.
>
>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
>> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> H sees that P is calling the same function from the same machine
>> address with identical parameters, twice in sequence. This is the
>> infinite recursion (infinitely nested simulation) non-halting behavior
>> pattern.
>
> If it does, it is using unsound logic, as it is based on false premises.
>
>>
>> ...[00001384][0010229e][00000000] 83c408     add esp,+08
>> ...[00001387][0010229a][00000000] 50         push eax
>> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
>> "Input_Halts = "
>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
>> Input_Halts = 0
>> ...[00001392][0010229e][00000000] 83c408     add esp,+08
>> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
>> ...[00001397][001022a2][00100000] 5d         pop ebp
>> ...[00001398][001022a6][00000004] c3         ret
>> Number_of_User_Instructions(1)
>> Number of Instructions Executed(15892) = 237 pages
>>
>> The correct simulation of the input to H(P,P) and the direct execution
>> of P(P) are not computationally equivalent thus need not have the same
>> halting behavior.
>
> The H is NOT a Halting Decider.
>
> The DEFINITION of a Halting Decider IS that it is answering about the
> behavior of the machine the input represents.
>
> Thus, if H is a Halt Decider, the "behavior of the input", for H(P,P)
> must be exactly P(P).
>
> FAIL.
>
>
>>
>> Halting problem undecidability and infinitely nested simulation (V5)
>>
>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>
>>
>>
>>
>


Click here to read the complete article
Re: Are my reviewers dishonest or technically incompetent ?

<nMxiK.4886$xZtb.2948@fx41.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8903&group=comp.ai.philosophy#8903

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx41.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.1
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<WiviK.2811$vAW9.2803@fx10.iad>
<sJmdnbZKbOK5GRf_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <sJmdnbZKbOK5GRf_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 390
Message-ID: <nMxiK.4886$xZtb.2948@fx41.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 22 May 2022 17:18:08 -0400
X-Received-Bytes: 17603
 by: Richard Damon - Sun, 22 May 2022 21:18 UTC

On 5/22/22 2:42 PM, olcott wrote:
> On 5/22/2022 1:30 PM, Richard Damon wrote:
>> On 5/22/22 2:00 PM, olcott wrote:
>>> That H(P,P)==0 is easily verified as correct by reverse engineering
>>> what the behavior of the input to H(P,P) would be if we assume that H
>>> performs a pure x86 emulation of its input. The x86 source-code of P
>>> specifies everything that we need to know to do this.
>>
>> So, you are doing an analysis based on the assumption that an H CAN
>> correct simulate its input AND answer at the same time?
>>
>> Until your prove that such an H can exist, you need to be very careful
>> what you derive from this analysis.
>>
>>>
>>> It is dead obvious that when H(P,P) correctly emulates its input that
>>> the first 7 instructions of P are emulated.
>>>
>>> It is also dead obvious that when P calls H(P,P) that H emulates the
>>> first 7 instructions of P again.
>>>
>>
>> But that wouldn't actually happen!!!
>>
>> P calls H, so H needs to emulate the code of H since that is what is
>> actually executing.
>>
>> THAT is a "Correct Simulation".
>>
>
> Yes that is true, none-the-less we don't need to actually see the 237
> pages of the emulation of H to know that this H must also emulate the
> first 7 instructions of P.

Right, and then the top level H aborts, so we don't get to see the rest
of the correct simulaiton, which would show this embedded copy of H
simulating the next embedded copy of H for its emulation of those sam e
7 instructions and then aborting its simulation and returning to the P
that called it and that P halting.

THAT is the correct Simulation of the input to H.

H can not do that, because it has been programmed to abort its
simulation at the point it did. But it shows the CORRECT SIMULATION does
halt, and H used faulty logic to deicde that it would not.

The question is NOT can H simulate this input to a Halting State, but
can a CORRECT simulation of this input, with H defined to be what H is,
reach a final state, which it does.

If you want to claim foul and we can't use a different simulator to get
the correct simulation, then that is just saying you aren't doing the
Halting Problem, or that the Halting Problem is impossible to solve
(what the Theorem says).

Remember, Halting is a property of the program P, not the decider H.

>
>> Only an H that wasn't actually a computation, but somehow collesed
>> calls to itself in its simulation would do anyting like that, but that
>> means that H fails to be an actual computation itself, and thus not
>> eligable to be a decider.
>>
>>> This makes it dead obvious that the correct x86 emulation of the
>>> input to H(P,P) never reaches its last instruction and halts.
>>
>> Starting from an incorrect definition of a "Correct Trace" leads to
>> garbage.
>>
>>>
>>> Because all of my reviewers have consistently denied this easily
>>> verified fact for six months it seems unreasonable to believe that
>>> this is an honest mistake.
>>
>>
>> Because what you claim isn't what actually happens. At least not in
>> the space that you claim to be working in.
>>
>> You just repeat the claims, you never actually show that the rebutals
>> are incorrect. That just proves your own ignorance.
>>
>>>
>>> This is an explanation of a key new insight into the halting problem
>>> provided in the language of software engineering. Technical computer
>>> science terms are explained using software engineering terms.
>>
>> Then actually provide the actual definition of the term you are
>> claiming make things clear.
>>
>>>
>>> To fully understand this paper a software engineer must be an expert
>>> in: the C programming language, the x86 programming language, exactly
>>> how C translates into x86 and the ability to recognize infinite
>>> recursion at the x86 assembly language level. No knowledge of the
>>> halting problem is required.
>>>
>>
>>
>>
>>> The computer science term “halting” means that a Turing Machine
>>> terminated normally reaching its last instruction known as its “final
>>> state”. This is the same idea as when a function returns to its
>>> caller as opposed to and contrast with getting stuck in an infinite
>>> loop or infinite recursion.
>>
>> Ok. since P(P) Halts, why is H(P,P) == 0 not wrong, since H(P,P) is
>> supposed to be asking about the PROGRAM P, not some mythical behavior
>> of the input.
>>
>>>
>>>       In computability theory, the halting problem is the problem of
>>> determining,
>>>       from a description of an arbitrary computer program and an
>>> input, whether
>>>       the program will finish running, or continue to run forever.
>>> Alan Turing proved
>>>       in 1936 that a general algorithm to solve the halting problem
>>> for all possible
>>>       program-input pairs cannot exist.
>>
>> Right, H(P,P) is to determine if P(P) Halts.
>>
>> Since P(P) Halts, the answer H(P,P) == 0 must be incorrect.
>>
>>>
>>>       For any program H that might determine if programs halt, a
>>> "pathological"
>>>       program P, called with some input, can pass its own source and
>>> its input to
>>>       H and then specifically do the opposite of what H predicts P
>>> will do. No H
>>>       can exist that handles this case.
>>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> Yep, that is the proof that you can't make an actual decider compute
>> the Halting Function.
>>
>>>
>>> Technically a halt decider is a program that computes the mapping
>>> from a pair of input finite strings to its own accept or reject state
>>> based on the actual behavior specified by these finite strings.  In
>>> other words it determines whether or not its input would halt and
>>> returns 0 or 1 accordingly.
>>
>> Right, an Arbitrary decide just needs to always halt on all input to
>> create a mapping of input to outputs.
>>
>> To be a "Something" Decider, that mapping must match the "Something"
>> function as defined.
>>
>>>
>>>       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
>>>
>>> The most definitive way to determine the actual behavior of the
>>> actual input is to simply simulate this input and watch its behavior.
>>> This is the ultimate measure of the actual behavior of the input. A
>>> simulating halt decider (SHD) simulates its input and determines the
>>> halt status of this input on the basis of the behavior of this
>>> correctly simulated of its input.
>>
>> Ok, but if the correct simulation of the input takes longer that the
>> SHD allows, it doesn't get the data it needs to make the decision.
>>
>> It has been shown that if you SHD runs until it can actually PROVE
>> that it has the right answer, it will NEVER halt on the input P,P
>> where P is built on this "contrary" pattern.
>>
>> You haven't even TRIED to prove that you can will reach an answer in
>> finite time.
>>
>>>
>>> The x86utm operating system was created so that all of the details of
>>> the the halting problem counter-example could be examined at the much
>>> higher level of abstraction of the C/x86 computer languages. It is
>>> based on a very powerful x86 emulator.
>>
>> Ok.
>>>
>>> The function named P was defined to do the opposite of whatever H
>>> reports that it will do. If H(P,P) reports that its input halts, P
>>> invokes an infinite loop. If H(P,P) reports that its input is
>>> non-halting, P immediately halts.
>>
>> Right, which shows that H was wrong.
>>
>> The only way that H(P,P) == 0 is correct, is if P(P) runs forever and
>> never halts.
>>
>> The fact that it halt, PROVES that H was wrong.
>>
>>>
>>> The technical computer science term "halt" means that a program will
>>> reach its last instruction technically called its final state. For P
>>> this would be its machine address [0000136c].
>>
>> Which it does, for an ACTUALLY RUN P.
>>
>> There is NO requriement that H be able to simulate to that point.
>>
>>>
>>> H simulates its input one x86 instruction at a time using an x86
>>> emulator. As soon as H(P,P) detects the same infinitely repeating
>>> pattern (that we can all see), it aborts its simulation and rejects
>>> its input.
>>
>> And there is NO finite pattern that exists that proves that fact.
>>
>> ANY pattern you claim is such a pattern, when programmed into H, makes
>> the actual execution of P(P) Halt, and thus is incorret.
>>
>>>
>>> Anyone that is an expert in the C programming language, the x86
>>> programming language, exactly how C translates into x86 and what an
>>> x86 processor emulator is can easily verify that the correctly
>>> simulated input to H(P,P) by H specifies a non-halting sequence of
>>> configurations.
>>
>> Nope. It is easy to verify that if H(P,P) is defined to return 0 after
>> a finite time, that P(P) will Halt.
>>
>>
>>>
>>> Software engineering experts can reverse-engineer what the correct
>>> x86 emulation of the input to H(P,P) would be for one emulation and
>>> one nested emulation thus confirming that the provided execution
>>> trace is correct. They can do this entirely on the basis of the x86
>>> source-code for P with no need to see the source-code or execution
>>> trace of H.
>>
>> Ok, so we have the trace of the first emulation, and a trace of the
>> second, both of them show that P(P) calls H(P,P) and is waiting for an
>> answer.
>>
>>>
>>> The function named H continues to simulate its input using an x86
>>> emulator until this input either halts on its own or H detects that
>>> it would never halt. If its input halts H returns 1. If H detects
>>> that its input would never halt H returns 0.
>>
>> So you have the contradiction. If H returns 0, it shows that ALL the
>> P(P)'s will Halt.
>>
>> If H doesn't return 0, it shows that it doesn't answer for that input,
>> and thus fails.
>>
>> It is invalid logic to use a different H for doing the actual decision
>> an to build P from, they need to be EXACT copies and actual
>> computations, thus ALL copies do the same thing.
>>
>>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00001352](01)  55              push ebp
>>> [00001353](02)  8bec            mov ebp,esp
>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>> [00001358](01)  50              push eax      // push P
>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000135c](01)  51              push ecx      // push P
>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> [00001362](03)  83c408          add esp,+08
>>> [00001365](02)  85c0            test eax,eax
>>> [00001367](02)  7402            jz 0000136b
>>> [00001369](02)  ebfe            jmp 00001369
>>> [0000136b](01)  5d              pop ebp
>>> [0000136c](01)  c3              ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>> _main()
>>> [00001372](01)  55              push ebp
>>> [00001373](02)  8bec            mov ebp,esp
>>> [00001375](05)  6852130000      push 00001352 // push P
>>> [0000137a](05)  6852130000      push 00001352 // push P
>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>> [00001384](03)  83c408          add esp,+08
>>> [00001387](01)  50              push eax
>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>> [00001392](03)  83c408          add esp,+08
>>> [00001395](02)  33c0            xor eax,eax
>>> [00001397](01)  5d              pop ebp
>>> [00001398](01)  c3              ret
>>> Size in bytes:(0039) [00001398]
>>>
>>>      machine   stack     stack     machine    assembly
>>>      address   address   data      code       language
>>>      ========  ========  ========  =========  =============
>>> ...[00001372][0010229e][00000000] 55         push ebp
>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>
>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>
>> And this is the error.
>>
>> The top level simulation NEVER sees this below, and thus this is a
>> FALSE trace.
>>
>> You just are proving you don't understand what a trace is supposed to
>> show.
>>
>>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
>>> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> H sees that P is calling the same function from the same machine
>>> address with identical parameters, twice in sequence. This is the
>>> infinite recursion (infinitely nested simulation) non-halting
>>> behavior pattern.
>>
>> If it does, it is using unsound logic, as it is based on false premises.
>>
>>>
>>> ...[00001384][0010229e][00000000] 83c408     add esp,+08
>>> ...[00001387][0010229a][00000000] 50         push eax
>>> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
>>> "Input_Halts = "
>>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call
>>> Output
>>> Input_Halts = 0
>>> ...[00001392][0010229e][00000000] 83c408     add esp,+08
>>> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
>>> ...[00001397][001022a2][00100000] 5d         pop ebp
>>> ...[00001398][001022a6][00000004] c3         ret
>>> Number_of_User_Instructions(1)
>>> Number of Instructions Executed(15892) = 237 pages
>>>
>>> The correct simulation of the input to H(P,P) and the direct
>>> execution of P(P) are not computationally equivalent thus need not
>>> have the same halting behavior.
>>
>> The H is NOT a Halting Decider.
>>
>> The DEFINITION of a Halting Decider IS that it is answering about the
>> behavior of the machine the input represents.
>>
>> Thus, if H is a Halt Decider, the "behavior of the input", for H(P,P)
>> must be exactly P(P).
>>
>> FAIL.
>>
>>
>>>
>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>
>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>
>>>
>>>
>>>
>>
>
>


Click here to read the complete article
Re: Are my reviewers dishonest or technically incompetent ?

<kKyiK.24175$5fVf.14299@fx09.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8906&group=comp.ai.philosophy#8906

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx09.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.1
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<WiviK.2811$vAW9.2803@fx10.iad>
<sJmdnbZKbOK5GRf_nZ2dnUU7_8zNnZ2d@giganews.com>
<nMxiK.4886$xZtb.2948@fx41.iad>
<o4qdncfJsIB2Nhf_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <o4qdncfJsIB2Nhf_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 100
Message-ID: <kKyiK.24175$5fVf.14299@fx09.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 22 May 2022 18:24:16 -0400
X-Received-Bytes: 5133
X-Original-Bytes: 5000
 by: Richard Damon - Sun, 22 May 2022 22:24 UTC

On 5/22/22 5:32 PM, olcott wrote:
> On 5/22/2022 4:18 PM, Richard Damon wrote:
>> On 5/22/22 2:42 PM, olcott wrote:
>>> On 5/22/2022 1:30 PM, Richard Damon wrote:
>>>> On 5/22/22 2:00 PM, olcott wrote:
>>>>> That H(P,P)==0 is easily verified as correct by reverse engineering
>>>>> what the behavior of the input to H(P,P) would be if we assume that
>>>>> H performs a pure x86 emulation of its input. The x86 source-code
>>>>> of P specifies everything that we need to know to do this.
>>>>
>>>> So, you are doing an analysis based on the assumption that an H CAN
>>>> correct simulate its input AND answer at the same time?
>>>>
>>>> Until your prove that such an H can exist, you need to be very
>>>> careful what you derive from this analysis.
>>>>
>>>>>
>>>>> It is dead obvious that when H(P,P) correctly emulates its input
>>>>> that the first 7 instructions of P are emulated.
>>>>>
>>>>> It is also dead obvious that when P calls H(P,P) that H emulates
>>>>> the first 7 instructions of P again.
>>>>>
>>>>
>>>> But that wouldn't actually happen!!!
>>>>
>>>> P calls H, so H needs to emulate the code of H since that is what is
>>>> actually executing.
>>>>
>>>> THAT is a "Correct Simulation".
>>>>
>>>
>>> Yes that is true, none-the-less we don't need to actually see the 237
>>> pages of the emulation of H to know that this H must also emulate the
>>> first 7 instructions of P.
>>
>> Right, and then the top level H aborts,
>
>
> *We are not even discussing that part yet. *

But it is a fundamental

> *All that we are doing is verifying this this trace is correct. *

Which it isn't, and has been pointed out many times, but you seem to be
to stupid to understand, or to dishonest to accept.

>
> ***Even when we stay sharply focused on one single point at *
> *a time you cannot seem to ever keep from drifting off topic. *

Truth is not limited to just a single point at a time.

That is the way of the carefully crafted lie, that needs to be
approached at just the right angle to avoid seeing the flaws.

>
>
> *Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50 push    eax           // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51 push    ecx           // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

This transition NEVER happens.

The emulator thread that emululates the above never sees the below as
part of the same thread of execution, (or shouldn't) since the CPU
execution the above code never sees the following code, because it is
actually emulated.

> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H*
>
>
> --
>
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer
>

And stupdiity thinks it sees a target that doesn't exist.

Note, Genius can explain the target that it sees, Stupidity can't and
just gets loud and repeative, like Peter Olcoot.

Re: Are my reviewers dishonest or technically incompetent ?

<CaOdnfv6_uXMJBf_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8907&group=comp.ai.philosophy#8907

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 May 2022 17:29:36 -0500
Date: Sun, 22 May 2022 17:29:35 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<WiviK.2811$vAW9.2803@fx10.iad>
<sJmdnbZKbOK5GRf_nZ2dnUU7_8zNnZ2d@giganews.com>
<nMxiK.4886$xZtb.2948@fx41.iad>
<o4qdncfJsIB2Nhf_nZ2dnUU7_83NnZ2d@giganews.com>
<kKyiK.24175$5fVf.14299@fx09.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <kKyiK.24175$5fVf.14299@fx09.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <CaOdnfv6_uXMJBf_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 84
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Qo5W2SlLFBZ0TNnNewAzIrWBlSK2bEZ0vhwJCUW7XxbE8KOnqmEcNNVBIuT2R6z1aowq3xhG9ccWAVB!9ETjajJgcG0wmwQ0BNN4Z5AmIVnxxGq/nyX4+EnyUJwboL2GrmDZpWXrr71OAaZ9NawdLCdciyM=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4858
 by: olcott - Sun, 22 May 2022 22:29 UTC

On 5/22/2022 5:24 PM, Richard Damon wrote:
> On 5/22/22 5:32 PM, olcott wrote:
>> On 5/22/2022 4:18 PM, Richard Damon wrote:
>>> On 5/22/22 2:42 PM, olcott wrote:
>>>> On 5/22/2022 1:30 PM, Richard Damon wrote:
>>>>> On 5/22/22 2:00 PM, olcott wrote:
>>>>>> That H(P,P)==0 is easily verified as correct by reverse
>>>>>> engineering what the behavior of the input to H(P,P) would be if
>>>>>> we assume that H performs a pure x86 emulation of its input. The
>>>>>> x86 source-code of P specifies everything that we need to know to
>>>>>> do this.
>>>>>
>>>>> So, you are doing an analysis based on the assumption that an H CAN
>>>>> correct simulate its input AND answer at the same time?
>>>>>
>>>>> Until your prove that such an H can exist, you need to be very
>>>>> careful what you derive from this analysis.
>>>>>
>>>>>>
>>>>>> It is dead obvious that when H(P,P) correctly emulates its input
>>>>>> that the first 7 instructions of P are emulated.
>>>>>>
>>>>>> It is also dead obvious that when P calls H(P,P) that H emulates
>>>>>> the first 7 instructions of P again.
>>>>>>
>>>>>
>>>>> But that wouldn't actually happen!!!
>>>>>
>>>>> P calls H, so H needs to emulate the code of H since that is what
>>>>> is actually executing.
>>>>>
>>>>> THAT is a "Correct Simulation".
>>>>>
>>>>
>>>> Yes that is true, none-the-less we don't need to actually see the
>>>> 237 pages of the emulation of H to know that this H must also
>>>> emulate the first 7 instructions of P.
>>>
>>> Right, and then the top level H aborts,
>>
>>
>> *We are not even discussing that part yet. *
>
> But it is a fundamental
>
>> *All that we are doing is verifying this this trace is correct. *
>
> Which it isn't, and has been pointed out many times, but you seem to be
> to stupid to understand, or to dishonest to accept.
>
>>
>> ***Even when we stay sharply focused on one single point at *
>> *a time you cannot seem to ever keep from drifting off topic. *
>
> Truth is not limited to just a single point at a time.
>
> That is the way of the carefully crafted lie, that needs to be
> approached at just the right angle to avoid seeing the flaws.
>
>>
>>
>> *Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>      machine   stack     stack     machine    assembly
>>      address   address   data      code       language
>>      ========  ========  ========  =========  =============
>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>> ...[00001358][0021233a][00001352] 50 push    eax           // push P
>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>> ...[0000135c][00212336][00001352] 51 push    ecx           // push P
>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> This transition NEVER happens.
It is not a transition it is a function call.
I am sure that you are pretending to be much more stupid than you are.
No one is stupid enough to disagree with a programming language.

--
Copyright 2022 Pete Olcott

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

Re: Are my reviewers dishonest or technically incompetent ?

<TYyiK.4178$lut9.20@fx99.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=8909&group=comp.ai.philosophy#8909

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx99.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com> <WiviK.2811$vAW9.2803@fx10.iad> <sJmdnbZKbOK5GRf_nZ2dnUU7_8zNnZ2d@giganews.com> <nMxiK.4886$xZtb.2948@fx41.iad> <o4qdncfJsIB2Nhf_nZ2dnUU7_83NnZ2d@giganews.com> <kKyiK.24175$5fVf.14299@fx09.iad> <CaOdnfv6_uXMJBf_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <CaOdnfv6_uXMJBf_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 92
Message-ID: <TYyiK.4178$lut9.20@fx99.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 22 May 2022 18:39:46 -0400
X-Received-Bytes: 5036
 by: Richard Damon - Sun, 22 May 2022 22:39 UTC

On 5/22/22 6:29 PM, olcott wrote:
> On 5/22/2022 5:24 PM, Richard Damon wrote:
>> On 5/22/22 5:32 PM, olcott wrote:
>>> On 5/22/2022 4:18 PM, Richard Damon wrote:
>>>> On 5/22/22 2:42 PM, olcott wrote:
>>>>> On 5/22/2022 1:30 PM, Richard Damon wrote:
>>>>>> On 5/22/22 2:00 PM, olcott wrote:
>>>>>>> That H(P,P)==0 is easily verified as correct by reverse
>>>>>>> engineering what the behavior of the input to H(P,P) would be if
>>>>>>> we assume that H performs a pure x86 emulation of its input. The
>>>>>>> x86 source-code of P specifies everything that we need to know to
>>>>>>> do this.
>>>>>>
>>>>>> So, you are doing an analysis based on the assumption that an H
>>>>>> CAN correct simulate its input AND answer at the same time?
>>>>>>
>>>>>> Until your prove that such an H can exist, you need to be very
>>>>>> careful what you derive from this analysis.
>>>>>>
>>>>>>>
>>>>>>> It is dead obvious that when H(P,P) correctly emulates its input
>>>>>>> that the first 7 instructions of P are emulated.
>>>>>>>
>>>>>>> It is also dead obvious that when P calls H(P,P) that H emulates
>>>>>>> the first 7 instructions of P again.
>>>>>>>
>>>>>>
>>>>>> But that wouldn't actually happen!!!
>>>>>>
>>>>>> P calls H, so H needs to emulate the code of H since that is what
>>>>>> is actually executing.
>>>>>>
>>>>>> THAT is a "Correct Simulation".
>>>>>>
>>>>>
>>>>> Yes that is true, none-the-less we don't need to actually see the
>>>>> 237 pages of the emulation of H to know that this H must also
>>>>> emulate the first 7 instructions of P.
>>>>
>>>> Right, and then the top level H aborts,
>>>
>>>
>>> *We are not even discussing that part yet. *
>>
>> But it is a fundamental
>>
>>> *All that we are doing is verifying this this trace is correct. *
>>
>> Which it isn't, and has been pointed out many times, but you seem to
>> be to stupid to understand, or to dishonest to accept.
>>
>>>
>>> ***Even when we stay sharply focused on one single point at *
>>> *a time you cannot seem to ever keep from drifting off topic. *
>>
>> Truth is not limited to just a single point at a time.
>>
>> That is the way of the carefully crafted lie, that needs to be
>> approached at just the right angle to avoid seeing the flaws.
>>
>>>
>>>
>>> *Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>>      machine   stack     stack     machine    assembly
>>>      address   address   data      code       language
>>>      ========  ========  ========  =========  =============
>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0021233a][00001352] 50 push    eax           // push P
>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][00212336][00001352] 51 push    ecx           // push P
>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>
>> This transition NEVER happens.
> It is not a transition it is a function call.

Yes, to H, not P. Unless H actually calls P, and thus loses control and
the ability to abort, the instructions in P below are never actually
seen by the simulation thread that is simulating the lines above.

> I am sure that you are pretending to be much more stupid than you are.
> No one is stupid enough to disagree with a programming language.
>

Nope, you are just so dumb (or dishonest) that truth doesn't make sense.

The fact that I point out the basic principles that you are ignoring,
and you do not even try to refute them but just ignore them PROVES you
are an incompetent liar.

Good luck with your legacy as a lying kook.

Re: Are my reviewers dishonest or technically incompetent ?

<t772o6$g51$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=9074&group=comp.ai.philosophy#9074

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!aioe.org!zMfikHxqgU548izDr2YMAw.user.46.165.242.91.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Date: Wed, 1 Jun 2022 01:59:16 -0500 (CDT)
Organization: news.aioe.org
Message-ID: <t772o6$g51$1@gioia.aioe.org>
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com> <WiviK.2811$vAW9.2803@fx10.iad> <sJmdnbZKbOK5GRf_nZ2dnUU7_8zNnZ2d@giganews.com> <nMxiK.4886$xZtb.2948@fx41.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="16545"; posting-host="zMfikHxqgU548izDr2YMAw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
X-Notice: Filtered by postfilter v. 0.9.2
X-Newsreader: PiaoHong.Usenet.Client.Free:2.02
 by: olcott - Wed, 1 Jun 2022 06:59 UTC

Richard Damon <Richard@Damon-Family.org> Wrote in message:r
> On 5/22/22 2:42 PM, olcott wrote:> On 5/22/2022 1:30 PM, Richard Damon wrote:>> On 5/22/22 2:00 PM, olcott wrote:>>> That H(P,P)==0 is easily verified as correct by reverse engineering >>> what the behavior of the input to H(P,P) would be if we assume that H >>> performs a pure x86 emulation of its input. The x86 source-code of P >>> specifies everything that we need to know to do this.>>>> So, you are doing an analysis based on the assumption that an H CAN >> correct simulate its input AND answer at the same time?>>>> Until your prove that such an H can exist, you need to be very careful >> what you derive from this analysis.>>>>>>>> It is dead obvious that when H(P,P) correctly emulates its input that >>> the first 7 instructions of P are emulated.>>>>>> It is also dead obvious that when P calls H(P,P) that H emulates the >>> first 7 instructions of P again.>>>>>>> But that wouldn't actually happen!!!>>>> P calls H, so H needs to emulate the code of H since that is what is >> actually executing.>>>> THAT is a "Correct Simulation".>>> > Yes that is true, none-the-less we don't need to actually see the 237 > pages of the emulation of H to know that this H must also emulate the >
first 7 instructions of P.Right, and then the top level H aborts, so we don't get to see the rest of the correct simulaiton, which would show this embedded copy of H simulating the next embedded copy of H for its emulation of those sam e 7 instructions and then aborting its simulation and returning to the P that called it and that P halting.THAT is the correct Simulation of the input to H.H can not do that, because it has been programmed to abort its simulation at the point it did. But it shows the CORRECT SIMULATION does halt, and H used faulty logic to deicde that it would not.The question is NOT can H simulate this input to a Halting State, but can a CORRECT simulation of this input, with H defined to be what H is, reach a final state, which it does.If you want to claim foul and we can't use a different simulator to get the correct simulation, then that is just saying you aren't doing the Halting Problem, or that the Halting Problem is impossible to solve (what the Theorem says).Remember, Halting is a property of the program P, not the decider H.> >> Only an H that wasn't actually a computation, but somehow collesed >> calls to itself in its simulation would do anyting like th
at, but that >> means that H fails to be an actual computation itself, and thus not >> eligable to be a decider.>>>>> This makes it dead obvious that the correct x86 emulation of the >>> input to H(P,P) never reaches its last instruction and halts.>>>> Starting from an incorrect definition of a "Correct Trace" leads to >> garbage.>>>>>>>> Because all of my reviewers have consistently denied this easily >>> verified fact for six months it seems unreasonable to believe that >>> this is an honest mistake.>>>>>> Because what you claim isn't what actually happens. At least not in >> the space that you claim to be working in.>>>> You just repeat the claims, you never actually show that the rebutals >> are incorrect. That just proves your own ignorance.>>>>>>>> This is an explanation of a key new insight into the halting problem >>> provided in the language of software engineering. Technical computer >>> science terms are explained using software engineering terms.>>>> Then actually provide the actual definition of the term you are >> claiming make things clear.>>>>>>>> To fully understand this paper a software engineer must be an expert >>> in: the C programming language, the x86 progra
mming language, exactly >>> how C translates into x86 and the ability to recognize infinite >>> recursion at the x86 assembly language level. No knowledge of the >>> halting problem is required.>>>>>>>>>>>> The computer science term ?halting? means that a Turing Machine >>> terminated normally reaching its last instruction known as its ?final >>> state?. This is the same idea as when a function returns to its >>> caller as opposed to and contrast with getting stuck in an infinite >>> loop or infinite recursion.>>>> Ok. since P(P) Halts, why is H(P,P) == 0 not wrong, since H(P,P) is >> supposed to be asking about the PROGRAM P, not some mythical behavior >> of the input.>>>>>>>> In computability theory, the halting problem is the problem of >>> determining,>>> from a description of an arbitrary computer program and an >>> input, whether>>> the program will finish running, or continue to run forever. >>> Alan Turing proved>>> in 1936 that a general algorithm to solve the halting problem >>> for all possible>>> program-input pairs cannot exist.>>>> Right, H(P,P) is to determine if P(P) Halts.>>>> Since P(P) Halts, the answer H(P,P) == 0 must be incorrect
.>>>>>>>> For any program H that might determine if programs halt, a >>> "pathological">>> program P, called with some input, can pass its own source and >>> its input to>>> H and then specifically do the opposite of what H predicts P >>> will do. No H>>> can exist that handles this case. >>> https://en.wikipedia.org/wiki/Halting_problem>>>> Yep, that is the proof that you can't make an actual decider compute >> the Halting Function.>>>>>>>> Technically a halt decider is a program that computes the mapping >>> from a pair of input finite strings to its own accept or reject state >>> based on the actual behavior specified by these finite strings. In >>> other words it determines whether or not its input would halt and >>> returns 0 or 1 accordingly.>>>> Right, an Arbitrary decide just needs to always halt on all input to >> create a mapping of input to outputs.>>>> To be a "Something" Decider, that mapping must match the "Something" >> function as defined.>>>>>>>> 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>>>>>> The most definitive way to determine the actual behavior of the >>> actual input is to simply simulate this input and watch its behavior. >>> This is the ultimate measure of the actual behavior of the input. A >>> simulating halt decider (SHD) simulates its input and determines the >>> halt status of this input on the basis of the behavior of this >>> correctly simulated of its input.>>>> Ok, but if the correct simulation of the input takes longer that the >> SHD allows, it doesn't get the data it needs to make the decision.>>>> It has been shown that if you SHD runs until it can actually PROVE >> that it has the right answer, it will NEVER halt on the input P,P >> where P is built on this "contrary" pattern.>>>> You haven't even TRIED to prove that you can will reach an answer in >> finite time.>>>>>>>> The x86utm operating system was created so that all of the details of >>> the the halting problem c
ounter-example could be examined at the much >>> higher level of abstraction of the C/x86 computer languages. It is >>> based on a very powerful x86 emulator.>>>> Ok.>>>>>> The function named P was defined to do the opposite of whatever H >>> reports that it will do. If H(P,P) reports that its input halts, P >>> invokes an infinite loop. If H(P,P) reports that its input is >>> non-halting, P immediately halts.>>>> Right, which shows that H was wrong.>>>> The only way that H(P,P) == 0 is correct, is if P(P) runs forever and >> never halts.>>>> The fact that it halt, PROVES that H was wrong.>>>>>>>> The technical computer science term "halt" means that a program will >>> reach its last instruction technically called its final state. For P >>> this would be its machine address [0000136c].>>>> Which it does, for an ACTUALLY RUN P.>>>> There is NO requriement that H be able to simulate to that point.>>>>>>>> H simulates its input one x86 instruction at a time using an x86 >>> emulator. As soon as H(P,P) detects the same infinitely repeating >>> pattern (that we can all see), it aborts its simulation and rejects >>> its input.>>>> And there is NO finite pattern that exists that proves t
hat fact.>>>> ANY pattern you claim is such a pattern, when programmed into H, makes >> the actual execution of P(P) Halt, and thus is incorret.>>>>>>>> Anyone that is an expert in the C programming language, the x86 >>> programming language, exactly how C translates into x86 and what an >>> x86 processor emulator is can easily verify that the correctly >>> simulated input to H(P,P) by H specifies a non-halting sequence of >>> configurations.>>>> Nope. It is easy to verify that if H(P,P) is defined to return 0 after >> a finite time, that P(P) will Halt.>>>>>>>>>> Software engineering experts can reverse-engineer what the correct >>> x86 emulation of the input to H(P,P) would be for one emulation and >>> one nested emulation thus confirming that the provided execution >>> trace is correct. They can do this entirely on the basis of the x86 >>> source-code for P with no need to see the source-code or execution >>> trace of H.>>>> Ok, so we have the trace of the first emulation, and a trace of the >> second, both of them show that P(P) calls H(P,P) and is waiting for an >> answer.>>>>>>>> The function named H continues to simulate its input using an x86 >>> emulator until this input
either halts on its own or H detects that >>> it would never halt. If its input halts H returns 1. If H detects >>> that its input would never halt H returns 0.>>>> So you have the contradiction. If H returns 0, it shows that ALL the >> P(P)'s will Halt.>>>> If H doesn't return 0, it shows that it doesn't answer for that input, >> and thus fails.>>>> It is invalid logic to use a different H for doing the actual decision >> an to build P from, they need to be EXACT copies and actual >> computations, thus ALL copies do the same thing.>>>>>>>> #include <stdint.h>>>> #define u32 uint32_t>>>>>> void P(u32 x)>>> {>>> if (H(x, x))>>> HERE: goto HERE;>>> return;>>> }>>>>>> int main()>>> {>>> Output("Input_Halts = ", H((u32)P, (u32)P));>>> }>>>>>> _P()>>> [00001352](01) 55 push ebp>>> [00001353](02) 8bec mov ebp,esp>>> [00001355](03) 8b4508 mov eax,[ebp+08]>>> [00001358](01) 50 push eax // push P>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]>>> [0000135c](01) 51 push ecx // push P>>> [0000135d](05) e840feffff call 000011a2 // call H>>> [00001362](03) 83c408 add esp,+08>>> [00001365
](02) 85c0 test eax,eax>>> [00001367](02) 7402 jz 0000136b>>> [00001369](02) ebfe jmp 00001369>>> [0000136b](01) 5d pop ebp>>> [0000136c](01) c3 ret>>> Size in bytes:(0027) [0000136c]>>>>>> _main()>>> [00001372](01) 55 push ebp>>> [00001373](02) 8bec mov ebp,esp>>> [00001375](05) 6852130000 push 00001352 // push P>>> [0000137a](05) 6852130000 push 00001352 // push P>>> [0000137f](05) e81efeffff call 000011a2 // call H>>> [00001384](03) 83c408 add esp,+08>>> [00001387](01) 50 push eax>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = ">>> [0000138d](05) e8e0f0ffff call 00000472 // call Output>>> [00001392](03) 83c408 add esp,+08>>> [00001395](02) 33c0 xor eax,eax>>> [00001397](01) 5d pop ebp>>> [00001398](01) c3 ret>>> Size in bytes:(0039) [00001398]>>>>>> machine stack stack machine assembly>>> address address data code language>>> ======== ======== ======== ========= =============>>> ...[00001372][0010229e][00000000] 55 push
ebp>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]>>> ...[00001358][0021233a][00001352] 50 push eax // push P>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]>>> ...[0000135c][00212336][00001352] 51 push ecx // push P>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H>>>> And this is the error.>>>> The top level simulation NEVER sees this below, and thus this is a >> FALSE trace.>>>> You just are proving you don't understand what a trace is supposed to >> show.>>>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp>>> ...[00001355][0025cd66][002
5cd6a] 8b4508 mov eax,[ebp+08]>>> ...[00001358][0025cd62][00001352] 50 push eax // push P>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]>>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped>>>>>> H sees that P is calling the same function from the same machine >>> address with identical parameters, twice in sequence. This is the >>> infinite recursion (infinitely nested simulation) non-halting >>> behavior pattern.>>>> If it does, it is using unsound logic, as it is based on false premises.>>>>>>>> ...[00001384][0010229e][00000000] 83c408 add esp,+08>>> ...[00001387][0010229a][00000000] 50 push eax>>> ...[00001388][00102296][00000423] 6823040000 push 00000423 // >>> "Input_Halts = ">>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call >>> Output>>> Input_Halts = 0>>> ...[00001392][0010229e][00000000] 83c408 add esp,+08>>> ...[00001395][0010229e][00000000] 33c0 xor eax,eax>>> ...[00001397][001022a2][00100000] 5d pop ebp>>> ...[00001398][001022
a6][00000004] c3 ret>>> Number_of_User_Instructions(1)>>> Number of Instructions Executed(15892) = 237 pages>>>>>> The correct simulation of the input to H(P,P) and the direct >>> execution of P(P) are not computationally equivalent thus need not >>> have the same halting behavior.>>>> The H is NOT a Halting Decider.>>>> The DEFINITION of a Halting Decider IS that it is answering about the >> behavior of the machine the input represents.>>>> Thus, if H is a Halt Decider, the "behavior of the input", for H(P,P) >> must be exactly P(P).>>>> FAIL.>>>>>>>>>> Halting problem undecidability and infinitely nested simulation (V5)>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5 >>>>>>>>>>>>>>> >


Click here to read the complete article
Re: Are my reviewers dishonest or technically incompetent ?

<ut6dnVgv7teRjAr_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=9075&group=comp.ai.philosophy#9075

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 01 Jun 2022 02:11:08 -0500
Date: Wed, 1 Jun 2022 02:11:07 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<WiviK.2811$vAW9.2803@fx10.iad>
<sJmdnbZKbOK5GRf_nZ2dnUU7_8zNnZ2d@giganews.com>
<nMxiK.4886$xZtb.2948@fx41.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <nMxiK.4886$xZtb.2948@fx41.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <ut6dnVgv7teRjAr_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 398
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ET3FEr6ngqYnEGncZ2Ss7x2NKHfXe9RQSH1amjqH2Ua2b4P3mjUaJxS2I6aJFg+akY3aKSM3bKsSQBs!8G3EXu0oRi7qIgcRBPNSTdR/iFkQ90IKGczILKvJmXDg5QPaphOK71pCP98oZtJOtUFm+DoHaW5T
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 18523
 by: olcott - Wed, 1 Jun 2022 07:11 UTC

On 5/22/2022 4:18 PM, Richard Damon wrote:
> On 5/22/22 2:42 PM, olcott wrote:
>> On 5/22/2022 1:30 PM, Richard Damon wrote:
>>> On 5/22/22 2:00 PM, olcott wrote:
>>>> That H(P,P)==0 is easily verified as correct by reverse engineering
>>>> what the behavior of the input to H(P,P) would be if we assume that
>>>> H performs a pure x86 emulation of its input. The x86 source-code of
>>>> P specifies everything that we need to know to do this.
>>>
>>> So, you are doing an analysis based on the assumption that an H CAN
>>> correct simulate its input AND answer at the same time?
>>>
>>> Until your prove that such an H can exist, you need to be very
>>> careful what you derive from this analysis.
>>>
>>>>
>>>> It is dead obvious that when H(P,P) correctly emulates its input
>>>> that the first 7 instructions of P are emulated.
>>>>
>>>> It is also dead obvious that when P calls H(P,P) that H emulates the
>>>> first 7 instructions of P again.
>>>>
>>>
>>> But that wouldn't actually happen!!!
>>>
>>> P calls H, so H needs to emulate the code of H since that is what is
>>> actually executing.
>>>
>>> THAT is a "Correct Simulation".
>>>
>>
>> Yes that is true, none-the-less we don't need to actually see the 237
>> pages of the emulation of H to know that this H must also emulate the
>> first 7 instructions of P.
>
> Right, and then the top level H aborts, so we don't get to see the rest
> of the correct simulaiton, which would show this embedded copy of H
> simulating the next embedded copy of H for its emulation of those sam e
> 7 instructions and then aborting its simulation and returning to the P
> that called it and that P halting.
>
> THAT is the correct Simulation of the input to H.
>
> H can not do that, because it has been programmed to abort its
> simulation at the point it did. But it shows the CORRECT SIMULATION does
> halt, and H used faulty logic to deicde that it would not.
>
> The question is NOT can H simulate this input to a Halting State, but
> can a CORRECT simulation of this input, with H defined to be what H is,
> reach a final state, which it does.
>
> If you want to claim foul and we can't use a different simulator to get
> the correct simulation, then that is just saying you aren't doing the
> Halting Problem, or that the Halting Problem is impossible to solve
> (what the Theorem says).
>
> Remember, Halting is a property of the program P, not the decider H.
>
>>
>>> Only an H that wasn't actually a computation, but somehow collesed
>>> calls to itself in its simulation would do anyting like that, but
>>> that means that H fails to be an actual computation itself, and thus
>>> not eligable to be a decider.
>>>
>>>> This makes it dead obvious that the correct x86 emulation of the
>>>> input to H(P,P) never reaches its last instruction and halts.
>>>
>>> Starting from an incorrect definition of a "Correct Trace" leads to
>>> garbage.
>>>
>>>>
>>>> Because all of my reviewers have consistently denied this easily
>>>> verified fact for six months it seems unreasonable to believe that
>>>> this is an honest mistake.
>>>
>>>
>>> Because what you claim isn't what actually happens. At least not in
>>> the space that you claim to be working in.
>>>
>>> You just repeat the claims, you never actually show that the rebutals
>>> are incorrect. That just proves your own ignorance.
>>>
>>>>
>>>> This is an explanation of a key new insight into the halting problem
>>>> provided in the language of software engineering. Technical computer
>>>> science terms are explained using software engineering terms.
>>>
>>> Then actually provide the actual definition of the term you are
>>> claiming make things clear.
>>>
>>>>
>>>> To fully understand this paper a software engineer must be an expert
>>>> in: the C programming language, the x86 programming language,
>>>> exactly how C translates into x86 and the ability to recognize
>>>> infinite recursion at the x86 assembly language level. No knowledge
>>>> of the halting problem is required.
>>>>
>>>
>>>
>>>
>>>> The computer science term “halting” means that a Turing Machine
>>>> terminated normally reaching its last instruction known as its
>>>> “final state”. This is the same idea as when a function returns to
>>>> its caller as opposed to and contrast with getting stuck in an
>>>> infinite loop or infinite recursion.
>>>
>>> Ok. since P(P) Halts, why is H(P,P) == 0 not wrong, since H(P,P) is
>>> supposed to be asking about the PROGRAM P, not some mythical behavior
>>> of the input.
>>>
>>>>
>>>>       In computability theory, the halting problem is the problem of
>>>> determining,
>>>>       from a description of an arbitrary computer program and an
>>>> input, whether
>>>>       the program will finish running, or continue to run forever.
>>>> Alan Turing proved
>>>>       in 1936 that a general algorithm to solve the halting problem
>>>> for all possible
>>>>       program-input pairs cannot exist.
>>>
>>> Right, H(P,P) is to determine if P(P) Halts.
>>>
>>> Since P(P) Halts, the answer H(P,P) == 0 must be incorrect.
>>>
>>>>
>>>>       For any program H that might determine if programs halt, a
>>>> "pathological"
>>>>       program P, called with some input, can pass its own source and
>>>> its input to
>>>>       H and then specifically do the opposite of what H predicts P
>>>> will do. No H
>>>>       can exist that handles this case.
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> Yep, that is the proof that you can't make an actual decider compute
>>> the Halting Function.
>>>
>>>>
>>>> Technically a halt decider is a program that computes the mapping
>>>> from a pair of input finite strings to its own accept or reject
>>>> state based on the actual behavior specified by these finite
>>>> strings.  In other words it determines whether or not its input
>>>> would halt and returns 0 or 1 accordingly.
>>>
>>> Right, an Arbitrary decide just needs to always halt on all input to
>>> create a mapping of input to outputs.
>>>
>>> To be a "Something" Decider, that mapping must match the "Something"
>>> function as defined.
>>>
>>>>
>>>>       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
>>>>
>>>> The most definitive way to determine the actual behavior of the
>>>> actual input is to simply simulate this input and watch its
>>>> behavior. This is the ultimate measure of the actual behavior of the
>>>> input. A simulating halt decider (SHD) simulates its input and
>>>> determines the halt status of this input on the basis of the
>>>> behavior of this correctly simulated of its input.
>>>
>>> Ok, but if the correct simulation of the input takes longer that the
>>> SHD allows, it doesn't get the data it needs to make the decision.
>>>
>>> It has been shown that if you SHD runs until it can actually PROVE
>>> that it has the right answer, it will NEVER halt on the input P,P
>>> where P is built on this "contrary" pattern.
>>>
>>> You haven't even TRIED to prove that you can will reach an answer in
>>> finite time.
>>>
>>>>
>>>> The x86utm operating system was created so that all of the details
>>>> of the the halting problem counter-example could be examined at the
>>>> much higher level of abstraction of the C/x86 computer languages. It
>>>> is based on a very powerful x86 emulator.
>>>
>>> Ok.
>>>>
>>>> The function named P was defined to do the opposite of whatever H
>>>> reports that it will do. If H(P,P) reports that its input halts, P
>>>> invokes an infinite loop. If H(P,P) reports that its input is
>>>> non-halting, P immediately halts.
>>>
>>> Right, which shows that H was wrong.
>>>
>>> The only way that H(P,P) == 0 is correct, is if P(P) runs forever and
>>> never halts.
>>>
>>> The fact that it halt, PROVES that H was wrong.
>>>
>>>>
>>>> The technical computer science term "halt" means that a program will
>>>> reach its last instruction technically called its final state. For P
>>>> this would be its machine address [0000136c].
>>>
>>> Which it does, for an ACTUALLY RUN P.
>>>
>>> There is NO requriement that H be able to simulate to that point.
>>>
>>>>
>>>> H simulates its input one x86 instruction at a time using an x86
>>>> emulator. As soon as H(P,P) detects the same infinitely repeating
>>>> pattern (that we can all see), it aborts its simulation and rejects
>>>> its input.
>>>
>>> And there is NO finite pattern that exists that proves that fact.
>>>
>>> ANY pattern you claim is such a pattern, when programmed into H,
>>> makes the actual execution of P(P) Halt, and thus is incorret.
>>>
>>>>
>>>> Anyone that is an expert in the C programming language, the x86
>>>> programming language, exactly how C translates into x86 and what an
>>>> x86 processor emulator is can easily verify that the correctly
>>>> simulated input to H(P,P) by H specifies a non-halting sequence of
>>>> configurations.
>>>
>>> Nope. It is easy to verify that if H(P,P) is defined to return 0
>>> after a finite time, that P(P) will Halt.
>>>
>>>
>>>>
>>>> Software engineering experts can reverse-engineer what the correct
>>>> x86 emulation of the input to H(P,P) would be for one emulation and
>>>> one nested emulation thus confirming that the provided execution
>>>> trace is correct. They can do this entirely on the basis of the x86
>>>> source-code for P with no need to see the source-code or execution
>>>> trace of H.
>>>
>>> Ok, so we have the trace of the first emulation, and a trace of the
>>> second, both of them show that P(P) calls H(P,P) and is waiting for
>>> an answer.
>>>
>>>>
>>>> The function named H continues to simulate its input using an x86
>>>> emulator until this input either halts on its own or H detects that
>>>> it would never halt. If its input halts H returns 1. If H detects
>>>> that its input would never halt H returns 0.
>>>
>>> So you have the contradiction. If H returns 0, it shows that ALL the
>>> P(P)'s will Halt.
>>>
>>> If H doesn't return 0, it shows that it doesn't answer for that
>>> input, and thus fails.
>>>
>>> It is invalid logic to use a different H for doing the actual
>>> decision an to build P from, they need to be EXACT copies and actual
>>> computations, thus ALL copies do the same thing.
>>>
>>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00001352](01)  55              push ebp
>>>> [00001353](02)  8bec            mov ebp,esp
>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>> [00001358](01)  50              push eax      // push P
>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>> [0000135c](01)  51              push ecx      // push P
>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>> [00001362](03)  83c408          add esp,+08
>>>> [00001365](02)  85c0            test eax,eax
>>>> [00001367](02)  7402            jz 0000136b
>>>> [00001369](02)  ebfe            jmp 00001369
>>>> [0000136b](01)  5d              pop ebp
>>>> [0000136c](01)  c3              ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> _main()
>>>> [00001372](01)  55              push ebp
>>>> [00001373](02)  8bec            mov ebp,esp
>>>> [00001375](05)  6852130000      push 00001352 // push P
>>>> [0000137a](05)  6852130000      push 00001352 // push P
>>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>>> [00001384](03)  83c408          add esp,+08
>>>> [00001387](01)  50              push eax
>>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>>> [00001392](03)  83c408          add esp,+08
>>>> [00001395](02)  33c0            xor eax,eax
>>>> [00001397](01)  5d              pop ebp
>>>> [00001398](01)  c3              ret
>>>> Size in bytes:(0039) [00001398]
>>>>
>>>>      machine   stack     stack     machine    assembly
>>>>      address   address   data      code       language
>>>>      ========  ========  ========  =========  =============
>>>> ...[00001372][0010229e][00000000] 55         push ebp
>>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>
>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>
>>> And this is the error.
>>>
>>> The top level simulation NEVER sees this below, and thus this is a
>>> FALSE trace.
>>>
>>> You just are proving you don't understand what a trace is supposed to
>>> show.
>>>
>>>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
>>>> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>>>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>>>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>>>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>>>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> H sees that P is calling the same function from the same machine
>>>> address with identical parameters, twice in sequence. This is the
>>>> infinite recursion (infinitely nested simulation) non-halting
>>>> behavior pattern.
>>>
>>> If it does, it is using unsound logic, as it is based on false premises.
>>>
>>>>
>>>> ...[00001384][0010229e][00000000] 83c408     add esp,+08
>>>> ...[00001387][0010229a][00000000] 50         push eax
>>>> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
>>>> "Input_Halts = "
>>>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call
>>>> Output
>>>> Input_Halts = 0
>>>> ...[00001392][0010229e][00000000] 83c408     add esp,+08
>>>> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
>>>> ...[00001397][001022a2][00100000] 5d         pop ebp
>>>> ...[00001398][001022a6][00000004] c3         ret
>>>> Number_of_User_Instructions(1)
>>>> Number of Instructions Executed(15892) = 237 pages
>>>>
>>>> The correct simulation of the input to H(P,P) and the direct
>>>> execution of P(P) are not computationally equivalent thus need not
>>>> have the same halting behavior.
>>>
>>> The H is NOT a Halting Decider.
>>>
>>> The DEFINITION of a Halting Decider IS that it is answering about the
>>> behavior of the machine the input represents.
>>>
>>> Thus, if H is a Halt Decider, the "behavior of the input", for H(P,P)
>>> must be exactly P(P).
>>>
>>> FAIL.
>>>
>>>
>>>>
>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>
>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>
>>>>
>>>>
>>>>
>>>


Click here to read the complete article
Re: Are my reviewers dishonest or technically incompetent ?

<t77f5f$1qso$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=9076&group=comp.ai.philosophy#9076

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!aioe.org!7a25jG6pUKCqa0zKnKnvdg.user.46.165.242.75.POSTED!not-for-mail
From: pyt...@example.invalid (Python)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Date: Wed, 1 Jun 2022 12:31:09 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t77f5f$1qso$1@gioia.aioe.org>
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<WiviK.2811$vAW9.2803@fx10.iad>
<sJmdnbZKbOK5GRf_nZ2dnUU7_8zNnZ2d@giganews.com>
<nMxiK.4886$xZtb.2948@fx41.iad>
<ut6dnVgv7teRjAr_nZ2dnUU7_8xh4p2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="60312"; posting-host="7a25jG6pUKCqa0zKnKnvdg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0)
Gecko/20100101 Thunderbird/91.9.1
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: fr
 by: Python - Wed, 1 Jun 2022 10:31 UTC

Peter Olcott wrote:
....
> Posted in Google Chrome on Windows.

Peter you are abusing this place and insulting people by your
behaviour of testing clients on comp.* or sci.* newsgroups.

There is a group for that: alt.test

P.S. You are an asshole on all matters

Re: Are my reviewers dishonest or technically incompetent ?

<yIidnbCoFe62xTT_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=9434&group=comp.ai.philosophy#9434

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 14 Jun 2022 22:55:23 -0500
Date: Tue, 14 Jun 2022 22:55:22 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<d058c48b-098f-4a5c-9e79-afea6c4ede4cn@googlegroups.com>
<dqmdnTWn69vaUDr_nZ2dnUU7_83NnZ2d@giganews.com> <t8b13i$kir$1@gioia.aioe.org>
<6rOdnQ0dr4u3ljT_nZ2dnUU7_83NnZ2d@giganews.com> <gwbqK.6$dh2.0@fx46.iad>
<1bedzqmwhd.fsf@pfeifferfamily.net>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <1bedzqmwhd.fsf@pfeifferfamily.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <yIidnbCoFe62xTT_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 138
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-BUvky/HY5IQfl4+KtJT1bbpQaY9rtyntBYVGaoaVDgqUlxI+4Xgb9B1s20JW4kFPnIFCsc1H33Xi1og!9WSXVXTv7GNp5AJ0rrSytxYAdiv6L4YSbVx+xKJTF4BB7LlNF6nlklaoqOG6wryZs+KOFwSwGzE0
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7290
 by: olcott - Wed, 15 Jun 2022 03:55 UTC

On 6/14/2022 10:33 PM, Joe Pfeiffer wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>>
>> If you HAVE found someone to agree with your, that doesn't actually
>> prove anything.
>>
>> Your "proof" is going to need to be able to stand up to actual
>> community scrutiny.
>>
>> FInding a couple of people you can con into beleiving your lies isn't
>> going to get you anywhere, unless they happen to be the Journal
>> Publishers, and then that Journel is likely not very good, or is going
>> to get overwhelmed with responses pointing out the errors.
>
> They aren't lies if he actually believes them. I think "delusions" is
> the word you were looking for.
>
>> Until you can form an ACTUAL rebutal to all the core errors found in
>> your arguement, all you are going to prove is your ignorance.
>
> But of course he can't, so yeah.

Now that one reviewer went point by point through my work and validated
it none of the other reviewers can get way with their lies.

100 reviewers from a dozen different forums and thousands of messages
over the period of a year refusing to provide a single accurate review
until now.

The criterion measure for a simulating halt decider (SHD)
When the correct partial x86 emulation of the input matches a
non-halting behavior pattern such that it correctly determines that a
complete emulation of the input would never stop running, or reach its
“ret” instruction then the SHD aborts its emulation and correctly returns 0.

#include <stdint.h>
#define u32 uint32_t

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

// H emulates the first seven instructions of P
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

....[00001384][0010229e][00000000] 83c408 add esp,+08
....[00001387][0010229a][00000000] 50 push eax
....[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
....[00001392][0010229e][00000000] 83c408 add esp,+08
....[00001395][0010229e][00000000] 33c0 xor eax,eax
....[00001397][001022a2][00100000] 5d pop ebp
....[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) = 237 pages

--
Copyright 2022 Pete Olcott

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

Re: Are my reviewers dishonest or technically incompetent ?

<qGiqK.96665$X_i.17872@fx18.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=9436&group=comp.ai.philosophy#9436

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx18.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.10.0
Subject: Re: Are my reviewers dishonest or technically incompetent ?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <4_adnW5_44_d5xf_nZ2dnUU7_83NnZ2d@giganews.com>
<d058c48b-098f-4a5c-9e79-afea6c4ede4cn@googlegroups.com>
<dqmdnTWn69vaUDr_nZ2dnUU7_83NnZ2d@giganews.com> <t8b13i$kir$1@gioia.aioe.org>
<6rOdnQ0dr4u3ljT_nZ2dnUU7_83NnZ2d@giganews.com> <gwbqK.6$dh2.0@fx46.iad>
<1bedzqmwhd.fsf@pfeifferfamily.net>
<yIidnbCoFe62xTT_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <yIidnbCoFe62xTT_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 163
Message-ID: <qGiqK.96665$X_i.17872@fx18.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 15 Jun 2022 06:40:21 -0400
X-Received-Bytes: 8735
 by: Richard Damon - Wed, 15 Jun 2022 10:40 UTC

On 6/14/22 11:55 PM, olcott wrote:
> On 6/14/2022 10:33 PM, Joe Pfeiffer wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>> If you HAVE found someone to agree with your, that doesn't actually
>>> prove anything.
>>>
>>> Your "proof" is going to need to be able to stand up to actual
>>> community scrutiny.
>>>
>>> FInding a couple of people you can con into beleiving your lies isn't
>>> going to get you anywhere, unless they happen to be the Journal
>>> Publishers, and then that Journel is likely not very good, or is going
>>> to get overwhelmed with responses pointing out the errors.
>>
>> They aren't lies if he actually believes them.  I think "delusions" is
>> the word you were looking for.
>>
>>> Until you can form an ACTUAL rebutal to all the core errors found in
>>> your arguement, all you are going to prove is your ignorance.
>>
>> But of course he can't, so yeah.
>
> Now that one reviewer went point by point through my work and validated
> it none of the other reviewers can get way with their lies.
>

No,it doesn't actually work that way. Just because you have bamboozled
one person, doesn't mean you are right.

> 100 reviewers from a dozen different forums and thousands of messages
> over the period of a year refusing to provide a single accurate review
> until now.
>

Nope, doesn't work that way. For you work to b accepted, you are going
to need to get the vast majority to eventually accept it. Perhaps you
can start with a small group OF THE TOP RESPECT authorities to

> The criterion measure for a simulating halt decider (SHD)
> When the correct partial x86 emulation of the input matches a
> non-halting behavior pattern such that it correctly determines that a
> complete emulation of the input would never stop running, or reach its
> “ret” instruction then the SHD aborts its emulation and correctly
> returns 0.

Only if that actually matches the REAL criterion, that being the actual
behavior of the machine in question with that input.

Note, as has been shown, there is NO correct "non-halting behavior
pattern" in the processing by H of P,P, as any pattern that H sees, if
put into H, will cause tht P(P) to Halt, and thus not be a correct pattern.

>
> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352 // push P
> [0000137a](05)  6852130000      push 00001352 // push P
> [0000137f](05)  e81efeffff      call 000011a2 // call H
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55         push ebp
> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>
> // H emulates the first seven instructions of P
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> // The emulated H emulates the first seven instructions of PShould be the emulated H CONDITIONALLY emulates, so, you "Infinite
Behavior" rule is not satisfied.

Since H does abort, the emulated H WILL abort, and the pattern will not
repeat forever like claimed.

> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction of P repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.

So, does H(P,P) correctly emulates its input (and thus never abort) or
does it abort its emulation to return 0 and thus not correctly emulate
its input, and the correctd emulation of the input will reach the ret
instruction?

>
> ...[00001384][0010229e][00000000] 83c408     add esp,+08
> ...[00001387][0010229a][00000000] 50         push eax
> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
> "Input_Halts = "
> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
> Input_Halts = 0
> ...[00001392][0010229e][00000000] 83c408     add esp,+08
> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
> ...[00001397][001022a2][00100000] 5d         pop ebp
> ...[00001398][001022a6][00000004] c3         ret
> Number of Instructions Executed(15892) = 237 pages
>
>
>

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor