On 1/13/24 00:53, wij wrote:
> If what you said were true, you believed words of an idiot.

Actually, the paragraph is correct. The paragraph is just an
Olcott-complicated way of saying "if a halting decider returns 0 when it
has proved that its input doesn't halt, then it returns 0 correctly."

On 1/13/24 04:39, Richard Damon wrote:
> So, are you admitting that H doesn't care about getting the right answer
> to the Halting Problem? (Since it doesn't rely on the actual definiton
> of what it is to do)

Olcott has acknowledged at least a few times that his H doesn't solve
the halting problem, but he thinks it does solve a different problem,
which I'll call the Olcott-halting problem, which is the halting problem
for "non-self-contradictory" programs.

He hasn't even solved that, and he can't even tell which programs are
self-contradictory, except that it's all the ones H gets wrong. But then
H is useless because how do we know if it gets the wrong answer or not?

H still isn't an Olcott-halting decider, since it can't prove or
disprove the Collatz conjecture, which an Olcott-halting decider could.

On 1/13/2024 5:38 AM, wij wrote:
> On 1/13/24 11:18, olcott wrote:
>> On 1/12/2024 6:06 PM, wij wrote:
>>> On 1/13/24 07:58, olcott wrote:
>>>> On 1/12/2024 5:53 PM, wij wrote:
>>>>> On 1/13/24 07:40, olcott wrote:
>>>>>> On 1/12/2024 4:36 PM, wij wrote:
>>>>>>> On 1/13/24 06:23, olcott wrote:
>>>>>>>> On 1/12/2024 4:17 PM, wij wrote:
>>>>>>>>> On 1/13/24 06:08, olcott wrote:
>>>>>>>>>> On 1/12/2024 3:55 PM, wij wrote:
>>>>>>>>>>> On 1/13/24 05:44, olcott wrote:
>>>>>>>>>>>> On 1/12/2024 3:26 PM, wij wrote:
>>>>>>>>>>>>> On 1/13/24 03:01, olcott wrote:
>>>>>>>>>>>>>> On 1/12/2024 10:40 AM, immibis wrote:
>>>>>>>>>>>>>>> On 1/12/24 15:24, olcott wrote:
>>>>>>>>>>>>>>>> On 1/12/2024 12:43 AM, immibis wrote:
>>>>>>>>>>>>>>>>> On 1/11/24 15:22, olcott wrote:
>>>>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>>>>> 06   int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>> 07   if (Halt_Status)
>>>>>>>>>>>>>>>>>> 08     HERE: goto HERE;
>>>>>>>>>>>>>>>>>> 09   return Halt_Status;
>>>>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>>>>> 14   H(D,D);
>>>>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *Execution Trace*
>>>>>>>>>>>>>>>>>> Line 14: main() invokes H(D,D);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *keeps repeating* (unless aborted)
>>>>>>>>>>>>>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that
>>>>>>>>>>>>>>>>>> simulates D(D)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *Simulation invariant*
>>>>>>>>>>>>>>>>>> *D correctly simulated by H cannot possibly reach past
>>>>>>>>>>>>>>>>>> its own line 06*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The correct simulation of D by H is the same simulation
>>>>>>>>>>>>>>>>> you get when you simulate D by H1.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Do I really have to simulate D by H1 and then paste the
>>>>>>>>>>>>>>>>> trace, or can you do that yourself?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It would be a deception to show the correct simulation
>>>>>>>>>>>>>>>> of D by H1,
>>>>>>>>>>>>>>>> as the correct simulation of D by H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is like saying the correct proof that 1+1=2 is the one
>>>>>>>>>>>>>>> which Lisa Simpson knows.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When I ask for the execution trace of D correctly
>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>> then providing any execution trace besides the execution
>>>>>>>>>>>>>> trace of
>>>>>>>>>>>>>> D correctly simulated by H IS THE WRONG ANSWER.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is the same as I ask you: "What time is it?"
>>>>>>>>>>>>>> and you answer with the color of your car.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Halting Problem asks for a program that determines
>>>>>>>>>>>>> whether an given
>>>>>>>>>>>>> input program will finish running or not.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your POOH does not accept any input except the hard-coded D
>>>>>>>>>>>>> (as if it
>>>>>>>>>>>>> were an input). This is like I ask for the color of the car
>>>>>>>>>>>>> and you
>>>>>>>>>>>>> reply with the time on the wall.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It is a verified fact that D correctly simulated by H cannot
>>>>>>>>>>>> possibly halt.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *** The Halting Problem asks for a program that determines
>>>>>>>>>>> whether an
>>>>>>>>>>> given input program will finish running or not.***
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You kept answering the time on the wall !!!
>>>>>>>>>>>
>>>>>>>>>>> What does your H,D have anything to do with the Halting Problem?
>>>>>>>>>>> Your POOH does not decide any given input !!!
>>>>>>>>>>
>>>>>>>>>> MIT Professor Michael Sipser agreed that this verbatim
>>>>>>>>>> paragraph is correct
>>>>>>>>>> (a) 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
>>>>>>>>>> (b) H can abort its simulation of D and correctly report that
>>>>>>>>>> D specifies a non-halting sequence of configurations.
>>>>>>>>>>
>>>>>>>>>> He is the author of the best selling book on the theory of
>>>>>>>>>> computation.
>>>>>>>>>> *D correctly simulated by H would never stop running unless
>>>>>>>>>> aborted*
>>>>>>>>>> (More precisely D correctly simulated by H cannot possibly halt)
>>>>>>>>>>
>>>>>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If it were true (hardly true), you read a wrong book. See Peter
>>>>>>>>> Linz's book.
>>>>>>>>
>>>>>>>> I contacted Professor Sipser directly and still have his
>>>>>>>> 10/13/2022 11:29:23 AM email agreeing to the verbatim words
>>>>>>>> of that paragraph.
>>>>>>>>
>>>>>>>
>>>>>>> 1. This is a serious lie, be careful.
>>>>>>> 2. If it were true, it is still nothing to the Halting Problem.
>>>>>>
>>>>>> *There is a long conversation about this in comp.theory*
>>>>>>
>>>>>> [Michael Sipser of MIT validates the notion of a simulating halt
>>>>>> decider]
>>>>>>
>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>  > MIT Professor Michael Sipser has agreed that the following
>>>>>>  > verbatim paragraph is correct (he has not agreed to anything
>>>>>>  > else in this paper):
>>>>>>  >
>>>>>>  > 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.
>>>>>>  >
>>>>>>  > When one accepts this definition of a simulating halt decider
>>>>>>  > then my code shows that H correctly determines the halt status
>>>>>>  > of D.
>>>>>>
>>>>>>
>>>>>
>>>>> If what you said were true, you believed words of an idiot. However,
>>>>> this is not important.
>>>>>
>>>>
>>>> Professor Sipser is the #1 best selling author of Theory of
>>>> Computation textbooks
>>>>
>>>>> The Halting Problem asks for a program that determines whether an
>>>>> given
>>>>> input program will finish running or not.
>>>>>
>>>>
>>>> *Yes and the directly executed D(D) IS NOT A FREAKING INPUT*
>>>>
>>>>> The Halting Problem asks for a program that determines whether an
>>>>> given
>>>>> input program will finish running or not.
>>>>>
>>>>
>>>> *Yes and the directly executed D(D) IS NOT A FREAKING INPUT*
>>>>
>>>>> The Halting Problem asks for a program that determines whether an
>>>>> given
>>>>> input program will finish running or not.
>>>>>
>>>>
>>>> *Yes and the directly executed D(D) IS NOT A FREAKING INPUT*
>>>>
>>>>
>>>
>>> D is a function you selected, you already know everything about it
>>> inside out.
>>>
>>> POOH is not a halting decider.
>>> The Halting Problem asks for a program that determines whether an given
>>> input program will finish running or not.
>>>
>>> POOH is not a halting decider.
>>> The Halting Problem asks for a program that determines whether an given
>>> input program will finish running or not.
>>>
>>
>> H does not *RELY* on that.
>> There are all kinds of different sample inputs that H works with.
>>
>>
>
> The "all kind" still means the kind you choose.
>
> "The Halting Problem asks for a program that determines whether an given
> input program will finish running or not."
>
> The question asks:
>  1. The halting decider must return and give a value, e.g. 1 or 0
>  2. The return value must indicate the given program will finish running
>     or not.
>  3. (This rule is supplement for idiots) The halting decider is a
>     'fixed', 'deterministic' computer program which must behave
>     consistently. I.e. rule 1,2 must be consistently satisfied.
>     In short, H must be REPRODUCIBLE.
>
> As we know, POOH does not behave consistently and cannot be reproduced:
> You had argued very hard that POOH H returning 1 (or 0, or both!!) is
> correct. But now, you seemed to change to argue that H cannot return
> (yes or no) to be correct. Every such changes indicates that you don't
> have the proof but keep announcing the HP is refuted. How can such
> volatile thing be reproduced in class rooms, from person to person, from
> today to someday latter?
>
> Every time you posted proves that The HP theorem is correct and you are
> wrong. So far, it is the fact people perceived.

On 1/13/2024 6:00 AM, immibis wrote:
> On 1/12/24 20:01, olcott wrote:
>> On 1/12/2024 10:40 AM, immibis wrote:
>>> On 1/12/24 15:24, olcott wrote:
>>>> On 1/12/2024 12:43 AM, immibis wrote:
>>>>>
>>>>> The correct simulation of D by H is the same simulation you get
>>>>> when you simulate D by H1.
>>>>>
>>>>
>>>> It would be a deception to show the correct simulation of D by H1,
>>>> as the correct simulation of D by H.
>>>
>>> It is like saying the correct proof that 1+1=2 is the one which Lisa
>>> Simpson knows.
>>
>> This is the same as I ask you: "What time is it?"
>> and you answer with the color of your car.
>>
>
> No, it's like I ask you "what's the execution trace?" and you answer
> "it's the one in my github repository."

No one can possibly provide the exact sequence of the line numbers
of D correctly simulated by H that differs from this sequence.
*This proves that the execution shown below trace is it correct*

01 int D(ptr x) // ptr is pointer to int function
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*Execution Trace*
Line 11: main() invokes H(D,D);

*keeps repeating* (unless aborted)
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 03.

It is like a smash a Boston Cream pie in your face and
you deny that there ever was a pie while the pie drips
from your face.

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

On 1/13/2024 6:01 AM, immibis wrote:
> On 1/12/24 23:08, olcott wrote:
>> On 1/12/2024 3:55 PM, wij wrote:
>>>
>>> You kept answering the time on the wall !!!
>>>
>>> What does your H,D have anything to do with the Halting Problem?
>>> Your POOH does not decide any given input !!!
>>
>> MIT Professor Michael Sipser agreed that this verbatim paragraph is
>> correct
>> (a) 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
>> (b) H can abort its simulation of D and correctly report that D
>> specifies a non-halting sequence of configurations.
> It's correct. The H you wrote is different from the H in the paragraph.
> Calling two different programs by the same letter doesn't make them the
> same.

*This paraphrase of (a) uses its terms more accurately*
(a) If simulating termination analyzer H correctly determines
that D correctly simulated by H cannot possibly reach its own
final state and terminate normally then

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

On 1/13/2024 6:03 AM, immibis wrote:
> On 1/13/24 00:53, wij wrote:
>> If what you said were true, you believed words of an idiot.
>
> Actually, the paragraph is correct. The paragraph is just an
> Olcott-complicated way of saying "if a halting decider returns 0 when it
> has proved that its input doesn't halt, then it returns 0 correctly."
>

Yes that is correct. You are a much better reviewer than
most of my reviewers.

Mike Terry did a great job of getting all of the facts of N
steps of D correctly simulated by H or HH correctly.

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

On 1/13/2024 6:07 AM, immibis wrote:
> On 1/13/24 04:39, Richard Damon wrote:
>> So, are you admitting that H doesn't care about getting the right
>> answer to the Halting Problem? (Since it doesn't rely on the actual
>> definiton of what it is to do)
>
> Olcott has acknowledged at least a few times that his H doesn't solve
> the halting problem, but he thinks it does solve a different problem,
> which I'll call the Olcott-halting problem, which is the halting problem
> for "non-self-contradictory" programs.
>

It is true that H either correctly solves the halting problem
or the halting problem's pathological input must be rejected
as semantically invalid.

> He hasn't even solved that, and he can't even tell which programs are
> self-contradictory,

https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
At the bottom of the file:

H: Begin Simulation Execution Trace Stored at:112fd1
Address_of_H:1542
[00001c72][00112fbd][00112fc1] 55 push ebp
[00001c73][00112fbd][00112fc1] 8bec mov ebp,esp
[00001c75][00112fb9][00102f8d] 51 push ecx
[00001c76][00112fb9][00102f8d] 8b4508 mov eax,[ebp+08]
[00001c79][00112fb5][00001c72] 50 push eax
[00001c7a][00112fb5][00001c72] 8b4d08 mov ecx,[ebp+08]
[00001c7d][00112fb1][00001c72] 51 push ecx
[00001c7e][00112fad][00001c83] e8bff8ffff call 00001542
H: *Infinitely Recursive Simulation Detected Simulation Stopped*

> except that it's all the ones H gets wrong. But then
> H is useless because how do we know if it gets the wrong answer or not?
>
> H still isn't an Olcott-halting decider, since it can't prove or
> disprove the Collatz conjecture, which an Olcott-halting decider could.

*That is why I started calling it a simulating termination analyzer*
It was always only intended to determine the halt status of the
counter-example input. It also does infinite recursion and infinite
loops.

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

On 1/13/24 23:03, olcott wrote:
> On 1/13/2024 5:38 AM, wij wrote:
>> On 1/13/24 11:18, olcott wrote:
>>> On 1/12/2024 6:06 PM, wij wrote:
>>>> On 1/13/24 07:58, olcott wrote:
>>>>> On 1/12/2024 5:53 PM, wij wrote:
>>>>>> On 1/13/24 07:40, olcott wrote:
>>>>>>> On 1/12/2024 4:36 PM, wij wrote:
>>>>>>>> On 1/13/24 06:23, olcott wrote:
>>>>>>>>> On 1/12/2024 4:17 PM, wij wrote:
>>>>>>>>>> On 1/13/24 06:08, olcott wrote:
>>>>>>>>>>> On 1/12/2024 3:55 PM, wij wrote:
>>>>>>>>>>>> On 1/13/24 05:44, olcott wrote:
>>>>>>>>>>>>> On 1/12/2024 3:26 PM, wij wrote:
>>>>>>>>>>>>>> On 1/13/24 03:01, olcott wrote:
>>>>>>>>>>>>>>> On 1/12/2024 10:40 AM, immibis wrote:
>>>>>>>>>>>>>>>> On 1/12/24 15:24, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/12/2024 12:43 AM, immibis wrote:
>>>>>>>>>>>>>>>>>> On 1/11/24 15:22, olcott wrote:
>>>>>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>>>>>> 06   int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>> 07   if (Halt_Status)
>>>>>>>>>>>>>>>>>>> 08     HERE: goto HERE;
>>>>>>>>>>>>>>>>>>> 09   return Halt_Status;
>>>>>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>>>>>> 14   H(D,D);
>>>>>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *Execution Trace*
>>>>>>>>>>>>>>>>>>> Line 14: main() invokes H(D,D);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *keeps repeating* (unless aborted)
>>>>>>>>>>>>>>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that
>>>>>>>>>>>>>>>>>>> simulates D(D)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *Simulation invariant*
>>>>>>>>>>>>>>>>>>> *D correctly simulated by H cannot possibly reach
>>>>>>>>>>>>>>>>>>> past its own line 06*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The correct simulation of D by H is the same
>>>>>>>>>>>>>>>>>> simulation you get when you simulate D by H1.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Do I really have to simulate D by H1 and then paste
>>>>>>>>>>>>>>>>>> the trace, or can you do that yourself?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It would be a deception to show the correct simulation
>>>>>>>>>>>>>>>>> of D by H1,
>>>>>>>>>>>>>>>>> as the correct simulation of D by H.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is like saying the correct proof that 1+1=2 is the
>>>>>>>>>>>>>>>> one which Lisa Simpson knows.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When I ask for the execution trace of D correctly
>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>> then providing any execution trace besides the execution
>>>>>>>>>>>>>>> trace of
>>>>>>>>>>>>>>> D correctly simulated by H IS THE WRONG ANSWER.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is the same as I ask you: "What time is it?"
>>>>>>>>>>>>>>> and you answer with the color of your car.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The Halting Problem asks for a program that determines
>>>>>>>>>>>>>> whether an given
>>>>>>>>>>>>>> input program will finish running or not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your POOH does not accept any input except the hard-coded
>>>>>>>>>>>>>> D (as if it
>>>>>>>>>>>>>> were an input). This is like I ask for the color of the
>>>>>>>>>>>>>> car and you
>>>>>>>>>>>>>> reply with the time on the wall.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is a verified fact that D correctly simulated by H
>>>>>>>>>>>>> cannot possibly halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *** The Halting Problem asks for a program that determines
>>>>>>>>>>>> whether an
>>>>>>>>>>>> given input program will finish running or not.***
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You kept answering the time on the wall !!!
>>>>>>>>>>>>
>>>>>>>>>>>> What does your H,D have anything to do with the Halting
>>>>>>>>>>>> Problem?
>>>>>>>>>>>> Your POOH does not decide any given input !!!
>>>>>>>>>>>
>>>>>>>>>>> MIT Professor Michael Sipser agreed that this verbatim
>>>>>>>>>>> paragraph is correct
>>>>>>>>>>> (a) 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
>>>>>>>>>>> (b) H can abort its simulation of D and correctly report that
>>>>>>>>>>> D specifies a non-halting sequence of configurations.
>>>>>>>>>>>
>>>>>>>>>>> He is the author of the best selling book on the theory of
>>>>>>>>>>> computation.
>>>>>>>>>>> *D correctly simulated by H would never stop running unless
>>>>>>>>>>> aborted*
>>>>>>>>>>> (More precisely D correctly simulated by H cannot possibly halt)
>>>>>>>>>>>
>>>>>>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If it were true (hardly true), you read a wrong book. See
>>>>>>>>>> Peter Linz's book.
>>>>>>>>>
>>>>>>>>> I contacted Professor Sipser directly and still have his
>>>>>>>>> 10/13/2022 11:29:23 AM email agreeing to the verbatim words
>>>>>>>>> of that paragraph.
>>>>>>>>>
>>>>>>>>
>>>>>>>> 1. This is a serious lie, be careful.
>>>>>>>> 2. If it were true, it is still nothing to the Halting Problem.
>>>>>>>
>>>>>>> *There is a long conversation about this in comp.theory*
>>>>>>>
>>>>>>> [Michael Sipser of MIT validates the notion of a simulating halt
>>>>>>> decider]
>>>>>>>
>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>  > MIT Professor Michael Sipser has agreed that the following
>>>>>>>  > verbatim paragraph is correct (he has not agreed to anything
>>>>>>>  > else in this paper):
>>>>>>>  >
>>>>>>>  > 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.
>>>>>>>  >
>>>>>>>  > When one accepts this definition of a simulating halt decider
>>>>>>>  > then my code shows that H correctly determines the halt status
>>>>>>>  > of D.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> If what you said were true, you believed words of an idiot. However,
>>>>>> this is not important.
>>>>>>
>>>>>
>>>>> Professor Sipser is the #1 best selling author of Theory of
>>>>> Computation textbooks
>>>>>
>>>>>> The Halting Problem asks for a program that determines whether an
>>>>>> given
>>>>>> input program will finish running or not.
>>>>>>
>>>>>
>>>>> *Yes and the directly executed D(D) IS NOT A FREAKING INPUT*
>>>>>
>>>>>> The Halting Problem asks for a program that determines whether an
>>>>>> given
>>>>>> input program will finish running or not.
>>>>>>
>>>>>
>>>>> *Yes and the directly executed D(D) IS NOT A FREAKING INPUT*
>>>>>
>>>>>> The Halting Problem asks for a program that determines whether an
>>>>>> given
>>>>>> input program will finish running or not.
>>>>>>
>>>>>
>>>>> *Yes and the directly executed D(D) IS NOT A FREAKING INPUT*
>>>>>
>>>>>
>>>>
>>>> D is a function you selected, you already know everything about it
>>>> inside out.
>>>>
>>>> POOH is not a halting decider.
>>>> The Halting Problem asks for a program that determines whether an given
>>>> input program will finish running or not.
>>>>
>>>> POOH is not a halting decider.
>>>> The Halting Problem asks for a program that determines whether an given
>>>> input program will finish running or not.
>>>>
>>>
>>> H does not *RELY* on that.
>>> There are all kinds of different sample inputs that H works with.
>>>
>>>
>>
>> The "all kind" still means the kind you choose.
>>
>> "The Halting Problem asks for a program that determines whether an given
>> input program will finish running or not."
>>
>> The question asks:
>>   1. The halting decider must return and give a value, e.g. 1 or 0
>>   2. The return value must indicate the given program will finish running
>>      or not.
>>   3. (This rule is supplement for idiots) The halting decider is a
>>      'fixed', 'deterministic' computer program which must behave
>>      consistently. I.e. rule 1,2 must be consistently satisfied.
>>      In short, H must be REPRODUCIBLE.
>>
>> As we know, POOH does not behave consistently and cannot be reproduced:
>> You had argued very hard that POOH H returning 1 (or 0, or both!!) is
>> correct. But now, you seemed to change to argue that H cannot return
>> (yes or no) to be correct. Every such changes indicates that you don't
>> have the proof but keep announcing the HP is refuted. How can such
>> volatile thing be reproduced in class rooms, from person to person, from
>> today to someday latter?
>>
>> Every time you posted proves that The HP theorem is correct and you are
>> wrong. So far, it is the fact people perceived.
>
> That you continue to dodge my challenge to provide a 100%
> detailed correct execution trace of D correctly simulated
> by H that differs from the one provided proves that you
> only have bluster and no reasoning to support your position
> that the trace below is incorrect.
>

On 1/13/2024 11:02 AM, wij wrote:
> On 1/13/24 23:03, olcott wrote:
>> On 1/13/2024 5:38 AM, wij wrote:
>>> On 1/13/24 11:18, olcott wrote:
>>>> On 1/12/2024 6:06 PM, wij wrote:
>>>>> On 1/13/24 07:58, olcott wrote:
>>>>>> On 1/12/2024 5:53 PM, wij wrote:
>>>>>>> On 1/13/24 07:40, olcott wrote:
>>>>>>>> On 1/12/2024 4:36 PM, wij wrote:
>>>>>>>>> On 1/13/24 06:23, olcott wrote:
>>>>>>>>>> On 1/12/2024 4:17 PM, wij wrote:
>>>>>>>>>>> On 1/13/24 06:08, olcott wrote:
>>>>>>>>>>>> On 1/12/2024 3:55 PM, wij wrote:
>>>>>>>>>>>>> On 1/13/24 05:44, olcott wrote:
>>>>>>>>>>>>>> On 1/12/2024 3:26 PM, wij wrote:
>>>>>>>>>>>>>>> On 1/13/24 03:01, olcott wrote:
>>>>>>>>>>>>>>>> On 1/12/2024 10:40 AM, immibis wrote:
>>>>>>>>>>>>>>>>> On 1/12/24 15:24, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/12/2024 12:43 AM, immibis wrote:
>>>>>>>>>>>>>>>>>>> On 1/11/24 15:22, olcott wrote:
>>>>>>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>>>>>>> 06   int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>> 07   if (Halt_Status)
>>>>>>>>>>>>>>>>>>>> 08     HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>> 09   return Halt_Status;
>>>>>>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>>>>>>> 14   H(D,D);
>>>>>>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Execution Trace*
>>>>>>>>>>>>>>>>>>>> Line 14: main() invokes H(D,D);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *keeps repeating* (unless aborted)
>>>>>>>>>>>>>>>>>>>> Line 06: simulated D(D) invokes simulated H(D,D)
>>>>>>>>>>>>>>>>>>>> that simulates D(D)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Simulation invariant*
>>>>>>>>>>>>>>>>>>>> *D correctly simulated by H cannot possibly reach
>>>>>>>>>>>>>>>>>>>> past its own line 06*
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The correct simulation of D by H is the same
>>>>>>>>>>>>>>>>>>> simulation you get when you simulate D by H1.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Do I really have to simulate D by H1 and then paste
>>>>>>>>>>>>>>>>>>> the trace, or can you do that yourself?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It would be a deception to show the correct simulation
>>>>>>>>>>>>>>>>>> of D by H1,
>>>>>>>>>>>>>>>>>> as the correct simulation of D by H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is like saying the correct proof that 1+1=2 is the
>>>>>>>>>>>>>>>>> one which Lisa Simpson knows.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When I ask for the execution trace of D correctly
>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>> then providing any execution trace besides the execution
>>>>>>>>>>>>>>>> trace of
>>>>>>>>>>>>>>>> D correctly simulated by H IS THE WRONG ANSWER.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is the same as I ask you: "What time is it?"
>>>>>>>>>>>>>>>> and you answer with the color of your car.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The Halting Problem asks for a program that determines
>>>>>>>>>>>>>>> whether an given
>>>>>>>>>>>>>>> input program will finish running or not.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Your POOH does not accept any input except the hard-coded
>>>>>>>>>>>>>>> D (as if it
>>>>>>>>>>>>>>> were an input). This is like I ask for the color of the
>>>>>>>>>>>>>>> car and you
>>>>>>>>>>>>>>> reply with the time on the wall.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is a verified fact that D correctly simulated by H
>>>>>>>>>>>>>> cannot possibly halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *** The Halting Problem asks for a program that determines
>>>>>>>>>>>>> whether an
>>>>>>>>>>>>> given input program will finish running or not.***
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You kept answering the time on the wall !!!
>>>>>>>>>>>>>
>>>>>>>>>>>>> What does your H,D have anything to do with the Halting
>>>>>>>>>>>>> Problem?
>>>>>>>>>>>>> Your POOH does not decide any given input !!!
>>>>>>>>>>>>
>>>>>>>>>>>> MIT Professor Michael Sipser agreed that this verbatim
>>>>>>>>>>>> paragraph is correct
>>>>>>>>>>>> (a) 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
>>>>>>>>>>>> (b) H can abort its simulation of D and correctly report
>>>>>>>>>>>> that D specifies a non-halting sequence of configurations.
>>>>>>>>>>>>
>>>>>>>>>>>> He is the author of the best selling book on the theory of
>>>>>>>>>>>> computation.
>>>>>>>>>>>> *D correctly simulated by H would never stop running unless
>>>>>>>>>>>> aborted*
>>>>>>>>>>>> (More precisely D correctly simulated by H cannot possibly
>>>>>>>>>>>> halt)
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If it were true (hardly true), you read a wrong book. See
>>>>>>>>>>> Peter Linz's book.
>>>>>>>>>>
>>>>>>>>>> I contacted Professor Sipser directly and still have his
>>>>>>>>>> 10/13/2022 11:29:23 AM email agreeing to the verbatim words
>>>>>>>>>> of that paragraph.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1. This is a serious lie, be careful.
>>>>>>>>> 2. If it were true, it is still nothing to the Halting Problem.
>>>>>>>>
>>>>>>>> *There is a long conversation about this in comp.theory*
>>>>>>>>
>>>>>>>> [Michael Sipser of MIT validates the notion of a simulating halt
>>>>>>>> decider]
>>>>>>>>
>>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>>  > MIT Professor Michael Sipser has agreed that the following
>>>>>>>>  > verbatim paragraph is correct (he has not agreed to anything
>>>>>>>>  > else in this paper):
>>>>>>>>  >
>>>>>>>>  > 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.
>>>>>>>>  >
>>>>>>>>  > When one accepts this definition of a simulating halt decider
>>>>>>>>  > then my code shows that H correctly determines the halt status
>>>>>>>>  > of D.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> If what you said were true, you believed words of an idiot. However,
>>>>>>> this is not important.
>>>>>>>
>>>>>>
>>>>>> Professor Sipser is the #1 best selling author of Theory of
>>>>>> Computation textbooks
>>>>>>
>>>>>>> The Halting Problem asks for a program that determines whether an
>>>>>>> given
>>>>>>> input program will finish running or not.
>>>>>>>
>>>>>>
>>>>>> *Yes and the directly executed D(D) IS NOT A FREAKING INPUT*
>>>>>>
>>>>>>> The Halting Problem asks for a program that determines whether an
>>>>>>> given
>>>>>>> input program will finish running or not.
>>>>>>>
>>>>>>
>>>>>> *Yes and the directly executed D(D) IS NOT A FREAKING INPUT*
>>>>>>
>>>>>>> The Halting Problem asks for a program that determines whether an
>>>>>>> given
>>>>>>> input program will finish running or not.
>>>>>>>
>>>>>>
>>>>>> *Yes and the directly executed D(D) IS NOT A FREAKING INPUT*
>>>>>>
>>>>>>
>>>>>
>>>>> D is a function you selected, you already know everything about it
>>>>> inside out.
>>>>>
>>>>> POOH is not a halting decider.
>>>>> The Halting Problem asks for a program that determines whether an
>>>>> given
>>>>> input program will finish running or not.
>>>>>
>>>>> POOH is not a halting decider.
>>>>> The Halting Problem asks for a program that determines whether an
>>>>> given
>>>>> input program will finish running or not.
>>>>>
>>>>
>>>> H does not *RELY* on that.
>>>> There are all kinds of different sample inputs that H works with.
>>>>
>>>>
>>>
>>> The "all kind" still means the kind you choose.
>>>
>>> "The Halting Problem asks for a program that determines whether an given
>>> input program will finish running or not."
>>>
>>> The question asks:
>>>   1. The halting decider must return and give a value, e.g. 1 or 0
>>>   2. The return value must indicate the given program will finish
>>> running
>>>      or not.
>>>   3. (This rule is supplement for idiots) The halting decider is a
>>>      'fixed', 'deterministic' computer program which must behave
>>>      consistently. I.e. rule 1,2 must be consistently satisfied.
>>>      In short, H must be REPRODUCIBLE.
>>>
>>> As we know, POOH does not behave consistently and cannot be reproduced:
>>> You had argued very hard that POOH H returning 1 (or 0, or both!!) is
>>> correct. But now, you seemed to change to argue that H cannot return
>>> (yes or no) to be correct. Every such changes indicates that you don't
>>> have the proof but keep announcing the HP is refuted. How can such
>>> volatile thing be reproduced in class rooms, from person to person, from
>>> today to someday latter?
>>>
>>> Every time you posted proves that The HP theorem is correct and you are
>>> wrong. So far, it is the fact people perceived.
>>
>> That you continue to dodge my challenge to provide a 100%
>> detailed correct execution trace of D correctly simulated
>> by H that differs from the one provided proves that you
>> only have bluster and no reasoning to support your position
>> that the trace below is incorrect.
>>
>
> Did you read English? It seems I can read better than you do !!!
>
> ---------------------------------
> The Halting Problem asks for a program that determines whether an given
> input
> program will finish running or not.
>

On 1/13/2024 12:34 PM, Mike Terry wrote:
> On 13/01/2024 14:57, olcott wrote:
>> On 1/13/2024 2:36 AM, Mikko wrote:
>>> On 2024-01-12 16:26:52 +0000, olcott said:
>>>
>>>> On 1/12/2024 2:22 AM, Mikko wrote:
>>>>> On 2024-01-11 14:22:34 +0000, olcott said about
>>>>> "Try and show how D correctly simulated by H reaches its own line 09":
>>>>>
>>>>>> 04 int D(ptr x)
>>>>>> 05 {
>>>>>> 06   int Halt_Status = H(x, x);
>>>>>> 07   if (Halt_Status)
>>>>>> 08     HERE: goto HERE;
>>>>>> 09   return Halt_Status;
>>>>>> 10 }
>>>>>> 11
>>>>>> 12 void main()
>>>>>> 13 {
>>>>>> 14   H(D,D);
>>>>>> 15 }
>>>>>>
>>>>>> *Execution Trace*
>>>>>> Line 14: main() invokes H(D,D);
>>>>>>
>>>>>> *keeps repeating* (unless aborted)
>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>
>>>>>> *Simulation invariant*
>>>>>> *D correctly simulated by H cannot possibly reach past its own
>>>>>> line 06*
>>>>>
>>>>> What the correct simulation trace is, and in particular whether it
>>>>> reaches the line 09, depends on what H does.
>>>>>
>>>>
>>>> Mike Terry has confirmed that H does correctly simulate N steps of D.
>>>> There is no possible way that any correct simulation of D by any H
>>>> that can possibly exist ever reaches line 06 of D.
>>>>
>>>> *This can be confirmed by the source code of D posted above*
>>>
>>> Apparently Mike Terry had a different interpretation of "any H that
>>> can possibly exist". What I said is true about some H that is consitent
>>> with the question of OP.
>>>
>>> Mikko
>>>
>>
>> Mike Terry was carefully reporting on the actual behavior
>> of D correctly simulated by H at the x86 machine code level.
>> He confirmed that N instructions of D were correctly simulated by H.
>>
>> After N instructions of D are correctly simulated by H or HH
>> then H and HH correctly detect a non-halting behavior pattern
>
> the pattern is "correctly spotted", i.e. the computation in question
> does indeed match the pattern, but as I pointed out IT IS NOT A
> NON-HALTING PATTERN...
>
> Mike.

01 int D(ptr x) // pointer to int function
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }

In other words you fail to comprehend that D correctly simulated by H
*IS FREAKING NON-HALTING* when it is impossible for D correctly
simulated by H to reach its own line 06 and terminate normally.

*Your other analysis was very excellent*

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

On 1/13/2024 12:25 PM, Mike Terry wrote:
> On 13/01/2024 08:36, Mikko wrote:
>> On 2024-01-12 16:26:52 +0000, olcott said:
>>
>>> On 1/12/2024 2:22 AM, Mikko wrote:
>>>> On 2024-01-11 14:22:34 +0000, olcott said about
>>>> "Try and show how D correctly simulated by H reaches its own line 09":
>>>>
>>>>> 04 int D(ptr x)
>>>>> 05 {
>>>>> 06   int Halt_Status = H(x, x);
>>>>> 07   if (Halt_Status)
>>>>> 08     HERE: goto HERE;
>>>>> 09   return Halt_Status;
>>>>> 10 }
>>>>> 11
>>>>> 12 void main()
>>>>> 13 {
>>>>> 14   H(D,D);
>>>>> 15 }
>>>>>
>>>>> *Execution Trace*
>>>>> Line 14: main() invokes H(D,D);
>>>>>
>>>>> *keeps repeating* (unless aborted)
>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>
>>>>> *Simulation invariant*
>>>>> *D correctly simulated by H cannot possibly reach past its own line
>>>>> 06*
>>>>
>>>> What the correct simulation trace is, and in particular whether it
>>>> reaches the line 09, depends on what H does.
>>>>
>>>
>>> Mike Terry has confirmed that H does correctly simulate N steps of D.
>>> There is no possible way that any correct simulation of D by any H
>>> that can possibly exist ever reaches line 06 of D.
>>>
>>> *This can be confirmed by the source code of D posted above*
>>
>> Apparently Mike Terry had a different interpretation of "any H that
>> can possibly exist". What I said is true about some H that is consitent
>> with the question of OP.
>
> I don't recall ever commenting on the phrase "any H that can possibly
> exist".  It's one of those "duffer" phrases that I wouldn't even bother
> trying to pin down with PO.  Like his "What is the /correct simulation
> trace/ of D(D) /by H/ ?"
>
> PO loves to grab little quotations from people, and then present them
> without the surrounding context so that he can make out that people are
> supporting his position when they are not.  It's one of his ways of
> trying to swat away legitimate criticisms of his arguments without
> addressing them.
>
> Anyway, FTR what I said was that AFAICT the x86utm simulation code does
> indeed correctly simulate individual x86 instructions.  For example if
> it simulates a "push eax" instruction, the current (virtual) eax
> register gets stored in virtual memory at the correct location on the
> stack, and (virtual) esp register is correctly decremented, and
> (virtual) eip is correctly incremented etc. etc..  That functionality
> was not written by PO, and while it is tedious it is not "difficult"
> code, and is all within .  Also AFAICT PO's own x86utm "step simulation"
> primitive appears to be correctly simulated and to nest correctly.  So
> if H simulates (say) 427 steps of D(D), AFAICT those 427 steps are
> simulated correctly.
>
> I also made it clear that if after those 427 steps, H decides it's seen
> enough, and stops simulating and returns "non-halting" then since D(D)
> does in fact halt, that means that H's /termination analysis/ code is
> wonky.  (But still, the 427 simulation steps were done correctly.)
>
>
> Regards,
> Mike.
>

01 int D(ptr x) // pointer to int function
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }

That means that you are using the strawman deception and changing the
subject away from D correctly simulated by H that cannot possibly reach
its own line 06 and terminate normally in 1 to infinity steps of correct
simulation.

Do you understand that int sum(int y, int x){return x + y;}
cannot correctly return 7 for sum(3,2) ???

A decider must report on its actual input and is not allowed
to report on anything else. The directly executed
*D(D) IS NOT A FREAKING INPUT TO H*

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

On 1/13/24 11:01 AM, olcott wrote:
> On 1/13/2024 6:00 AM, immibis wrote:
>> On 1/12/24 20:01, olcott wrote:
>>> On 1/12/2024 10:40 AM, immibis wrote:
>>>> On 1/12/24 15:24, olcott wrote:
>>>>> On 1/12/2024 12:43 AM, immibis wrote:
>>>>>>
>>>>>> The correct simulation of D by H is the same simulation you get
>>>>>> when you simulate D by H1.
>>>>>>
>>>>>
>>>>> It would be a deception to show the correct simulation of D by H1,
>>>>> as the correct simulation of D by H.
>>>>
>>>> It is like saying the correct proof that 1+1=2 is the one which Lisa
>>>> Simpson knows.
>>>
>>> This is the same as I ask you: "What time is it?"
>>> and you answer with the color of your car.
>>>
>>
>> No, it's like I ask you "what's the execution trace?" and you answer
>> "it's the one in my github repository."
>
> No one can possibly provide the exact sequence of the line numbers
> of D correctly simulated by H that differs from this sequence.
> *This proves that the execution shown below trace is it correct*
>
> 01 int D(ptr x)  // ptr is pointer to int function
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 void main()
> 10 {
> 11   H(D,D);
> 12 }
>
> *Execution Trace*
> Line 11: main() invokes H(D,D);
>
> *keeps repeating* (unless aborted)
> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
> *Simulation invariant*
> D correctly simulated by H cannot possibly reach past its own line 03.
>
> It is like a smash a Boston Cream pie in your face and
> you deny that there ever was a pie while the pie drips
> from your face.
>

Yep, that is what you are doing, just ignoring the Boston Cream Pie of
the definiton of Halting.

D(D) Halts, as you admit.

condition "unless aborted" is not fulfilled by your H, since it does
abort, thus the conclusion is not applicable.

Thus, H is incorrect in aborting and saying the input is non-halting.

YOu are missing the second Simulation invariant, criteria based on H
doing a correct simulaiton means H can not abort its simulation.

Remember, the DEFINITION of "Correct Simulation" as you are using it
means a simulation that does exactly the same thing as the original
machine, and that includes NOT aborting the simulation unless something
makes the machine actually stop (which only happens at a final state).

On 1/13/24 11:15 AM, olcott wrote:
> On 1/13/2024 6:07 AM, immibis wrote:
>> On 1/13/24 04:39, Richard Damon wrote:
>>> So, are you admitting that H doesn't care about getting the right
>>> answer to the Halting Problem? (Since it doesn't rely on the actual
>>> definiton of what it is to do)
>>
>> Olcott has acknowledged at least a few times that his H doesn't solve
>> the halting problem, but he thinks it does solve a different problem,
>> which I'll call the Olcott-halting problem, which is the halting
>> problem for "non-self-contradictory" programs.
>>
>
> It is true that H either correctly solves the halting problem
> or the halting problem's pathological input must be rejected
> as semantically invalid.
>
>> He hasn't even solved that, and he can't even tell which programs are
>> self-contradictory,
>
> https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
> At the bottom of the file:
>
> H: Begin Simulation   Execution Trace Stored at:112fd1
> Address_of_H:1542
> [00001c72][00112fbd][00112fc1] 55             push ebp
> [00001c73][00112fbd][00112fc1] 8bec           mov ebp,esp
> [00001c75][00112fb9][00102f8d] 51             push ecx
> [00001c76][00112fb9][00102f8d] 8b4508         mov eax,[ebp+08]
> [00001c79][00112fb5][00001c72] 50             push eax
> [00001c7a][00112fb5][00001c72] 8b4d08         mov ecx,[ebp+08]
> [00001c7d][00112fb1][00001c72] 51             push ecx
> [00001c7e][00112fad][00001c83] e8bff8ffff     call 00001542
> H: *Infinitely Recursive Simulation Detected Simulation Stopped*
>
>> except that it's all the ones H gets wrong. But then H is useless
>> because how do we know if it gets the wrong answer or not?
>>
>> H still isn't an Olcott-halting decider, since it can't prove or
>> disprove the Collatz conjecture, which an Olcott-halting decider could.
>
> *That is why I started calling it a simulating termination analyzer*
> It was always only intended to determine the halt status of the
> counter-example input. It also does infinite recursion and infinite
> loops.
>

And it still fails at the counter example as the counter example D(D)
still halts and H(D,D) still returns non-halting, so BY THE DEFINITIONS,
it is wrong.

Only by changing the definition of the problem, can you say you have
solved a DIFFERENT problem, but that does NOTHING to the orignal problem.

HALTING, is still not computable.

On 1/13/24 2:38 PM, olcott wrote:
> On 1/13/2024 12:34 PM, Mike Terry wrote:
>> On 13/01/2024 14:57, olcott wrote:
>>> On 1/13/2024 2:36 AM, Mikko wrote:
>>>> On 2024-01-12 16:26:52 +0000, olcott said:
>>>>
>>>>> On 1/12/2024 2:22 AM, Mikko wrote:
>>>>>> On 2024-01-11 14:22:34 +0000, olcott said about
>>>>>> "Try and show how D correctly simulated by H reaches its own line
>>>>>> 09":
>>>>>>
>>>>>>> 04 int D(ptr x)
>>>>>>> 05 {
>>>>>>> 06   int Halt_Status = H(x, x);
>>>>>>> 07   if (Halt_Status)
>>>>>>> 08     HERE: goto HERE;
>>>>>>> 09   return Halt_Status;
>>>>>>> 10 }
>>>>>>> 11
>>>>>>> 12 void main()
>>>>>>> 13 {
>>>>>>> 14   H(D,D);
>>>>>>> 15 }
>>>>>>>
>>>>>>> *Execution Trace*
>>>>>>> Line 14: main() invokes H(D,D);
>>>>>>>
>>>>>>> *keeps repeating* (unless aborted)
>>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>>
>>>>>>> *Simulation invariant*
>>>>>>> *D correctly simulated by H cannot possibly reach past its own
>>>>>>> line 06*
>>>>>>
>>>>>> What the correct simulation trace is, and in particular whether it
>>>>>> reaches the line 09, depends on what H does.
>>>>>>
>>>>>
>>>>> Mike Terry has confirmed that H does correctly simulate N steps of D.
>>>>> There is no possible way that any correct simulation of D by any H
>>>>> that can possibly exist ever reaches line 06 of D.
>>>>>
>>>>> *This can be confirmed by the source code of D posted above*
>>>>
>>>> Apparently Mike Terry had a different interpretation of "any H that
>>>> can possibly exist". What I said is true about some H that is consitent
>>>> with the question of OP.
>>>>
>>>> Mikko
>>>>
>>>
>>> Mike Terry was carefully reporting on the actual behavior
>>> of D correctly simulated by H at the x86 machine code level.
>>> He confirmed that N instructions of D were correctly simulated by H.
>>>
>>> After N instructions of D are correctly simulated by H or HH
>>> then H and HH correctly detect a non-halting behavior pattern
>>
>> the pattern is "correctly spotted", i.e. the computation in question
>> does indeed match the pattern, but as I pointed out IT IS NOT A
>> NON-HALTING PATTERN...
>>
>> Mike.
>
> 01 int D(ptr x)  // pointer to int function
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
>
> In other words you fail to comprehend that D correctly simulated by H
> *IS FREAKING NON-HALTING* when it is impossible for D correctly
> simulated by H to reach its own line 06 and terminate normally.
>
> *Your other analysis was very excellent*
>

But the counter example isn't the D that is based on the H that
correctly simulates it, but the D that is based on the H that says it is
non-halting.

Since THAT is the D in question, and it is HALTING, and is the input
given to H, then H is just wrong.

On 1/13/24 2:39 PM, olcott wrote:
> On 1/13/2024 12:25 PM, Mike Terry wrote:
>> On 13/01/2024 08:36, Mikko wrote:
>>> On 2024-01-12 16:26:52 +0000, olcott said:
>>>
>>>> On 1/12/2024 2:22 AM, Mikko wrote:
>>>>> On 2024-01-11 14:22:34 +0000, olcott said about
>>>>> "Try and show how D correctly simulated by H reaches its own line 09":
>>>>>
>>>>>> 04 int D(ptr x)
>>>>>> 05 {
>>>>>> 06   int Halt_Status = H(x, x);
>>>>>> 07   if (Halt_Status)
>>>>>> 08     HERE: goto HERE;
>>>>>> 09   return Halt_Status;
>>>>>> 10 }
>>>>>> 11
>>>>>> 12 void main()
>>>>>> 13 {
>>>>>> 14   H(D,D);
>>>>>> 15 }
>>>>>>
>>>>>> *Execution Trace*
>>>>>> Line 14: main() invokes H(D,D);
>>>>>>
>>>>>> *keeps repeating* (unless aborted)
>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>
>>>>>> *Simulation invariant*
>>>>>> *D correctly simulated by H cannot possibly reach past its own
>>>>>> line 06*
>>>>>
>>>>> What the correct simulation trace is, and in particular whether it
>>>>> reaches the line 09, depends on what H does.
>>>>>
>>>>
>>>> Mike Terry has confirmed that H does correctly simulate N steps of D.
>>>> There is no possible way that any correct simulation of D by any H
>>>> that can possibly exist ever reaches line 06 of D.
>>>>
>>>> *This can be confirmed by the source code of D posted above*
>>>
>>> Apparently Mike Terry had a different interpretation of "any H that
>>> can possibly exist". What I said is true about some H that is consitent
>>> with the question of OP.
>>
>> I don't recall ever commenting on the phrase "any H that can possibly
>> exist".  It's one of those "duffer" phrases that I wouldn't even
>> bother trying to pin down with PO.  Like his "What is the /correct
>> simulation trace/ of D(D) /by H/ ?"
>>
>> PO loves to grab little quotations from people, and then present them
>> without the surrounding context so that he can make out that people
>> are supporting his position when they are not.  It's one of his ways
>> of trying to swat away legitimate criticisms of his arguments without
>> addressing them.
>>
>> Anyway, FTR what I said was that AFAICT the x86utm simulation code
>> does indeed correctly simulate individual x86 instructions.  For
>> example if it simulates a "push eax" instruction, the current
>> (virtual) eax register gets stored in virtual memory at the correct
>> location on the stack, and (virtual) esp register is correctly
>> decremented, and (virtual) eip is correctly incremented etc. etc..
>> That functionality was not written by PO, and while it is tedious it
>> is not "difficult" code, and is all within .  Also AFAICT PO's own
>> x86utm "step simulation" primitive appears to be correctly simulated
>> and to nest correctly.  So if H simulates (say) 427 steps of D(D),
>> AFAICT those 427 steps are simulated correctly.
>>
>> I also made it clear that if after those 427 steps, H decides it's
>> seen enough, and stops simulating and returns "non-halting" then since
>> D(D) does in fact halt, that means that H's /termination analysis/
>> code is wonky.  (But still, the 427 simulation steps were done
>> correctly.)
>>
>>
>> Regards,
>> Mike.
>>
>
> 01 int D(ptr x)  // pointer to int function
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
>
> That means that you are using the strawman deception and changing the
> subject away from D correctly simulated by H that cannot possibly reach
> its own line 06 and terminate normally in 1 to infinity steps of correct
> simulation.
>
> Do you understand that int sum(int y, int x){return x + y;}
> cannot correctly return 7 for sum(3,2) ???
>
> A decider must report on its actual input and is not allowed
> to report on anything else. The directly executed
> *D(D) IS NOT A FREAKING INPUT TO H*
>
>

And the ACTUAL input is the D based on the H that says non-halting, and
the behavior of the program so descirbied is the property that H needs
to report on.

The "Program" D is NEVER the input to H, only the DESCRIPTION of it.

The DESCRIPTION does have the property derived from the direct execution
of the program it describes.

You are just stuck in a category error about the problem, because you
don't understand how programs works.

On 1/13/24 7:07 AM, immibis wrote:
> On 1/13/24 04:39, Richard Damon wrote:
>> So, are you admitting that H doesn't care about getting the right
>> answer to the Halting Problem? (Since it doesn't rely on the actual
>> definiton of what it is to do)
>
> Olcott has acknowledged at least a few times that his H doesn't solve
> the halting problem, but he thinks it does solve a different problem,
> which I'll call the Olcott-halting problem, which is the halting problem
> for "non-self-contradictory" programs.
>
> He hasn't even solved that, and he can't even tell which programs are
> self-contradictory, except that it's all the ones H gets wrong. But then
> H is useless because how do we know if it gets the wrong answer or not?
>
> H still isn't an Olcott-halting decider, since it can't prove or
> disprove the Collatz conjecture, which an Olcott-halting decider could.

Olcott isn't even really interested in the Halting problem, except that
the proof of the Halting Theorem provides an easy proof model of the
thing he really can't stand, and that is the Incompleteness Theorem. (I
don't think he understand the incompleteness Theorem proof well enough
to even try to directly refute it, so uses his claim of the Halting
Problem being incorrect to model the Incompleteness Theorem being incorrct)

Peter Olcott seems incapbable of understand how something could be True,
but not Provable, and thinks any logic system that allows that must be
fundamentally broken.

It seems that he has trouble distinguishing between Knowledge and Truth.

He also has a problem with Tarski's "Definiton of Truth" problem, it
seems largely because he doesn't understand what Tarski means by that
phrase, thinking somehow if we can't have what Tarski calls his
"Definition of Truth" (which is a procedure that can be applied to any
statement to always determine if the statement is True or not) then we
can't know at all what is actually True, and have to accept lies as Truth.

He also seems to have fundamental issue with understanding the need for
something to actually exist for it to be able to prove something from
(so his non-existent Halt Decider that works by the impossible to be
wrong method of Correctly Simulating its input until it can correctly
determine the answer, but also always gives an answer solves the Halting
Problem).

On 1/13/24 17:15, olcott wrote:
> On 1/13/2024 6:07 AM, immibis wrote:
>> On 1/13/24 04:39, Richard Damon wrote:
>>> So, are you admitting that H doesn't care about getting the right
>>> answer to the Halting Problem? (Since it doesn't rely on the actual
>>> definiton of what it is to do)
>>
>> Olcott has acknowledged at least a few times that his H doesn't solve
>> the halting problem, but he thinks it does solve a different problem,
>> which I'll call the Olcott-halting problem, which is the halting
>> problem for "non-self-contradictory" programs.
>>
>
> It is true that H either correctly solves the halting problem
> or the halting problem's pathological input must be rejected
> as semantically invalid.
>
>> He hasn't even solved that, and he can't even tell which programs are
>> self-contradictory,
>
> https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
> At the bottom of the file:
>
> H: Begin Simulation   Execution Trace Stored at:112fd1
> Address_of_H:1542
> [00001c72][00112fbd][00112fc1] 55             push ebp
> [00001c73][00112fbd][00112fc1] 8bec           mov ebp,esp
> [00001c75][00112fb9][00102f8d] 51             push ecx
> [00001c76][00112fb9][00102f8d] 8b4508         mov eax,[ebp+08]
> [00001c79][00112fb5][00001c72] 50             push eax
> [00001c7a][00112fb5][00001c72] 8b4d08         mov ecx,[ebp+08]
> [00001c7d][00112fb1][00001c72] 51             push ecx
> [00001c7e][00112fad][00001c83] e8bff8ffff     call 00001542
> H: *Infinitely Recursive Simulation Detected Simulation Stopped*

The simulation is only infinitely recursive if the program it simulates
doesn't have an infinite recursion checker. If it has an infinite
recursion checker, the checker stops the recursion and it isn't infinite.

On 1/14/2024 5:04 AM, Mikko wrote:
> On 2024-01-13 19:17:08 +0000, olcott said:
>
>> On 1/13/2024 12:25 PM, Mike Terry wrote:
>>> On 13/01/2024 08:36, Mikko wrote:
>>>> On 2024-01-12 16:26:52 +0000, olcott said:
>>>>
>>>>> On 1/12/2024 2:22 AM, Mikko wrote:
>>>>>> On 2024-01-11 14:22:34 +0000, olcott said about
>>>>>> "Try and show how D correctly simulated by H reaches its own line
>>>>>> 09":
>>>>>>
>>>>>>> 04 int D(ptr x)
>>>>>>> 05 {
>>>>>>> 06   int Halt_Status = H(x, x);
>>>>>>> 07   if (Halt_Status)
>>>>>>> 08     HERE: goto HERE;
>>>>>>> 09   return Halt_Status;
>>>>>>> 10 }
>>>>>>> 11
>>>>>>> 12 void main()
>>>>>>> 13 {
>>>>>>> 14   H(D,D);
>>>>>>> 15 }
>>>>>>>
>>>>>>> *Execution Trace*
>>>>>>> Line 14: main() invokes H(D,D);
>>>>>>>
>>>>>>> *keeps repeating* (unless aborted)
>>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>>
>>>>>>> *Simulation invariant*
>>>>>>> *D correctly simulated by H cannot possibly reach past its own
>>>>>>> line 06*
>>>>>>
>>>>>> What the correct simulation trace is, and in particular whether it
>>>>>> reaches the line 09, depends on what H does.
>>>>>>
>>>>>
>>>>> Mike Terry has confirmed that H does correctly simulate N steps of D.
>>>>> There is no possible way that any correct simulation of D by any H
>>>>> that can possibly exist ever reaches line 06 of D.
>>>>>
>>>>> *This can be confirmed by the source code of D posted above*
>>>>
>>>> Apparently Mike Terry had a different interpretation of "any H that
>>>> can possibly exist". What I said is true about some H that is consitent
>>>> with the question of OP.
>>>
>>> I don't recall ever commenting on the phrase "any H that can possibly
>>> exist".  It's one of those "duffer" phrases that I wouldn't even
>>> bother trying to pin down with PO.  Like his "What is the /correct
>>> simulation trace/ of D(D) /by H/ ?"
>>>
>>> PO loves to grab little quotations from people, and then present them
>>> without the surrounding context so that he can make out that people
>>> are supporting his position when they are not.  It's one of his ways
>>> of trying to swat away legitimate criticisms of his arguments without
>>> addressing them.
>>>
>>> Anyway, FTR what I said was that AFAICT the x86utm simulation code
>>> does indeed correctly simulate individual x86 instructions.  For
>>> example if it simulates a "push eax" instruction, the current
>>> (virtual) eax register gets stored in virtual memory at the correct
>>> location on the stack, and (virtual) esp register is correctly
>>> decremented, and (virtual) eip is correctly incremented etc. etc..
>>> That functionality was not written by PO, and while it is tedious it
>>> is not "difficult" code, and is all within .  Also AFAICT PO's own
>>> x86utm "step simulation" primitive appears to be correctly simulated
>>> and to nest correctly.  So if H simulates (say) 427 steps of D(D),
>>> AFAICT those 427 steps are simulated correctly.
>>>
>>> I also made it clear that if after those 427 steps, H decides it's
>>> seen enough, and stops simulating and returns "non-halting" then
>>> since D(D) does in fact halt,
>>
>> 01 int D(ptr x)  // pointer to int function
>> 02 {
>> 03   int Halt_Status = H(x, x);
>> 04   if (Halt_Status)
>> 05     HERE: goto HERE;
>> 06   return Halt_Status;
>> 07 }
>>
>> That means that you are using the strawman deception and changing the
>> subject away from D correctly simulated by H that cannot possibly reach
>> its own line 06 and terminate normally in 1 to infinity steps of correct
>> simulation.
>>
>> Do you understand that int sum(int y, int x){return x + y;}
>> cannot correctly return 7 for sum(3,2) ???
>>
>> A decider must report on its actual input and is not allowed
>> to report on anything else. The directly executed
>> *D(D) IS NOT A FREAKING INPUT TO H*
>
> Yes it is. A call H(T, I) tells H everything about T(I), so T(I) is
> given in the input. If T == D and I == D then T(I) == D(D) and
> is given in the input.
>
> Mikko
>

01 int D(ptr x) // ptr is pointer to int function
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }

*Execution Trace*
Line 11: main() invokes H(D,D);

*keeps repeating* (unless aborted)
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 03.

No one can possibly provide the exact sequence of the line numbers
of D correctly simulated by H that differs from the above sequence.
*This proves that D correctly simulated by H does not halt*

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

On 1/14/2024 2:14 AM, immibis wrote:
> On 1/13/24 17:15, olcott wrote:
>> On 1/13/2024 6:07 AM, immibis wrote:
>>> On 1/13/24 04:39, Richard Damon wrote:
>>>> So, are you admitting that H doesn't care about getting the right
>>>> answer to the Halting Problem? (Since it doesn't rely on the actual
>>>> definiton of what it is to do)
>>>
>>> Olcott has acknowledged at least a few times that his H doesn't solve
>>> the halting problem, but he thinks it does solve a different problem,
>>> which I'll call the Olcott-halting problem, which is the halting
>>> problem for "non-self-contradictory" programs.
>>>
>>
>> It is true that H either correctly solves the halting problem
>> or the halting problem's pathological input must be rejected
>> as semantically invalid.
>>
>>> He hasn't even solved that, and he can't even tell which programs are
>>> self-contradictory,
>>
>> https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
>> At the bottom of the file:
>>
>> H: Begin Simulation   Execution Trace Stored at:112fd1
>> Address_of_H:1542
>> [00001c72][00112fbd][00112fc1] 55             push ebp
>> [00001c73][00112fbd][00112fc1] 8bec           mov ebp,esp
>> [00001c75][00112fb9][00102f8d] 51             push ecx
>> [00001c76][00112fb9][00102f8d] 8b4508         mov eax,[ebp+08]
>> [00001c79][00112fb5][00001c72] 50             push eax
>> [00001c7a][00112fb5][00001c72] 8b4d08         mov ecx,[ebp+08]
>> [00001c7d][00112fb1][00001c72] 51             push ecx
>> [00001c7e][00112fad][00001c83] e8bff8ffff     call 00001542
>> H: *Infinitely Recursive Simulation Detected Simulation Stopped*
>
> The simulation is only infinitely recursive if the program it simulates
> doesn't have an infinite recursion checker. If it has an infinite
> recursion checker, the checker stops the recursion and it isn't infinite.
>

void Infinite_Loop2()
{ L1: goto L3;
L2: goto L1;
L3: goto L2;
}

The above is not an actual infinite loop because
its simulator aborts it simulation?

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

On 1/14/24 10:55 AM, olcott wrote:
> On 1/14/2024 2:14 AM, immibis wrote:
>> On 1/13/24 17:15, olcott wrote:
>>> On 1/13/2024 6:07 AM, immibis wrote:
>>>> On 1/13/24 04:39, Richard Damon wrote:
>>>>> So, are you admitting that H doesn't care about getting the right
>>>>> answer to the Halting Problem? (Since it doesn't rely on the actual
>>>>> definiton of what it is to do)
>>>>
>>>> Olcott has acknowledged at least a few times that his H doesn't
>>>> solve the halting problem, but he thinks it does solve a different
>>>> problem, which I'll call the Olcott-halting problem, which is the
>>>> halting problem for "non-self-contradictory" programs.
>>>>
>>>
>>> It is true that H either correctly solves the halting problem
>>> or the halting problem's pathological input must be rejected
>>> as semantically invalid.
>>>
>>>> He hasn't even solved that, and he can't even tell which programs
>>>> are self-contradictory,
>>>
>>> https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
>>> At the bottom of the file:
>>>
>>> H: Begin Simulation   Execution Trace Stored at:112fd1
>>> Address_of_H:1542
>>> [00001c72][00112fbd][00112fc1] 55             push ebp
>>> [00001c73][00112fbd][00112fc1] 8bec           mov ebp,esp
>>> [00001c75][00112fb9][00102f8d] 51             push ecx
>>> [00001c76][00112fb9][00102f8d] 8b4508         mov eax,[ebp+08]
>>> [00001c79][00112fb5][00001c72] 50             push eax
>>> [00001c7a][00112fb5][00001c72] 8b4d08         mov ecx,[ebp+08]
>>> [00001c7d][00112fb1][00001c72] 51             push ecx
>>> [00001c7e][00112fad][00001c83] e8bff8ffff     call 00001542
>>> H: *Infinitely Recursive Simulation Detected Simulation Stopped*
>>
>> The simulation is only infinitely recursive if the program it
>> simulates doesn't have an infinite recursion checker. If it has an
>> infinite recursion checker, the checker stops the recursion and it
>> isn't infinite.
>>
>
> void Infinite_Loop2()
> {
> L1: goto L3;
> L2: goto L1;
> L3: goto L2;
> }
>
> The above is not an actual infinite loop because
> its simulator aborts it simulation?
>

So, you just go to Strawmen again.

You seem to think that the fallacy of proof by example shows an actual
valid proof. (That proving something works for one case shwos it works
for all)

You are just showing you don't understand the nature of logic and
qualifiers.

H, to be a correct Halt Decider, must get the answer right for ALL
inputs, not just SOME. And even if you want to down grade to a "partial"
halt deciders, it needs to get the answers right for the ones in its
limited set, which do be a counter example for the Halting Proof, the
program created in that.

On 1/14/24 16:55, olcott wrote:
> On 1/14/2024 2:14 AM, immibis wrote:
>> On 1/13/24 17:15, olcott wrote:
>>> On 1/13/2024 6:07 AM, immibis wrote:
>>>> On 1/13/24 04:39, Richard Damon wrote:
>>>>> So, are you admitting that H doesn't care about getting the right
>>>>> answer to the Halting Problem? (Since it doesn't rely on the actual
>>>>> definiton of what it is to do)
>>>>
>>>> Olcott has acknowledged at least a few times that his H doesn't
>>>> solve the halting problem, but he thinks it does solve a different
>>>> problem, which I'll call the Olcott-halting problem, which is the
>>>> halting problem for "non-self-contradictory" programs.
>>>>
>>>
>>> It is true that H either correctly solves the halting problem
>>> or the halting problem's pathological input must be rejected
>>> as semantically invalid.
>>>
>>>> He hasn't even solved that, and he can't even tell which programs
>>>> are self-contradictory,
>>>
>>> https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
>>> At the bottom of the file:
>>>
>>> H: Begin Simulation   Execution Trace Stored at:112fd1
>>> Address_of_H:1542
>>> [00001c72][00112fbd][00112fc1] 55             push ebp
>>> [00001c73][00112fbd][00112fc1] 8bec           mov ebp,esp
>>> [00001c75][00112fb9][00102f8d] 51             push ecx
>>> [00001c76][00112fb9][00102f8d] 8b4508         mov eax,[ebp+08]
>>> [00001c79][00112fb5][00001c72] 50             push eax
>>> [00001c7a][00112fb5][00001c72] 8b4d08         mov ecx,[ebp+08]
>>> [00001c7d][00112fb1][00001c72] 51             push ecx
>>> [00001c7e][00112fad][00001c83] e8bff8ffff     call 00001542
>>> H: *Infinitely Recursive Simulation Detected Simulation Stopped*
>>
>> The simulation is only infinitely recursive if the program it
>> simulates doesn't have an infinite recursion checker. If it has an
>> infinite recursion checker, the checker stops the recursion and it
>> isn't infinite.
>>
>
> void Infinite_Loop2()
> {
> L1: goto L3;
> L2: goto L1;
> L3: goto L2;
> }
>
> The above is not an actual infinite loop because
> its simulator aborts it simulation?
>
The above is not a simulator.

On 1/14/2024 10:55 PM, immibis wrote:
> On 1/14/24 16:55, olcott wrote:
>> On 1/14/2024 2:14 AM, immibis wrote:
>>> On 1/13/24 17:15, olcott wrote:
>>>> On 1/13/2024 6:07 AM, immibis wrote:
>>>>> On 1/13/24 04:39, Richard Damon wrote:
>>>>>> So, are you admitting that H doesn't care about getting the right
>>>>>> answer to the Halting Problem? (Since it doesn't rely on the
>>>>>> actual definiton of what it is to do)
>>>>>
>>>>> Olcott has acknowledged at least a few times that his H doesn't
>>>>> solve the halting problem, but he thinks it does solve a different
>>>>> problem, which I'll call the Olcott-halting problem, which is the
>>>>> halting problem for "non-self-contradictory" programs.
>>>>>
>>>>
>>>> It is true that H either correctly solves the halting problem
>>>> or the halting problem's pathological input must be rejected
>>>> as semantically invalid.
>>>>
>>>>> He hasn't even solved that, and he can't even tell which programs
>>>>> are self-contradictory,
>>>>
>>>> https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
>>>> At the bottom of the file:
>>>>
>>>> H: Begin Simulation   Execution Trace Stored at:112fd1
>>>> Address_of_H:1542
>>>> [00001c72][00112fbd][00112fc1] 55             push ebp
>>>> [00001c73][00112fbd][00112fc1] 8bec           mov ebp,esp
>>>> [00001c75][00112fb9][00102f8d] 51             push ecx
>>>> [00001c76][00112fb9][00102f8d] 8b4508         mov eax,[ebp+08]
>>>> [00001c79][00112fb5][00001c72] 50             push eax
>>>> [00001c7a][00112fb5][00001c72] 8b4d08         mov ecx,[ebp+08]
>>>> [00001c7d][00112fb1][00001c72] 51             push ecx
>>>> [00001c7e][00112fad][00001c83] e8bff8ffff     call 00001542
>>>> H: *Infinitely Recursive Simulation Detected Simulation Stopped*
>>>
>>> The simulation is only infinitely recursive if the program it
>>> simulates doesn't have an infinite recursion checker. If it has an
>>> infinite recursion checker, the checker stops the recursion and it
>>> isn't infinite.
>>>
>>
>> void Infinite_Loop2()
>> {
>> L1: goto L3;
>> L2: goto L1;
>> L3: goto L2;
>> }
>>
>> The above is not an actual infinite loop because
>> its simulator aborts it simulation?
>>
> The above is not a simulator.

Exactly what software engineering background do you have?
I have been a professional C++ software engineer since 2000.

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

On 1/16/24 00:55, olcott wrote:
> On 1/14/2024 10:55 PM, immibis wrote:
>> On 1/14/24 16:55, olcott wrote:
>>> On 1/14/2024 2:14 AM, immibis wrote:
>>>> On 1/13/24 17:15, olcott wrote:
>>>>> On 1/13/2024 6:07 AM, immibis wrote:
>>>>>> On 1/13/24 04:39, Richard Damon wrote:
>>>>>>> So, are you admitting that H doesn't care about getting the right
>>>>>>> answer to the Halting Problem? (Since it doesn't rely on the
>>>>>>> actual definiton of what it is to do)
>>>>>>
>>>>>> Olcott has acknowledged at least a few times that his H doesn't
>>>>>> solve the halting problem, but he thinks it does solve a different
>>>>>> problem, which I'll call the Olcott-halting problem, which is the
>>>>>> halting problem for "non-self-contradictory" programs.
>>>>>>
>>>>>
>>>>> It is true that H either correctly solves the halting problem
>>>>> or the halting problem's pathological input must be rejected
>>>>> as semantically invalid.
>>>>>
>>>>>> He hasn't even solved that, and he can't even tell which programs
>>>>>> are self-contradictory,
>>>>>
>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
>>>>> At the bottom of the file:
>>>>>
>>>>> H: Begin Simulation   Execution Trace Stored at:112fd1
>>>>> Address_of_H:1542
>>>>> [00001c72][00112fbd][00112fc1] 55             push ebp
>>>>> [00001c73][00112fbd][00112fc1] 8bec           mov ebp,esp
>>>>> [00001c75][00112fb9][00102f8d] 51             push ecx
>>>>> [00001c76][00112fb9][00102f8d] 8b4508         mov eax,[ebp+08]
>>>>> [00001c79][00112fb5][00001c72] 50             push eax
>>>>> [00001c7a][00112fb5][00001c72] 8b4d08         mov ecx,[ebp+08]
>>>>> [00001c7d][00112fb1][00001c72] 51             push ecx
>>>>> [00001c7e][00112fad][00001c83] e8bff8ffff     call 00001542
>>>>> H: *Infinitely Recursive Simulation Detected Simulation Stopped*
>>>>
>>>> The simulation is only infinitely recursive if the program it
>>>> simulates doesn't have an infinite recursion checker. If it has an
>>>> infinite recursion checker, the checker stops the recursion and it
>>>> isn't infinite.
>>>>
>>>
>>> void Infinite_Loop2()
>>> {
>>> L1: goto L3;
>>> L2: goto L1;
>>> L3: goto L2;
>>> }
>>>
>>> The above is not an actual infinite loop because
>>> its simulator aborts it simulation?
>>>
>> The above is not a simulator.
>
> Exactly what software engineering background do you have?
> I have been a professional C++ software engineer since 2000.
>
Enough to understand the difference between the inner simulator and the
outer simulator when you simulate a simulator.

On 1/16/2024 1:49 AM, immibis wrote:
> On 1/16/24 00:55, olcott wrote:
>> On 1/14/2024 10:55 PM, immibis wrote:
>>> On 1/14/24 16:55, olcott wrote:
>>>> On 1/14/2024 2:14 AM, immibis wrote:
>>>>> On 1/13/24 17:15, olcott wrote:
>>>>>> On 1/13/2024 6:07 AM, immibis wrote:
>>>>>>> On 1/13/24 04:39, Richard Damon wrote:
>>>>>>>> So, are you admitting that H doesn't care about getting the
>>>>>>>> right answer to the Halting Problem? (Since it doesn't rely on
>>>>>>>> the actual definiton of what it is to do)
>>>>>>>
>>>>>>> Olcott has acknowledged at least a few times that his H doesn't
>>>>>>> solve the halting problem, but he thinks it does solve a
>>>>>>> different problem, which I'll call the Olcott-halting problem,
>>>>>>> which is the halting problem for "non-self-contradictory" programs.
>>>>>>>
>>>>>>
>>>>>> It is true that H either correctly solves the halting problem
>>>>>> or the halting problem's pathological input must be rejected
>>>>>> as semantically invalid.
>>>>>>
>>>>>>> He hasn't even solved that, and he can't even tell which programs
>>>>>>> are self-contradictory,
>>>>>>
>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
>>>>>> At the bottom of the file:
>>>>>>
>>>>>> H: Begin Simulation   Execution Trace Stored at:112fd1
>>>>>> Address_of_H:1542
>>>>>> [00001c72][00112fbd][00112fc1] 55             push ebp
>>>>>> [00001c73][00112fbd][00112fc1] 8bec           mov ebp,esp
>>>>>> [00001c75][00112fb9][00102f8d] 51             push ecx
>>>>>> [00001c76][00112fb9][00102f8d] 8b4508         mov eax,[ebp+08]
>>>>>> [00001c79][00112fb5][00001c72] 50             push eax
>>>>>> [00001c7a][00112fb5][00001c72] 8b4d08         mov ecx,[ebp+08]
>>>>>> [00001c7d][00112fb1][00001c72] 51             push ecx
>>>>>> [00001c7e][00112fad][00001c83] e8bff8ffff     call 00001542
>>>>>> H: *Infinitely Recursive Simulation Detected Simulation Stopped*
>>>>>
>>>>> The simulation is only infinitely recursive if the program it
>>>>> simulates doesn't have an infinite recursion checker. If it has an
>>>>> infinite recursion checker, the checker stops the recursion and it
>>>>> isn't infinite.
>>>>>
>>>>
>>>> void Infinite_Loop2()
>>>> {
>>>> L1: goto L3;
>>>> L2: goto L1;
>>>> L3: goto L2;
>>>> }
>>>>
>>>> The above is not an actual infinite loop because
>>>> its simulator aborts it simulation?
>>>>
>>> The above is not a simulator.
>>
>> Exactly what software engineering background do you have?
>> I have been a professional C++ software engineer since 2000.
>>
> Enough to understand the difference between the inner simulator and the
> outer simulator when you simulate a simulator.

Apparently not quite.
I repeat the question what computer language do you have
ten full time years as a software engineer?

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

On 1/16/24 15:52, olcott wrote:
> On 1/16/2024 1:49 AM, immibis wrote:
>> On 1/16/24 00:55, olcott wrote:
>>> On 1/14/2024 10:55 PM, immibis wrote:
>>>> On 1/14/24 16:55, olcott wrote:
>>>>> On 1/14/2024 2:14 AM, immibis wrote:
>>>>>> On 1/13/24 17:15, olcott wrote:
>>>>>>> On 1/13/2024 6:07 AM, immibis wrote:
>>>>>>>> On 1/13/24 04:39, Richard Damon wrote:
>>>>>>>>> So, are you admitting that H doesn't care about getting the
>>>>>>>>> right answer to the Halting Problem? (Since it doesn't rely on
>>>>>>>>> the actual definiton of what it is to do)
>>>>>>>>
>>>>>>>> Olcott has acknowledged at least a few times that his H doesn't
>>>>>>>> solve the halting problem, but he thinks it does solve a
>>>>>>>> different problem, which I'll call the Olcott-halting problem,
>>>>>>>> which is the halting problem for "non-self-contradictory" programs.
>>>>>>>>
>>>>>>>
>>>>>>> It is true that H either correctly solves the halting problem
>>>>>>> or the halting problem's pathological input must be rejected
>>>>>>> as semantically invalid.
>>>>>>>
>>>>>>>> He hasn't even solved that, and he can't even tell which
>>>>>>>> programs are self-contradictory,
>>>>>>>
>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7out.txt
>>>>>>> At the bottom of the file:
>>>>>>>
>>>>>>> H: Begin Simulation   Execution Trace Stored at:112fd1
>>>>>>> Address_of_H:1542
>>>>>>> [00001c72][00112fbd][00112fc1] 55             push ebp
>>>>>>> [00001c73][00112fbd][00112fc1] 8bec           mov ebp,esp
>>>>>>> [00001c75][00112fb9][00102f8d] 51             push ecx
>>>>>>> [00001c76][00112fb9][00102f8d] 8b4508         mov eax,[ebp+08]
>>>>>>> [00001c79][00112fb5][00001c72] 50             push eax
>>>>>>> [00001c7a][00112fb5][00001c72] 8b4d08         mov ecx,[ebp+08]
>>>>>>> [00001c7d][00112fb1][00001c72] 51             push ecx
>>>>>>> [00001c7e][00112fad][00001c83] e8bff8ffff     call 00001542
>>>>>>> H: *Infinitely Recursive Simulation Detected Simulation Stopped*
>>>>>>
>>>>>> The simulation is only infinitely recursive if the program it
>>>>>> simulates doesn't have an infinite recursion checker. If it has an
>>>>>> infinite recursion checker, the checker stops the recursion and it
>>>>>> isn't infinite.
>>>>>>
>>>>>
>>>>> void Infinite_Loop2()
>>>>> {
>>>>> L1: goto L3;
>>>>> L2: goto L1;
>>>>> L3: goto L2;
>>>>> }
>>>>>
>>>>> The above is not an actual infinite loop because
>>>>> its simulator aborts it simulation?
>>>>>
>>>> The above is not a simulator.
>>>
>>> Exactly what software engineering background do you have?
>>> I have been a professional C++ software engineer since 2000.
>>>
>> Enough to understand the difference between the inner simulator and
>> the outer simulator when you simulate a simulator.
>
> Apparently not quite.
> I repeat the question what computer language do you have
> ten full time years as a software engineer?
>

Enough to understand that if the only reason a program doesn't reach its
final state is that it's aborted then the correct return value from the
halting decider is 1.