Liste des Groupes | Revenir à c theory |
Op 01.jul.2025 om 03:34 schreef olcott:*I keep correcting you on this and you keep ignoring my correction*On 6/30/2025 8:12 PM, Richard Damon wrote:The input is a pointer to a 'finite string' that includes the code of DDD and all functions called by it, in particular including the code to abort and halt.On 6/30/25 2:30 PM, Mr Flibble wrote:>On Sun, 29 Jun 2025 22:39:10 -0400, Richard Damon wrote:>
>On 6/29/25 3:51 PM, Mr Flibble wrote:>On Sun, 29 Jun 2025 15:00:35 -0400, Richard Damon wrote:>
>Remember, the simulator must be simulating the INPUT, and thus to goNo. If HHH is simulating DDD then HHH can detect a call to itself being
past the call HHH instruction, the code must be part of the input, and
the input needs to be a constant.
passed DDD within DDD and can assert at that point that the input is
non-
halting.
>
/Flibble
And thus isn't simu;ating THE INPUT, and that the input isn't a PROGRAM.
>
Also, what if DDD is using a copy of HHH, as per the proof program,
which might have variations in the code.
>
Sorry, just shows you don't understand the problem.
No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.
>
/Flibble
Right, but the program of the input DOES halt.
>
The directly executed DDD() *IS NOT AN INPUT*
Directly executed Turing machines have always been
outside of the domain of any function computed by
a Turing machine therefore directly executed Turing
machines have never contradicted the decision of
any halt decider.
>
Halt deciders compute the mapping from the behavior
that their finite string inputs actually specifies.
>
>
Therefore, even a beginner can see that this input specifies a halting program. That your HHH cannot see that, does not change the specification.Five chatbots all agree that the input to HHH(DDD) specifies
Your attempt to distract from the specification with many irrelevant words about direct execution that is not the input, does not change the fact that the input specifies a halting program according to the semantics of the x86 language. Exactly the same input, when given to world-class simulators and direct execution show halting behaviour, which supports this claim.--
I have worked with many different simulators. The first thing that is learned is that the goal of a simulation is to reproduce the properties of reality. If it fails to reproduce relevant properties of reality, it is a worthless and incorrect simulator. Your simulator is meant to simulate the execution of x86 code. If that simulation has completely different results from reality, than even beginners will understand that the simulation is incorrect and worthless. Using such a simulation as a measure for the halting behaviour of the program specified in the input is ridiculous.
Les messages affichés proviennent d'usenet.