Path: ...!feeder1.cambriumusenet.nl!feed.tweak.nl!217.73.144.44.MISMATCH!feeder.ecngs.de!ecngs!feeder2.ecngs.de!192.241.129.152.MISMATCH!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: =?UTF-8?B?UmU6IFZlcmlmaWVkIGZhY3QgdGhhdCDEpC5IIOKfqMSk4p+pIOKfqMSk?=
 =?UTF-8?B?4p+pIGFuZCBIIOKfqMSk4p+pIOKfqMSk4p+pIGhhdmUgZGlmZmVyZW50IGJlaGF2?=
 =?UTF-8?Q?ior_ZFC?=
Date: Sun, 10 Mar 2024 19:58:52 -0700
Organization: i2pn2 (i2pn.org)
Message-ID: <usls1d$1enef$19@i2pn2.org>
References: <usia2e$2f2pd$1@dont-email.me> <usiq9n$2ijsm$1@dont-email.me>
 <usir82$2inqh$2@dont-email.me> <usit21$2j3c8$1@dont-email.me>
 <usiufa$2j99n$1@dont-email.me> <usiukh$2jaj3$1@dont-email.me>
 <usiuup$2jdc7$2@dont-email.me> <usj254$2jutc$2@dont-email.me>
 <usj2e3$2jut2$1@dont-email.me> <usj2je$2jutc$3@dont-email.me>
 <usj2rs$2jut2$2@dont-email.me> <usj32s$2k5id$1@dont-email.me>
 <usjd20$2plge$1@dont-email.me> <usjef5$1cf5q$6@i2pn2.org>
 <usjfj8$2q613$1@dont-email.me> <usjgs6$1cf5q$7@i2pn2.org>
 <usjhks$2qhfq$1@dont-email.me> <usjj7v$1cf5q$8@i2pn2.org>
 <uskg1p$30hr1$1@dont-email.me> <KEkHN.386271$vFZa.185803@fx13.iad>
 <uskog1$32h3c$1@dont-email.me> <uskpe3$32l00$1@dont-email.me>
 <uskq04$32h3c$3@dont-email.me> <usksvk$33a1p$5@dont-email.me>
 <uskubp$33lov$3@dont-email.me> <usl0hh$34290$3@dont-email.me>
 <usl0v5$347rv$2@dont-email.me> <usljui$385q4$2@dont-email.me>
 <uslmh7$38jtu$2@dont-email.me> <IEtHN.366351$q3F7.176464@fx45.iad>
 <uslqr6$3d3q7$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 11 Mar 2024 02:58:54 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1531343"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <uslqr6$3d3q7$1@dont-email.me>
Content-Language: en-US
Bytes: 7953
Lines: 143

On 3/10/24 7:38 PM, olcott wrote:
> On 3/10/2024 9:04 PM, Richard Damon wrote:
>> On 3/10/24 6:24 PM, olcott wrote:
>>> On 3/10/2024 7:40 PM, immibis wrote:
>>>> On 10/03/24 20:16, olcott wrote:
>>>>> On 3/10/2024 2:09 PM, immibis wrote:
>>>>>> On 10/03/24 19:32, olcott wrote:
>>>>>>> On 3/10/2024 1:08 PM, immibis wrote:
>>>>>>>> On 10/03/24 18:17, olcott wrote:
>>>>>>>>> ZFC simply tossed out the Russell's Paradox question as unsound.
>>>>>>>>
>>>>>>>> So you are saying that some Turing machines are not sound?
>>>>>>>>
>>>>>>>>>>> Both H ⟨Ĥ⟩ ⟨Ĥ⟩ and Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide that:
>>>>>>>>>>> (a) Their input halts H.qy
>>>>>>>>>>> (b) Their input fails to halt or has a pathological
>>>>>>>>>>> relationship to itself H.qn.
>>>>>>>>>>
>>>>>>>>>> But the "Pathological Relationship" is ALLOWED.
>>>>>>>>>>
>>>>>>>>> ZFC simply tossed out the Russell's Paradox question as unsound
>>>>>>>>> expressly disallowing the "Pathological Relationship".
>>>>>>>>
>>>>>>>> So you are saying that some Turing machines are not real Turing 
>>>>>>>> machines?
>>>>>>>>
>>>>>>>>> I am only claiming that both H and Ĥ.H correctly say YES
>>>>>>>>> when their input halts and correctly say NOT YES otherwise.
>>>>>>>>
>>>>>>>> well the halting problem requires them to correctly say NO, so 
>>>>>>>> you haven't solved it
>>>>>>>
>>>>>>> All decision problem instances of program/input such that both
>>>>>>> yes and no are the wrong answer toss out the input as invalid.
>>>>>>>
>>>>>>
>>>>>> all decision problems are defined so that all instances are valid 
>>>>>> or else they are not defined properly
>>>>>>
>>>>>
>>>>> Not in the case of Russell's Paradox.
>>>>
>>>> And now we are back to: Every Turing machine and input pair defines 
>>>> an execution sequence. Every sequence is either finite or infinite. 
>>>> Therefore it is well-defined and there is no paradox.
>>>>
>>>> Can you show me a Turing machine that specifies a sequence of 
>>>> configurations that is not finite or infinite?
>>>
>>> When we construe every yes/no question that cannot possibly
>>> have a correct yes/no answer as an incorrect question
>>>
>>> then we must correspondingly construe every decider/input
>>> pair that has no correct yes/no answer as invalid input.
>>>
>>
>> And when you remember that when we posse that ACTUAL question, the 
>> input is a FIXED machine, (not a template that changes by the decide 
>> that it trying to decide it) then there are a LOT of machines that get 
>> the right answer. The key is we know that there is ONE that doesn't, 
>> the one that particular decider was built to foil. Thus, the problem 
>> isn't an invalid question.
> 
> 
> In computability theory and computational complexity theory,
> an undecidable problem is a decision problem for which it is
> proved to be impossible to construct an algorithm that always
> leads to a correct yes-or-no answer.
> https://en.wikipedia.org/wiki/Undecidable_problem

Right.

> 
> If the only reason that a machine does not get a correct yes/no answer
> for this machine/input pair is that both yes and no are the wrong answer
> for this machine/input pair then this machine/input pair is a yes/no
> question that has no correct yes/no answer for this machine/input pair.
> 
> The exact same word-for-word question:
> Are you a little girl?
> Has a different meaning depending on who is asked.

Right, but "Does this input describd a computation that Halts when Run?" 
ALWAYS has a correct answer, when that input IS a computation, a 
SPECIFIC algorithm applied to a SPECIFIC input.

Nothing in that question refers to who it is being ask of.

Note, Converting the input to a template that looks at the decider 
deciding on it, that IS an invalid input, and can't actually be build 
with a Turing Machine description as an input.

Part of your problem is you have changed the problem because you don't 
understand it.

H^ uses a SPECIFIC DEFINED H, the ONE machine this H^ is designed to 
foil. It doesn't change when you change the H looking at it.

There ALWAYS is a correct answer for that H^ (H^), it is just a fact the 
particular H it was built for will get it wrong.

When you combine that with the fact that you can make a similar input 
for ANY machine that wants to try to claim to be a Halt Decider, and we 
end up not being able to have Halt Deciders.

> 
> The exact same word-for-word question:
> Does your input halt on its input?
> Has a different meaning depending on who is asked.

NOPE.

Because H^ (H^) Will always do the same thing no matter who you ask 
about it, because a given H^ (which is what the question is about) will 
ALWAYS use its one specific H and always do the same thing.

> 
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
> 
> When every Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is asked this question:
> Does your input halt on its input?
> It is an incorrect question.
> 

What do you mean by "Every"?

For any specific question, there is just one specific H^ with a specific 
operation and that H^ will always end up in qy or qn depending on 
exactly what the specific H it was built on does.

You have the wrong question.

The question is NOT about the TEMPLATE, but a specific instance of that 
template built on a specific decider, that makes that one decider wrong.

You just seem too dumb to understand that.

H^ is NOT a "Template", ^ is a template that has been applied to a 
SPECIFIC machine H (not a set of them, but just a specific one).

You have just been lying to yourself too long, and have forgottent the 
actual problem.