Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Asynchronous inputs are at the root of our race problems. -- D. Winker and F. Prosser


computers / comp.ai.philosophy / Re: Competent software engineers will agree that H(P,P)==0 is correct [ deception ]

SubjectAuthor
* Re: Competent software engineers will agree that H(P,P)==0 is correctolcott
`* Re: Competent software engineers will agree that H(P,P)==0 is correctRichard Damon
 `* Re: Competent software engineers will agree that H(P,P)==0 is correctolcott
  `- Re: Competent software engineers will agree that H(P,P)==0 is correct [ deceptioRichard Damon

1
Re: Competent software engineers will agree that H(P,P)==0 is correct [ deception ]

<t7mhs0$ctl$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Subject: Re: Competent software engineers will agree that H(P,P)==0 is correct
[ deception ]
Date: Mon, 6 Jun 2022 22:49:17 -0500
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <t7mhs0$ctl$1@dont-email.me>
References: <N5-dnal-trqPgQP_nZ2dnUU7_83NnZ2d@giganews.com>
<d25678aa-3764-4027-9076-c6b372e290e7n@googlegroups.com>
<875yldljuz.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 7 Jun 2022 03:49:20 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="5ea2cc72425088691c569a84c3b1faa0";
logging-data="13237"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19477c4GTn9MfjFqcbF5myc"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:uyJ+gKxlI52MspXbHuizMkVmCRU=
In-Reply-To: <875yldljuz.fsf@bsb.me.uk>
Content-Language: en-US
 by: olcott - Tue, 7 Jun 2022 03:49 UTC

On 6/6/2022 1:36 PM, Ben wrote:
> wij <wyniijj2@gmail.com> writes:
>
>> Students of average level understand Halting decider cannot exist, as olcott
>> has demonstrated for years (no 'correct' H exists).
>>
>> If H does not exist, what dose "H(P,P)==0" mean?
>
> H as specified in, say, Linz does not exist. But PO's H does and so P
> (which should really be called something like H_Hat) also exists.
> That's why H is wrong about the "halting" of P(P).
>
> Another way to write the proof is to show that every Turing machine gets
> at least one instance wrong -- i.e. that no TM computes the halting
> function. PO's H is just an example of that, and he even tells us that
> it gets the instance representing P(P) wrong.
>

Since you know that

(1) Deciders in computer science compute the mapping from their inputs
to an accept or reject state.

(2) P(P) is not an input to H

Why do you persist in the deception that H must compute the halt status
of P(P) ?

--
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: Competent software engineers will agree that H(P,P)==0 is correct [ deception ]

<OsGnK.43377$elob.8187@fx43.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx43.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: Competent software engineers will agree that H(P,P)==0 is correct
[ deception ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <N5-dnal-trqPgQP_nZ2dnUU7_83NnZ2d@giganews.com>
<d25678aa-3764-4027-9076-c6b372e290e7n@googlegroups.com>
<875yldljuz.fsf@bsb.me.uk> <t7mhs0$ctl$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <t7mhs0$ctl$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 46
Message-ID: <OsGnK.43377$elob.8187@fx43.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: Tue, 7 Jun 2022 07:17:02 -0400
X-Received-Bytes: 2674
 by: Richard Damon - Tue, 7 Jun 2022 11:17 UTC

On 6/6/22 11:49 PM, olcott wrote:
> On 6/6/2022 1:36 PM, Ben wrote:
>> wij <wyniijj2@gmail.com> writes:
>>
>>> Students of average level understand Halting decider cannot exist, as
>>> olcott
>>> has demonstrated for years (no 'correct' H exists).
>>>
>>> If H does not exist, what dose "H(P,P)==0" mean?
>>
>> H as specified in, say, Linz does not exist.  But PO's H does and so P
>> (which should really be called something like H_Hat) also exists.
>> That's why H is wrong about the "halting" of P(P).
>>
>> Another way to write the proof is to show that every Turing machine gets
>> at least one instance wrong -- i.e. that no TM computes the halting
>> function.  PO's H is just an example of that, and he even tells us that
>> it gets the instance representing P(P) wrong.
>>
>
> Since you know that
>
> (1) Deciders in computer science compute the mapping from their inputs
> to an accept or reject state.
>
> (2) P(P) is not an input to H
>
> Why do you persist in the deception that H must compute the halt status
> of P(P) ?
>

But P(P) IS an input to H via its representation being given to H.

If you want to say that you can't actually give a computation to a
Turing Machine then the Halting Theorem is trivially proven true.

If the domain of inputs to Turing Machines does not include being able
to ask them about the behavior of other Turing Machines applied to
inputs, then no Turing Machine can correctly answer about the Halting
Property of a Turing machine applied to an Input.

Sorry, that claim doesn't hold water, and just shows your ignorance of
the topic.

FAIL.

Re: Competent software engineers will agree that H(P,P)==0 is correct [ deception ]

<uOGdnZ4qXfgIwwL_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 07 Jun 2022 09:20:05 -0500
Date: Tue, 7 Jun 2022 09:20:04 -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: Competent software engineers will agree that H(P,P)==0 is correct
[ deception ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <N5-dnal-trqPgQP_nZ2dnUU7_83NnZ2d@giganews.com>
<d25678aa-3764-4027-9076-c6b372e290e7n@googlegroups.com>
<875yldljuz.fsf@bsb.me.uk> <t7mhs0$ctl$1@dont-email.me>
<OsGnK.43377$elob.8187@fx43.iad>
<211565cd-e73c-4069-90b9-057e4f21888bn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <211565cd-e73c-4069-90b9-057e4f21888bn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <uOGdnZ4qXfgIwwL_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 66
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Zl61ULoPGta3A/0XJLMGDow8mDTZzRqHtJj7p++7AgfeFv7avqCdVyUunxI7SpPoKbzeu8Iq5HsiVxM!TKdwKFg5H0/3cTlLCsqOFteipDXSufwxDo5CZ7diH+wJDWaBpb1gGgP243h+3i9WxLRuwMRL0Mwr
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: 4274
 by: olcott - Tue, 7 Jun 2022 14:20 UTC

On 6/7/2022 6:30 AM, Malcolm McLean wrote:
> On Tuesday, 7 June 2022 at 12:17:05 UTC+1, richar...@gmail.com wrote:
>> On 6/6/22 11:49 PM, olcott wrote:
>>> On 6/6/2022 1:36 PM, Ben wrote:
>>>> wij <wyni...@gmail.com> writes:
>>>>
>>>>> Students of average level understand Halting decider cannot exist, as
>>>>> olcott
>>>>> has demonstrated for years (no 'correct' H exists).
>>>>>
>>>>> If H does not exist, what dose "H(P,P)==0" mean?
>>>>
>>>> H as specified in, say, Linz does not exist. But PO's H does and so P
>>>> (which should really be called something like H_Hat) also exists.
>>>> That's why H is wrong about the "halting" of P(P).
>>>>
>>>> Another way to write the proof is to show that every Turing machine gets
>>>> at least one instance wrong -- i.e. that no TM computes the halting
>>>> function. PO's H is just an example of that, and he even tells us that
>>>> it gets the instance representing P(P) wrong.
>>>>
>>>
>>> Since you know that
>>>
>>> (1) Deciders in computer science compute the mapping from their inputs
>>> to an accept or reject state.
>>>
>>> (2) P(P) is not an input to H
>>>
>>> Why do you persist in the deception that H must compute the halt status
>>> of P(P) ?
>>>
>> But P(P) IS an input to H via its representation being given to H.
>>
>> If you want to say that you can't actually give a computation to a
>> Turing Machine then the Halting Theorem is trivially proven true.
>>
> x86 is von Neumann architecture. So stored programs can be manipulated
> as data. In PO's system, H is passed a pointer to the actual machine code of
> P. PO is trying to draw a distinction between P when it is called, and P
> when it is passed to H. I think Ben might have been a bit over-pedantic
> with him and he might have misunderstood what Ben was saying.
>
> WIth Turing machines, you can't pass an actual machine. You can only
> provide a description of a machine, on the tape. A Turing machine has
> no access to its own states, and it cannot examine another Turing machine.
> This isn't true of x86 programs.
> The distinction shouldn't be important, but there seems to be some confusion
> somewhere.

A simulating halt decider based on an x86 emulator or a UTM is the same
idea and fundamentally works the same way.

It is the case that P(P) is not and cannot be an input to H(P,P) because
the input to H(P,P) has a pathological self-reference relationship to H
and P(P) has no such relationship.

The correct and complete simulation of the input to HP(P,P) is stuck in
infinitely nested simulation and P(P) halts.

--
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: Competent software engineers will agree that H(P,P)==0 is correct [ deception ]

<CzSnK.213767$zgr9.55842@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.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: Competent software engineers will agree that H(P,P)==0 is correct [ deception ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <N5-dnal-trqPgQP_nZ2dnUU7_83NnZ2d@giganews.com> <d25678aa-3764-4027-9076-c6b372e290e7n@googlegroups.com> <875yldljuz.fsf@bsb.me.uk> <t7mhs0$ctl$1@dont-email.me> <OsGnK.43377$elob.8187@fx43.iad> <211565cd-e73c-4069-90b9-057e4f21888bn@googlegroups.com> <uOGdnZ4qXfgIwwL_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <uOGdnZ4qXfgIwwL_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 105
Message-ID: <CzSnK.213767$zgr9.55842@fx13.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: Tue, 7 Jun 2022 21:03:30 -0400
X-Received-Bytes: 5633
 by: Richard Damon - Wed, 8 Jun 2022 01:03 UTC

On 6/7/22 10:20 AM, olcott wrote:
> On 6/7/2022 6:30 AM, Malcolm McLean wrote:
>> On Tuesday, 7 June 2022 at 12:17:05 UTC+1, richar...@gmail.com wrote:
>>> On 6/6/22 11:49 PM, olcott wrote:
>>>> On 6/6/2022 1:36 PM, Ben wrote:
>>>>> wij <wyni...@gmail.com> writes:
>>>>>
>>>>>> Students of average level understand Halting decider cannot exist, as
>>>>>> olcott
>>>>>> has demonstrated for years (no 'correct' H exists).
>>>>>>
>>>>>> If H does not exist, what dose "H(P,P)==0" mean?
>>>>>
>>>>> H as specified in, say, Linz does not exist.  But PO's H does and so P
>>>>> (which should really be called something like H_Hat) also exists.
>>>>> That's why H is wrong about the "halting" of P(P).
>>>>>
>>>>> Another way to write the proof is to show that every Turing machine
>>>>> gets
>>>>> at least one instance wrong -- i.e. that no TM computes the halting
>>>>> function.  PO's H is just an example of that, and he even tells us
>>>>> that
>>>>> it gets the instance representing P(P) wrong.
>>>>>
>>>>
>>>> Since you know that
>>>>
>>>> (1) Deciders in computer science compute the mapping from their inputs
>>>> to an accept or reject state.
>>>>
>>>> (2) P(P) is not an input to H
>>>>
>>>> Why do you persist in the deception that H must compute the halt status
>>>> of P(P) ?
>>>>
>>> But P(P) IS an input to H via its representation being given to H.
>>>
>>> If you want to say that you can't actually give a computation to a
>>> Turing Machine then the Halting Theorem is trivially proven true.
>>>
>> x86 is von Neumann architecture. So stored programs can be manipulated
>> as data. In PO's system, H is passed a pointer to the actual machine
>> code of
>> P.  PO is trying to draw a distinction between P when it is called, and P
>> when it is passed to H. I think Ben might have been a bit over-pedantic
>> with him and he might have misunderstood what Ben was saying.
>>
>> WIth Turing machines, you can't pass an actual machine. You can only
>> provide a description of  a machine, on the tape. A Turing machine has
>> no access to its own states, and it cannot examine another Turing
>> machine.
>> This isn't true of x86 programs.
>> The distinction shouldn't be important, but there seems to be some
>> confusion
>> somewhere.
>
> A simulating halt decider based on an x86 emulator or a UTM is the same
> idea and fundamentally works the same way.
>
> It is the case that P(P) is not and cannot be an input to H(P,P) because
> the input to H(P,P) has a pathological self-reference relationship to H
> and P(P) has no such relationship.

Maybe in your construction of H/P you have created an actual
self-reference BECAUSE You have built H and P incorrectly.

In the ACTUAL H / H^ case, there is NO SELF-reference because nothing is
built to actually refer to itself.

H is a decider that can take in a description of any machine and an input

H^ is a machine that can take in a description of any machine.

NONE of this code EVER actually refers to itself.

When we build the input, the representation of H^, that doesn't ACTUALLY
"refer" to H^, but is just a description of it. There is NOTHING in that
input that tells H^ or H that this input "refers" to either of those.

So, the fact that you claim that H(P,P) has a "pathological
self-reference" says that you must have built something wrong, and the
obvious part of that is that you didn't build P with the COPY of H as
required, and in fact P calling the H that is deciding it actually makes
the problem DIFFERENT than the pattern described, and breaks the rules
of forming computations, you no longer have two distinct machines and an
input, the H deciding, the P whose representation is being decided on
and the copy of the representaiton of P that is the input to the P.

THAT makes the "self-reference" and makes your setup incorrect.

The fact that you can't see this just shows the level of your understand
of even the basics of Computer Science.

>
> The correct and complete simulation of the input to HP(P,P) is stuck in
> infinitely nested simulation and P(P) halts.
>

Only if H(P,P) never aborts, and if it never aborts it never answers and
thus is wrong.

ALL H(P,P) need to behave the same, so somewhere you are lying when you
say that H(P,P) actually returns a 0 and also creates an infinitely
nested simulation.

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor