Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Work continues in this area. -- DEC's SPR-Answering-Automaton


devel / comp.theory / Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

SubjectAuthor
* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ keyolcott
+- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
+- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
 `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |+* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Malcolm McLean
    ||`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    || `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Malcolm McLean
    ||  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    ||   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    ||   |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    ||   | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    ||   |  `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    ||   `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    | |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    | |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    | |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | |     `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |     +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |     `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |      +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |      |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |      | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |      |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |      |   `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |      `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |       `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |   |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |+- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
    |   |        |    |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |     `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Jeff Barnett
    |   |        |    |      |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Jeff Barnett
    |   |        |    |      |   |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |     `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |      `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |       +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |       |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |       `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |      |   `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |      `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |       `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |        `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |         `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |          +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |          `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |           `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |            |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Dennis Bush
    |   |        |    |            | |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
    |   |        |    |            | | |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | | | +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
    |   |        |    |            | | | `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |            | | `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |            | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |            | |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |            `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |             +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Malcolm McLean
    |   |        |    |             `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |              `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |               `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |                `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |                 `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Andy Walker
    `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse

Pages:12345678910111213141516171819202122232425262728293031323334353637383940
Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29571&group=comp.theory#29571

 copy link   Newsgroups: comp.theory
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, 06 Apr 2022 20:47:33 -0500
Date: Wed, 6 Apr 2022 20:47:32 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d847hkd.fsf@bsb.me.uk> <UeadnWsKI5oqzNb_nZ2dnUU7_83NnZ2d@giganews.com>
<87r16c5tm0.fsf@bsb.me.uk> <4dSdnWjHVszE4tb_nZ2dnUU7_8zNnZ2d@giganews.com>
<87lewk5otp.fsf@bsb.me.uk> <leidnWIfpu2XBtb_nZ2dnUU7_83NnZ2d@giganews.com>
<874k3761bq.fsf@bsb.me.uk> <yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87k0c33rk3.fsf@bsb.me.uk> <9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81e3mso.fsf@bsb.me.uk> <eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk> <t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <t2lffh$m4b$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 91
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-bXWWye2mjd/r5WpM1IgHKlcoo0yIixYGCpqzrtbNgaBGYOKVuE/yqU1KbEcYi+/W0Z5ZLLfBTcLVl7z!ixdtiZxUKvy/hSzpQZ6yA92wwg8YB4kaMWru6lGoE5qhh0AgC3B0d+dovXuK8lQsI97gg8BUahZN!DQ==
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: 5519
 by: olcott - Thu, 7 Apr 2022 01:47 UTC

On 4/6/2022 8:41 PM, André G. Isaak wrote:
> On 2022-04-06 19:25, olcott wrote:
>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>> On 2022-04-06 19:10, olcott wrote:
>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>
>>>>> But, now that we've got that out of the way, here's a simple
>>>>> question for you: If you want your evenness decider to decide
>>>>> whether seven is even, which string would you pass to it? [yes, I
>>>>> know this is trivially obvious, just humour me]
>>>>>
>>>>> André
>>>>
>>>> 111[]
>>>
>>> I'm assuming that you're using [] to indicate a blank.
>>>
>>> Presumably your E would *reject* this string since seven is an odd
>>> number rather than an even one.
>>>
>>> But notice that in the above case your Turing Machine is rejecting a
>>> finite string "111␣" based on the fact that the *integer* seven,
>>> which is neither an input nor a finite string, is not even.
>>>
>>> So your decider is mapping from a finite string (its input) to
>>> reject/accept based on something which is a "non-input non-finite
>>> string" (to use an expression you've often used).
>>>
>>
>> That seems totally incoherent.
>>
>> The TM maps its input finite string to its reject state based on a
>> property of this finite string.
>
>
> But 'evenness' is not a property of strings; it is a property of
> numbers, and strings are not numbers.
>

It can be correctly construed as the property of the string.

> Your decider bases its decision on a property of the string (is the
> final digit 0?), but that property only corresponds to evenness by
> virtue of the encoding you have chosen.
>
> A decider which uses a unary representation (which would be slightly
> simpler than your binary one) couldn't just look at a single digit. Nor

Thus not actually simpler.

> could one that used trinary representation (which would be only slightly
> more complex than your binary one).
>
> What makes all three of these valid evenness deciders is that they
> conform to the specification of an evenness decider:
>
> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
> E.q0 S ⊦* E.qn otherwise.
>
> Yes, the TM maps a finite string to an accept/reject state, but this
> mapping is based on the property of the *number* which that string
> encodes. That number is not an input, but because it can be encoded as a
> string we can still legitimately expect a Turing Machine to answer
> questions about that number.
>

It can be construed as a property of the string.

> Talking about a finite string as being even or odd is completely
> meaningless. Only numbers can be even or odd. Yet there is no problem in
> constructing such a decider.
>

The string has the "even binary integer" property.

> Similarly, there is no problem creating a TM which answers questions
> about other Turing Machines even though TMs take only strings and not
> Turing Machines as their input. As long as it is possible to encode a
> Turing Machine as a string (which it is), a decider can answer questions
> about it.
>
> André
>

--
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: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<877d81ek89.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29572&group=comp.theory#29572

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]
Date: Thu, 07 Apr 2022 02:49:10 +0100
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <877d81ek89.fsf@bsb.me.uk>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<VMSdneUyrJVin9f_nZ2dnUU7_83NnZ2d@giganews.com>
<871qydde5e.fsf@bsb.me.uk>
<w-edndUxIuQ1h9f_nZ2dnUU7_83NnZ2d@giganews.com>
<w-edndQxIuTUhtf_nZ2dnUU7_81g4p2d@giganews.com>
<87ilrpbwrt.fsf@bsb.me.uk>
<n72dnae_RMuWrdf_nZ2dnUU7_83NnZ2d@giganews.com>
<877d85buic.fsf@bsb.me.uk> <t2eghp$5n3$1@gioia.aioe.org>
<8735it7zaj.fsf@bsb.me.uk> <t2hsgu$mmd$1@gioia.aioe.org>
<878rsj3rdn.fsf@bsb.me.uk> <t2k1bu$1srt$1@gioia.aioe.org>
<87y20iguq6.fsf@bsb.me.uk>
<Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk>
<5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="9875e55d8daa06cc2a53aa953015877e";
logging-data="21166"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19gr/CP3Ky0Lc426XO/Vey7nRfWmLBoR4k="
Cancel-Lock: sha1:Z1ZNPipwYIZKFP1IvgivZcEdFhA=
sha1:g7VOUo3a5uAqh+OC+4sR8fbW9b0=
X-BSB-Auth: 1.b7d5c13a448dadd69c06.20220407024910BST.877d81ek89.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 7 Apr 2022 01:49 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/6/2022 7:34 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/6/2022 6:35 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/6/2022 4:36 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/6/2022 9:19 AM, Ben Bacarisse wrote:
>>>>
>>>>>>>> As for the main mistake, I know enough about cranks to aim for only one
>>>>>>>> of two things: can they be persuaded to say enough to show others that
>>>>>>>> they are wrong (for example PO admission that H(P,P) == false is correct
>>>>>>>> despite the fact that P(P) halts),
>>>>>>>
>>>>>>> If it is the case that the simulated input to H cannot possibly reach
>>>>>>> its own final state under any condition what-so-ever then H correctly
>>>>>>> maps this finite string input to its reject state and nothing in the
>>>>>>> universe can correctly contradict that H is correct.
>>>>>>>
>>>>>>> If you have a white dog in your living room and everyone in the
>>>>>>> universe disagrees, you still have a white dog in your living room.
>>>>>>
>>>>>> Good to see that you are still asserting that false is the correct
>>>>>> result from a halt decider for at least one halting computation.
>>>>>
>>>>> If the input to the halt decider specifies a non-halting sequence of
>>>>> configurations then any damn thing anywhere else is totally
>>>>> irrelevant.
>>>> If P(P) halts, H(P,P) should be true.
>>>
>>> Like I said any damn thing else is actually 100% perfectly totally
>>> irrelevant.
>> Yes! The only thing that matters is whether the "input", (P,P),
>> specifies a halting computation or not.
>>
>>>> The "input" to H is two
>>>> parameters that specify the halting computation P(P).
>>>
>>> A halting computation that cannot possibly reach its own final state
>>> under any condition what-so-ever?
>> Either P(P) halts or it does not. Did you tell a fib when you said it
>> does? Since it halts, H(P,P) == false is wrong.
>>
>>> The input to H(P,P) cannot possibly reach its own final state under
>>> any condition what-so-ever, thus if God and all his angels and every
>>> being great and small said that the input to H specifies a halting
>>> computation they would all be liars.
>> You told that us P(P) halts. Until you retract that, I will take it to
>> be true. You also told us that H(P,P) == false. Do you need to correct
>> one or other of these statements?
>
> As long as the input to H(P,P) never reaches its final state under any
> condition what-so-ever then no matter what P(P) does H was still
> correct because P(P) is not an input and H is only accountable for
> getting its inputs correctly.

So what two arguments must be passed to H to get H to tell us whether
P(P) halts or not? (Already asked, of course, but you a dodging this
issue for obvious reasons.)

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29573&group=comp.theory#29573

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!rocksolid2!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 06 Apr 2022 20:58:08 -0500
Date: Wed, 6 Apr 2022 20:58:08 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<VMSdneUyrJVin9f_nZ2dnUU7_83NnZ2d@giganews.com> <871qydde5e.fsf@bsb.me.uk>
<w-edndUxIuQ1h9f_nZ2dnUU7_83NnZ2d@giganews.com>
<w-edndQxIuTUhtf_nZ2dnUU7_81g4p2d@giganews.com> <87ilrpbwrt.fsf@bsb.me.uk>
<n72dnae_RMuWrdf_nZ2dnUU7_83NnZ2d@giganews.com> <877d85buic.fsf@bsb.me.uk>
<t2eghp$5n3$1@gioia.aioe.org> <8735it7zaj.fsf@bsb.me.uk>
<t2hsgu$mmd$1@gioia.aioe.org> <878rsj3rdn.fsf@bsb.me.uk>
<t2k1bu$1srt$1@gioia.aioe.org> <87y20iguq6.fsf@bsb.me.uk>
<Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81dgah5.fsf@bsb.me.uk>
<5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com> <87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com> <87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <877d81ek89.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 96
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-nEalurC+O98e6D4i8RfNXvY3SkU6eNYvp5saVvzP4iBu6M4HfUojfg1nX1rcrj0reQOP/yNBKaTuB1+!TKX9Ua7JtfLyU5xb1YRGB4IZGb1JuzHgBrXMU063e1hB1D3yOMhB7j0PhKxyTW1Ktf6ZTKdBuTjo!MQ==
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: 6228
 by: olcott - Thu, 7 Apr 2022 01:58 UTC

On 4/6/2022 8:49 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/6/2022 7:34 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/6/2022 6:35 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/6/2022 4:36 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/6/2022 9:19 AM, Ben Bacarisse wrote:
>>>>>
>>>>>>>>> As for the main mistake, I know enough about cranks to aim for only one
>>>>>>>>> of two things: can they be persuaded to say enough to show others that
>>>>>>>>> they are wrong (for example PO admission that H(P,P) == false is correct
>>>>>>>>> despite the fact that P(P) halts),
>>>>>>>>
>>>>>>>> If it is the case that the simulated input to H cannot possibly reach
>>>>>>>> its own final state under any condition what-so-ever then H correctly
>>>>>>>> maps this finite string input to its reject state and nothing in the
>>>>>>>> universe can correctly contradict that H is correct.
>>>>>>>>
>>>>>>>> If you have a white dog in your living room and everyone in the
>>>>>>>> universe disagrees, you still have a white dog in your living room.
>>>>>>>
>>>>>>> Good to see that you are still asserting that false is the correct
>>>>>>> result from a halt decider for at least one halting computation.
>>>>>>
>>>>>> If the input to the halt decider specifies a non-halting sequence of
>>>>>> configurations then any damn thing anywhere else is totally
>>>>>> irrelevant.
>>>>> If P(P) halts, H(P,P) should be true.
>>>>
>>>> Like I said any damn thing else is actually 100% perfectly totally
>>>> irrelevant.
>>> Yes! The only thing that matters is whether the "input", (P,P),
>>> specifies a halting computation or not.
>>>
>>>>> The "input" to H is two
>>>>> parameters that specify the halting computation P(P).
>>>>
>>>> A halting computation that cannot possibly reach its own final state
>>>> under any condition what-so-ever?
>>> Either P(P) halts or it does not. Did you tell a fib when you said it
>>> does? Since it halts, H(P,P) == false is wrong.
>>>
>>>> The input to H(P,P) cannot possibly reach its own final state under
>>>> any condition what-so-ever, thus if God and all his angels and every
>>>> being great and small said that the input to H specifies a halting
>>>> computation they would all be liars.
>>> You told that us P(P) halts. Until you retract that, I will take it to
>>> be true. You also told us that H(P,P) == false. Do you need to correct
>>> one or other of these statements?
>>
>> As long as the input to H(P,P) never reaches its final state under any
>> condition what-so-ever then no matter what P(P) does H was still
>> correct because P(P) is not an input and H is only accountable for
>> getting its inputs correctly.
>
> So what two arguments must be passed to H to get H to tell us whether
> P(P) halts or not? (Already asked, of course, but you a dodging this
> issue for obvious reasons.)
>

You won't understand what I am saying until you first understand that
your question has nothing to do with the correctness of the rejection of
the input.

I am referring to a point that is so subtle that no one ever noticed
this subtle point for 90 years.

I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
I WILL KEEP REPEATING THIS UNTIL YOU RESPOND

As long as the input to H(P,P) never reaches its final state under any
condition what-so-ever then no matter what P(P) does H was still correct
because P(P) is not an input and H is only accountable for getting its
inputs correctly.

If a guard is assigned to watch the front door and no one comes in the
front door and thousands of people come in the back door the guard is
correct to say that no one came in the front door.

The input to H is its front door that it must guard. What P(P) does when
it is not an input is all back door stuff and none of the business of
any decider.

--
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: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<t2lgpi$a5h$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29574&group=comp.theory#29574

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Date: Wed, 6 Apr 2022 20:03:29 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 97
Message-ID: <t2lgpi$a5h$1@dont-email.me>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87r16c5tm0.fsf@bsb.me.uk> <4dSdnWjHVszE4tb_nZ2dnUU7_8zNnZ2d@giganews.com>
<87lewk5otp.fsf@bsb.me.uk> <leidnWIfpu2XBtb_nZ2dnUU7_83NnZ2d@giganews.com>
<874k3761bq.fsf@bsb.me.uk> <yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87k0c33rk3.fsf@bsb.me.uk> <9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81e3mso.fsf@bsb.me.uk> <eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk> <t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me> <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 7 Apr 2022 02:03:31 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="12651d4b4861d86e6d7c5491f3f6b544";
logging-data="10417"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/xvpZDY+D+CE9YH27q3MSw"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:pcNB+ZRQ7yITh3HeGhLaoyEY1Ec=
In-Reply-To: <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 7 Apr 2022 02:03 UTC

On 2022-04-06 19:47, olcott wrote:
> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>> On 2022-04-06 19:25, olcott wrote:
>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>> On 2022-04-06 19:10, olcott wrote:
>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>
>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>> question for you: If you want your evenness decider to decide
>>>>>> whether seven is even, which string would you pass to it? [yes, I
>>>>>> know this is trivially obvious, just humour me]
>>>>>>
>>>>>> André
>>>>>
>>>>> 111[]
>>>>
>>>> I'm assuming that you're using [] to indicate a blank.
>>>>
>>>> Presumably your E would *reject* this string since seven is an odd
>>>> number rather than an even one.
>>>>
>>>> But notice that in the above case your Turing Machine is rejecting a
>>>> finite string "111␣" based on the fact that the *integer* seven,
>>>> which is neither an input nor a finite string, is not even.
>>>>
>>>> So your decider is mapping from a finite string (its input) to
>>>> reject/accept based on something which is a "non-input non-finite
>>>> string" (to use an expression you've often used).
>>>>
>>>
>>> That seems totally incoherent.
>>>
>>> The TM maps its input finite string to its reject state based on a
>>> property of this finite string.
>>
>>
>> But 'evenness' is not a property of strings; it is a property of
>> numbers, and strings are not numbers.
>>
>
> It can be correctly construed as the property of the string.

Not by any normal definition.

A string is an *uninterpreted* sequence of symbols.

>> Your decider bases its decision on a property of the string (is the
>> final digit 0?), but that property only corresponds to evenness by
>> virtue of the encoding you have chosen.
>>
>> A decider which uses a unary representation (which would be slightly
>> simpler than your binary one) couldn't just look at a single digit. Nor
>
> Thus not actually simpler.

If you actually attempted to write the two versions of E, you'd discover
that you are simply wrong in this assessment. The fact that you don't
realize this is merely a testament to the fact that you really don't
understand how Turing Machines work. At all.

>> could one that used trinary representation (which would be only
>> slightly more complex than your binary one).
>>
>> What makes all three of these valid evenness deciders is that they
>> conform to the specification of an evenness decider:
>>
>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>> E.q0 S ⊦* E.qn otherwise.
>>
>> Yes, the TM maps a finite string to an accept/reject state, but this
>> mapping is based on the property of the *number* which that string
>> encodes. That number is not an input, but because it can be encoded as
>> a string we can still legitimately expect a Turing Machine to answer
>> questions about that number.
>>
>
> It can be construed as a property of the string.

No. It cannot be. Properties of a string would include things like
'length', 'number of distinct symbols', 'is it a palindrome?', etc.
Evenness is not one of those properties.

>> Talking about a finite string as being even or odd is completely
>> meaningless. Only numbers can be even or odd. Yet there is no problem
>> in constructing such a decider.
>>
>
> The string has the "even binary integer" property.

No. As soon as you start assigning numerical values to a string (or even
to the individual symbols of a string) you are no longer treating it
purely as a string. You are considering the information which is encoded
in that string, which is a separate matter.

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<a6c81bc4-203b-442a-81af-9dc2b53cd624n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29575&group=comp.theory#29575

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:620a:95c:b0:680:e024:5336 with SMTP id w28-20020a05620a095c00b00680e0245336mr7902795qkw.690.1649297072539;
Wed, 06 Apr 2022 19:04:32 -0700 (PDT)
X-Received: by 2002:a05:690c:39a:b0:2e6:d7e2:c66c with SMTP id
bh26-20020a05690c039a00b002e6d7e2c66cmr10336498ywb.482.1649297072336; Wed, 06
Apr 2022 19:04:32 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Wed, 6 Apr 2022 19:04:32 -0700 (PDT)
In-Reply-To: <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<VMSdneUyrJVin9f_nZ2dnUU7_83NnZ2d@giganews.com> <871qydde5e.fsf@bsb.me.uk>
<w-edndUxIuQ1h9f_nZ2dnUU7_83NnZ2d@giganews.com> <w-edndQxIuTUhtf_nZ2dnUU7_81g4p2d@giganews.com>
<87ilrpbwrt.fsf@bsb.me.uk> <n72dnae_RMuWrdf_nZ2dnUU7_83NnZ2d@giganews.com>
<877d85buic.fsf@bsb.me.uk> <t2eghp$5n3$1@gioia.aioe.org> <8735it7zaj.fsf@bsb.me.uk>
<t2hsgu$mmd$1@gioia.aioe.org> <878rsj3rdn.fsf@bsb.me.uk> <t2k1bu$1srt$1@gioia.aioe.org>
<87y20iguq6.fsf@bsb.me.uk> <Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a6c81bc4-203b-442a-81af-9dc2b53cd624n@googlegroups.com>
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Thu, 07 Apr 2022 02:04:32 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 99
 by: Dennis Bush - Thu, 7 Apr 2022 02:04 UTC

On Wednesday, April 6, 2022 at 9:58:16 PM UTC-4, olcott wrote:
> On 4/6/2022 8:49 PM, Ben Bacarisse wrote:
> > olcott <No...@NoWhere.com> writes:
> >
> >> On 4/6/2022 7:34 PM, Ben Bacarisse wrote:
> >>> olcott <No...@NoWhere.com> writes:
> >>>
> >>>> On 4/6/2022 6:35 PM, Ben Bacarisse wrote:
> >>>>> olcott <No...@NoWhere.com> writes:
> >>>>>
> >>>>>> On 4/6/2022 4:36 PM, Ben Bacarisse wrote:
> >>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>
> >>>>>>>> On 4/6/2022 9:19 AM, Ben Bacarisse wrote:
> >>>>>
> >>>>>>>>> As for the main mistake, I know enough about cranks to aim for only one
> >>>>>>>>> of two things: can they be persuaded to say enough to show others that
> >>>>>>>>> they are wrong (for example PO admission that H(P,P) == false is correct
> >>>>>>>>> despite the fact that P(P) halts),
> >>>>>>>>
> >>>>>>>> If it is the case that the simulated input to H cannot possibly reach
> >>>>>>>> its own final state under any condition what-so-ever then H correctly
> >>>>>>>> maps this finite string input to its reject state and nothing in the
> >>>>>>>> universe can correctly contradict that H is correct.
> >>>>>>>>
> >>>>>>>> If you have a white dog in your living room and everyone in the
> >>>>>>>> universe disagrees, you still have a white dog in your living room.
> >>>>>>>
> >>>>>>> Good to see that you are still asserting that false is the correct
> >>>>>>> result from a halt decider for at least one halting computation.
> >>>>>>
> >>>>>> If the input to the halt decider specifies a non-halting sequence of
> >>>>>> configurations then any damn thing anywhere else is totally
> >>>>>> irrelevant.
> >>>>> If P(P) halts, H(P,P) should be true.
> >>>>
> >>>> Like I said any damn thing else is actually 100% perfectly totally
> >>>> irrelevant.
> >>> Yes! The only thing that matters is whether the "input", (P,P),
> >>> specifies a halting computation or not.
> >>>
> >>>>> The "input" to H is two
> >>>>> parameters that specify the halting computation P(P).
> >>>>
> >>>> A halting computation that cannot possibly reach its own final state
> >>>> under any condition what-so-ever?
> >>> Either P(P) halts or it does not. Did you tell a fib when you said it
> >>> does? Since it halts, H(P,P) == false is wrong.
> >>>
> >>>> The input to H(P,P) cannot possibly reach its own final state under
> >>>> any condition what-so-ever, thus if God and all his angels and every
> >>>> being great and small said that the input to H specifies a halting
> >>>> computation they would all be liars.
> >>> You told that us P(P) halts. Until you retract that, I will take it to
> >>> be true. You also told us that H(P,P) == false. Do you need to correct
> >>> one or other of these statements?
> >>
> >> As long as the input to H(P,P) never reaches its final state under any
> >> condition what-so-ever then no matter what P(P) does H was still
> >> correct because P(P) is not an input and H is only accountable for
> >> getting its inputs correctly.
> >
> > So what two arguments must be passed to H to get H to tell us whether
> > P(P) halts or not? (Already asked, of course, but you a dodging this
> > issue for obvious reasons.)
> >
> You won't understand what I am saying until you first understand that
> your question has nothing to do with the correctness of the rejection of
> the input.
>
> I am referring to a point that is so subtle that no one ever noticed
> this subtle point for 90 years.
>
> I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
> I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
> I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
> As long as the input to H(P,P) never reaches its final state under any
> condition what-so-ever then no matter what P(P) does H was still correct
> because P(P) is not an input and H is only accountable for getting its
> inputs correctly.

UTM(P,P) is a condition where the input reaches a final state. So your claim that "the input to H(P,P) never reaches its final state under any condition what-so-ever" is false.

> If a guard is assigned to watch the front door and no one comes in the
> front door and thousands of people come in the back door the guard is
> correct to say that no one came in the front door.

Except the guard was actually assigned the back door but he took it upon himself to guard the front door because guarding the back door didn't make sense to him.

>
> The input to H is its front door that it must guard. What P(P) does when
> it is not an input is all back door stuff and none of the business of
> any decider.
>
> --
> 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: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29576&group=comp.theory#29576

 copy link   Newsgroups: comp.theory
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, 06 Apr 2022 21:10:38 -0500
Date: Wed, 6 Apr 2022 21:10:37 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<4dSdnWjHVszE4tb_nZ2dnUU7_8zNnZ2d@giganews.com> <87lewk5otp.fsf@bsb.me.uk>
<leidnWIfpu2XBtb_nZ2dnUU7_83NnZ2d@giganews.com> <874k3761bq.fsf@bsb.me.uk>
<yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com> <87k0c33rk3.fsf@bsb.me.uk>
<9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81e3mso.fsf@bsb.me.uk>
<eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com> <877d822zfj.fsf@bsb.me.uk>
<t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com> <t2l84o$12q$1@dont-email.me>
<RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com> <t2l9u5$s78$1@dont-email.me>
<cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com> <t2lbfp$l03$1@dont-email.me>
<ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lchk$69m$1@dont-email.me>
<ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com> <t2le3m$ucg$1@dont-email.me>
<0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lffh$m4b$1@dont-email.me>
<-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com> <t2lgpi$a5h$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <t2lgpi$a5h$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 105
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-DFtjydy4bqzGUfOBskp4MDLsLUcMm+As0tRfqcNS3EnWwUtlJliTVNnDIogFk09poh93x6VaopsS14/!0JASrCu1/spB+UKsI5B+MI4YWnfIIjtuwshZzMv++LlBYIIM4z2h4ABSqwawCaGE/sbXiB5Hldgn!Jw==
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: 6350
 by: olcott - Thu, 7 Apr 2022 02:10 UTC

On 4/6/2022 9:03 PM, André G. Isaak wrote:
> On 2022-04-06 19:47, olcott wrote:
>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>> On 2022-04-06 19:25, olcott wrote:
>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>
>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>> whether seven is even, which string would you pass to it? [yes, I
>>>>>>> know this is trivially obvious, just humour me]
>>>>>>>
>>>>>>> André
>>>>>>
>>>>>> 111[]
>>>>>
>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>
>>>>> Presumably your E would *reject* this string since seven is an odd
>>>>> number rather than an even one.
>>>>>
>>>>> But notice that in the above case your Turing Machine is rejecting
>>>>> a finite string "111␣" based on the fact that the *integer* seven,
>>>>> which is neither an input nor a finite string, is not even.
>>>>>
>>>>> So your decider is mapping from a finite string (its input) to
>>>>> reject/accept based on something which is a "non-input non-finite
>>>>> string" (to use an expression you've often used).
>>>>>
>>>>
>>>> That seems totally incoherent.
>>>>
>>>> The TM maps its input finite string to its reject state based on a
>>>> property of this finite string.
>>>
>>>
>>> But 'evenness' is not a property of strings; it is a property of
>>> numbers, and strings are not numbers.
>>>
>>
>> It can be correctly construed as the property of the string.
>
> Not by any normal definition.
>
> A string is an *uninterpreted* sequence of symbols.
>
>>> Your decider bases its decision on a property of the string (is the
>>> final digit 0?), but that property only corresponds to evenness by
>>> virtue of the encoding you have chosen.
>>>
>>> A decider which uses a unary representation (which would be slightly
>>> simpler than your binary one) couldn't just look at a single digit. Nor
>>
>> Thus not actually simpler.
>
> If you actually attempted to write the two versions of E, you'd discover
> that you are simply wrong in this assessment. The fact that you don't
> realize this is merely a testament to the fact that you really don't
> understand how Turing Machines work. At all.
>
>>> could one that used trinary representation (which would be only
>>> slightly more complex than your binary one).
>>>
>>> What makes all three of these valid evenness deciders is that they
>>> conform to the specification of an evenness decider:
>>>
>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>>> E.q0 S ⊦* E.qn otherwise.
>>>
>>> Yes, the TM maps a finite string to an accept/reject state, but this
>>> mapping is based on the property of the *number* which that string
>>> encodes. That number is not an input, but because it can be encoded
>>> as a string we can still legitimately expect a Turing Machine to
>>> answer questions about that number.
>>>
>>
>> It can be construed as a property of the string.
>
> No. It cannot be. Properties of a string would include things like
> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
> Evenness is not one of those properties.
>
>>> Talking about a finite string as being even or odd is completely
>>> meaningless. Only numbers can be even or odd. Yet there is no problem
>>> in constructing such a decider.
>>>
>>
>> The string has the "even binary integer" property.
>
> No. As soon as you start assigning numerical values to a string (or even
> to the individual symbols of a string) you are no longer treating it
> purely as a string. You are considering the information which is encoded
> in that string, which is a separate matter.
>

The all has to do with mathematicaly fomrmalizing semantic meanings.
Finite strings can have semantic properties.

--
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: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<NLr3K.5090$n41.45@fx35.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29577&group=comp.theory#29577

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx35.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.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<VMSdneUyrJVin9f_nZ2dnUU7_83NnZ2d@giganews.com> <871qydde5e.fsf@bsb.me.uk>
<w-edndUxIuQ1h9f_nZ2dnUU7_83NnZ2d@giganews.com>
<w-edndQxIuTUhtf_nZ2dnUU7_81g4p2d@giganews.com> <87ilrpbwrt.fsf@bsb.me.uk>
<n72dnae_RMuWrdf_nZ2dnUU7_83NnZ2d@giganews.com> <877d85buic.fsf@bsb.me.uk>
<t2eghp$5n3$1@gioia.aioe.org> <8735it7zaj.fsf@bsb.me.uk>
<t2hsgu$mmd$1@gioia.aioe.org> <878rsj3rdn.fsf@bsb.me.uk>
<t2k1bu$1srt$1@gioia.aioe.org> <87y20iguq6.fsf@bsb.me.uk>
<Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81dgah5.fsf@bsb.me.uk>
<5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com> <87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com> <87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 130
Message-ID: <NLr3K.5090$n41.45@fx35.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, 6 Apr 2022 22:11:56 -0400
X-Received-Bytes: 7173
 by: Richard Damon - Thu, 7 Apr 2022 02:11 UTC

On 4/6/22 9:58 PM, olcott wrote:
> On 4/6/2022 8:49 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/6/2022 7:34 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/6/2022 6:35 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/6/2022 4:36 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/6/2022 9:19 AM, Ben Bacarisse wrote:
>>>>>>
>>>>>>>>>> As for the main mistake, I know enough about cranks to aim for
>>>>>>>>>> only one
>>>>>>>>>> of two things: can they be persuaded to say enough to show
>>>>>>>>>> others that
>>>>>>>>>> they are wrong (for example PO admission that H(P,P) == false
>>>>>>>>>> is correct
>>>>>>>>>> despite the fact that P(P) halts),
>>>>>>>>>
>>>>>>>>> If it is the case that the simulated input to H cannot possibly
>>>>>>>>> reach
>>>>>>>>> its own final state under any condition what-so-ever then H
>>>>>>>>> correctly
>>>>>>>>> maps this finite string input to its reject state and nothing
>>>>>>>>> in the
>>>>>>>>> universe can correctly contradict that H is correct.
>>>>>>>>>
>>>>>>>>> If you have a white dog in your living room and everyone in the
>>>>>>>>> universe disagrees, you still have a white dog in your living
>>>>>>>>> room.
>>>>>>>>
>>>>>>>> Good to see that you are still asserting that false is the correct
>>>>>>>> result from a halt decider for at least one halting computation.
>>>>>>>
>>>>>>> If the input to the halt decider specifies a non-halting sequence of
>>>>>>> configurations then any damn thing anywhere else is totally
>>>>>>> irrelevant.
>>>>>> If P(P) halts, H(P,P) should be true.
>>>>>
>>>>> Like I said any damn thing else is actually 100% perfectly totally
>>>>> irrelevant.
>>>> Yes!  The only thing that matters is whether the "input", (P,P),
>>>> specifies a halting computation or not.
>>>>
>>>>>> The "input" to H is two
>>>>>> parameters that specify the halting computation P(P).
>>>>>
>>>>> A halting computation that cannot possibly reach its own final state
>>>>> under any condition what-so-ever?
>>>> Either P(P) halts or it does not.  Did you tell a fib when you said it
>>>> does?  Since it halts, H(P,P) == false is wrong.
>>>>
>>>>> The input to H(P,P) cannot possibly reach its own final state under
>>>>> any condition what-so-ever, thus if God and all his angels and every
>>>>> being great and small said that the input to H specifies a halting
>>>>> computation they would all be liars.
>>>> You told that us P(P) halts.  Until you retract that, I will take it to
>>>> be true.  You also told us that H(P,P) == false.  Do you need to
>>>> correct
>>>> one or other of these statements?
>>>
>>> As long as the input to H(P,P) never reaches its final state under any
>>> condition what-so-ever then no matter what P(P) does H was still
>>> correct because P(P) is not an input and H is only accountable for
>>> getting its inputs correctly.
>>
>> So what two arguments must be passed to H to get H to tell us whether
>> P(P) halts or not?  (Already asked, of course, but you a dodging this
>> issue for obvious reasons.)
>>
>
> You won't understand what I am saying until you first understand that
> your question has nothing to do with the correctness of the rejection of
> the input.
>
> I am referring to a point that is so subtle that no one ever noticed
> this subtle point for 90 years.
>
> I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
> I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
> I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
>
> As long as the input to H(P,P) never reaches its final state under any
> condition what-so-ever then no matter what P(P) does H was still correct
> because P(P) is not an input and H is only accountable for getting its
> inputs correctly.

Except that 'inputs' are 'strings' which don't actually DO anything, and
thus 'reaching a final state' is a meaningless property.

Only by considering it a REPRESENTATION of something, does it get behavior.

And the problem statement defines how to interpret that representation.

And by THAT definition, the 'input' DOES reach a final state exactly if
H(P,P) returns the 'non-halting' answer, so that answer is BY DEFINITION
wrong.

Remember, the DEFINITION of H says it needs to care about the behavior
of the Turing machine the input represents. H applied to <M> w needs to
try to figur out the behavior of M applied to w to get the answer.

DEFINITION.

>
> If a guard is assigned to watch the front door and no one comes in the
> front door and thousands of people come in the back door the guard is
> correct to say that no one came in the front door.

Right, but if he watch the door he THINKS is the front door, but is
actually the back door, and someone actually came in the front door, he
would be wrong.

>
> The input to H is its front door that it must guard. What P(P) does when
> it is not an input is all back door stuff and none of the business of
> any decider.
>

Right, the 'Front Door' for the input '<H> <H>' is DEFINED to be H^
applied to <H^>, and the 'back door' is your embedded_H's simulaiton of
the input.

Your put the guards on the wrong door.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29578&group=comp.theory#29578

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:622a:208:b0:2e1:b3ec:b7ce with SMTP id b8-20020a05622a020800b002e1b3ecb7cemr10151851qtx.345.1649297577163;
Wed, 06 Apr 2022 19:12:57 -0700 (PDT)
X-Received: by 2002:a0d:f883:0:b0:2d0:ee66:5f97 with SMTP id
i125-20020a0df883000000b002d0ee665f97mr9485364ywf.313.1649297576990; Wed, 06
Apr 2022 19:12:56 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Wed, 6 Apr 2022 19:12:56 -0700 (PDT)
In-Reply-To: <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<4dSdnWjHVszE4tb_nZ2dnUU7_8zNnZ2d@giganews.com> <87lewk5otp.fsf@bsb.me.uk>
<leidnWIfpu2XBtb_nZ2dnUU7_83NnZ2d@giganews.com> <874k3761bq.fsf@bsb.me.uk>
<yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com> <87k0c33rk3.fsf@bsb.me.uk>
<9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81e3mso.fsf@bsb.me.uk>
<eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com> <877d822zfj.fsf@bsb.me.uk>
<t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com> <t2l84o$12q$1@dont-email.me>
<RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com> <t2l9u5$s78$1@dont-email.me>
<cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com> <t2lbfp$l03$1@dont-email.me>
<ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lchk$69m$1@dont-email.me>
<ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com> <t2le3m$ucg$1@dont-email.me>
<0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lffh$m4b$1@dont-email.me>
<-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com> <t2lgpi$a5h$1@dont-email.me> <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com>
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Thu, 07 Apr 2022 02:12:57 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 118
 by: Dennis Bush - Thu, 7 Apr 2022 02:12 UTC

On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
> On 4/6/2022 9:03 PM, André G. Isaak wrote:
> > On 2022-04-06 19:47, olcott wrote:
> >> On 4/6/2022 8:41 PM, André G. Isaak wrote:
> >>> On 2022-04-06 19:25, olcott wrote:
> >>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
> >>>>> On 2022-04-06 19:10, olcott wrote:
> >>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
> >>>>>>>
> >>>>>>> But, now that we've got that out of the way, here's a simple
> >>>>>>> question for you: If you want your evenness decider to decide
> >>>>>>> whether seven is even, which string would you pass to it? [yes, I
> >>>>>>> know this is trivially obvious, just humour me]
> >>>>>>>
> >>>>>>> André
> >>>>>>
> >>>>>> 111[]
> >>>>>
> >>>>> I'm assuming that you're using [] to indicate a blank.
> >>>>>
> >>>>> Presumably your E would *reject* this string since seven is an odd
> >>>>> number rather than an even one.
> >>>>>
> >>>>> But notice that in the above case your Turing Machine is rejecting
> >>>>> a finite string "111␣" based on the fact that the *integer* seven,
> >>>>> which is neither an input nor a finite string, is not even.
> >>>>>
> >>>>> So your decider is mapping from a finite string (its input) to
> >>>>> reject/accept based on something which is a "non-input non-finite
> >>>>> string" (to use an expression you've often used).
> >>>>>
> >>>>
> >>>> That seems totally incoherent.
> >>>>
> >>>> The TM maps its input finite string to its reject state based on a
> >>>> property of this finite string.
> >>>
> >>>
> >>> But 'evenness' is not a property of strings; it is a property of
> >>> numbers, and strings are not numbers.
> >>>
> >>
> >> It can be correctly construed as the property of the string.
> >
> > Not by any normal definition.
> >
> > A string is an *uninterpreted* sequence of symbols.
> >
> >>> Your decider bases its decision on a property of the string (is the
> >>> final digit 0?), but that property only corresponds to evenness by
> >>> virtue of the encoding you have chosen.
> >>>
> >>> A decider which uses a unary representation (which would be slightly
> >>> simpler than your binary one) couldn't just look at a single digit. Nor
> >>
> >> Thus not actually simpler.
> >
> > If you actually attempted to write the two versions of E, you'd discover
> > that you are simply wrong in this assessment. The fact that you don't
> > realize this is merely a testament to the fact that you really don't
> > understand how Turing Machines work. At all.
> >
> >>> could one that used trinary representation (which would be only
> >>> slightly more complex than your binary one).
> >>>
> >>> What makes all three of these valid evenness deciders is that they
> >>> conform to the specification of an evenness decider:
> >>>
> >>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
> >>> E.q0 S ⊦* E.qn otherwise.
> >>>
> >>> Yes, the TM maps a finite string to an accept/reject state, but this
> >>> mapping is based on the property of the *number* which that string
> >>> encodes. That number is not an input, but because it can be encoded
> >>> as a string we can still legitimately expect a Turing Machine to
> >>> answer questions about that number.
> >>>
> >>
> >> It can be construed as a property of the string.
> >
> > No. It cannot be. Properties of a string would include things like
> > 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
> > Evenness is not one of those properties.
> >
> >>> Talking about a finite string as being even or odd is completely
> >>> meaningless. Only numbers can be even or odd. Yet there is no problem
> >>> in constructing such a decider.
> >>>
> >>
> >> The string has the "even binary integer" property.
> >
> > No. As soon as you start assigning numerical values to a string (or even
> > to the individual symbols of a string) you are no longer treating it
> > purely as a string. You are considering the information which is encoded
> > in that string, which is a separate matter.
> >
> The all has to do with mathematicaly fomrmalizing semantic meanings.
> Finite strings can have semantic properties.

And just like the meaning assigned to the string "111␣" is the number 7, the meaning assigned to the string <H^><H^> is the turing machine H^ applied to <H^>.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<m_-dnSwD685g1dP_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29579&group=comp.theory#29579

 copy link   Newsgroups: comp.theory
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, 06 Apr 2022 21:14:21 -0500
Date: Wed, 6 Apr 2022 21:14:20 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<VMSdneUyrJVin9f_nZ2dnUU7_83NnZ2d@giganews.com> <871qydde5e.fsf@bsb.me.uk>
<w-edndUxIuQ1h9f_nZ2dnUU7_83NnZ2d@giganews.com>
<w-edndQxIuTUhtf_nZ2dnUU7_81g4p2d@giganews.com> <87ilrpbwrt.fsf@bsb.me.uk>
<n72dnae_RMuWrdf_nZ2dnUU7_83NnZ2d@giganews.com> <877d85buic.fsf@bsb.me.uk>
<t2eghp$5n3$1@gioia.aioe.org> <8735it7zaj.fsf@bsb.me.uk>
<t2hsgu$mmd$1@gioia.aioe.org> <878rsj3rdn.fsf@bsb.me.uk>
<t2k1bu$1srt$1@gioia.aioe.org> <87y20iguq6.fsf@bsb.me.uk>
<Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81dgah5.fsf@bsb.me.uk>
<5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com> <87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com> <87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<a6c81bc4-203b-442a-81af-9dc2b53cd624n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <a6c81bc4-203b-442a-81af-9dc2b53cd624n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <m_-dnSwD685g1dP_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 102
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Xs6UJibFxWQ7ASS68HzmN9DB1ySGD57p4kYQP+e+xyKBwlirbKwViPX5oAn+0La7tOZPpBN+LfmCTtN!KcE/ZvgZLj708Q1l66weKpmvxsLFJ1kof21Hs1FQw+TJHp79RxnhqOAIUgDnxCM/EGG5nZpmmHn2!iQ==
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: 7146
 by: olcott - Thu, 7 Apr 2022 02:14 UTC

On 4/6/2022 9:04 PM, Dennis Bush wrote:
> On Wednesday, April 6, 2022 at 9:58:16 PM UTC-4, olcott wrote:
>> On 4/6/2022 8:49 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 4/6/2022 7:34 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 4/6/2022 6:35 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/6/2022 4:36 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/6/2022 9:19 AM, Ben Bacarisse wrote:
>>>>>>>
>>>>>>>>>>> As for the main mistake, I know enough about cranks to aim for only one
>>>>>>>>>>> of two things: can they be persuaded to say enough to show others that
>>>>>>>>>>> they are wrong (for example PO admission that H(P,P) == false is correct
>>>>>>>>>>> despite the fact that P(P) halts),
>>>>>>>>>>
>>>>>>>>>> If it is the case that the simulated input to H cannot possibly reach
>>>>>>>>>> its own final state under any condition what-so-ever then H correctly
>>>>>>>>>> maps this finite string input to its reject state and nothing in the
>>>>>>>>>> universe can correctly contradict that H is correct.
>>>>>>>>>>
>>>>>>>>>> If you have a white dog in your living room and everyone in the
>>>>>>>>>> universe disagrees, you still have a white dog in your living room.
>>>>>>>>>
>>>>>>>>> Good to see that you are still asserting that false is the correct
>>>>>>>>> result from a halt decider for at least one halting computation.
>>>>>>>>
>>>>>>>> If the input to the halt decider specifies a non-halting sequence of
>>>>>>>> configurations then any damn thing anywhere else is totally
>>>>>>>> irrelevant.
>>>>>>> If P(P) halts, H(P,P) should be true.
>>>>>>
>>>>>> Like I said any damn thing else is actually 100% perfectly totally
>>>>>> irrelevant.
>>>>> Yes! The only thing that matters is whether the "input", (P,P),
>>>>> specifies a halting computation or not.
>>>>>
>>>>>>> The "input" to H is two
>>>>>>> parameters that specify the halting computation P(P).
>>>>>>
>>>>>> A halting computation that cannot possibly reach its own final state
>>>>>> under any condition what-so-ever?
>>>>> Either P(P) halts or it does not. Did you tell a fib when you said it
>>>>> does? Since it halts, H(P,P) == false is wrong.
>>>>>
>>>>>> The input to H(P,P) cannot possibly reach its own final state under
>>>>>> any condition what-so-ever, thus if God and all his angels and every
>>>>>> being great and small said that the input to H specifies a halting
>>>>>> computation they would all be liars.
>>>>> You told that us P(P) halts. Until you retract that, I will take it to
>>>>> be true. You also told us that H(P,P) == false. Do you need to correct
>>>>> one or other of these statements?
>>>>
>>>> As long as the input to H(P,P) never reaches its final state under any
>>>> condition what-so-ever then no matter what P(P) does H was still
>>>> correct because P(P) is not an input and H is only accountable for
>>>> getting its inputs correctly.
>>>
>>> So what two arguments must be passed to H to get H to tell us whether
>>> P(P) halts or not? (Already asked, of course, but you a dodging this
>>> issue for obvious reasons.)
>>>
>> You won't understand what I am saying until you first understand that
>> your question has nothing to do with the correctness of the rejection of
>> the input.
>>
>> I am referring to a point that is so subtle that no one ever noticed
>> this subtle point for 90 years.
>>
>> I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
>> I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
>> I WILL KEEP REPEATING THIS UNTIL YOU RESPOND
>> As long as the input to H(P,P) never reaches its final state under any
>> condition what-so-ever then no matter what P(P) does H was still correct
>> because P(P) is not an input and H is only accountable for getting its
>> inputs correctly.
>
> UTM(P,P) is a condition where the input reaches a final state. So your claim that "the input to H(P,P) never reaches its final state under any condition what-so-ever" is false.
>
>> If a guard is assigned to watch the front door and no one comes in the
>> front door and thousands of people come in the back door the guard is
>> correct to say that no one came in the front door.
>
> Except the guard was actually assigned the back door but he took it upon himself to guard the front door because guarding the back door didn't make sense to him.
No the input to a decider is its front door and everthing besides the
input is totally irrelevant.

If the input never halts then the decider correctly rejects it even if
when the input is directly executed this input converts the Rebublican
party to Fascism for the purpose of abolishing Democracy in the USA.

--
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: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29580&group=comp.theory#29580

 copy link   Newsgroups: comp.theory
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: Wed, 06 Apr 2022 21:15:10 -0500
Date: Wed, 6 Apr 2022 21:15:10 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<874k3761bq.fsf@bsb.me.uk> <yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87k0c33rk3.fsf@bsb.me.uk> <9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81e3mso.fsf@bsb.me.uk> <eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk> <t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me> <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lgpi$a5h$1@dont-email.me> <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
<167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 110
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-HdHvfCtZ3vuh5KBNVQ7LCLsJCuBYc5gXQ1km/uAyBQtXUN+c0aQGfYnEL2ieaBDxZmyfvl9i//U9XmL!bkjSVdSjEno+Z5ewn8zTnOouyffNNpI48IkiymBA26VqvHsY5lv5aCbY0g6/UVCgbZ9yGiPTmOBK!mg==
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: 6801
 by: olcott - Thu, 7 Apr 2022 02:15 UTC

On 4/6/2022 9:12 PM, Dennis Bush wrote:
> On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
>> On 4/6/2022 9:03 PM, André G. Isaak wrote:
>>> On 2022-04-06 19:47, olcott wrote:
>>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>>>> On 2022-04-06 19:25, olcott wrote:
>>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>>>> whether seven is even, which string would you pass to it? [yes, I
>>>>>>>>> know this is trivially obvious, just humour me]
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>
>>>>>>>> 111[]
>>>>>>>
>>>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>>>
>>>>>>> Presumably your E would *reject* this string since seven is an odd
>>>>>>> number rather than an even one.
>>>>>>>
>>>>>>> But notice that in the above case your Turing Machine is rejecting
>>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
>>>>>>> which is neither an input nor a finite string, is not even.
>>>>>>>
>>>>>>> So your decider is mapping from a finite string (its input) to
>>>>>>> reject/accept based on something which is a "non-input non-finite
>>>>>>> string" (to use an expression you've often used).
>>>>>>>
>>>>>>
>>>>>> That seems totally incoherent.
>>>>>>
>>>>>> The TM maps its input finite string to its reject state based on a
>>>>>> property of this finite string.
>>>>>
>>>>>
>>>>> But 'evenness' is not a property of strings; it is a property of
>>>>> numbers, and strings are not numbers.
>>>>>
>>>>
>>>> It can be correctly construed as the property of the string.
>>>
>>> Not by any normal definition.
>>>
>>> A string is an *uninterpreted* sequence of symbols.
>>>
>>>>> Your decider bases its decision on a property of the string (is the
>>>>> final digit 0?), but that property only corresponds to evenness by
>>>>> virtue of the encoding you have chosen.
>>>>>
>>>>> A decider which uses a unary representation (which would be slightly
>>>>> simpler than your binary one) couldn't just look at a single digit. Nor
>>>>
>>>> Thus not actually simpler.
>>>
>>> If you actually attempted to write the two versions of E, you'd discover
>>> that you are simply wrong in this assessment. The fact that you don't
>>> realize this is merely a testament to the fact that you really don't
>>> understand how Turing Machines work. At all.
>>>
>>>>> could one that used trinary representation (which would be only
>>>>> slightly more complex than your binary one).
>>>>>
>>>>> What makes all three of these valid evenness deciders is that they
>>>>> conform to the specification of an evenness decider:
>>>>>
>>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>>>>> E.q0 S ⊦* E.qn otherwise.
>>>>>
>>>>> Yes, the TM maps a finite string to an accept/reject state, but this
>>>>> mapping is based on the property of the *number* which that string
>>>>> encodes. That number is not an input, but because it can be encoded
>>>>> as a string we can still legitimately expect a Turing Machine to
>>>>> answer questions about that number.
>>>>>
>>>>
>>>> It can be construed as a property of the string.
>>>
>>> No. It cannot be. Properties of a string would include things like
>>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
>>> Evenness is not one of those properties.
>>>
>>>>> Talking about a finite string as being even or odd is completely
>>>>> meaningless. Only numbers can be even or odd. Yet there is no problem
>>>>> in constructing such a decider.
>>>>>
>>>>
>>>> The string has the "even binary integer" property.
>>>
>>> No. As soon as you start assigning numerical values to a string (or even
>>> to the individual symbols of a string) you are no longer treating it
>>> purely as a string. You are considering the information which is encoded
>>> in that string, which is a separate matter.
>>>
>> The all has to do with mathematicaly fomrmalizing semantic meanings.
>> Finite strings can have semantic properties.
>
> And just like the meaning assigned to the string "111␣" is the number 7, the meaning assigned to the string <H^><H^> is the turing machine H^ applied to <H^>.

Yes.

--
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: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<t2li0v$smb$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29581&group=comp.theory#29581

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Date: Wed, 6 Apr 2022 20:24:29 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 118
Message-ID: <t2li0v$smb$1@dont-email.me>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87lewk5otp.fsf@bsb.me.uk> <leidnWIfpu2XBtb_nZ2dnUU7_83NnZ2d@giganews.com>
<874k3761bq.fsf@bsb.me.uk> <yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87k0c33rk3.fsf@bsb.me.uk> <9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81e3mso.fsf@bsb.me.uk> <eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk> <t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me> <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lgpi$a5h$1@dont-email.me> <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 7 Apr 2022 02:24:31 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="12651d4b4861d86e6d7c5491f3f6b544";
logging-data="29387"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/77oGDELV6NWNZZurd24ie"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:4esQ6bAPNSayMbghzrTyJqDE53o=
In-Reply-To: <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 7 Apr 2022 02:24 UTC

On 2022-04-06 20:10, olcott wrote:
> On 4/6/2022 9:03 PM, André G. Isaak wrote:
>> On 2022-04-06 19:47, olcott wrote:
>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>>> On 2022-04-06 19:25, olcott wrote:
>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>>
>>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>>> whether seven is even, which string would you pass to it? [yes,
>>>>>>>> I know this is trivially obvious, just humour me]
>>>>>>>>
>>>>>>>> André
>>>>>>>
>>>>>>> 111[]
>>>>>>
>>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>>
>>>>>> Presumably your E would *reject* this string since seven is an odd
>>>>>> number rather than an even one.
>>>>>>
>>>>>> But notice that in the above case your Turing Machine is rejecting
>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
>>>>>> which is neither an input nor a finite string, is not even.
>>>>>>
>>>>>> So your decider is mapping from a finite string (its input) to
>>>>>> reject/accept based on something which is a "non-input non-finite
>>>>>> string" (to use an expression you've often used).
>>>>>>
>>>>>
>>>>> That seems totally incoherent.
>>>>>
>>>>> The TM maps its input finite string to its reject state based on a
>>>>> property of this finite string.
>>>>
>>>>
>>>> But 'evenness' is not a property of strings; it is a property of
>>>> numbers, and strings are not numbers.
>>>>
>>>
>>> It can be correctly construed as the property of the string.
>>
>> Not by any normal definition.
>>
>> A string is an *uninterpreted* sequence of symbols.
>>
>>>> Your decider bases its decision on a property of the string (is the
>>>> final digit 0?), but that property only corresponds to evenness by
>>>> virtue of the encoding you have chosen.
>>>>
>>>> A decider which uses a unary representation (which would be slightly
>>>> simpler than your binary one) couldn't just look at a single digit. Nor
>>>
>>> Thus not actually simpler.
>>
>> If you actually attempted to write the two versions of E, you'd
>> discover that you are simply wrong in this assessment. The fact that
>> you don't realize this is merely a testament to the fact that you
>> really don't understand how Turing Machines work. At all.
>>
>>>> could one that used trinary representation (which would be only
>>>> slightly more complex than your binary one).
>>>>
>>>> What makes all three of these valid evenness deciders is that they
>>>> conform to the specification of an evenness decider:
>>>>
>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>>>> E.q0 S ⊦* E.qn otherwise.
>>>>
>>>> Yes, the TM maps a finite string to an accept/reject state, but this
>>>> mapping is based on the property of the *number* which that string
>>>> encodes. That number is not an input, but because it can be encoded
>>>> as a string we can still legitimately expect a Turing Machine to
>>>> answer questions about that number.
>>>>
>>>
>>> It can be construed as a property of the string.
>>
>> No. It cannot be. Properties of a string would include things like
>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
>> Evenness is not one of those properties.
>>
>>>> Talking about a finite string as being even or odd is completely
>>>> meaningless. Only numbers can be even or odd. Yet there is no
>>>> problem in constructing such a decider.
>>>>
>>>
>>> The string has the "even binary integer" property.
>>
>> No. As soon as you start assigning numerical values to a string (or
>> even to the individual symbols of a string) you are no longer treating
>> it purely as a string. You are considering the information which is
>> encoded in that string, which is a separate matter.
>>
>
> The all has to do with mathematicaly fomrmalizing semantic meanings.
> Finite strings can have semantic properties.

'101' represents an odd number if it is interpreted as a sequence of
binary digits.

'101' represents an even if it is interpreted as a sequence of trinary
digits.

The string '101' is neither even nor odd, because evenness is *not* a
property of strings.

That '101' is three symbols long *is* a property of the string. That
property holds true regardless of which information (if any) the string
might encode.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<QYr3K.210668$OT%7.198206@fx07.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29582&group=comp.theory#29582

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.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.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com> <87k0c33rk3.fsf@bsb.me.uk>
<9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81e3mso.fsf@bsb.me.uk>
<eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com> <877d822zfj.fsf@bsb.me.uk>
<t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com> <t2l84o$12q$1@dont-email.me>
<RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com> <t2l9u5$s78$1@dont-email.me>
<cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com> <t2lbfp$l03$1@dont-email.me>
<ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lchk$69m$1@dont-email.me>
<ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com> <t2le3m$ucg$1@dont-email.me>
<0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lffh$m4b$1@dont-email.me>
<-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com> <t2lgpi$a5h$1@dont-email.me>
<a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
<167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com>
<m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 118
Message-ID: <QYr3K.210668$OT%7.198206@fx07.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, 6 Apr 2022 22:25:52 -0400
X-Received-Bytes: 6798
 by: Richard Damon - Thu, 7 Apr 2022 02:25 UTC

On 4/6/22 10:15 PM, olcott wrote:
> On 4/6/2022 9:12 PM, Dennis Bush wrote:
>> On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
>>> On 4/6/2022 9:03 PM, André G. Isaak wrote:
>>>> On 2022-04-06 19:47, olcott wrote:
>>>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>>>>> On 2022-04-06 19:25, olcott wrote:
>>>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>>>>
>>>>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>>>>> whether seven is even, which string would you pass to it? [yes, I
>>>>>>>>>> know this is trivially obvious, just humour me]
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>
>>>>>>>>> 111[]
>>>>>>>>
>>>>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>>>>
>>>>>>>> Presumably your E would *reject* this string since seven is an odd
>>>>>>>> number rather than an even one.
>>>>>>>>
>>>>>>>> But notice that in the above case your Turing Machine is rejecting
>>>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
>>>>>>>> which is neither an input nor a finite string, is not even.
>>>>>>>>
>>>>>>>> So your decider is mapping from a finite string (its input) to
>>>>>>>> reject/accept based on something which is a "non-input non-finite
>>>>>>>> string" (to use an expression you've often used).
>>>>>>>>
>>>>>>>
>>>>>>> That seems totally incoherent.
>>>>>>>
>>>>>>> The TM maps its input finite string to its reject state based on a
>>>>>>> property of this finite string.
>>>>>>
>>>>>>
>>>>>> But 'evenness' is not a property of strings; it is a property of
>>>>>> numbers, and strings are not numbers.
>>>>>>
>>>>>
>>>>> It can be correctly construed as the property of the string.
>>>>
>>>> Not by any normal definition.
>>>>
>>>> A string is an *uninterpreted* sequence of symbols.
>>>>
>>>>>> Your decider bases its decision on a property of the string (is the
>>>>>> final digit 0?), but that property only corresponds to evenness by
>>>>>> virtue of the encoding you have chosen.
>>>>>>
>>>>>> A decider which uses a unary representation (which would be slightly
>>>>>> simpler than your binary one) couldn't just look at a single
>>>>>> digit. Nor
>>>>>
>>>>> Thus not actually simpler.
>>>>
>>>> If you actually attempted to write the two versions of E, you'd
>>>> discover
>>>> that you are simply wrong in this assessment. The fact that you don't
>>>> realize this is merely a testament to the fact that you really don't
>>>> understand how Turing Machines work. At all.
>>>>
>>>>>> could one that used trinary representation (which would be only
>>>>>> slightly more complex than your binary one).
>>>>>>
>>>>>> What makes all three of these valid evenness deciders is that they
>>>>>> conform to the specification of an evenness decider:
>>>>>>
>>>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>>>>>> E.q0 S ⊦* E.qn otherwise.
>>>>>>
>>>>>> Yes, the TM maps a finite string to an accept/reject state, but this
>>>>>> mapping is based on the property of the *number* which that string
>>>>>> encodes. That number is not an input, but because it can be encoded
>>>>>> as a string we can still legitimately expect a Turing Machine to
>>>>>> answer questions about that number.
>>>>>>
>>>>>
>>>>> It can be construed as a property of the string.
>>>>
>>>> No. It cannot be. Properties of a string would include things like
>>>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
>>>> Evenness is not one of those properties.
>>>>
>>>>>> Talking about a finite string as being even or odd is completely
>>>>>> meaningless. Only numbers can be even or odd. Yet there is no problem
>>>>>> in constructing such a decider.
>>>>>>
>>>>>
>>>>> The string has the "even binary integer" property.
>>>>
>>>> No. As soon as you start assigning numerical values to a string (or
>>>> even
>>>> to the individual symbols of a string) you are no longer treating it
>>>> purely as a string. You are considering the information which is
>>>> encoded
>>>> in that string, which is a separate matter.
>>>>
>>> The all has to do with mathematicaly fomrmalizing semantic meanings.
>>> Finite strings can have semantic properties.
>>
>> And just like the meaning assigned to the string "111␣"  is the number
>> 7, the meaning assigned to the string <H^><H^> is the turing machine
>> H^ applied to <H^>.
>
> Yes.
>

Which means H applied to "<H^> <H^>" is asking if H^ applied to "<H^>"
will halt.

Which it does if H applied to "<H^> <H^>" -> Qn, so that answer (which
means H decided non-halting) is WRONG, by DEFINITION.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<2e2cf0ab-e246-40a9-9d2d-bd9bf5f65d62n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29583&group=comp.theory#29583

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ac8:57d6:0:b0:2e0:68af:7c52 with SMTP id w22-20020ac857d6000000b002e068af7c52mr9921815qta.380.1649298409056;
Wed, 06 Apr 2022 19:26:49 -0700 (PDT)
X-Received: by 2002:a25:6191:0:b0:63c:92df:66c6 with SMTP id
v139-20020a256191000000b0063c92df66c6mr8079955ybb.242.1649298408852; Wed, 06
Apr 2022 19:26:48 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Wed, 6 Apr 2022 19:26:48 -0700 (PDT)
In-Reply-To: <m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<874k3761bq.fsf@bsb.me.uk> <yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87k0c33rk3.fsf@bsb.me.uk> <9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81e3mso.fsf@bsb.me.uk> <eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk> <t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me> <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lgpi$a5h$1@dont-email.me> <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
<167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com> <m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2e2cf0ab-e246-40a9-9d2d-bd9bf5f65d62n@googlegroups.com>
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Thu, 07 Apr 2022 02:26:49 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 133
 by: Dennis Bush - Thu, 7 Apr 2022 02:26 UTC

On Wednesday, April 6, 2022 at 10:15:18 PM UTC-4, olcott wrote:
> On 4/6/2022 9:12 PM, Dennis Bush wrote:
> > On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
> >> On 4/6/2022 9:03 PM, André G. Isaak wrote:
> >>> On 2022-04-06 19:47, olcott wrote:
> >>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
> >>>>> On 2022-04-06 19:25, olcott wrote:
> >>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
> >>>>>>> On 2022-04-06 19:10, olcott wrote:
> >>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
> >>>>>>>>>
> >>>>>>>>> But, now that we've got that out of the way, here's a simple
> >>>>>>>>> question for you: If you want your evenness decider to decide
> >>>>>>>>> whether seven is even, which string would you pass to it? [yes, I
> >>>>>>>>> know this is trivially obvious, just humour me]
> >>>>>>>>>
> >>>>>>>>> André
> >>>>>>>>
> >>>>>>>> 111[]
> >>>>>>>
> >>>>>>> I'm assuming that you're using [] to indicate a blank.
> >>>>>>>
> >>>>>>> Presumably your E would *reject* this string since seven is an odd
> >>>>>>> number rather than an even one.
> >>>>>>>
> >>>>>>> But notice that in the above case your Turing Machine is rejecting
> >>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
> >>>>>>> which is neither an input nor a finite string, is not even.
> >>>>>>>
> >>>>>>> So your decider is mapping from a finite string (its input) to
> >>>>>>> reject/accept based on something which is a "non-input non-finite
> >>>>>>> string" (to use an expression you've often used).
> >>>>>>>
> >>>>>>
> >>>>>> That seems totally incoherent.
> >>>>>>
> >>>>>> The TM maps its input finite string to its reject state based on a
> >>>>>> property of this finite string.
> >>>>>
> >>>>>
> >>>>> But 'evenness' is not a property of strings; it is a property of
> >>>>> numbers, and strings are not numbers.
> >>>>>
> >>>>
> >>>> It can be correctly construed as the property of the string.
> >>>
> >>> Not by any normal definition.
> >>>
> >>> A string is an *uninterpreted* sequence of symbols.
> >>>
> >>>>> Your decider bases its decision on a property of the string (is the
> >>>>> final digit 0?), but that property only corresponds to evenness by
> >>>>> virtue of the encoding you have chosen.
> >>>>>
> >>>>> A decider which uses a unary representation (which would be slightly
> >>>>> simpler than your binary one) couldn't just look at a single digit. Nor
> >>>>
> >>>> Thus not actually simpler.
> >>>
> >>> If you actually attempted to write the two versions of E, you'd discover
> >>> that you are simply wrong in this assessment. The fact that you don't
> >>> realize this is merely a testament to the fact that you really don't
> >>> understand how Turing Machines work. At all.
> >>>
> >>>>> could one that used trinary representation (which would be only
> >>>>> slightly more complex than your binary one).
> >>>>>
> >>>>> What makes all three of these valid evenness deciders is that they
> >>>>> conform to the specification of an evenness decider:
> >>>>>
> >>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
> >>>>> E.q0 S ⊦* E.qn otherwise.
> >>>>>
> >>>>> Yes, the TM maps a finite string to an accept/reject state, but this
> >>>>> mapping is based on the property of the *number* which that string
> >>>>> encodes. That number is not an input, but because it can be encoded
> >>>>> as a string we can still legitimately expect a Turing Machine to
> >>>>> answer questions about that number.
> >>>>>
> >>>>
> >>>> It can be construed as a property of the string.
> >>>
> >>> No. It cannot be. Properties of a string would include things like
> >>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
> >>> Evenness is not one of those properties.
> >>>
> >>>>> Talking about a finite string as being even or odd is completely
> >>>>> meaningless. Only numbers can be even or odd. Yet there is no problem
> >>>>> in constructing such a decider.
> >>>>>
> >>>>
> >>>> The string has the "even binary integer" property.
> >>>
> >>> No. As soon as you start assigning numerical values to a string (or even
> >>> to the individual symbols of a string) you are no longer treating it
> >>> purely as a string. You are considering the information which is encoded
> >>> in that string, which is a separate matter.
> >>>
> >> The all has to do with mathematicaly fomrmalizing semantic meanings.
> >> Finite strings can have semantic properties.
> >
> > And just like the meaning assigned to the string "111␣" is the number 7, the meaning assigned to the string <H^><H^> is the turing machine H^ applied to <H^>.
> Yes.

Ah, so you're finally agreeing that the input <H^><H^> represents H^ applied to <H^>, and that therefore H applied to <H^><H^> is supposed determine if H^ applied to <H^> halts?

Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<q%r3K.210669$OT%7.147268@fx07.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29584&group=comp.theory#29584

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.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.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87lewk5otp.fsf@bsb.me.uk> <leidnWIfpu2XBtb_nZ2dnUU7_83NnZ2d@giganews.com>
<874k3761bq.fsf@bsb.me.uk> <yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87k0c33rk3.fsf@bsb.me.uk> <9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81e3mso.fsf@bsb.me.uk> <eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk> <t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me> <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lgpi$a5h$1@dont-email.me> <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 110
Message-ID: <q%r3K.210669$OT%7.147268@fx07.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, 6 Apr 2022 22:28:38 -0400
X-Received-Bytes: 6435
 by: Richard Damon - Thu, 7 Apr 2022 02:28 UTC

On 4/6/22 10:10 PM, olcott wrote:
> On 4/6/2022 9:03 PM, André G. Isaak wrote:
>> On 2022-04-06 19:47, olcott wrote:
>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>>> On 2022-04-06 19:25, olcott wrote:
>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>>
>>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>>> whether seven is even, which string would you pass to it? [yes,
>>>>>>>> I know this is trivially obvious, just humour me]
>>>>>>>>
>>>>>>>> André
>>>>>>>
>>>>>>> 111[]
>>>>>>
>>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>>
>>>>>> Presumably your E would *reject* this string since seven is an odd
>>>>>> number rather than an even one.
>>>>>>
>>>>>> But notice that in the above case your Turing Machine is rejecting
>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
>>>>>> which is neither an input nor a finite string, is not even.
>>>>>>
>>>>>> So your decider is mapping from a finite string (its input) to
>>>>>> reject/accept based on something which is a "non-input non-finite
>>>>>> string" (to use an expression you've often used).
>>>>>>
>>>>>
>>>>> That seems totally incoherent.
>>>>>
>>>>> The TM maps its input finite string to its reject state based on a
>>>>> property of this finite string.
>>>>
>>>>
>>>> But 'evenness' is not a property of strings; it is a property of
>>>> numbers, and strings are not numbers.
>>>>
>>>
>>> It can be correctly construed as the property of the string.
>>
>> Not by any normal definition.
>>
>> A string is an *uninterpreted* sequence of symbols.
>>
>>>> Your decider bases its decision on a property of the string (is the
>>>> final digit 0?), but that property only corresponds to evenness by
>>>> virtue of the encoding you have chosen.
>>>>
>>>> A decider which uses a unary representation (which would be slightly
>>>> simpler than your binary one) couldn't just look at a single digit. Nor
>>>
>>> Thus not actually simpler.
>>
>> If you actually attempted to write the two versions of E, you'd
>> discover that you are simply wrong in this assessment. The fact that
>> you don't realize this is merely a testament to the fact that you
>> really don't understand how Turing Machines work. At all.
>>
>>>> could one that used trinary representation (which would be only
>>>> slightly more complex than your binary one).
>>>>
>>>> What makes all three of these valid evenness deciders is that they
>>>> conform to the specification of an evenness decider:
>>>>
>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>>>> E.q0 S ⊦* E.qn otherwise.
>>>>
>>>> Yes, the TM maps a finite string to an accept/reject state, but this
>>>> mapping is based on the property of the *number* which that string
>>>> encodes. That number is not an input, but because it can be encoded
>>>> as a string we can still legitimately expect a Turing Machine to
>>>> answer questions about that number.
>>>>
>>>
>>> It can be construed as a property of the string.
>>
>> No. It cannot be. Properties of a string would include things like
>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
>> Evenness is not one of those properties.
>>
>>>> Talking about a finite string as being even or odd is completely
>>>> meaningless. Only numbers can be even or odd. Yet there is no
>>>> problem in constructing such a decider.
>>>>
>>>
>>> The string has the "even binary integer" property.
>>
>> No. As soon as you start assigning numerical values to a string (or
>> even to the individual symbols of a string) you are no longer treating
>> it purely as a string. You are considering the information which is
>> encoded in that string, which is a separate matter.
>>
>
> The all has to do with mathematicaly fomrmalizing semantic meanings.
> Finite strings can have semantic properties.
>

The key point is that strings, by themselves, don't have semantic
meaning, but only in context.

You need to use the right context to get the right semantic meaning.

The Halting Problem defines the context we are in, and thus the meaning
of the strings given to the Halt Decider.

YOU seem to be claiming a WRONG definition of this context.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<bcWdnbL5C64E0dP_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29585&group=comp.theory#29585

 copy link   Newsgroups: comp.theory
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: Wed, 06 Apr 2022 21:29:45 -0500
Date: Wed, 6 Apr 2022 21:29:43 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<leidnWIfpu2XBtb_nZ2dnUU7_83NnZ2d@giganews.com> <874k3761bq.fsf@bsb.me.uk>
<yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com> <87k0c33rk3.fsf@bsb.me.uk>
<9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81e3mso.fsf@bsb.me.uk>
<eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com> <877d822zfj.fsf@bsb.me.uk>
<t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com> <t2l84o$12q$1@dont-email.me>
<RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com> <t2l9u5$s78$1@dont-email.me>
<cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com> <t2lbfp$l03$1@dont-email.me>
<ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lchk$69m$1@dont-email.me>
<ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com> <t2le3m$ucg$1@dont-email.me>
<0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lffh$m4b$1@dont-email.me>
<-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com> <t2lgpi$a5h$1@dont-email.me>
<a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com> <t2li0v$smb$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <t2li0v$smb$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <bcWdnbL5C64E0dP_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 131
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-58ZuiCWj+uHv7XYcTm6GU48MG3wyGwTvqT/Yz+VyZjIkHCQcvCOhr0IjYq+Nvc0ZOfk0nlNc4abrBXZ!6omB5Qj9dfA5dHdfTTaKdUFff1+/BIfY9iS+grR3qYK+h8BMCg2D0NDaRCkF3mgtt2OMfhrzaY2I!8w==
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: 7322
 by: olcott - Thu, 7 Apr 2022 02:29 UTC

On 4/6/2022 9:24 PM, André G. Isaak wrote:
> On 2022-04-06 20:10, olcott wrote:
>> On 4/6/2022 9:03 PM, André G. Isaak wrote:
>>> On 2022-04-06 19:47, olcott wrote:
>>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>>>> On 2022-04-06 19:25, olcott wrote:
>>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>>>> whether seven is even, which string would you pass to it? [yes,
>>>>>>>>> I know this is trivially obvious, just humour me]
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>
>>>>>>>> 111[]
>>>>>>>
>>>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>>>
>>>>>>> Presumably your E would *reject* this string since seven is an
>>>>>>> odd number rather than an even one.
>>>>>>>
>>>>>>> But notice that in the above case your Turing Machine is
>>>>>>> rejecting a finite string "111␣" based on the fact that the
>>>>>>> *integer* seven, which is neither an input nor a finite string,
>>>>>>> is not even.
>>>>>>>
>>>>>>> So your decider is mapping from a finite string (its input) to
>>>>>>> reject/accept based on something which is a "non-input non-finite
>>>>>>> string" (to use an expression you've often used).
>>>>>>>
>>>>>>
>>>>>> That seems totally incoherent.
>>>>>>
>>>>>> The TM maps its input finite string to its reject state based on a
>>>>>> property of this finite string.
>>>>>
>>>>>
>>>>> But 'evenness' is not a property of strings; it is a property of
>>>>> numbers, and strings are not numbers.
>>>>>
>>>>
>>>> It can be correctly construed as the property of the string.
>>>
>>> Not by any normal definition.
>>>
>>> A string is an *uninterpreted* sequence of symbols.
>>>
>>>>> Your decider bases its decision on a property of the string (is the
>>>>> final digit 0?), but that property only corresponds to evenness by
>>>>> virtue of the encoding you have chosen.
>>>>>
>>>>> A decider which uses a unary representation (which would be
>>>>> slightly simpler than your binary one) couldn't just look at a
>>>>> single digit. Nor
>>>>
>>>> Thus not actually simpler.
>>>
>>> If you actually attempted to write the two versions of E, you'd
>>> discover that you are simply wrong in this assessment. The fact that
>>> you don't realize this is merely a testament to the fact that you
>>> really don't understand how Turing Machines work. At all.
>>>
>>>>> could one that used trinary representation (which would be only
>>>>> slightly more complex than your binary one).
>>>>>
>>>>> What makes all three of these valid evenness deciders is that they
>>>>> conform to the specification of an evenness decider:
>>>>>
>>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>>>>> E.q0 S ⊦* E.qn otherwise.
>>>>>
>>>>> Yes, the TM maps a finite string to an accept/reject state, but
>>>>> this mapping is based on the property of the *number* which that
>>>>> string encodes. That number is not an input, but because it can be
>>>>> encoded as a string we can still legitimately expect a Turing
>>>>> Machine to answer questions about that number.
>>>>>
>>>>
>>>> It can be construed as a property of the string.
>>>
>>> No. It cannot be. Properties of a string would include things like
>>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
>>> Evenness is not one of those properties.
>>>
>>>>> Talking about a finite string as being even or odd is completely
>>>>> meaningless. Only numbers can be even or odd. Yet there is no
>>>>> problem in constructing such a decider.
>>>>>
>>>>
>>>> The string has the "even binary integer" property.
>>>
>>> No. As soon as you start assigning numerical values to a string (or
>>> even to the individual symbols of a string) you are no longer
>>> treating it purely as a string. You are considering the information
>>> which is encoded in that string, which is a separate matter.
>>>
>>
>> The all has to do with mathematicaly fomrmalizing semantic meanings.
>> Finite strings can have semantic properties.
>
> '101' represents an odd number if it is interpreted as a sequence of
> binary digits.
>
> '101' represents an even if it is interpreted as a sequence of trinary
> digits.
>
> The string '101' is neither even nor odd, because evenness is *not* a
> property of strings.
>
> That '101' is three symbols long *is* a property of the string. That
> property holds true regardless of which information (if any) the string
> might encode.
>
> André
>

Semantic properties of strings are an aspect of formalizing natural
language semantics.

A string of binary digits could have the semantic property of "the
current best way to do brain surgery".

--
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: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<BPSdnVwEgvGa0tP_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29586&group=comp.theory#29586

 copy link   Newsgroups: comp.theory
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: Wed, 06 Apr 2022 21:40:07 -0500
Date: Wed, 6 Apr 2022 21:40:06 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87k0c33rk3.fsf@bsb.me.uk> <9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81e3mso.fsf@bsb.me.uk> <eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk> <t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me> <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lgpi$a5h$1@dont-email.me> <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
<167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com>
<m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>
<2e2cf0ab-e246-40a9-9d2d-bd9bf5f65d62n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <2e2cf0ab-e246-40a9-9d2d-bd9bf5f65d62n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <BPSdnVwEgvGa0tP_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 123
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-TVzioXuQ4acOjW/8/bEeLyIT4Mrro2fTHtSo1czWX4opAmzcr3HS5LCNyM4OnMD19D/vVDtke+Hqf46!cJd56nE/ilLodbT1p0L8faiWZGoYzB5hxyAWF4wOmF8qE7hFic5ozbKF8AIl5ZbxaCq++oEutGr8!dA==
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: 7672
 by: olcott - Thu, 7 Apr 2022 02:40 UTC

On 4/6/2022 9:26 PM, Dennis Bush wrote:
> On Wednesday, April 6, 2022 at 10:15:18 PM UTC-4, olcott wrote:
>> On 4/6/2022 9:12 PM, Dennis Bush wrote:
>>> On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
>>>> On 4/6/2022 9:03 PM, André G. Isaak wrote:
>>>>> On 2022-04-06 19:47, olcott wrote:
>>>>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>>>>>> On 2022-04-06 19:25, olcott wrote:
>>>>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>>>>>
>>>>>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>>>>>> whether seven is even, which string would you pass to it? [yes, I
>>>>>>>>>>> know this is trivially obvious, just humour me]
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>> 111[]
>>>>>>>>>
>>>>>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>>>>>
>>>>>>>>> Presumably your E would *reject* this string since seven is an odd
>>>>>>>>> number rather than an even one.
>>>>>>>>>
>>>>>>>>> But notice that in the above case your Turing Machine is rejecting
>>>>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
>>>>>>>>> which is neither an input nor a finite string, is not even.
>>>>>>>>>
>>>>>>>>> So your decider is mapping from a finite string (its input) to
>>>>>>>>> reject/accept based on something which is a "non-input non-finite
>>>>>>>>> string" (to use an expression you've often used).
>>>>>>>>>
>>>>>>>>
>>>>>>>> That seems totally incoherent.
>>>>>>>>
>>>>>>>> The TM maps its input finite string to its reject state based on a
>>>>>>>> property of this finite string.
>>>>>>>
>>>>>>>
>>>>>>> But 'evenness' is not a property of strings; it is a property of
>>>>>>> numbers, and strings are not numbers.
>>>>>>>
>>>>>>
>>>>>> It can be correctly construed as the property of the string.
>>>>>
>>>>> Not by any normal definition.
>>>>>
>>>>> A string is an *uninterpreted* sequence of symbols.
>>>>>
>>>>>>> Your decider bases its decision on a property of the string (is the
>>>>>>> final digit 0?), but that property only corresponds to evenness by
>>>>>>> virtue of the encoding you have chosen.
>>>>>>>
>>>>>>> A decider which uses a unary representation (which would be slightly
>>>>>>> simpler than your binary one) couldn't just look at a single digit. Nor
>>>>>>
>>>>>> Thus not actually simpler.
>>>>>
>>>>> If you actually attempted to write the two versions of E, you'd discover
>>>>> that you are simply wrong in this assessment. The fact that you don't
>>>>> realize this is merely a testament to the fact that you really don't
>>>>> understand how Turing Machines work. At all.
>>>>>
>>>>>>> could one that used trinary representation (which would be only
>>>>>>> slightly more complex than your binary one).
>>>>>>>
>>>>>>> What makes all three of these valid evenness deciders is that they
>>>>>>> conform to the specification of an evenness decider:
>>>>>>>
>>>>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>>>>>>> E.q0 S ⊦* E.qn otherwise.
>>>>>>>
>>>>>>> Yes, the TM maps a finite string to an accept/reject state, but this
>>>>>>> mapping is based on the property of the *number* which that string
>>>>>>> encodes. That number is not an input, but because it can be encoded
>>>>>>> as a string we can still legitimately expect a Turing Machine to
>>>>>>> answer questions about that number.
>>>>>>>
>>>>>>
>>>>>> It can be construed as a property of the string.
>>>>>
>>>>> No. It cannot be. Properties of a string would include things like
>>>>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
>>>>> Evenness is not one of those properties.
>>>>>
>>>>>>> Talking about a finite string as being even or odd is completely
>>>>>>> meaningless. Only numbers can be even or odd. Yet there is no problem
>>>>>>> in constructing such a decider.
>>>>>>>
>>>>>>
>>>>>> The string has the "even binary integer" property.
>>>>>
>>>>> No. As soon as you start assigning numerical values to a string (or even
>>>>> to the individual symbols of a string) you are no longer treating it
>>>>> purely as a string. You are considering the information which is encoded
>>>>> in that string, which is a separate matter.
>>>>>
>>>> The all has to do with mathematicaly fomrmalizing semantic meanings.
>>>> Finite strings can have semantic properties.
>>>
>>> And just like the meaning assigned to the string "111␣" is the number 7, the meaning assigned to the string <H^><H^> is the turing machine H^ applied to <H^>.
>> Yes.
>
> Ah, so you're finally agreeing that the input <H^><H^> represents H^ applied to <H^>, and that therefore H applied to <H^><H^> is supposed determine if H^ applied to <H^> halts?

It represents a sequence of configurations.

Here are three different sequences of configurations that have different
behavior because they are not the same sequence of configurations:

H ⟨Ĥ⟩ ⟨Ĥ⟩ Converts the Republican party to Fascism to take over Democracy
Ĥ ⟨Ĥ⟩
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ Transitions to H.qn

--
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: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<t2lj5q$c2n$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29587&group=comp.theory#29587

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Date: Wed, 6 Apr 2022 20:44:09 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 25
Message-ID: <t2lj5q$c2n$1@dont-email.me>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<874k3761bq.fsf@bsb.me.uk> <yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87k0c33rk3.fsf@bsb.me.uk> <9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81e3mso.fsf@bsb.me.uk> <eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk> <t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me> <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lgpi$a5h$1@dont-email.me> <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
<t2li0v$smb$1@dont-email.me> <bcWdnbL5C64E0dP_nZ2dnUU7_83NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 7 Apr 2022 02:44:10 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="12651d4b4861d86e6d7c5491f3f6b544";
logging-data="12375"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ZKkY6zuxFYQ/tREZEbCFx"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:T5aGCAXR2iKhvYTEYTX0PH0FAEA=
In-Reply-To: <bcWdnbL5C64E0dP_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 7 Apr 2022 02:44 UTC

On 2022-04-06 20:29, olcott wrote:

> A string of binary digits could have the semantic property of "the
> current best way to do brain surgery".

No, it cannot. A string might encode the English phrase "the current
best way to do brain surgery", or it might encode information about what
is currently believed to be the best way to do brain surgery. But a
string cannot have the property "the current best way to do brain surgery".

You are confusing strings with the things that strings might represent.
They are not the same thing. A string is simply a sequence of
intrinsically meaningless symbols. There are many contexts in which
people conflate these two things and assume the reader will nonetheless
be able to follow, but this is one context where it is important to keep
the two separate.

This is one of those definitional points you need to learn if you want
to be taken seriously. Which is something you claim is one of your goals.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<b047b854-fa33-4c83-9066-e9c196c6bebbn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29588&group=comp.theory#29588

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a0c:f68d:0:b0:444:fbd:8c0a with SMTP id p13-20020a0cf68d000000b004440fbd8c0amr352369qvn.125.1649299503199;
Wed, 06 Apr 2022 19:45:03 -0700 (PDT)
X-Received: by 2002:a81:8d4a:0:b0:2ca:287c:6d3f with SMTP id
w10-20020a818d4a000000b002ca287c6d3fmr9674795ywj.484.1649299503039; Wed, 06
Apr 2022 19:45:03 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Wed, 6 Apr 2022 19:45:02 -0700 (PDT)
In-Reply-To: <BPSdnVwEgvGa0tP_nZ2dnUU7_83NnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87k0c33rk3.fsf@bsb.me.uk> <9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81e3mso.fsf@bsb.me.uk> <eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk> <t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me> <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lgpi$a5h$1@dont-email.me> <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
<167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com> <m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>
<2e2cf0ab-e246-40a9-9d2d-bd9bf5f65d62n@googlegroups.com> <BPSdnVwEgvGa0tP_nZ2dnUU7_83NnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b047b854-fa33-4c83-9066-e9c196c6bebbn@googlegroups.com>
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Thu, 07 Apr 2022 02:45:03 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 168
 by: Dennis Bush - Thu, 7 Apr 2022 02:45 UTC

On Wednesday, April 6, 2022 at 10:40:15 PM UTC-4, olcott wrote:
> On 4/6/2022 9:26 PM, Dennis Bush wrote:
> > On Wednesday, April 6, 2022 at 10:15:18 PM UTC-4, olcott wrote:
> >> On 4/6/2022 9:12 PM, Dennis Bush wrote:
> >>> On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
> >>>> On 4/6/2022 9:03 PM, André G. Isaak wrote:
> >>>>> On 2022-04-06 19:47, olcott wrote:
> >>>>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
> >>>>>>> On 2022-04-06 19:25, olcott wrote:
> >>>>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
> >>>>>>>>> On 2022-04-06 19:10, olcott wrote:
> >>>>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> But, now that we've got that out of the way, here's a simple
> >>>>>>>>>>> question for you: If you want your evenness decider to decide
> >>>>>>>>>>> whether seven is even, which string would you pass to it? [yes, I
> >>>>>>>>>>> know this is trivially obvious, just humour me]
> >>>>>>>>>>>
> >>>>>>>>>>> André
> >>>>>>>>>>
> >>>>>>>>>> 111[]
> >>>>>>>>>
> >>>>>>>>> I'm assuming that you're using [] to indicate a blank.
> >>>>>>>>>
> >>>>>>>>> Presumably your E would *reject* this string since seven is an odd
> >>>>>>>>> number rather than an even one.
> >>>>>>>>>
> >>>>>>>>> But notice that in the above case your Turing Machine is rejecting
> >>>>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
> >>>>>>>>> which is neither an input nor a finite string, is not even.
> >>>>>>>>>
> >>>>>>>>> So your decider is mapping from a finite string (its input) to
> >>>>>>>>> reject/accept based on something which is a "non-input non-finite
> >>>>>>>>> string" (to use an expression you've often used).
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> That seems totally incoherent.
> >>>>>>>>
> >>>>>>>> The TM maps its input finite string to its reject state based on a
> >>>>>>>> property of this finite string.
> >>>>>>>
> >>>>>>>
> >>>>>>> But 'evenness' is not a property of strings; it is a property of
> >>>>>>> numbers, and strings are not numbers.
> >>>>>>>
> >>>>>>
> >>>>>> It can be correctly construed as the property of the string.
> >>>>>
> >>>>> Not by any normal definition.
> >>>>>
> >>>>> A string is an *uninterpreted* sequence of symbols.
> >>>>>
> >>>>>>> Your decider bases its decision on a property of the string (is the
> >>>>>>> final digit 0?), but that property only corresponds to evenness by
> >>>>>>> virtue of the encoding you have chosen.
> >>>>>>>
> >>>>>>> A decider which uses a unary representation (which would be slightly
> >>>>>>> simpler than your binary one) couldn't just look at a single digit. Nor
> >>>>>>
> >>>>>> Thus not actually simpler.
> >>>>>
> >>>>> If you actually attempted to write the two versions of E, you'd discover
> >>>>> that you are simply wrong in this assessment. The fact that you don't
> >>>>> realize this is merely a testament to the fact that you really don't
> >>>>> understand how Turing Machines work. At all.
> >>>>>
> >>>>>>> could one that used trinary representation (which would be only
> >>>>>>> slightly more complex than your binary one).
> >>>>>>>
> >>>>>>> What makes all three of these valid evenness deciders is that they
> >>>>>>> conform to the specification of an evenness decider:
> >>>>>>>
> >>>>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
> >>>>>>> E.q0 S ⊦* E.qn otherwise.
> >>>>>>>
> >>>>>>> Yes, the TM maps a finite string to an accept/reject state, but this
> >>>>>>> mapping is based on the property of the *number* which that string
> >>>>>>> encodes. That number is not an input, but because it can be encoded
> >>>>>>> as a string we can still legitimately expect a Turing Machine to
> >>>>>>> answer questions about that number.
> >>>>>>>
> >>>>>>
> >>>>>> It can be construed as a property of the string.
> >>>>>
> >>>>> No. It cannot be. Properties of a string would include things like
> >>>>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
> >>>>> Evenness is not one of those properties.
> >>>>>
> >>>>>>> Talking about a finite string as being even or odd is completely
> >>>>>>> meaningless. Only numbers can be even or odd. Yet there is no problem
> >>>>>>> in constructing such a decider.
> >>>>>>>
> >>>>>>
> >>>>>> The string has the "even binary integer" property.
> >>>>>
> >>>>> No. As soon as you start assigning numerical values to a string (or even
> >>>>> to the individual symbols of a string) you are no longer treating it
> >>>>> purely as a string. You are considering the information which is encoded
> >>>>> in that string, which is a separate matter.
> >>>>>
> >>>> The all has to do with mathematicaly fomrmalizing semantic meanings.
> >>>> Finite strings can have semantic properties.
> >>>
> >>> And just like the meaning assigned to the string "111␣" is the number 7, the meaning assigned to the string <H^><H^> is the turing machine H^ applied to <H^>.
> >> Yes.
> >
> > Ah, so you're finally agreeing that the input <H^><H^> represents H^ applied to <H^>, and that therefore H applied to <H^><H^> is supposed determine if H^ applied to <H^> halts?
> It represents a sequence of configurations.

And that sequence of configurations is H^ applied to <H^> as per the stipulative definition of a halt decider:

---
A solution of the halting problem is a Turing machine
H, which for any <M> and <w>, performs the computation

H.q0 ⟨M⟩⟨w⟩ ⊦* H.qy

if M applied to <w> halts, and

H.q0 ⟨M⟩⟨w⟩ ⊦* H.qn

if M applied to <w> does not halt.
---

It is incorrect to disagree with stipulative definitions.
https://en.wikipedia.org/wiki/Stipulative_definition

Disagreeing with a stipulative definition is like disagreeing with
arithmetic.

When in BASIC we say let X = 5,
disagreeing that X has the value of 5 is incorrect.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<4OidnY57QK-czNP_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29589&group=comp.theory#29589

 copy link   Newsgroups: comp.theory
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, 06 Apr 2022 21:48:32 -0500
Date: Wed, 6 Apr 2022 21:48:32 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com> <87k0c33rk3.fsf@bsb.me.uk>
<9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81e3mso.fsf@bsb.me.uk>
<eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com> <877d822zfj.fsf@bsb.me.uk>
<t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com> <t2l84o$12q$1@dont-email.me>
<RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com> <t2l9u5$s78$1@dont-email.me>
<cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com> <t2lbfp$l03$1@dont-email.me>
<ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lchk$69m$1@dont-email.me>
<ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com> <t2le3m$ucg$1@dont-email.me>
<0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lffh$m4b$1@dont-email.me>
<-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com> <t2lgpi$a5h$1@dont-email.me>
<a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com> <t2li0v$smb$1@dont-email.me>
<bcWdnbL5C64E0dP_nZ2dnUU7_83NnZ2d@giganews.com> <t2lj5q$c2n$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <t2lj5q$c2n$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <4OidnY57QK-czNP_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 18
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-tNlW9X3ar53H2xr+ZDkTl87Vx/1Hq47EJpMX5u3UsyApiF6fsd3s1JQTjOzqdraaCQLyIcxqgd0SzuJ!tJFhvy31ng+ut1tCOYitdTuIKs2SMG096WN+DbuwGXGdv1LFrJXU8wBLDzLEA5IM9TQN3p6ZbEYU!0Q==
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: 2713
 by: olcott - Thu, 7 Apr 2022 02:48 UTC

On 4/6/2022 9:44 PM, André G. Isaak wrote:
> On 2022-04-06 20:29, olcott wrote:
>
>> A string of binary digits could have the semantic property of "the
>> current best way to do brain surgery".
>
> No, it cannot. A string might encode the English phrase "the current
> best way to do brain surgery",

You simply fail to grasp semantic properties of strings.

--
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: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<ibidnd7EQLcez9P_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29590&group=comp.theory#29590

 copy link   Newsgroups: comp.theory
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: Wed, 06 Apr 2022 21:54:59 -0500
Date: Wed, 6 Apr 2022 21:54:58 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com> <877d822zfj.fsf@bsb.me.uk>
<t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com> <t2l84o$12q$1@dont-email.me>
<RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com> <t2l9u5$s78$1@dont-email.me>
<cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com> <t2lbfp$l03$1@dont-email.me>
<ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lchk$69m$1@dont-email.me>
<ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com> <t2le3m$ucg$1@dont-email.me>
<0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lffh$m4b$1@dont-email.me>
<-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com> <t2lgpi$a5h$1@dont-email.me>
<a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
<167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com>
<m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>
<2e2cf0ab-e246-40a9-9d2d-bd9bf5f65d62n@googlegroups.com>
<BPSdnVwEgvGa0tP_nZ2dnUU7_83NnZ2d@giganews.com>
<b047b854-fa33-4c83-9066-e9c196c6bebbn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <b047b854-fa33-4c83-9066-e9c196c6bebbn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <ibidnd7EQLcez9P_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 132
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-MG0++Tm2eaFq6rAaR0fhtbxoiaymAAjqdrkb7qXmI3B/QhYpuEvaCWcqSpEJqcsbxVPbE3AwTgrh1AD!EMdJBRjGRjKFDgd3xAgcjIMo8om0RaixOFnZjnYdqABUtFJCaqgIHlCM7ZCT97CRfCBB99GQvySU!Ew==
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: 8236
 by: olcott - Thu, 7 Apr 2022 02:54 UTC

On 4/6/2022 9:45 PM, Dennis Bush wrote:
> On Wednesday, April 6, 2022 at 10:40:15 PM UTC-4, olcott wrote:
>> On 4/6/2022 9:26 PM, Dennis Bush wrote:
>>> On Wednesday, April 6, 2022 at 10:15:18 PM UTC-4, olcott wrote:
>>>> On 4/6/2022 9:12 PM, Dennis Bush wrote:
>>>>> On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
>>>>>> On 4/6/2022 9:03 PM, André G. Isaak wrote:
>>>>>>> On 2022-04-06 19:47, olcott wrote:
>>>>>>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-04-06 19:25, olcott wrote:
>>>>>>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>>>>>>>> whether seven is even, which string would you pass to it? [yes, I
>>>>>>>>>>>>> know this is trivially obvious, just humour me]
>>>>>>>>>>>>>
>>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>> 111[]
>>>>>>>>>>>
>>>>>>>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>>>>>>>
>>>>>>>>>>> Presumably your E would *reject* this string since seven is an odd
>>>>>>>>>>> number rather than an even one.
>>>>>>>>>>>
>>>>>>>>>>> But notice that in the above case your Turing Machine is rejecting
>>>>>>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
>>>>>>>>>>> which is neither an input nor a finite string, is not even.
>>>>>>>>>>>
>>>>>>>>>>> So your decider is mapping from a finite string (its input) to
>>>>>>>>>>> reject/accept based on something which is a "non-input non-finite
>>>>>>>>>>> string" (to use an expression you've often used).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That seems totally incoherent.
>>>>>>>>>>
>>>>>>>>>> The TM maps its input finite string to its reject state based on a
>>>>>>>>>> property of this finite string.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But 'evenness' is not a property of strings; it is a property of
>>>>>>>>> numbers, and strings are not numbers.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It can be correctly construed as the property of the string.
>>>>>>>
>>>>>>> Not by any normal definition.
>>>>>>>
>>>>>>> A string is an *uninterpreted* sequence of symbols.
>>>>>>>
>>>>>>>>> Your decider bases its decision on a property of the string (is the
>>>>>>>>> final digit 0?), but that property only corresponds to evenness by
>>>>>>>>> virtue of the encoding you have chosen.
>>>>>>>>>
>>>>>>>>> A decider which uses a unary representation (which would be slightly
>>>>>>>>> simpler than your binary one) couldn't just look at a single digit. Nor
>>>>>>>>
>>>>>>>> Thus not actually simpler.
>>>>>>>
>>>>>>> If you actually attempted to write the two versions of E, you'd discover
>>>>>>> that you are simply wrong in this assessment. The fact that you don't
>>>>>>> realize this is merely a testament to the fact that you really don't
>>>>>>> understand how Turing Machines work. At all.
>>>>>>>
>>>>>>>>> could one that used trinary representation (which would be only
>>>>>>>>> slightly more complex than your binary one).
>>>>>>>>>
>>>>>>>>> What makes all three of these valid evenness deciders is that they
>>>>>>>>> conform to the specification of an evenness decider:
>>>>>>>>>
>>>>>>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>>>>>>>>> E.q0 S ⊦* E.qn otherwise.
>>>>>>>>>
>>>>>>>>> Yes, the TM maps a finite string to an accept/reject state, but this
>>>>>>>>> mapping is based on the property of the *number* which that string
>>>>>>>>> encodes. That number is not an input, but because it can be encoded
>>>>>>>>> as a string we can still legitimately expect a Turing Machine to
>>>>>>>>> answer questions about that number.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It can be construed as a property of the string.
>>>>>>>
>>>>>>> No. It cannot be. Properties of a string would include things like
>>>>>>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
>>>>>>> Evenness is not one of those properties.
>>>>>>>
>>>>>>>>> Talking about a finite string as being even or odd is completely
>>>>>>>>> meaningless. Only numbers can be even or odd. Yet there is no problem
>>>>>>>>> in constructing such a decider.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The string has the "even binary integer" property.
>>>>>>>
>>>>>>> No. As soon as you start assigning numerical values to a string (or even
>>>>>>> to the individual symbols of a string) you are no longer treating it
>>>>>>> purely as a string. You are considering the information which is encoded
>>>>>>> in that string, which is a separate matter.
>>>>>>>
>>>>>> The all has to do with mathematicaly fomrmalizing semantic meanings.
>>>>>> Finite strings can have semantic properties.
>>>>>
>>>>> And just like the meaning assigned to the string "111␣" is the number 7, the meaning assigned to the string <H^><H^> is the turing machine H^ applied to <H^>.
>>>> Yes.
>>>
>>> Ah, so you're finally agreeing that the input <H^><H^> represents H^ applied to <H^>, and that therefore H applied to <H^><H^> is supposed determine if H^ applied to <H^> halts?
>> It represents a sequence of configurations.
>
> And that sequence of configurations is H^ applied to <H^> as per the stipulative definition of a halt decider:

The actual sequence of configurations specified by these three is not
the same thus the behavior can vary.

H ⟨Ĥ⟩ ⟨Ĥ⟩
Ĥ ⟨Ĥ⟩
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩

You can simply assume that they must be the same, yet when you list them
you can see that they are not the same.

Counting to ten beginning at five and counting to ten beginning at one
are both counting to ten yet not the same.

--
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: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<3d6fb15e-b313-4d09-86ed-595ab8784ce5n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29591&group=comp.theory#29591

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ac8:5ad6:0:b0:2e2:27b6:7b3e with SMTP id d22-20020ac85ad6000000b002e227b67b3emr10704621qtd.216.1649302063180;
Wed, 06 Apr 2022 20:27:43 -0700 (PDT)
X-Received: by 2002:a25:780a:0:b0:633:ccea:3430 with SMTP id
t10-20020a25780a000000b00633ccea3430mr8704084ybc.26.1649302062977; Wed, 06
Apr 2022 20:27:42 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Wed, 6 Apr 2022 20:27:42 -0700 (PDT)
In-Reply-To: <ibidnd7EQLcez9P_nZ2dnUU7_8zNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com> <877d822zfj.fsf@bsb.me.uk>
<t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com> <t2l84o$12q$1@dont-email.me>
<RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com> <t2l9u5$s78$1@dont-email.me>
<cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com> <t2lbfp$l03$1@dont-email.me>
<ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lchk$69m$1@dont-email.me>
<ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com> <t2le3m$ucg$1@dont-email.me>
<0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com> <t2lffh$m4b$1@dont-email.me>
<-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com> <t2lgpi$a5h$1@dont-email.me>
<a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com> <167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com>
<m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com> <2e2cf0ab-e246-40a9-9d2d-bd9bf5f65d62n@googlegroups.com>
<BPSdnVwEgvGa0tP_nZ2dnUU7_83NnZ2d@giganews.com> <b047b854-fa33-4c83-9066-e9c196c6bebbn@googlegroups.com>
<ibidnd7EQLcez9P_nZ2dnUU7_8zNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3d6fb15e-b313-4d09-86ed-595ab8784ce5n@googlegroups.com>
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Thu, 07 Apr 2022 03:27:43 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 168
 by: Dennis Bush - Thu, 7 Apr 2022 03:27 UTC

On Wednesday, April 6, 2022 at 10:55:06 PM UTC-4, olcott wrote:
> On 4/6/2022 9:45 PM, Dennis Bush wrote:
> > On Wednesday, April 6, 2022 at 10:40:15 PM UTC-4, olcott wrote:
> >> On 4/6/2022 9:26 PM, Dennis Bush wrote:
> >>> On Wednesday, April 6, 2022 at 10:15:18 PM UTC-4, olcott wrote:
> >>>> On 4/6/2022 9:12 PM, Dennis Bush wrote:
> >>>>> On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
> >>>>>> On 4/6/2022 9:03 PM, André G. Isaak wrote:
> >>>>>>> On 2022-04-06 19:47, olcott wrote:
> >>>>>>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
> >>>>>>>>> On 2022-04-06 19:25, olcott wrote:
> >>>>>>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
> >>>>>>>>>>> On 2022-04-06 19:10, olcott wrote:
> >>>>>>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But, now that we've got that out of the way, here's a simple
> >>>>>>>>>>>>> question for you: If you want your evenness decider to decide
> >>>>>>>>>>>>> whether seven is even, which string would you pass to it? [yes, I
> >>>>>>>>>>>>> know this is trivially obvious, just humour me]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> André
> >>>>>>>>>>>>
> >>>>>>>>>>>> 111[]
> >>>>>>>>>>>
> >>>>>>>>>>> I'm assuming that you're using [] to indicate a blank.
> >>>>>>>>>>>
> >>>>>>>>>>> Presumably your E would *reject* this string since seven is an odd
> >>>>>>>>>>> number rather than an even one.
> >>>>>>>>>>>
> >>>>>>>>>>> But notice that in the above case your Turing Machine is rejecting
> >>>>>>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
> >>>>>>>>>>> which is neither an input nor a finite string, is not even.
> >>>>>>>>>>>
> >>>>>>>>>>> So your decider is mapping from a finite string (its input) to
> >>>>>>>>>>> reject/accept based on something which is a "non-input non-finite
> >>>>>>>>>>> string" (to use an expression you've often used).
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> That seems totally incoherent.
> >>>>>>>>>>
> >>>>>>>>>> The TM maps its input finite string to its reject state based on a
> >>>>>>>>>> property of this finite string.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> But 'evenness' is not a property of strings; it is a property of
> >>>>>>>>> numbers, and strings are not numbers.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> It can be correctly construed as the property of the string.
> >>>>>>>
> >>>>>>> Not by any normal definition.
> >>>>>>>
> >>>>>>> A string is an *uninterpreted* sequence of symbols.
> >>>>>>>
> >>>>>>>>> Your decider bases its decision on a property of the string (is the
> >>>>>>>>> final digit 0?), but that property only corresponds to evenness by
> >>>>>>>>> virtue of the encoding you have chosen.
> >>>>>>>>>
> >>>>>>>>> A decider which uses a unary representation (which would be slightly
> >>>>>>>>> simpler than your binary one) couldn't just look at a single digit. Nor
> >>>>>>>>
> >>>>>>>> Thus not actually simpler.
> >>>>>>>
> >>>>>>> If you actually attempted to write the two versions of E, you'd discover
> >>>>>>> that you are simply wrong in this assessment. The fact that you don't
> >>>>>>> realize this is merely a testament to the fact that you really don't
> >>>>>>> understand how Turing Machines work. At all.
> >>>>>>>
> >>>>>>>>> could one that used trinary representation (which would be only
> >>>>>>>>> slightly more complex than your binary one).
> >>>>>>>>>
> >>>>>>>>> What makes all three of these valid evenness deciders is that they
> >>>>>>>>> conform to the specification of an evenness decider:
> >>>>>>>>>
> >>>>>>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
> >>>>>>>>> E.q0 S ⊦* E.qn otherwise.
> >>>>>>>>>
> >>>>>>>>> Yes, the TM maps a finite string to an accept/reject state, but this
> >>>>>>>>> mapping is based on the property of the *number* which that string
> >>>>>>>>> encodes. That number is not an input, but because it can be encoded
> >>>>>>>>> as a string we can still legitimately expect a Turing Machine to
> >>>>>>>>> answer questions about that number.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> It can be construed as a property of the string.
> >>>>>>>
> >>>>>>> No. It cannot be. Properties of a string would include things like
> >>>>>>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
> >>>>>>> Evenness is not one of those properties.
> >>>>>>>
> >>>>>>>>> Talking about a finite string as being even or odd is completely
> >>>>>>>>> meaningless. Only numbers can be even or odd. Yet there is no problem
> >>>>>>>>> in constructing such a decider.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> The string has the "even binary integer" property.
> >>>>>>>
> >>>>>>> No. As soon as you start assigning numerical values to a string (or even
> >>>>>>> to the individual symbols of a string) you are no longer treating it
> >>>>>>> purely as a string. You are considering the information which is encoded
> >>>>>>> in that string, which is a separate matter.
> >>>>>>>
> >>>>>> The all has to do with mathematicaly fomrmalizing semantic meanings.
> >>>>>> Finite strings can have semantic properties.
> >>>>>
> >>>>> And just like the meaning assigned to the string "111␣" is the number 7, the meaning assigned to the string <H^><H^> is the turing machine H^ applied to <H^>.
> >>>> Yes.
> >>>
> >>> Ah, so you're finally agreeing that the input <H^><H^> represents H^ applied to <H^>, and that therefore H applied to <H^><H^> is supposed determine if H^ applied to <H^> halts?
> >> It represents a sequence of configurations.
> >
> > And that sequence of configurations is H^ applied to <H^> as per the stipulative definition of a halt decider:
> The actual sequence of configurations specified by these three is not
> the same thus the behavior can vary.
>
> H ⟨Ĥ⟩ ⟨Ĥ⟩
> Ĥ ⟨Ĥ⟩
> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> You can simply assume that they must be the same, yet when you list them
> you can see that they are not the same.

By definition the input to H and embedded_H is the representation of Ĥ ⟨Ĥ⟩


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<cZ6dnRLq0c8y_dP_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29592&group=comp.theory#29592

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
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: Wed, 06 Apr 2022 22:55:27 -0500
Date: Wed, 6 Apr 2022 22:55:26 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me> <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lgpi$a5h$1@dont-email.me> <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
<167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com>
<m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>
<2e2cf0ab-e246-40a9-9d2d-bd9bf5f65d62n@googlegroups.com>
<BPSdnVwEgvGa0tP_nZ2dnUU7_83NnZ2d@giganews.com>
<b047b854-fa33-4c83-9066-e9c196c6bebbn@googlegroups.com>
<ibidnd7EQLcez9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<3d6fb15e-b313-4d09-86ed-595ab8784ce5n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <3d6fb15e-b313-4d09-86ed-595ab8784ce5n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <cZ6dnRLq0c8y_dP_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 146
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-otjNKYWt9cpfvtTKwLq8jy3aiw/OVkXYD+mlsSUIEmVMYKDoiDGFn4IJAiDvCN0h8Z14jkQExWRH335!gqiRKy0jfz1D7IasHcATNDF4MJgMtf6Naj3RRI2F9b6193EvBD4ndAPBBZpoX/flB4xRHFB48VLn!wg==
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: 9276
 by: olcott - Thu, 7 Apr 2022 03:55 UTC

On 4/6/2022 10:27 PM, Dennis Bush wrote:
> On Wednesday, April 6, 2022 at 10:55:06 PM UTC-4, olcott wrote:
>> On 4/6/2022 9:45 PM, Dennis Bush wrote:
>>> On Wednesday, April 6, 2022 at 10:40:15 PM UTC-4, olcott wrote:
>>>> On 4/6/2022 9:26 PM, Dennis Bush wrote:
>>>>> On Wednesday, April 6, 2022 at 10:15:18 PM UTC-4, olcott wrote:
>>>>>> On 4/6/2022 9:12 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
>>>>>>>> On 4/6/2022 9:03 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-04-06 19:47, olcott wrote:
>>>>>>>>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-04-06 19:25, olcott wrote:
>>>>>>>>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>>>>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>>>>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>>>>>>>>>> whether seven is even, which string would you pass to it? [yes, I
>>>>>>>>>>>>>>> know this is trivially obvious, just humour me]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 111[]
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Presumably your E would *reject* this string since seven is an odd
>>>>>>>>>>>>> number rather than an even one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But notice that in the above case your Turing Machine is rejecting
>>>>>>>>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
>>>>>>>>>>>>> which is neither an input nor a finite string, is not even.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So your decider is mapping from a finite string (its input) to
>>>>>>>>>>>>> reject/accept based on something which is a "non-input non-finite
>>>>>>>>>>>>> string" (to use an expression you've often used).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That seems totally incoherent.
>>>>>>>>>>>>
>>>>>>>>>>>> The TM maps its input finite string to its reject state based on a
>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But 'evenness' is not a property of strings; it is a property of
>>>>>>>>>>> numbers, and strings are not numbers.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It can be correctly construed as the property of the string.
>>>>>>>>>
>>>>>>>>> Not by any normal definition.
>>>>>>>>>
>>>>>>>>> A string is an *uninterpreted* sequence of symbols.
>>>>>>>>>
>>>>>>>>>>> Your decider bases its decision on a property of the string (is the
>>>>>>>>>>> final digit 0?), but that property only corresponds to evenness by
>>>>>>>>>>> virtue of the encoding you have chosen.
>>>>>>>>>>>
>>>>>>>>>>> A decider which uses a unary representation (which would be slightly
>>>>>>>>>>> simpler than your binary one) couldn't just look at a single digit. Nor
>>>>>>>>>>
>>>>>>>>>> Thus not actually simpler.
>>>>>>>>>
>>>>>>>>> If you actually attempted to write the two versions of E, you'd discover
>>>>>>>>> that you are simply wrong in this assessment. The fact that you don't
>>>>>>>>> realize this is merely a testament to the fact that you really don't
>>>>>>>>> understand how Turing Machines work. At all.
>>>>>>>>>
>>>>>>>>>>> could one that used trinary representation (which would be only
>>>>>>>>>>> slightly more complex than your binary one).
>>>>>>>>>>>
>>>>>>>>>>> What makes all three of these valid evenness deciders is that they
>>>>>>>>>>> conform to the specification of an evenness decider:
>>>>>>>>>>>
>>>>>>>>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>>>>>>>>>>> E.q0 S ⊦* E.qn otherwise.
>>>>>>>>>>>
>>>>>>>>>>> Yes, the TM maps a finite string to an accept/reject state, but this
>>>>>>>>>>> mapping is based on the property of the *number* which that string
>>>>>>>>>>> encodes. That number is not an input, but because it can be encoded
>>>>>>>>>>> as a string we can still legitimately expect a Turing Machine to
>>>>>>>>>>> answer questions about that number.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It can be construed as a property of the string.
>>>>>>>>>
>>>>>>>>> No. It cannot be. Properties of a string would include things like
>>>>>>>>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
>>>>>>>>> Evenness is not one of those properties.
>>>>>>>>>
>>>>>>>>>>> Talking about a finite string as being even or odd is completely
>>>>>>>>>>> meaningless. Only numbers can be even or odd. Yet there is no problem
>>>>>>>>>>> in constructing such a decider.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The string has the "even binary integer" property.
>>>>>>>>>
>>>>>>>>> No. As soon as you start assigning numerical values to a string (or even
>>>>>>>>> to the individual symbols of a string) you are no longer treating it
>>>>>>>>> purely as a string. You are considering the information which is encoded
>>>>>>>>> in that string, which is a separate matter.
>>>>>>>>>
>>>>>>>> The all has to do with mathematicaly fomrmalizing semantic meanings.
>>>>>>>> Finite strings can have semantic properties.
>>>>>>>
>>>>>>> And just like the meaning assigned to the string "111␣" is the number 7, the meaning assigned to the string <H^><H^> is the turing machine H^ applied to <H^>.
>>>>>> Yes.
>>>>>
>>>>> Ah, so you're finally agreeing that the input <H^><H^> represents H^ applied to <H^>, and that therefore H applied to <H^><H^> is supposed determine if H^ applied to <H^> halts?
>>>> It represents a sequence of configurations.
>>>
>>> And that sequence of configurations is H^ applied to <H^> as per the stipulative definition of a halt decider:
>> The actual sequence of configurations specified by these three is not
>> the same thus the behavior can vary.
>>
>> H ⟨Ĥ⟩ ⟨Ĥ⟩
>> Ĥ ⟨Ĥ⟩
>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> You can simply assume that they must be the same, yet when you list them
>> you can see that they are not the same.
>
> By definition the input to H and embedded_H is the representation of Ĥ ⟨Ĥ⟩


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<87v8vlcgrs.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29593&group=comp.theory#29593

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]
Date: Thu, 07 Apr 2022 11:46:47 +0100
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <87v8vlcgrs.fsf@bsb.me.uk>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<874k3761bq.fsf@bsb.me.uk>
<yLWdnZ05dv-m6tH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87k0c33rk3.fsf@bsb.me.uk>
<9OCdnd0y-MtNatH_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81e3mso.fsf@bsb.me.uk>
<eI6dnePeWI_8jdD_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk>
<t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me>
<RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me>
<cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me>
<ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me>
<ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me>
<0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me>
<-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="9875e55d8daa06cc2a53aa953015877e";
logging-data="15389"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19L1//pagFKnAs8eEH8eP4irBkcKMkSDEk="
Cancel-Lock: sha1:RrQCiC4KzMjgmVVxUIUQRN9ZpME=
sha1:RBddUOUpNGp7PiXnUfmvMIeQxFI=
X-BSB-Auth: 1.e66aa0dfe2a4e8857f34.20220407114647BST.87v8vlcgrs.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 7 Apr 2022 10:46 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/6/2022 8:41 PM, André G. Isaak wrote:

>> What makes all three of these valid evenness deciders is that they
>> conform to the specification of an evenness decider:
>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>> E.q0 S ⊦* E.qn otherwise.
>>
>> Yes, the TM maps a finite string to an accept/reject state, but this
>> mapping is based on the property of the *number* which that string
>> encodes. That number is not an input, but because it can be encoded
>> as a string we can still legitimately expect a Turing Machine to
>> answer questions about that number.
>
> It can be construed as a property of the string.

I know I said I would leave the side threads alone, but this is too
interesting a digression.

I added in the example of the TM P because, for the specification to be
shorter than an essay, it should simply refer to the number a string
represents. But then you are not contradicting that. Your rather vague
phrase permits the number a string represents to be "construed as a
property of the string".

But here's the rub. You can't just say "a property of the string"
because whether "23 18 9 17 30 22" are next week's lottery numbers "can
be construed as a property of the string" but it certainly is not a
/computable property/ of the string. The reason halting is not
decidable is simply that it is not a computable property of the strings
we use, where primality is.

I say "of the strings that we use" because halting /is/ a decidable
property of some encodings. If we take our TM and it's input to Delphi,
we can get a string encoding that starts "1:(0000R(0110R..." for halting
pairs and "0:(0000R(0110R..." for non-halting ones. The gods are
helpful like that.

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<87pmltcg7x.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29594&group=comp.theory#29594

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]
Date: Thu, 07 Apr 2022 11:58:42 +0100
Organization: A noiseless patient Spider
Lines: 90
Message-ID: <87pmltcg7x.fsf@bsb.me.uk>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<w-edndUxIuQ1h9f_nZ2dnUU7_83NnZ2d@giganews.com>
<w-edndQxIuTUhtf_nZ2dnUU7_81g4p2d@giganews.com>
<87ilrpbwrt.fsf@bsb.me.uk>
<n72dnae_RMuWrdf_nZ2dnUU7_83NnZ2d@giganews.com>
<877d85buic.fsf@bsb.me.uk> <t2eghp$5n3$1@gioia.aioe.org>
<8735it7zaj.fsf@bsb.me.uk> <t2hsgu$mmd$1@gioia.aioe.org>
<878rsj3rdn.fsf@bsb.me.uk> <t2k1bu$1srt$1@gioia.aioe.org>
<87y20iguq6.fsf@bsb.me.uk>
<Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk>
<5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="9875e55d8daa06cc2a53aa953015877e";
logging-data="15389"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/TIDE9Ie4P3ojtf9tgDCLjtPbmAh5lkys="
Cancel-Lock: sha1:a/6Thb3geYsB1Ys3SDeKNLRm4yU=
sha1:hCKopttlCCwy1Q4ToSgd/+12hB8=
X-BSB-Auth: 1.cccd4da539cc2663e47e.20220407115842BST.87pmltcg7x.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 7 Apr 2022 10:58 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/6/2022 8:49 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/6/2022 7:34 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/6/2022 6:35 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/6/2022 4:36 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/6/2022 9:19 AM, Ben Bacarisse wrote:
>>>>>>
>>>>>>>>>> As for the main mistake, I know enough about cranks to aim for only one
>>>>>>>>>> of two things: can they be persuaded to say enough to show others that
>>>>>>>>>> they are wrong (for example PO admission that H(P,P) == false is correct
>>>>>>>>>> despite the fact that P(P) halts),
>>>>>>>>>
>>>>>>>>> If it is the case that the simulated input to H cannot possibly reach
>>>>>>>>> its own final state under any condition what-so-ever then H correctly
>>>>>>>>> maps this finite string input to its reject state and nothing in the
>>>>>>>>> universe can correctly contradict that H is correct.
>>>>>>>>>
>>>>>>>>> If you have a white dog in your living room and everyone in the
>>>>>>>>> universe disagrees, you still have a white dog in your living room.
>>>>>>>>
>>>>>>>> Good to see that you are still asserting that false is the correct
>>>>>>>> result from a halt decider for at least one halting computation.
>>>>>>>
>>>>>>> If the input to the halt decider specifies a non-halting sequence of
>>>>>>> configurations then any damn thing anywhere else is totally
>>>>>>> irrelevant.
>>>>>> If P(P) halts, H(P,P) should be true.
>>>>>
>>>>> Like I said any damn thing else is actually 100% perfectly totally
>>>>> irrelevant.
>>>> Yes! The only thing that matters is whether the "input", (P,P),
>>>> specifies a halting computation or not.
>>>>
>>>>>> The "input" to H is two
>>>>>> parameters that specify the halting computation P(P).
>>>>>
>>>>> A halting computation that cannot possibly reach its own final state
>>>>> under any condition what-so-ever?
>>>> Either P(P) halts or it does not. Did you tell a fib when you said it
>>>> does? Since it halts, H(P,P) == false is wrong.
>>>>
>>>>> The input to H(P,P) cannot possibly reach its own final state under
>>>>> any condition what-so-ever, thus if God and all his angels and every
>>>>> being great and small said that the input to H specifies a halting
>>>>> computation they would all be liars.
>>>> You told that us P(P) halts. Until you retract that, I will take it to
>>>> be true. You also told us that H(P,P) == false. Do you need to correct
>>>> one or other of these statements?
>>>
>>> As long as the input to H(P,P) never reaches its final state under any
>>> condition what-so-ever then no matter what P(P) does H was still
>>> correct because P(P) is not an input and H is only accountable for
>>> getting its inputs correctly.
>>
>> So what two arguments must be passed to H to get H to tell us whether
>> P(P) halts or not? (Already asked, of course, but you a dodging this
>> issue for obvious reasons.)
>
> You won't understand what I am saying until you first understand that
> your question has nothing to do with the correctness of the rejection
> of the input.
>
> I am referring to a point that is so subtle that no one ever noticed
> this subtle point for 90 years.
>
> I WILL KEEP REPEATING THIS UNTIL YOU RESPOND

Of course you will. You can't answer the question without being
obviously wrong, so what else can you do but insist that everyone take
the blue pill first?

P(P) is a halting computation. If H has any pretence to be a halt
decider there must be some pair of arguments that get H to tell us that
P(P) halts. What are they? It's not a complicated question.

(If it's not (P,P) then you certainly wasted a lot of time last year
talking about H(P,P) trying to persuade people that false if the correct
answer despite the fact that P(P) halts.)

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piece in dialogue ]

<MEz3K.210674$OT%7.36205@fx07.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29595&group=comp.theory#29595

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.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.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(10) [
key missing piece in dialogue ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d822zfj.fsf@bsb.me.uk> <t7SdnX_CbaqAM9D_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2l84o$12q$1@dont-email.me> <RNidnVr-m8VuutP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2l9u5$s78$1@dont-email.me> <cvOdnRh1oMwrsNP_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lbfp$l03$1@dont-email.me> <ddydnYa4KKXprtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lchk$69m$1@dont-email.me> <ceydnd_Rxc-Xp9P_nZ2dnUU7_8xh4p2d@giganews.com>
<t2le3m$ucg$1@dont-email.me> <0Y-dnRfPMZwYoNP_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2lffh$m4b$1@dont-email.me> <-Y-dneOIwoko39P_nZ2dnUU7_83NnZ2d@giganews.com>
<t2lgpi$a5h$1@dont-email.me> <a6idnUCCo_-D1dP_nZ2dnUU7_81g4p2d@giganews.com>
<167d7f14-8a54-4f5b-8932-99236586786fn@googlegroups.com>
<m_-dnS8D686z1NP_nZ2dnUU7_8xh4p2d@giganews.com>
<2e2cf0ab-e246-40a9-9d2d-bd9bf5f65d62n@googlegroups.com>
<BPSdnVwEgvGa0tP_nZ2dnUU7_83NnZ2d@giganews.com>
<b047b854-fa33-4c83-9066-e9c196c6bebbn@googlegroups.com>
<ibidnd7EQLcez9P_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <ibidnd7EQLcez9P_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 192
Message-ID: <MEz3K.210674$OT%7.36205@fx07.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: Thu, 7 Apr 2022 07:10:37 -0400
X-Received-Bytes: 10071
 by: Richard Damon - Thu, 7 Apr 2022 11:10 UTC

On 4/6/22 10:54 PM, olcott wrote:
> On 4/6/2022 9:45 PM, Dennis Bush wrote:
>> On Wednesday, April 6, 2022 at 10:40:15 PM UTC-4, olcott wrote:
>>> On 4/6/2022 9:26 PM, Dennis Bush wrote:
>>>> On Wednesday, April 6, 2022 at 10:15:18 PM UTC-4, olcott wrote:
>>>>> On 4/6/2022 9:12 PM, Dennis Bush wrote:
>>>>>> On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
>>>>>>> On 4/6/2022 9:03 PM, André G. Isaak wrote:
>>>>>>>> On 2022-04-06 19:47, olcott wrote:
>>>>>>>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-04-06 19:25, olcott wrote:
>>>>>>>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>>>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>>>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>>>>>>>>> whether seven is even, which string would you pass to it?
>>>>>>>>>>>>>> [yes, I
>>>>>>>>>>>>>> know this is trivially obvious, just humour me]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> André
>>>>>>>>>>>>>
>>>>>>>>>>>>> 111[]
>>>>>>>>>>>>
>>>>>>>>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>>>>>>>>
>>>>>>>>>>>> Presumably your E would *reject* this string since seven is
>>>>>>>>>>>> an odd
>>>>>>>>>>>> number rather than an even one.
>>>>>>>>>>>>
>>>>>>>>>>>> But notice that in the above case your Turing Machine is
>>>>>>>>>>>> rejecting
>>>>>>>>>>>> a finite string "111␣" based on the fact that the *integer*
>>>>>>>>>>>> seven,
>>>>>>>>>>>> which is neither an input nor a finite string, is not even.
>>>>>>>>>>>>
>>>>>>>>>>>> So your decider is mapping from a finite string (its input) to
>>>>>>>>>>>> reject/accept based on something which is a "non-input
>>>>>>>>>>>> non-finite
>>>>>>>>>>>> string" (to use an expression you've often used).
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That seems totally incoherent.
>>>>>>>>>>>
>>>>>>>>>>> The TM maps its input finite string to its reject state based
>>>>>>>>>>> on a
>>>>>>>>>>> property of this finite string.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But 'evenness' is not a property of strings; it is a property of
>>>>>>>>>> numbers, and strings are not numbers.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It can be correctly construed as the property of the string.
>>>>>>>>
>>>>>>>> Not by any normal definition.
>>>>>>>>
>>>>>>>> A string is an *uninterpreted* sequence of symbols.
>>>>>>>>
>>>>>>>>>> Your decider bases its decision on a property of the string
>>>>>>>>>> (is the
>>>>>>>>>> final digit 0?), but that property only corresponds to
>>>>>>>>>> evenness by
>>>>>>>>>> virtue of the encoding you have chosen.
>>>>>>>>>>
>>>>>>>>>> A decider which uses a unary representation (which would be
>>>>>>>>>> slightly
>>>>>>>>>> simpler than your binary one) couldn't just look at a single
>>>>>>>>>> digit. Nor
>>>>>>>>>
>>>>>>>>> Thus not actually simpler.
>>>>>>>>
>>>>>>>> If you actually attempted to write the two versions of E, you'd
>>>>>>>> discover
>>>>>>>> that you are simply wrong in this assessment. The fact that you
>>>>>>>> don't
>>>>>>>> realize this is merely a testament to the fact that you really
>>>>>>>> don't
>>>>>>>> understand how Turing Machines work. At all.
>>>>>>>>
>>>>>>>>>> could one that used trinary representation (which would be only
>>>>>>>>>> slightly more complex than your binary one).
>>>>>>>>>>
>>>>>>>>>> What makes all three of these valid evenness deciders is that
>>>>>>>>>> they
>>>>>>>>>> conform to the specification of an evenness decider:
>>>>>>>>>>
>>>>>>>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is
>>>>>>>>>> even
>>>>>>>>>> E.q0 S ⊦* E.qn otherwise.
>>>>>>>>>>
>>>>>>>>>> Yes, the TM maps a finite string to an accept/reject state,
>>>>>>>>>> but this
>>>>>>>>>> mapping is based on the property of the *number* which that
>>>>>>>>>> string
>>>>>>>>>> encodes. That number is not an input, but because it can be
>>>>>>>>>> encoded
>>>>>>>>>> as a string we can still legitimately expect a Turing Machine to
>>>>>>>>>> answer questions about that number.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It can be construed as a property of the string.
>>>>>>>>
>>>>>>>> No. It cannot be. Properties of a string would include things like
>>>>>>>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
>>>>>>>> Evenness is not one of those properties.
>>>>>>>>
>>>>>>>>>> Talking about a finite string as being even or odd is completely
>>>>>>>>>> meaningless. Only numbers can be even or odd. Yet there is no
>>>>>>>>>> problem
>>>>>>>>>> in constructing such a decider.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The string has the "even binary integer" property.
>>>>>>>>
>>>>>>>> No. As soon as you start assigning numerical values to a string
>>>>>>>> (or even
>>>>>>>> to the individual symbols of a string) you are no longer
>>>>>>>> treating it
>>>>>>>> purely as a string. You are considering the information which is
>>>>>>>> encoded
>>>>>>>> in that string, which is a separate matter.
>>>>>>>>
>>>>>>> The all has to do with mathematicaly fomrmalizing semantic meanings.
>>>>>>> Finite strings can have semantic properties.
>>>>>>
>>>>>> And just like the meaning assigned to the string "111␣" is the
>>>>>> number 7, the meaning assigned to the string <H^><H^> is the
>>>>>> turing machine H^ applied to <H^>.
>>>>> Yes.
>>>>
>>>> Ah, so you're finally agreeing that the input <H^><H^> represents H^
>>>> applied to <H^>, and that therefore H applied to <H^><H^> is
>>>> supposed determine if H^ applied to <H^> halts?
>>> It represents a sequence of configurations.
>>
>> And that sequence of configurations is H^ applied to <H^> as per the
>> stipulative definition of a halt decider:
>
> The actual sequence of configurations specified by these three is not
> the same thus the behavior can vary.
>
> H ⟨Ĥ⟩ ⟨Ĥ⟩
> Ĥ ⟨Ĥ⟩
> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>
> You can simply assume that they must be the same, yet when you list them
> you can see that they are not the same.
>
> Counting to ten beginning at five and counting to ten beginning at one
> are both counting to ten yet not the same.
>
>


Click here to read the complete article
Pages:12345678910111213141516171819202122232425262728293031323334353637383940
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor