Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: Is Richard a Liar?
Date: Tue, 14 May 2024 13:40:31 -0500
Organization: A noiseless patient Spider
Lines: 161
Message-ID: <v20b6v$akk9$1@dont-email.me>
References: <v18e32$1vbql$1@dont-email.me> <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>
 <v1na6f$1ugl0$1@dont-email.me> <v1o67n$24f4c$1@dont-email.me>
 <v1q1ie$2l40t$1@dont-email.me> <v1q9fp$qb0p$1@i2pn2.org>
 <v1qmq8$2prs6$1@dont-email.me> <v1qouc$2qb2s$1@dont-email.me>
 <v1vbpd$3gbc$1@dont-email.me> <v1vslr$7enr$1@dont-email.me>
 <v1vuor$24b2$1@news.muc.de> <v20027$865j$1@dont-email.me>
 <v200oo$843p$1@dont-email.me> <v200u2$8dd9$1@dont-email.me>
 <v202k0$8q16$1@dont-email.me> <v20654$9o07$1@dont-email.me>
 <v2086v$a4tr$1@dont-email.me> <v208db$a6jn$1@dont-email.me>
 <v20ak6$an12$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 14 May 2024 20:40:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e9b15de5cbd4b611ca4438a3f5fabf94";
	logging-data="348809"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18xSaGbdcHZje2Nvfj/qAjB"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gKYCL5gBF3xc/WyGhf0vIUNg/rA=
In-Reply-To: <v20ak6$an12$1@dont-email.me>
Content-Language: en-US
Bytes: 8152

On 5/14/2024 1:30 PM, Fred. Zwarts wrote:
> Op 14.mei.2024 om 19:52 schreef olcott:
>> On 5/14/2024 12:49 PM, Fred. Zwarts wrote:
>>> Op 14.mei.2024 om 19:14 schreef olcott:
>>>> On 5/14/2024 11:13 AM, Fred. Zwarts wrote:
>>>>> Op 14.mei.2024 om 17:45 schreef olcott:
>>>>>> On 5/14/2024 10:42 AM, Fred. Zwarts wrote:
>>>>>>> Op 14.mei.2024 om 17:30 schreef olcott:
>>>>>>>> On 5/14/2024 10:08 AM, Alan Mackenzie wrote:
>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>
>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>> 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 }
>>>>>>>>>
>>>>>>>>>> In any case you diverged away form the whole point of this 
>>>>>>>>>> thread.
>>>>>>>>>> Richard is wrong when he says that there exists an H/D pair such
>>>>>>>>>> that D simulated by H ever reaches past its own line 03.
>>>>>>>>>
>>>>>>>>> Yes, in the same way that you are wrong.  The above "C code" is 
>>>>>>>>> garbage;
>>>>>>>>> as already pointed out, it doesn't even compile.  So any talk of
>>>>>>>>> "reaching line 3" or "matching" that "code" is vacuous nonsense.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Any H/D pair matching the above template where D(D) is simulated
>>>>>>>> by the same H(D,D) that it calls cannot possibly reach past its own
>>>>>>>> line 03. Simple software engineering verified fact.
>>>>>>>
>>>>>>> Since nobody knows who has verified this fact en there have been 
>>>>>>> counter examples, 
>>>>>>
>>>>>> *See if you can show that your claim of counter-examples is not a 
>>>>>> lie*
>>>>>> *See if you can show that your claim of counter-examples is not a 
>>>>>> lie*
>>>>>> *See if you can show that your claim of counter-examples is not a 
>>>>>> lie*
>>>>>>
>>>>>
>>>>
>>>> *YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
>>>> IS THAT BECAUSE YOU KNOW IT IS FALSE?
>>>>
>>>> *YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
>>>> IS THAT BECAUSE YOU KNOW IT IS FALSE?
>>>>
>>>> *YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
>>>> IS THAT BECAUSE YOU KNOW IT IS FALSE?
>>>>
>>>>> Olcott is trying to stay at this point for several weeks now, but 
>>>>> he does not succeed. The reason probably is, that it is already a 
>>>>> few steps too far. First there must be agreement about the words 
>>>>> and terms used in what he says. So, we should delay this subject 
>>>>> and go back a few steps.
>>>>> Before we can talk about this, first there must be 100% agreement 
>>>>> about:
>>>>>
>>>>> 1) What is a "verified fact"? Who needs to do the verification 
>>>>> before it can be said that it is a verified fact?
>>>>
>>>> I am ONLY referring to expressions that are PROVEN
>>>> to be {true entirely on the basis of their meaning}.
>>>>
>>>> *CONCRETE EXAMPLES*
>>>> How do we know that 2 + 3 = 5?
>>>
>>> If needed we can write out the proof for this, starting from the 
>>> axioms for natural numbers. That proof is well known.
>>>
>>> But nobody here knows the proof for your assertion above, that it is 
>>> a verified fact that it cannot reach past line 03. So, we would like 
>>> to see that proof. Just the claim that it has been proven is not enough.
>>>
>>
>> The "nobody here" you are referring to must be clueless
>> about the semantics of the C programming language.
>>
> 
> Are you honest? Please, give the proof, instead of keeping away from it. 

I have been an expert C/C++ programmer for decades.
If you knew C will enough yourself you would comprehend
that my claim about:

Any H/D pair matching the above template where
D(D) is simulated by the same H(D,D) that it calls
cannot possibly reach past its own line 03.
This is a simple software engineering verified fact.

My grandfather was a diagnostician and pathologist
said: "You can't argue with ignorance".

> You give the impression that you are clueless about how to prove it. The 
> only evidence you gave, are the personal attacks to people who ask for 
> it, which does not convince anybody.
> It is your claim. You have the burden of the proof.
> We need to be 100% sure before we can proceed to the next step.

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