Re: V5 --- Professor Sipser --- Execution trace of simulating termination analyzer HHH on DDD input

On 8/24/24 9:21 AM, olcott wrote:

On 8/24/2024 3:47 AM, Fred. Zwarts wrote:

Op 23.aug.2024 om 23:40 schreef olcott:

On 8/23/2024 2:24 AM, joes wrote:

Am Thu, 22 Aug 2024 12:42:59 -0500 schrieb olcott:

>

Only IF it will in fact keep repeating, which is not the case.

>
Only IF it *WOULD* in fact keep repeating, *which is the case*
Only IF it *WOULD* in fact keep repeating, *which is the case*
Only IF it *WOULD* in fact keep repeating, *which is the case*
Only IF it *WOULD* in fact keep repeating, *which is the case*

 

It is the case only if you still cheat with the Root variable, which makes that HHH processes a non-input, when it is requested to predict the behaviour of the input.

 <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
      H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

But HHH failed to meet the criteria, since it neither itself does the required complete simulation or correctly predicts what one will do, even if we broaden the conditions to allow another simulator to do the test.

 The fact is that it *WOULD* in fact keep repeating,
thus *IT DOES* get the correct answer.

No, it doesn't, and the case you poibnt to just doesn't happen without changing the input, which makes you a cheat.
Remember, DDD it the FULL PROGRAM that was given to HHH to decide on, which means it includes the code of the HHH that it calls
How does the code for THIS HHH that DOES abort and return ever not abort and return.
The only way to test that is to give this exact input, which is the code for the function DDD, still calling that origial HHH that aborts and retturn to a variant of HHH, like HHH1, that doesn't abort and we see that this HHH1 does complete the simulation, and thus HHH was wrong, and that you are nothing but a stupid liar for

 

The input given to HHH in fact halts, as is seen in the direct execution and in the correct simulation by HHH1.

 The fact is that all deciders only report on the behavior
specified by their inputs and non-inputs are non-of-their-damn
business.

Right, and the input is the DDD that calls THIS HHH, that is the one that aborts and returns, and not the non-input of a different DDD that calls that other HHH that doesn't abort.
You break your own rules, and make yourself into a liar, by changing the program that your HHH is looking at.

 When HHH computes the mapping from its finite string input
of the x86 machine code of DDD to the the behavior that DDD
specifies HHH correctly predicts that DDD cannot possibly
stop running unless aborted.

But the behavior that HHH computed isn't the behavior of the DDD that it was given (the DDD that calls this HHH that returns). If a decider on program bhavior was allowed to be considered correct if it gives an answer based on its own, possibly incorrect, assumptions about the program, then add such deciders would be correct, just because they said so.
That's like says a person is correct to the question: "Do you think a penny is worth more than a dollor?" would be correct to say yes, because the answer really thought (stupidly) that a penny was worth more than a dollar.
The halting question is not asking the decider it "It thinks" the input will halt, (and thus allow bad logic off of partial emulation) but is asking the factual question, Will the program I am showing your halt when it is run.

 The reason that this seem so strange is not that I am incorrect.
The reason is that everyone rejected simulation as a basis for a
halt decider out-of-hand without review. Because of this they
never saw the details of this behavior when a termination analyzer
correctly emulates an input that calls itself.

Nope, you are incorrect because you are too ignorant to understand what a decider actually is.

 They never notices that there could possibly be a case where
the behavior of the emulation of the machine specified by its
own Machine description (x86 language) could differ from
the direct execution of this same machine.

But it can't be, and you have accepted that fact by failing, MANY TIMES, to point out which instruction, that was ACTUALLY CORRECT EMULATED, differed in the simulation from the direct execution.
You, and your HHH, *LIE* by not actually "correctly emulating" the input program, as you don't seem to understand what a "Call" instruction actually is, in part, because it seems you don't understand what a PROGRAM actually is

 

But HHH cannot possibly simulate itself correctly.

 The ONLY measure of simulated correctly is that each x86
instruction of N instructions of DDD is emulated correctly and
in the correct order. 2 + 3 = 5 even if you don't believe in numbers.

And thus, the CALL HHH instuction must go into HHH and show what it actually does.
Since, even when you do follow that path, you see the conditional instructions in HHH, and thus the "logic" (to use the term lightly) that you use to decide that DDD is non-halting is just incorrect.

 *Simulating Termination Analyzer H is Not Fooled by Pathological Input D*
https://www.researchgate.net/publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
 

LIES.