Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Bad faith and dishonesty
Date: Tue, 27 May 2025 10:28:30 -0500
Organization: A noiseless patient Spider
Lines: 178
Message-ID: <1014lmu$2lsi8$6@dont-email.me>
References: <m99YP.725664$B6tf.610565@fx02.ams4>
 <100uct4$184ak$1@dont-email.me> <100v9ta$1d5lg$7@dont-email.me>
 <1011eai$1urdm$1@dont-email.me> <10121bt$22da5$4@dont-email.me>
 <8bb5266e35845a4d8f2feb618c0c18629c04e4e7@i2pn2.org>
 <1012oj1$278f8$1@dont-email.me>
 <1196d9de2e2aebc1b6d1a85047192e8ea1aeb1f1@i2pn2.org>
 <10137lv$2djeu$1@dont-email.me>
 <95ba066e940ac7d1fdb79506825c51262a5cafd8@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 27 May 2025 17:28:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b05b1d7fc1f90d5563d667325c66ff38";
	logging-data="2814536"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/AZm7PZmOfK8SMxfzEjQrt"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:iokA+U3DP38aAfyBKZ4var46h3o=
Content-Language: en-US
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 250527-6, 5/27/2025), Outbound message
In-Reply-To: <95ba066e940ac7d1fdb79506825c51262a5cafd8@i2pn2.org>
Bytes: 9204

On 5/27/2025 6:11 AM, Richard Damon wrote:
> On 5/26/25 10:22 PM, olcott wrote:
>> On 5/26/2025 9:09 PM, Richard Damon wrote:
>>> On 5/26/25 6:05 PM, olcott wrote:
>>>> On 5/26/2025 3:44 PM, Richard Damon wrote:
>>>>> On 5/26/25 11:29 AM, olcott wrote:
>>>>>> On 5/26/2025 5:04 AM, Mikko wrote:
>>>>>>> On 2025-05-25 14:36:26 +0000, olcott said:
>>>>>>>
>>>>>>>> On 5/25/2025 1:21 AM, Mikko wrote:
>>>>>>>>> On 2025-05-24 01:20:18 +0000, Mr Flibble said:
>>>>>>>>>
>>>>>>>>>> So much bad faith and dishonesty shown in this forum that 
>>>>>>>>>> myself and Peter
>>>>>>>>>> Olcott have to fight against.
>>>>>>>>>
>>>>>>>>> Everything here seems to be dishonesty and protests against 
>>>>>>>>> dishonesty.
>>>>>>>>> If you could remove all dishonesty the protests woud stop, too, 
>>>>>>>>> and
>>>>>>>>> nothing would be left.
>>>>>>>>
>>>>>>>> _DDD()
>>>>>>>> [00002192] 55             push ebp
>>>>>>>> [00002193] 8bec           mov ebp,esp
>>>>>>>> [00002195] 6892210000     push 00002192
>>>>>>>> [0000219a] e833f4ffff     call 000015d2  // call HHH
>>>>>>>> [0000219f] 83c404         add esp,+04
>>>>>>>> [000021a2] 5d             pop ebp
>>>>>>>> [000021a3] c3             ret
>>>>>>>> Size in bytes:(0018) [000021a3]
>>>>>>>>
>>>>>>>> Then acknowledge that DDD simulated by HHH according
>>>>>>>> to the rules of the x86 language cannot possibly reach
>>>>>>>> its own "ret" instruction final halt state.
>>>>>>>
>>>>>>> I have never claimed that your HHH can simulate DDD to from the 
>>>>>>> beginning
>>>>>>> to end.
>>>>>>>
>>>>>>
>>>>>> I am asking you to affirm that I am correct about this point.
>>>>>> DDD simulated by HHH according to the rules of the x86
>>>>>> language cannot possibly reach its own "ret" instruction
>>>>>> final halt state, thus is correctly rejected as non-halting.
>>>>>>
>>>>>
>>>>> But you have to affirm first that HHH *IS* a program that does 
>>>>> that, and can't be "changed" to some other program, and that DDD is 
>>>>> "completed" to contain that same code.
>>>>>
>>>>> Of course, once you define that HHH is such a program, 
>>>>
>>>> Unless HHH(DDD) aborts its emulation of DDD then
>>>> DDD() and HHH() never stop running proving that
>>>> the input to HHH(DDD) SPECIFIES NON-TERMINATING
>>>> BEHAVIOR THAT MUST BE ABORTED.
>>>>
>>>
>>> But since HHH(DDD) DOES abort its emulation of DDD, it is a fact that 
>>> DDD() will halt.
>>>
>>
>> *Termination analyzers PREDICT behavior dip-shit*
>> It is a tautology that every input that must be
>> aborted to prevent the infinite simulation of this
>> input DOES SPECIFY NON-HALTING BEHAVIOR.
>>
>>
>>
> 
> RIGHT, A Termination analyzer is a PROGRAM that predicts the behavior of 
> the PROGRAM that has been supplied as an input.
> 

The term "Program" is too narrow minded.
Unit of computation within a model of computation.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     would never stop running unless aborted then

> This means that you H, must be fully defined in behavior, so it is a 
> program, and that the input contain all the code it uses, and thus (a 
> copy) of the code of the decider it is goig to all.
> 

The x86 machine code of every function in Halt7.c shares
the same global memory space. The behavior is fully defined
by the x86 language of each function.

The heart of the x86utm operating system is
https://github.com/wfeldt/libx86emu
a world class x86 emulator.

> Your idea of an "infinte set" of deciders doesn't create "a" problem to 
> solve, but an infinite set of problems, each with a DIFFERENT input, and 
> thus you can look at one version to determine the behavior of another.
> 

In other words when I prove that:
   All X are Y
you fail to understand that this entails:
   Some X are not Y is false.

> 
> It is a Tautology, that any program that just calls a Analyzer that will 
> eventually return 0, and then halts, will halt.
> 

You are still stupidly conflating an aborted simulation
with halting. They are not the same. Halting in computer
science is the same as a normal termination in software
engineering. Unless DDD emulated by HHH reaches its "ret"
instruction final halt state DDD HAS NEVER HALTED.

> The use "must" in the sense you are using it doesn't work, as if the 
> Termination analyzer decided to abort, then it does abort, and to 
> determine if that was correct, we need to look at the correct simulation 

Once HHH has correctly matches a non-terminating behavior
pattern it has complete proof that its simulated input
cannot possibly reach its own simulated "ret" instruction
final halt state.

> of *THAT* input, which from our tautology, we know that it *WILL* halt, 

If you run a program on a computer and smash the computer
into tiny bits with a sledge hammer we cannot say that its
program terminated normally, thus never halted. As soon as
we know that a simulated input cannot possibly reach its
own final halt state then we know it is non-halting.

> and thusthe decider didn't "need" to abort, but just did. You can't at 
> this point change it not to abort, as you can't change programs without 
> making them a different program.
> 
> Thus, your infinite set of programs can be divided into two classes:
> 
> Class 1, those deciders that do abort because they were programmed to do 
> so, under the mistaken belief that they needed to. None of the deciders 
> see the input reaching a final state, so return 0, but all of the 
> inputs, when given to a correct simulator (while still calling the 
> decider that aborted and returns 0) will halt. Thus, ALL the Class 1 
> deciders failed to predict the behavior of their input.
> 
> Class 2, those deciders that do not ever abort because that is the way 
> they are programmed. None of these deciders will ever return an answer, 
> and thus just fail to be deciders, because it is true that a program 
> that tries to actually completely simulate itself will become non- 
> halting. By not answering these deciders have failed, but there input 
> was a class 2 input, and thus do not show anything about the behavior of 
> a class 1 input.
> 
> Your problem is you forget about the requirement for things to be a 
> program, or just don't understand what that means. You then try to look 
> at a system that doesn't actually implement and follow the requirements 
> of the problem, as it can't have two independent programs in it, which 
> you sometimes admit.
> 
> Your argument is based on self-contradictory assumoptions, and thus is 
> just invalid. You have admitted and stipulated that your decider and 
> input are not programs, and thus just not valid entities to talk about 
> in the problem. You have asserted that your publisbhed Halt7.c is always 
> part of the problem, but also that you are allowed to change the code 
> that it specifies. In other words, you insist on the right to just LIE 
> about what your system is.
> 
> Sorry, all you are doing is proi=ving that you don't understand how to 
========== REMAINDER OF ARTICLE TRUNCATED ==========