Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: sci.logic
Subject: Re: Unconventional partial halt decider and grounding to a truthmaker
Date: Sat, 18 May 2024 11:23:17 +0300
Organization: -
Lines: 97
Message-ID: <v29ohl$2mrt9$1@dont-email.me>
References: <v18e32$1vbql$1@dont-email.me> <v1b7gl$2ndka$1@dont-email.me> <v1di1h$3b2m5$1@dont-email.me> <v1dtdv$3dqg4$1@dont-email.me> <v1du2i$3dt7u$1@dont-email.me> <v1ft42$3vdau$2@dont-email.me> <-5Gdnf-nQvstC6b7nZ2dnZfqnPadnZ2d@brightview.co.uk> <v1gid8$4ilc$1@dont-email.me> <v1h9eu$9faf$1@dont-email.me> <v1iqli$nsva$1@dont-email.me> <v1k0ts$iuna$1@i2pn2.org> <v1k381$14mbi$2@dont-email.me> <v1labh$kf53$1@i2pn2.org> <v1lfnq$1e7af$1@dont-email.me> <v1lh1g$kf52$4@i2pn2.org> <v1lmo1$1g1mj$1@dont-email.me> <v1luu1$lbo5$3@i2pn2.org> <v1lvuo$1i47i$1@dont-email.me> <v1m1bf$lbo5$4@i2pn2.org> <v1m2hc$1ijhr$1@dont-email.me> <v1m31m$lbo4$1@i2pn2.org> <v1m4et$1iv85$1@dont-email.me> <v1m5co$lbo4$2@i2pn2.org> <v1m71h$1jnpi$1@dont-email.me> <v1m7mh$lbo5$5@i2pn2.org> <v1mb8f$1kgpl$1@dont-email.me> <v1mkf8$lbo5$7@i2pn2.org> <v1mkmm$1q5ee$1@dont-email.me> <v1o67n$24f4c$1@dont-email.me> <v1vslr$7enr$1@dont-email.me> <v256bn$1kahe$1@dont-email.me> <v282h4$29miu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 18 May 2024 10:23:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="09f5db4735dcda801e35839cc47e3f1d";
	logging-data="2846633"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19N0fJe8syFghp4M9TQaMOK"
User-Agent: Unison/2.2
Cancel-Lock: sha1:xgIYDt83wEJbfQ6VCgk58ow3l5I=
Bytes: 5728

On 2024-05-17 17:01:23 +0000, olcott said:

> On 5/17/2024 5:45 AM, Mikko wrote:
>> On 2024-05-16 14:48:21 +0000, olcott said:
>> 
>>> On 5/16/2024 5:42 AM, Mikko wrote:
>>>> On 2024-05-15 15:06:26 +0000, olcott said:
>>>> 
>>>>> On 5/15/2024 3:06 AM, Mikko wrote:
>>>>>> On 2024-05-14 14:32:26 +0000, olcott said:
>>>>>> 
>>>>>>> On 5/14/2024 4:44 AM, Mikko wrote:
>>>>>>>> On 2024-05-12 15:58:02 +0000, olcott said:
>>>>>>>> 
>>>>>>>>> On 5/12/2024 10:21 AM, Mikko wrote:
>>>>>>>>>> On 2024-05-12 11:34:17 +0000, Richard Damon said:
>>>>>>>>>> 
>>>>>>>>>>> On 5/12/24 5:19 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-05-11 16:26:30 +0000, olcott said:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I am working on providing an academic quality definition of this
>>>>>>>>>>>>> term.
>>>>>>>>>>>> 
>>>>>>>>>>>> The definition in Wikipedia is good enough.
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I think he means, he is working on a definition that redefines the 
>>>>>>>>>>> field to allow him to claim what he wants.
>>>>>>>>>> 
>>>>>>>>>> Here one can claim whatever one wants anysay.
>>>>>>>>>> In if one wants to present ones claims on some significant forum then
>>>>>>>>>> it is better to stick to usual definitions as much as possible.
>>>>>>>>>> 
>>>>>>>>>>> Sort of like his new definition of H as an "unconventional" machine 
>>>>>>>>>>> that some how both returns an answer but also keeps on running.
>>>>>>>>>> 
>>>>>>>>>> There are systems where that is possible but unsolvable problems are
>>>>>>>>>> unsolvable even in those systems.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>> 
>>>>>>>> This notation does not work with machines that can, or have parts
>>>>>>>> that can, return a value without (or before) termination.
>>>>>>> 
>>>>>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>>>>>> 01 int D(ptr x)
>>>>>>> 02 {
>>>>>>> 03   int Halt_Status = H(x, x);
>>>>>>> 04   if (Halt_Status)
>>>>>>> 05     HERE: goto HERE;
>>>>>>> 06   return Halt_Status;
>>>>>>> 07 }
>>>>>>> 08
>>>>>>> 09 int main()
>>>>>>> 10 {
>>>>>>> 11   H(D,D);
>>>>>>> 12 }
>>>>>> 
>>>>>> That notation is not any better for the purpose.
>>>>>> 
>>>>> 
>>>>> I refer to transitioning through a specific state to indicate
>>>>> a specific halt status value, for Turing Machines.
>>>> 
>>>> That does not satisfy the usual definition of "halt decider".
>>> 
>>> Yet it <is> an incremental improvement over both YES and NO are
>>> the wrong answer for input D. YES <is> the correct answer and H
>>> can not SAY this answer in the conventional way.
>> 
>> For every computation "yes" is the correct answer if and only if one can
>> construct a finite sequence of configurations so that the first one is the
>> initial configuration, each other one follows from the previous one by a
>> transition rule, and no possible configuration follows from the last one
>> by any transition rule. If "yes" is not the correct answer then "no" is.
>> Therefore there is no D where neither "yes" and "no" is wrong for the
>> same input.
>> 
> 
> You are correct and I merely had a typo, I mean "NO" is the correct
> answer if the above is not met, otherwise YES is the correct answer.

That obviously implies that there is no case where both "yes" and "no"
are right and there is no case where both "yes" and "no" are wrong.

> What everyone gets confused about is that they disagree that:
> a partial halt decider must determine its correct halt status decision 
> on the basis of the actual behavior that its input actually specifies.

Who, other than you, has ever said otherwise?

-- 
Mikko