Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down

On 6/2/2024 3:56 AM, Fred. Zwarts wrote:

Op 01.jun.2024 om 22:11 schreef olcott:

On 6/1/2024 2:04 PM, Fred. Zwarts wrote:

Op 01.jun.2024 om 20:44 schreef olcott:

On 6/1/2024 1:40 PM, Fred. Zwarts wrote:

Op 01.jun.2024 om 18:24 schreef olcott:

On 6/1/2024 11:19 AM, Fred. Zwarts wrote:

Op 01.jun.2024 om 18:13 schreef olcott:

On 6/1/2024 10:56 AM, Richard Damon wrote:

On 6/1/24 11:30 AM, olcott wrote:

>
*I will not discuss any other points with you until after you either*
(a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
     simulated by embedded_H remain stuck in recursive simulation for
     1 to ∞ of correct simulation or
>
(b) Correctly prove otherwise.

>
And until you answer the question of what that actually means, I will reply WHO CARES.
>

>
typedef int (*ptr)();  // ptr is pointer to int function in C
00       int HH(ptr p, ptr i);
01       int DD(ptr p)
02       {
03         int Halt_Status = HH(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         HH(DD,DD);
12         return 0;
13       }
>
Every DD correctly simulated by any HH of the infinite set of HH/DD
pairs that match the above template never reaches past its own simulated
line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>
In this case HH is either a pure simulator that never halts or
HH is a pure function that stops simulating after some finite number
of simulated lines. The line count is stored in a local variable.
The pure function HH always returns the meaningless value of 56
after it stops simulating.
>

>
The simulated D never reaches past line 03, because the simulated HH never halts in 1 to ∞ steps of correct simulation of HH by HH.
I have told you that so many times.
HH is required to halt, thus HH does not match the requirement.

>
>
HH correctly reports that because DD calls HH(DD,DD) in
recursive simulation that DD never halts.
>
HHH(HH,DD,DD) would report that HH halts.
>

>
Maybe. And H1 (DD,DD) would report that DD halts.
>
In the recursive simulation by HH, neither the simulation of DD, nor the simulation of HH halts. If one of them would halt, the other one would halt as well.
>
So HH 'correctly' reports that both DD and HH do not halt, because they both keep starting an instance of each other.

>
>
I will not respond to any of your replies while you continue to play
head games.
>
*Changing the subject away from this is construed as a head game*

>
Bad excuse. I am not changing the subject. I show that the requirements of HH in the subject are contradictory.
>

DD correctly simulated by pure function HH cannot possibly reach
past its own line 03 in any finite number of steps of correct
simulation.

>
Only, because the simulation of HH did not halt.
>

>
In case you didn't know pure functions must halt because they must
return a value.
>

>
I know that HH is required to halt, but your own words implies that it doesn't. So apparently your HH does not match its requirements.
>
Correct me if I am wrong and show the trace of the simulated HH that reaches its final state and the next 10 instructions.
>

>
Pages 4-5 of
*The 2021-09-26 version of my first paper on simulating halt deciders*
*Halting problem undecidability and infinitely nested simulation*
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>

 I looked at it, but I could not find where the ret instruction of the simulated H simulated by itself was printed. Could you please tell the page number? I want to know how the simulation proceeds after this return.
I only see the ret instruction simulated by another H. I hope it is not an attempt to change the subject.

P correctly simulated by H cannot possibly reach its "ret" instruction.
All of the instructions of H are screened out otherwise the execution
trace of P would be mixed into with hundreds of other pages of P.
As I explain in the paper we do not need to see any of the execution
trace of P to
(1) *Confirm that P is correctly simulated by H*
     We confirm this by the fact that the execution trace
     of P corresponds to the x86 machine code specified by P.
(2) *Confirm that P demonstrates a repeating state*
     We directly see the repeating state of P in its execution trace.
We can tell that H has returned to main() because we see that after
main() has called H(P,P) at its machine address [00000c63] the next
instruction of main() [00000c68] is executed.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer