Liste des Groupes | Revenir à theory |
On 5/27/2025 6:11 AM, Richard Damon wrote:How does your "unit of computation" differ?On 5/26/25 10:22 PM, olcott wrote:The term "Program" is too narrow minded.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.
>
Unit of computation within a model of computation.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>PRofessor Sipser was using my definitio of program, and thus any change makes your interpretation just a LIE.
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
And thus, if any of them access any of that, then ALL of that becomes part of the "input" or you don't have a "Unit of Computation"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 isRight, which you ABUSE and MISUSE, to try to prove INVALID resutls.
https://github.com/wfeldt/libx86emu
a world class x86 emulator.
Except that you never prove that all X are Y, as none of your Xs meet the requirements to be Xs.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.
No, since Halting is based on the behavior of the PROGRAM in question, and that doesn't stop when the partial simulator aborts.>You are still stupidly conflating an aborted simulation
It is a Tautology, that any program that just calls a Analyzer that will eventually return 0, and then halts, will halt.
>
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.
But it doesn't match a non-terminating behavior pattern, as the pattern you try to use is incorrect.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 simulationOnce 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.
But you can't "smash" a Turing Machine, or the thoretical x86 that defines the behavior of the program.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.
Les messages affichés proviennent d'usenet.