Re: Bad faith and dishonesty

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 form a coherent argument, and that you "logic" system is based on the right to lie. This has sunk you ideas and reputation into the lake of fire that you seem to be ready to join in the near future.

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