On 6/7/2022 8:05 PM, Richard Damon wrote:
> On 6/7/22 8:52 PM, olcott wrote:
>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>> Hi,
>>>
>>>  From discussion with Olcott in comp.lang.c++ I have determined that
>>> his so called refutation of the HP proofs is based around the
>>> behaviour of his simulation-based decider, H:
>>>
>>> void Q(u32 x)
>>> {
>>>           if (H(x, x))
>>>             FUBAR();
>>>           return;
>>> }
>>>
>>> int main()
>>> {
>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>> }
>>>
>>> He asserts H(Q,Q)=0 based on a nested simulation being detected (i.e. Q
>>> invoking H) irregardless of whether FUBAR halts or not.
>>>
>>> If FUBAR halts H gives the wrong answer.
>>>
>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) simulation
>>> however that wouldn't be the case for non-simulating decider for which
>>> there would be no such recursion.
>>>
>>
>> I propose a way to correctly decide the impossible input and your
>> "rebuttal" is that there are still other wrong ways to do this that
>> don't work.
>
> Nope, you propose that if you can make a machine that both RUNS FOREVER
> and also STOPS PART WAY at the same time with the same input, that you
> can solve the problem.
>

RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL SIMULATION OF
AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE SIMULATION WOULD NEVER
HALT.

It is an easily verified fact that a partial simulation of
Infinite_Loop() conclusively proves that it never halts.

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6842130000 push 00001342
[0000137a](05) e833fdffff call 000010b2
[0000137f](03) 83c404 add esp,+04
[00001382](01) 50 push eax
[00001383](05) 6823040000 push 00000423
[00001388](05) e8e5f0ffff call 00000472
[0000138d](03) 83c408 add esp,+08
[00001390](02) 33c0 xor eax,eax
[00001392](01) 5d pop ebp
[00001393](01) c3 ret
Size in bytes:(0034) [00001393]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001372][0010228f][00000000] 55 push ebp
[00001373][0010228f][00000000] 8bec mov ebp,esp
[00001375][0010228b][00001342] 6842130000 push 00001342 // push
_Infinite_Loop
[0000137a][00102287][0000137f] e833fdffff call 000010b2 // call H0

Begin Local Halt Decider Simulation Execution Trace Stored at:212343
[00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

[0000137f][0010228f][00000000] 83c404 add esp,+04
[00001382][0010228b][00000000] 50 push eax
[00001383][00102287][00000423] 6823040000 push 00000423
[00001388][00102287][00000423] e8e5f0ffff call 00000472
Input_Halts = 0
[0000138d][0010228f][00000000] 83c408 add esp,+08
[00001390][0010228f][00000000] 33c0 xor eax,eax
[00001392][00102293][00100000] 5d pop ebp
[00001393][00102297][00000004] c3 ret
Number of Instructions Executed(680)

--
Copyright 2022 Pete Olcott

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

On 6/7/22 10:25 PM, olcott wrote:
> On 6/7/2022 8:05 PM, Richard Damon wrote:
>> On 6/7/22 8:52 PM, olcott wrote:
>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>> Hi,
>>>>
>>>>  From discussion with Olcott in comp.lang.c++ I have determined that
>>>> his so called refutation of the HP proofs is based around the
>>>> behaviour of his simulation-based decider, H:
>>>>
>>>> void Q(u32 x)
>>>> {
>>>>           if (H(x, x))
>>>>             FUBAR();
>>>>           return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>> }
>>>>
>>>> He asserts H(Q,Q)=0 based on a nested simulation being detected (i.e. Q
>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>
>>>> If FUBAR halts H gives the wrong answer.
>>>>
>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) simulation
>>>> however that wouldn't be the case for non-simulating decider for which
>>>> there would be no such recursion.
>>>>
>>>
>>> I propose a way to correctly decide the impossible input and your
>>> "rebuttal" is that there are still other wrong ways to do this that
>>> don't work.
>>
>> Nope, you propose that if you can make a machine that both RUNS
>> FOREVER and also STOPS PART WAY at the same time with the same input,
>> that you can solve the problem.
>>
>
> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL SIMULATION OF
> AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE SIMULATION WOULD NEVER
> HALT.

No, Peter Olcott shows he is too stupid to understand the fallacy of
Proof by Example.

Yes, SOME inputs can be correctly predicted because a valid and sound
proof can be built from the partial simulation.

You seem to be too dumb to realize that just because one case works,
that not all cases do.

If this is the level of your logic, you have proved yourself to be
incapable of even the most basic of logical deductions.

The fact that you just keep repeating this same mistake over and over
and over again, even though the error has been pointed out repeatedly
just shows tha tyou ar either a pathological liar, or an idiot that just
can't learn and is DOOMED to keep repeating the same mistake for all
eternity.

Yes, you can decide that Infinite_Loop is non-halting with a finite
partial trace. You can not do so for P(P).

I PITY YOU.

>
> It is an easily verified fact that a partial simulation of
> Infinite_Loop() conclusively proves that it never halts.
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0(Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001342](01)  55              push ebp
> [00001343](02)  8bec            mov ebp,esp
> [00001345](02)  ebfe            jmp 00001345
> [00001347](01)  5d              pop ebp
> [00001348](01)  c3              ret
> Size in bytes:(0007) [00001348]
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6842130000      push 00001342
> [0000137a](05)  e833fdffff      call 000010b2
> [0000137f](03)  83c404          add esp,+04
> [00001382](01)  50              push eax
> [00001383](05)  6823040000      push 00000423
> [00001388](05)  e8e5f0ffff      call 00000472
> [0000138d](03)  83c408          add esp,+08
> [00001390](02)  33c0            xor eax,eax
> [00001392](01)  5d              pop ebp
> [00001393](01)  c3              ret
> Size in bytes:(0034) [00001393]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001372][0010228f][00000000] 55         push ebp
> [00001373][0010228f][00000000] 8bec       mov ebp,esp
> [00001375][0010228b][00001342] 6842130000 push 00001342 // push
> _Infinite_Loop
> [0000137a][00102287][0000137f] e833fdffff call 000010b2 // call H0
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212343
> [00001342][00212333][00212337] 55         push ebp
> [00001343][00212333][00212337] 8bec       mov ebp,esp
> [00001345][00212333][00212337] ebfe       jmp 00001345
> [00001345][00212333][00212337] ebfe       jmp 00001345
> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>
> [0000137f][0010228f][00000000] 83c404     add esp,+04
> [00001382][0010228b][00000000] 50         push eax
> [00001383][00102287][00000423] 6823040000 push 00000423
> [00001388][00102287][00000423] e8e5f0ffff call 00000472
> Input_Halts = 0
> [0000138d][0010228f][00000000] 83c408     add esp,+08
> [00001390][0010228f][00000000] 33c0       xor eax,eax
> [00001392][00102293][00100000] 5d         pop ebp
> [00001393][00102297][00000004] c3         ret
> Number of Instructions Executed(680)
>
>
>

On 6/7/2022 9:50 PM, Richard Damon wrote:
> On 6/7/22 10:25 PM, olcott wrote:
>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>> On 6/7/22 8:52 PM, olcott wrote:
>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>> Hi,
>>>>>
>>>>>  From discussion with Olcott in comp.lang.c++ I have determined that
>>>>> his so called refutation of the HP proofs is based around the
>>>>> behaviour of his simulation-based decider, H:
>>>>>
>>>>> void Q(u32 x)
>>>>> {
>>>>>           if (H(x, x))
>>>>>             FUBAR();
>>>>>           return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>> }
>>>>>
>>>>> He asserts H(Q,Q)=0 based on a nested simulation being detected
>>>>> (i.e. Q
>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>
>>>>> If FUBAR halts H gives the wrong answer.
>>>>>
>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) simulation
>>>>> however that wouldn't be the case for non-simulating decider for which
>>>>> there would be no such recursion.
>>>>>
>>>>
>>>> I propose a way to correctly decide the impossible input and your
>>>> "rebuttal" is that there are still other wrong ways to do this that
>>>> don't work.
>>>
>>> Nope, you propose that if you can make a machine that both RUNS
>>> FOREVER and also STOPS PART WAY at the same time with the same input,
>>> that you can solve the problem.
>>>
>>
>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL SIMULATION
>> OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE SIMULATION WOULD
>> NEVER HALT.
>
> No, Peter Olcott shows he is too stupid to understand the fallacy of
> Proof by Example.
>

You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus making
inappropriate generalization impossible.

In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example

--
Copyright 2022 Pete Olcott

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

On 6/7/22 11:17 PM, olcott wrote:
> On 6/7/2022 9:50 PM, Richard Damon wrote:
>> On 6/7/22 10:25 PM, olcott wrote:
>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>> Hi,
>>>>>>
>>>>>>  From discussion with Olcott in comp.lang.c++ I have determined that
>>>>>> his so called refutation of the HP proofs is based around the
>>>>>> behaviour of his simulation-based decider, H:
>>>>>>
>>>>>> void Q(u32 x)
>>>>>> {
>>>>>>           if (H(x, x))
>>>>>>             FUBAR();
>>>>>>           return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>> }
>>>>>>
>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being detected
>>>>>> (i.e. Q
>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>
>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>
>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>> simulation
>>>>>> however that wouldn't be the case for non-simulating decider for
>>>>>> which
>>>>>> there would be no such recursion.
>>>>>>
>>>>>
>>>>> I propose a way to correctly decide the impossible input and your
>>>>> "rebuttal" is that there are still other wrong ways to do this that
>>>>> don't work.
>>>>
>>>> Nope, you propose that if you can make a machine that both RUNS
>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>> input, that you can solve the problem.
>>>>
>>>
>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL SIMULATION
>>> OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE SIMULATION WOULD
>>> NEVER HALT.
>>
>> No, Peter Olcott shows he is too stupid to understand the fallacy of
>> Proof by Example.
>>
>
> You are too stupid to know that this does not apply.
> When one is 100% specific there is no generalization at all thus making
> inappropriate generalization impossible.
>
> In logic and mathematics, proof by example (sometimes known as
> inappropriate generalization)
> https://en.wikipedia.org/wiki/Proof_by_example
>

Right, and showing that an algorith works to detect a infinite
recursion, even with a conditional simulation in the loop, by looking at
a program that does a jump to self is an inappropriate generalization.

The fact that you don't see that just proves how stupid you are,

You don't even know what they mean by "Generalization" there it seems.

On 6/7/2022 10:25 PM, Richard Damon wrote:
>
> On 6/7/22 11:17 PM, olcott wrote:
>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>> On 6/7/22 10:25 PM, olcott wrote:
>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>  From discussion with Olcott in comp.lang.c++ I have determined that
>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>
>>>>>>> void Q(u32 x)
>>>>>>> {
>>>>>>>           if (H(x, x))
>>>>>>>             FUBAR();
>>>>>>>           return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>> }
>>>>>>>
>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being detected
>>>>>>> (i.e. Q
>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>
>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>
>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>> simulation
>>>>>>> however that wouldn't be the case for non-simulating decider for
>>>>>>> which
>>>>>>> there would be no such recursion.
>>>>>>>
>>>>>>
>>>>>> I propose a way to correctly decide the impossible input and your
>>>>>> "rebuttal" is that there are still other wrong ways to do this
>>>>>> that don't work.
>>>>>
>>>>> Nope, you propose that if you can make a machine that both RUNS
>>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>>> input, that you can solve the problem.
>>>>>
>>>>
>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>> SIMULATION WOULD NEVER HALT.
>>>
>>> No, Peter Olcott shows he is too stupid to understand the fallacy of
>>> Proof by Example.
>>>
>>
>> You are too stupid to know that this does not apply.
>> When one is 100% specific there is no generalization at all thus
>> making inappropriate generalization impossible.
>>
>> In logic and mathematics, proof by example (sometimes known as
>> inappropriate generalization)
>> https://en.wikipedia.org/wiki/Proof_by_example
>>
>
> Right, and showing that an algorith works to detect a infinite
> recursion, even with a conditional simulation in the loop, by looking at
> a program that does a jump to self is an inappropriate generalization.
>
> The fact that you don't see that just proves how stupid you are,
>
> You don't even know what they mean by "Generalization" there it seems.

When I show every single step of the execution trace of P there is no
freaking generalization at all nitwit, it is all 100% specific.

--
Copyright 2022 Pete Olcott

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

On 6/7/2022 10:25 PM, Richard Damon wrote:
>
> On 6/7/22 11:17 PM, olcott wrote:
>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>> On 6/7/22 10:25 PM, olcott wrote:
>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>  From discussion with Olcott in comp.lang.c++ I have determined that
>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>
>>>>>>> void Q(u32 x)
>>>>>>> {
>>>>>>>           if (H(x, x))
>>>>>>>             FUBAR();
>>>>>>>           return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>> }
>>>>>>>
>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being detected
>>>>>>> (i.e. Q
>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>
>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>
>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>> simulation
>>>>>>> however that wouldn't be the case for non-simulating decider for
>>>>>>> which
>>>>>>> there would be no such recursion.
>>>>>>>
>>>>>>
>>>>>> I propose a way to correctly decide the impossible input and your
>>>>>> "rebuttal" is that there are still other wrong ways to do this
>>>>>> that don't work.
>>>>>
>>>>> Nope, you propose that if you can make a machine that both RUNS
>>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>>> input, that you can solve the problem.
>>>>>
>>>>
>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>> SIMULATION WOULD NEVER HALT.
>>>
>>> No, Peter Olcott shows he is too stupid to understand the fallacy of
>>> Proof by Example.
>>>
>>
>> You are too stupid to know that this does not apply.
>> When one is 100% specific there is no generalization at all thus
>> making inappropriate generalization impossible.
>>
>> In logic and mathematics, proof by example (sometimes known as
>> inappropriate generalization)
>> https://en.wikipedia.org/wiki/Proof_by_example
>>
>
> Right, and showing that an algorith works to detect

A single 100% specific instance of infinitely nested simulation is not
any freaking generalization at all. You actually might be stupid in
which case I take it back. It is rude to call stupid people stupid
because it is not their fault. I called you stupid because I thought you
were playing sadistic head games.

--
Copyright 2022 Pete Olcott

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

On 6/7/22 11:32 PM, olcott wrote:
> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>
>> On 6/7/22 11:17 PM, olcott wrote:
>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>  From discussion with Olcott in comp.lang.c++ I have determined
>>>>>>>> that
>>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>>
>>>>>>>> void Q(u32 x)
>>>>>>>> {
>>>>>>>>           if (H(x, x))
>>>>>>>>             FUBAR();
>>>>>>>>           return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>>> }
>>>>>>>>
>>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being detected
>>>>>>>> (i.e. Q
>>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>>
>>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>>
>>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>>> simulation
>>>>>>>> however that wouldn't be the case for non-simulating decider for
>>>>>>>> which
>>>>>>>> there would be no such recursion.
>>>>>>>>
>>>>>>>
>>>>>>> I propose a way to correctly decide the impossible input and your
>>>>>>> "rebuttal" is that there are still other wrong ways to do this
>>>>>>> that don't work.
>>>>>>
>>>>>> Nope, you propose that if you can make a machine that both RUNS
>>>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>>>> input, that you can solve the problem.
>>>>>>
>>>>>
>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>> SIMULATION WOULD NEVER HALT.
>>>>
>>>> No, Peter Olcott shows he is too stupid to understand the fallacy of
>>>> Proof by Example.
>>>>
>>>
>>> You are too stupid to know that this does not apply.
>>> When one is 100% specific there is no generalization at all thus
>>> making inappropriate generalization impossible.
>>>
>>> In logic and mathematics, proof by example (sometimes known as
>>> inappropriate generalization)
>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>
>>
>> Right, and showing that an algorith works to detect a infinite
>> recursion, even with a conditional simulation in the loop, by looking
>> at a program that does a jump to self is an inappropriate generalization.
>>
>> The fact that you don't see that just proves how stupid you are,
>>
>> You don't even know what they mean by "Generalization" there it seems.
>
> When I show every single step of the execution trace of P there is no
> freaking generalization at all nitwit, it is all 100% specific.
>
>

Except that is a lie.

You don't show the instruction that the x86 processor executes
immediately after the 7th instruction.

Remember, a "call" instruction does not change execution mode for a real
x86 processor, so your "System Code" excuse doesn't apply.

The copy of H that P calls is part of P, and thus needs to be traced.

Also, you show a basic lack of understanding of English, is the fact
that your used the fact that it is obviously possible for H to decide on
a partial trace of Infinite_Loop that it halts, so thus it must be
possible for H to decide on P with a partial trace.

You are just showing that you are too dumb to be making claims about logic.

A correct x86 emulation of a program shows every instruction in that
whole program that the processor executes, including all the subroutine
its calls, therefore the trace needs to show the trace in H.

You need to define the actual "infinte execution pattern" that H is
going to use, and that pattern needs to actually work when we actually
execute the P(P) that uses an H with that pattern installed. You just
don't seem to understand that.

You even admit that this P(P) does Halt, but then claim, without proof,
that it doesn't matter, when it is the actual definiton of what H needs
to decide on.

All you have done is proved that you don't understand what the meaning
of words actually mean, and since that is the basis of all your proofs,
that says you got NOTHING.

YOU HAVE FAILED.

YOU HAVE WASTED the last decades of your life.

YOU HAVE DOOMED yourself to dying with the reputation of a lying kook.

You just seem to be too dumb to understand that. I really think you have
achieved the remarkable feat of gaslighting yourself.

On 6/7/22 11:43 PM, olcott wrote:
> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>
>> On 6/7/22 11:17 PM, olcott wrote:
>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>  From discussion with Olcott in comp.lang.c++ I have determined
>>>>>>>> that
>>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>>
>>>>>>>> void Q(u32 x)
>>>>>>>> {
>>>>>>>>           if (H(x, x))
>>>>>>>>             FUBAR();
>>>>>>>>           return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>>> }
>>>>>>>>
>>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being detected
>>>>>>>> (i.e. Q
>>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>>
>>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>>
>>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>>> simulation
>>>>>>>> however that wouldn't be the case for non-simulating decider for
>>>>>>>> which
>>>>>>>> there would be no such recursion.
>>>>>>>>
>>>>>>>
>>>>>>> I propose a way to correctly decide the impossible input and your
>>>>>>> "rebuttal" is that there are still other wrong ways to do this
>>>>>>> that don't work.
>>>>>>
>>>>>> Nope, you propose that if you can make a machine that both RUNS
>>>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>>>> input, that you can solve the problem.
>>>>>>
>>>>>
>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>> SIMULATION WOULD NEVER HALT.
>>>>
>>>> No, Peter Olcott shows he is too stupid to understand the fallacy of
>>>> Proof by Example.
>>>>
>>>
>>> You are too stupid to know that this does not apply.
>>> When one is 100% specific there is no generalization at all thus
>>> making inappropriate generalization impossible.
>>>
>>> In logic and mathematics, proof by example (sometimes known as
>>> inappropriate generalization)
>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>
>>
>> Right, and showing that an algorith works to detect
>
> A single 100% specific instance of infinitely nested simulation is not
> any freaking generalization at all. You actually might be stupid in
> which case I take it back. It is rude to call stupid people stupid
> because it is not their fault. I called you stupid because I thought you
> were playing sadistic head games.
>
>

WHAT 100% specific instanc of infintely nested simualtions.

The only one of those you have presented is for the H that is just
exactly a UTM and never aborts, and thus never answers.

Yes, you can make P be non-halting with an H that fails to answer, but
such an H isn't a counter example.

Until you can show how to make a Turing Machine that given the same
machine and the same input can do BOTH, halt in finite time and also run
forever, you don't have anything in your proof.

You presume the impossible exists, and thus make your logic inconsistent.

On 6/7/2022 10:52 PM, Richard Damon wrote:
> On 6/7/22 11:32 PM, olcott wrote:
>> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>>
>>> On 6/7/22 11:17 PM, olcott wrote:
>>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>  From discussion with Olcott in comp.lang.c++ I have determined
>>>>>>>>> that
>>>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>>>
>>>>>>>>> void Q(u32 x)
>>>>>>>>> {
>>>>>>>>>           if (H(x, x))
>>>>>>>>>             FUBAR();
>>>>>>>>>           return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being detected
>>>>>>>>> (i.e. Q
>>>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>>>
>>>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>>>
>>>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>>>> simulation
>>>>>>>>> however that wouldn't be the case for non-simulating decider
>>>>>>>>> for which
>>>>>>>>> there would be no such recursion.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I propose a way to correctly decide the impossible input and
>>>>>>>> your "rebuttal" is that there are still other wrong ways to do
>>>>>>>> this that don't work.
>>>>>>>
>>>>>>> Nope, you propose that if you can make a machine that both RUNS
>>>>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>>>>> input, that you can solve the problem.
>>>>>>>
>>>>>>
>>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>>> SIMULATION WOULD NEVER HALT.
>>>>>
>>>>> No, Peter Olcott shows he is too stupid to understand the fallacy
>>>>> of Proof by Example.
>>>>>
>>>>
>>>> You are too stupid to know that this does not apply.
>>>> When one is 100% specific there is no generalization at all thus
>>>> making inappropriate generalization impossible.
>>>>
>>>> In logic and mathematics, proof by example (sometimes known as
>>>> inappropriate generalization)
>>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>>
>>>
>>> Right, and showing that an algorith works to detect a infinite
>>> recursion, even with a conditional simulation in the loop, by looking
>>> at a program that does a jump to self is an inappropriate
>>> generalization.
>>>
>>> The fact that you don't see that just proves how stupid you are,
>>>
>>> You don't even know what they mean by "Generalization" there it seems.
>>
>> When I show every single step of the execution trace of P there is no
>> freaking generalization at all nitwit, it is all 100% specific.
>>
>>
>
> Except that is a lie.
>
> You don't show the instruction that the x86 processor executes
> immediately after the 7th instruction.
>

I show every single step of the execution trace of P
of P
of P
of P
of P
of P

Even if you aren't very smart you could pay much better attention.

On very very difficult things such as the change document for the VISA
credit card processing system I had to read through the document 15
times before I was sure that I caught every single change.

VISA was the most difficult Discover card was the clearest.

--
Copyright 2022 Pete Olcott

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

On 6/7/2022 10:54 PM, Richard Damon wrote:
> On 6/7/22 11:43 PM, olcott wrote:
>> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>>
>>> On 6/7/22 11:17 PM, olcott wrote:
>>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>  From discussion with Olcott in comp.lang.c++ I have determined
>>>>>>>>> that
>>>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>>>
>>>>>>>>> void Q(u32 x)
>>>>>>>>> {
>>>>>>>>>           if (H(x, x))
>>>>>>>>>             FUBAR();
>>>>>>>>>           return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being detected
>>>>>>>>> (i.e. Q
>>>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>>>
>>>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>>>
>>>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>>>> simulation
>>>>>>>>> however that wouldn't be the case for non-simulating decider
>>>>>>>>> for which
>>>>>>>>> there would be no such recursion.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I propose a way to correctly decide the impossible input and
>>>>>>>> your "rebuttal" is that there are still other wrong ways to do
>>>>>>>> this that don't work.
>>>>>>>
>>>>>>> Nope, you propose that if you can make a machine that both RUNS
>>>>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>>>>> input, that you can solve the problem.
>>>>>>>
>>>>>>
>>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>>> SIMULATION WOULD NEVER HALT.
>>>>>
>>>>> No, Peter Olcott shows he is too stupid to understand the fallacy
>>>>> of Proof by Example.
>>>>>
>>>>
>>>> You are too stupid to know that this does not apply.
>>>> When one is 100% specific there is no generalization at all thus
>>>> making inappropriate generalization impossible.
>>>>
>>>> In logic and mathematics, proof by example (sometimes known as
>>>> inappropriate generalization)
>>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>>
>>>
>>> Right, and showing that an algorith works to detect
>>
>> A single 100% specific instance of infinitely nested simulation is not
>> any freaking generalization at all. You actually might be stupid in
>> which case I take it back. It is rude to call stupid people stupid
>> because it is not their fault. I called you stupid because I thought
>> you were playing sadistic head games.
>>
>>
>
> WHAT 100% specific instanc of infintely nested simualtions.
>

#include <stdint.h>
#define u32 uint32_t

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

// H emulates the first seven instructions of P
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

....[00001384][0010229e][00000000] 83c408 add esp,+08
....[00001387][0010229a][00000000] 50 push eax
....[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
....[00001392][0010229e][00000000] 83c408 add esp,+08
....[00001395][0010229e][00000000] 33c0 xor eax,eax
....[00001397][001022a2][00100000] 5d pop ebp
....[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) = 237 pages

--
Copyright 2022 Pete Olcott

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

On 6/7/22 11:59 PM, olcott wrote:
> On 6/7/2022 10:54 PM, Richard Damon wrote:
>> On 6/7/22 11:43 PM, olcott wrote:
>>> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>>>
>>>> On 6/7/22 11:17 PM, olcott wrote:
>>>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>  From discussion with Olcott in comp.lang.c++ I have
>>>>>>>>>> determined that
>>>>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>>>>
>>>>>>>>>> void Q(u32 x)
>>>>>>>>>> {
>>>>>>>>>>           if (H(x, x))
>>>>>>>>>>             FUBAR();
>>>>>>>>>>           return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being
>>>>>>>>>> detected (i.e. Q
>>>>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>>>>
>>>>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>>>>
>>>>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>>>>> simulation
>>>>>>>>>> however that wouldn't be the case for non-simulating decider
>>>>>>>>>> for which
>>>>>>>>>> there would be no such recursion.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I propose a way to correctly decide the impossible input and
>>>>>>>>> your "rebuttal" is that there are still other wrong ways to do
>>>>>>>>> this that don't work.
>>>>>>>>
>>>>>>>> Nope, you propose that if you can make a machine that both RUNS
>>>>>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>>>>>> input, that you can solve the problem.
>>>>>>>>
>>>>>>>
>>>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>>>> SIMULATION WOULD NEVER HALT.
>>>>>>
>>>>>> No, Peter Olcott shows he is too stupid to understand the fallacy
>>>>>> of Proof by Example.
>>>>>>
>>>>>
>>>>> You are too stupid to know that this does not apply.
>>>>> When one is 100% specific there is no generalization at all thus
>>>>> making inappropriate generalization impossible.
>>>>>
>>>>> In logic and mathematics, proof by example (sometimes known as
>>>>> inappropriate generalization)
>>>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>>>
>>>>
>>>> Right, and showing that an algorith works to detect
>>>
>>> A single 100% specific instance of infinitely nested simulation is
>>> not any freaking generalization at all. You actually might be stupid
>>> in which case I take it back. It is rude to call stupid people stupid
>>> because it is not their fault. I called you stupid because I thought
>>> you were playing sadistic head games.
>>>
>>>
>>
>> WHAT 100% specific instanc of infintely nested simualtions.
>>
>
> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352 // push P
> [0000137a](05)  6852130000      push 00001352 // push P
> [0000137f](05)  e81efeffff      call 000011a2 // call H
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55         push ebp
> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>
> // H emulates the first seven instructions of P
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> // The emulated H emulates the first seven instructions of P
> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction of P repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>
> ...[00001384][0010229e][00000000] 83c408     add esp,+08
> ...[00001387][0010229a][00000000] 50         push eax
> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
> "Input_Halts = "
> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
> Input_Halts = 0
> ...[00001392][0010229e][00000000] 83c408     add esp,+08
> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
> ...[00001397][001022a2][00100000] 5d         pop ebp
> ...[00001398][001022a6][00000004] c3         ret
> Number of Instructions Executed(15892) = 237 pages
>
>

On 6/7/22 11:57 PM, olcott wrote:
> On 6/7/2022 10:52 PM, Richard Damon wrote:
>> On 6/7/22 11:32 PM, olcott wrote:
>>> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>>>
>>>> On 6/7/22 11:17 PM, olcott wrote:
>>>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>  From discussion with Olcott in comp.lang.c++ I have
>>>>>>>>>> determined that
>>>>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>>>>
>>>>>>>>>> void Q(u32 x)
>>>>>>>>>> {
>>>>>>>>>>           if (H(x, x))
>>>>>>>>>>             FUBAR();
>>>>>>>>>>           return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being
>>>>>>>>>> detected (i.e. Q
>>>>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>>>>
>>>>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>>>>
>>>>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>>>>> simulation
>>>>>>>>>> however that wouldn't be the case for non-simulating decider
>>>>>>>>>> for which
>>>>>>>>>> there would be no such recursion.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I propose a way to correctly decide the impossible input and
>>>>>>>>> your "rebuttal" is that there are still other wrong ways to do
>>>>>>>>> this that don't work.
>>>>>>>>
>>>>>>>> Nope, you propose that if you can make a machine that both RUNS
>>>>>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>>>>>> input, that you can solve the problem.
>>>>>>>>
>>>>>>>
>>>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>>>> SIMULATION WOULD NEVER HALT.
>>>>>>
>>>>>> No, Peter Olcott shows he is too stupid to understand the fallacy
>>>>>> of Proof by Example.
>>>>>>
>>>>>
>>>>> You are too stupid to know that this does not apply.
>>>>> When one is 100% specific there is no generalization at all thus
>>>>> making inappropriate generalization impossible.
>>>>>
>>>>> In logic and mathematics, proof by example (sometimes known as
>>>>> inappropriate generalization)
>>>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>>>
>>>>
>>>> Right, and showing that an algorith works to detect a infinite
>>>> recursion, even with a conditional simulation in the loop, by
>>>> looking at a program that does a jump to self is an inappropriate
>>>> generalization.
>>>>
>>>> The fact that you don't see that just proves how stupid you are,
>>>>
>>>> You don't even know what they mean by "Generalization" there it seems.
>>>
>>> When I show every single step of the execution trace of P there is no
>>> freaking generalization at all nitwit, it is all 100% specific.
>>>
>>>
>>
>> Except that is a lie.
>>
>> You don't show the instruction that the x86 processor executes
>> immediately after the 7th instruction.
>>
>
> I show every single step of the execution trace of P
> of P
> of P
> of P
> of P
> of P

Nope, You just show that you don't even know what is in the program P.

The PROGRAM P includes the code of H that is calls, which you don't seem
to understand.

>
> Even if you aren't very smart you could pay much better attention.

Maybe, but I do know what makes up a program that you don't seem to
understand.

Maybe YOU need to pay attention to the actual requirements and
definitons and follow them, like making your trace actually trace the
full program, not just what you want to think of as the program because
that false interpretation helps supports your arguement.
>
> On very very difficult things such as the change document for the VISA
> credit card processing system I had to read through the document 15
> times before I was sure that I caught every single change.

It really shouldn't have. Either the document was very poorly written or
you just didn't understand how requirements work.

After all, a change document should be an organized list of what changes
are being requested. A couple times through might be reasonable to look
at this at different levels of details, but 15 sounds excessive.

It could have been that bad, but just like all your arguements, your
CLAIM that it was that bad isn't proof. If you could actually show the
document (which it is understandable that you can't, those often come
with NDAs), it might let you prove your case, but as is, it shows that
more likely you just have trouble unerstanding things.

>
> VISA was the most difficult Discover card was the clearest.
>

On 6/8/2022 5:57 AM, Richard Damon wrote:
> On 6/7/22 11:59 PM, olcott wrote:
>> On 6/7/2022 10:54 PM, Richard Damon wrote:
>>> On 6/7/22 11:43 PM, olcott wrote:
>>>> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>>>>
>>>>> On 6/7/22 11:17 PM, olcott wrote:
>>>>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>  From discussion with Olcott in comp.lang.c++ I have
>>>>>>>>>>> determined that
>>>>>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>>>>>
>>>>>>>>>>> void Q(u32 x)
>>>>>>>>>>> {
>>>>>>>>>>>           if (H(x, x))
>>>>>>>>>>>             FUBAR();
>>>>>>>>>>>           return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being
>>>>>>>>>>> detected (i.e. Q
>>>>>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>>>>>
>>>>>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>>>>>
>>>>>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>>>>>> simulation
>>>>>>>>>>> however that wouldn't be the case for non-simulating decider
>>>>>>>>>>> for which
>>>>>>>>>>> there would be no such recursion.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I propose a way to correctly decide the impossible input and
>>>>>>>>>> your "rebuttal" is that there are still other wrong ways to do
>>>>>>>>>> this that don't work.
>>>>>>>>>
>>>>>>>>> Nope, you propose that if you can make a machine that both RUNS
>>>>>>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>>>>>>> input, that you can solve the problem.
>>>>>>>>>
>>>>>>>>
>>>>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>>>>> SIMULATION WOULD NEVER HALT.
>>>>>>>
>>>>>>> No, Peter Olcott shows he is too stupid to understand the fallacy
>>>>>>> of Proof by Example.
>>>>>>>
>>>>>>
>>>>>> You are too stupid to know that this does not apply.
>>>>>> When one is 100% specific there is no generalization at all thus
>>>>>> making inappropriate generalization impossible.
>>>>>>
>>>>>> In logic and mathematics, proof by example (sometimes known as
>>>>>> inappropriate generalization)
>>>>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>>>>
>>>>>
>>>>> Right, and showing that an algorith works to detect
>>>>
>>>> A single 100% specific instance of infinitely nested simulation is
>>>> not any freaking generalization at all. You actually might be stupid
>>>> in which case I take it back. It is rude to call stupid people
>>>> stupid because it is not their fault. I called you stupid because I
>>>> thought you were playing sadistic head games.
>>>>
>>>>
>>>
>>> WHAT 100% specific instanc of infintely nested simualtions.
>>>
>>
>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> void P(u32 x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> _P()
>> [00001352](01)  55              push ebp
>> [00001353](02)  8bec            mov ebp,esp
>> [00001355](03)  8b4508          mov eax,[ebp+08]
>> [00001358](01)  50              push eax      // push P
>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>> [0000135c](01)  51              push ecx      // push P
>> [0000135d](05)  e840feffff      call 000011a2 // call H
>> [00001362](03)  83c408          add esp,+08
>> [00001365](02)  85c0            test eax,eax
>> [00001367](02)  7402            jz 0000136b
>> [00001369](02)  ebfe            jmp 00001369
>> [0000136b](01)  5d              pop ebp
>> [0000136c](01)  c3              ret
>> Size in bytes:(0027) [0000136c]
>>
>> _main()
>> [00001372](01)  55              push ebp
>> [00001373](02)  8bec            mov ebp,esp
>> [00001375](05)  6852130000      push 00001352 // push P
>> [0000137a](05)  6852130000      push 00001352 // push P
>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>> [00001384](03)  83c408          add esp,+08
>> [00001387](01)  50              push eax
>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>> [00001392](03)  83c408          add esp,+08
>> [00001395](02)  33c0            xor eax,eax
>> [00001397](01)  5d              pop ebp
>> [00001398](01)  c3              ret
>> Size in bytes:(0039) [00001398]
>>
>>      machine   stack     stack     machine    assembly
>>      address   address   data      code       language
>>      ========  ========  ========  =========  =============
>> ...[00001372][0010229e][00000000] 55         push ebp
>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>
>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>
>> // H emulates the first seven instructions of P
>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>
>> // The emulated H emulates the first seven instructions of P
>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
>> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> It is completely obvious that when H(P,P) correctly emulates its input
>> that it must emulate the first seven instructions of P. Because the
>> seventh instruction of P repeats this process we can know with
>> complete certainty that the emulated P never reaches its final “ret”
>> instruction, thus never halts.
>>
>> ...[00001384][0010229e][00000000] 83c408     add esp,+08
>> ...[00001387][0010229a][00000000] 50         push eax
>> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
>> "Input_Halts = "
>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
>> Input_Halts = 0
>> ...[00001392][0010229e][00000000] 83c408     add esp,+08
>> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
>> ...[00001397][001022a2][00100000] 5d         pop ebp
>> ...[00001398][001022a6][00000004] c3         ret
>> Number of Instructions Executed(15892) = 237 pages
>>
>>
>
> Except that H is wrong, because it didn't actually emulate the input
> correctly.

On 6/8/2022 6:08 AM, Richard Damon wrote:
> On 6/7/22 11:57 PM, olcott wrote:
>> On 6/7/2022 10:52 PM, Richard Damon wrote:
>>> On 6/7/22 11:32 PM, olcott wrote:
>>>> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>>>>
>>>>> On 6/7/22 11:17 PM, olcott wrote:
>>>>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>  From discussion with Olcott in comp.lang.c++ I have
>>>>>>>>>>> determined that
>>>>>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>>>>>
>>>>>>>>>>> void Q(u32 x)
>>>>>>>>>>> {
>>>>>>>>>>>           if (H(x, x))
>>>>>>>>>>>             FUBAR();
>>>>>>>>>>>           return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being
>>>>>>>>>>> detected (i.e. Q
>>>>>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>>>>>
>>>>>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>>>>>
>>>>>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>>>>>> simulation
>>>>>>>>>>> however that wouldn't be the case for non-simulating decider
>>>>>>>>>>> for which
>>>>>>>>>>> there would be no such recursion.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I propose a way to correctly decide the impossible input and
>>>>>>>>>> your "rebuttal" is that there are still other wrong ways to do
>>>>>>>>>> this that don't work.
>>>>>>>>>
>>>>>>>>> Nope, you propose that if you can make a machine that both RUNS
>>>>>>>>> FOREVER and also STOPS PART WAY at the same time with the same
>>>>>>>>> input, that you can solve the problem.
>>>>>>>>>
>>>>>>>>
>>>>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>>>>> SIMULATION WOULD NEVER HALT.
>>>>>>>
>>>>>>> No, Peter Olcott shows he is too stupid to understand the fallacy
>>>>>>> of Proof by Example.
>>>>>>>
>>>>>>
>>>>>> You are too stupid to know that this does not apply.
>>>>>> When one is 100% specific there is no generalization at all thus
>>>>>> making inappropriate generalization impossible.
>>>>>>
>>>>>> In logic and mathematics, proof by example (sometimes known as
>>>>>> inappropriate generalization)
>>>>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>>>>
>>>>>
>>>>> Right, and showing that an algorith works to detect a infinite
>>>>> recursion, even with a conditional simulation in the loop, by
>>>>> looking at a program that does a jump to self is an inappropriate
>>>>> generalization.
>>>>>
>>>>> The fact that you don't see that just proves how stupid you are,
>>>>>
>>>>> You don't even know what they mean by "Generalization" there it seems.
>>>>
>>>> When I show every single step of the execution trace of P there is
>>>> no freaking generalization at all nitwit, it is all 100% specific.
>>>>
>>>>
>>>
>>> Except that is a lie.
>>>
>>> You don't show the instruction that the x86 processor executes
>>> immediately after the 7th instruction.
>>>
>>
>> I show every single step of the execution trace of P
>> of P
>> of P
>> of P
>> of P
>> of P
>
> Nope, You just show that you don't even know what is in the program P.
>

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

> The PROGRAM P includes the code of H that is calls, which you don't seem
> to understand.
>
>
>>
>> Even if you aren't very smart you could pay much better attention.
>
> Maybe, but I do know what makes up a program that you don't seem to
> understand.

It is freaking stipulated that P is the C function under test and H is
the test function.

--
Copyright 2022 Pete Olcott

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

On 6/8/2022 8:27 AM, Malcolm McLean wrote:
> On Wednesday, 8 June 2022 at 13:35:50 UTC+1, olcott wrote:
>>
>>> Except that H is wrong, because it didn't actually emulate the input
>>> correctly.
>> H(P,P) correctly emulates 14 steps of its input providing H the
>> sufficient basis to determine that a complete emulation of its input
>> never reaches the "ret" instruction of this input.
>>
> You're drawing a distinction between "P(P)" and "the input P,P". I don't
> understand it and I suspect you don't either.

It is an easily verified fact that the correctly simulated input to
H(P,P) never halts and P(P) does halt.

Do you care about verified facts?

--
Copyright 2022 Pete Olcott

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

On 6/8/2022 9:08 AM, Andy Walker wrote:
> On 08/06/2022 14:31, olcott wrote:
>> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>>> You're drawing a distinction between "P(P)" and "the input P,P". I don't
>>> understand it and I suspect you don't either.
>> It is an easily verified fact that the correctly simulated input to
>> H(P,P) never halts and P(P) does halt.
>
>     That seems to be as succinct a statement as you have achieved over
> these many years and thousands of articles, showing that your "H" is not in
> fact a correct simulator.
>
>     I suggest you correct "H" before continuing your quest.
>

Yet the actual fact of the actual execution traces conclusively proves
that the simulation is correct. Everyone here seems to think that their
incorrect opinion supersedes the actual facts. How nuts is that?

--
Copyright 2022 Pete Olcott

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

On 6/8/2022 9:08 AM, Andy Walker wrote:
> On 08/06/2022 14:31, olcott wrote:
>> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>>> You're drawing a distinction between "P(P)" and "the input P,P". I don't
>>> understand it and I suspect you don't either.
>> It is an easily verified fact that the correctly simulated input to
>> H(P,P) never halts and P(P) does halt.
>
>     That seems to be as succinct a statement as you have achieved over
> these many years and thousands of articles, showing that your "H" is not in
> fact a correct simulator.
>
>     I suggest you correct "H" before continuing your quest.
>

Everyone here seems to believe that the x86 language itself is incorrect
and that P should magically jump to its "ret" instruction even though
that is not what is specified by the x86 source-code of P.

This leads me to believe that these people are simply despicable lying
bastards because no one would be stupid enough to actually disagree with
the x86 language.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ P(P);
}

_P()
[000012e7](01) 55 push ebp
[000012e8](02) 8bec mov ebp,esp
[000012ea](03) 8b4508 mov eax,[ebp+08]
[000012ed](01) 50 push eax
[000012ee](03) 8b4d08 mov ecx,[ebp+08]
[000012f1](01) 51 push ecx
[000012f2](05) e880feffff call 00001177
[000012f7](03) 83c408 add esp,+08
[000012fa](02) 85c0 test eax,eax
[000012fc](02) 7402 jz 00001300
[000012fe](02) ebfe jmp 000012fe
[00001300](01) 5d pop ebp
[00001301](01) c3 ret
Size in bytes:(0027) [00001301]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

--
Copyright 2022 Pete Olcott

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

On 6/8/22 8:39 AM, olcott wrote:
> On 6/8/2022 6:08 AM, Richard Damon wrote:
>> On 6/7/22 11:57 PM, olcott wrote:
>>> On 6/7/2022 10:52 PM, Richard Damon wrote:
>>>> On 6/7/22 11:32 PM, olcott wrote:
>>>>> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/7/22 11:17 PM, olcott wrote:
>>>>>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>>>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>  From discussion with Olcott in comp.lang.c++ I have
>>>>>>>>>>>> determined that
>>>>>>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>>>>>>
>>>>>>>>>>>> void Q(u32 x)
>>>>>>>>>>>> {
>>>>>>>>>>>>           if (H(x, x))
>>>>>>>>>>>>             FUBAR();
>>>>>>>>>>>>           return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being
>>>>>>>>>>>> detected (i.e. Q
>>>>>>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>>>>>>
>>>>>>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>>>>>>
>>>>>>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>>>>>>> simulation
>>>>>>>>>>>> however that wouldn't be the case for non-simulating decider
>>>>>>>>>>>> for which
>>>>>>>>>>>> there would be no such recursion.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I propose a way to correctly decide the impossible input and
>>>>>>>>>>> your "rebuttal" is that there are still other wrong ways to
>>>>>>>>>>> do this that don't work.
>>>>>>>>>>
>>>>>>>>>> Nope, you propose that if you can make a machine that both
>>>>>>>>>> RUNS FOREVER and also STOPS PART WAY at the same time with the
>>>>>>>>>> same input, that you can solve the problem.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>>>>>> SIMULATION WOULD NEVER HALT.
>>>>>>>>
>>>>>>>> No, Peter Olcott shows he is too stupid to understand the
>>>>>>>> fallacy of Proof by Example.
>>>>>>>>
>>>>>>>
>>>>>>> You are too stupid to know that this does not apply.
>>>>>>> When one is 100% specific there is no generalization at all thus
>>>>>>> making inappropriate generalization impossible.
>>>>>>>
>>>>>>> In logic and mathematics, proof by example (sometimes known as
>>>>>>> inappropriate generalization)
>>>>>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>>>>>
>>>>>>
>>>>>> Right, and showing that an algorith works to detect a infinite
>>>>>> recursion, even with a conditional simulation in the loop, by
>>>>>> looking at a program that does a jump to self is an inappropriate
>>>>>> generalization.
>>>>>>
>>>>>> The fact that you don't see that just proves how stupid you are,
>>>>>>
>>>>>> You don't even know what they mean by "Generalization" there it
>>>>>> seems.
>>>>>
>>>>> When I show every single step of the execution trace of P there is
>>>>> no freaking generalization at all nitwit, it is all 100% specific.
>>>>>
>>>>>
>>>>
>>>> Except that is a lie.
>>>>
>>>> You don't show the instruction that the x86 processor executes
>>>> immediately after the 7th instruction.
>>>>
>>>
>>> I show every single step of the execution trace of P
>>> of P
>>> of P
>>> of P
>>> of P
>>> of P
>>
>> Nope, You just show that you don't even know what is in the program P.
>>
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
>> The PROGRAM P includes the code of H that is calls, which you don't
>> seem to understand.
>>
>>
>>>
>>> Even if you aren't very smart you could pay much better attention.
>>
>> Maybe, but I do know what makes up a program that you don't seem to
>> understand.
>
> It is freaking stipulated that P is the C function under test and H is
> the test function.
>

But Halt Deciders work on PROGRAMS, not just 'functions' as narrowly
definied in C.

The Mathematical Function that P computes includes ALL the code that P
executes, the P, when given to whatever decider you want to give to it,
INCLUDES a copy of H.

Note, given your stipulations of H, that H(P,P) returns 0, then it is
clear that P(P) will call H(P,P), which will return 0, and P then Halt.

If you want to define that H will always simulate its input and not halt
until it gets the right answer, then the only possible behavior you get
out of that definition is that H(P,P) never aborts and thus never answers.

This is because if at ANY point H(P,P) will abort its processing, and
return 0, the first stipuatlion comes into play, and thus we KNOW that
P(P) Halts.

To say it does both correctly is just the liars paradox, is that
statement true or false.

You need to decide, does H(P,P) return a 0, or does it continue to run
until it can correctly give an answer (either by reaching a final state
or actually proving non-halting).

We have proved that it can't do both, just as the liars paradox can't be
both True and False at the same time.

The fact that you don't understand this just shows how little you
understand what you are talking about.

On 6/8/22 9:31 AM, olcott wrote:
> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>> On Wednesday, 8 June 2022 at 13:35:50 UTC+1, olcott wrote:
>>>
>>>> Except that H is wrong, because it didn't actually emulate the input
>>>> correctly.
>>> H(P,P) correctly emulates 14 steps of its input providing H the
>>> sufficient basis to determine that a complete emulation of its input
>>> never reaches the "ret" instruction of this input.
>>>
>> You're drawing a distinction between "P(P)" and "the input P,P". I don't
>> understand it and I suspect you don't either.
>
> It is an easily verified fact that the correctly simulated input to
> H(P,P) never halts and P(P) does halt.
>
> Do you care about verified facts?
>

Which just proves that H isn't actually a Halt Decider, because for a
Halt decider H(P,P) is, by definition, asking about P(P).

You just show that you don't understand correct definitions.

On 6/8/22 8:35 AM, olcott wrote:
> On 6/8/2022 5:57 AM, Richard Damon wrote:
>> On 6/7/22 11:59 PM, olcott wrote:
>>> On 6/7/2022 10:54 PM, Richard Damon wrote:
>>>> On 6/7/22 11:43 PM, olcott wrote:
>>>>> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/7/22 11:17 PM, olcott wrote:
>>>>>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>>>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>>>>>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>  From discussion with Olcott in comp.lang.c++ I have
>>>>>>>>>>>> determined that
>>>>>>>>>>>> his so called refutation of the HP proofs is based around the
>>>>>>>>>>>> behaviour of his simulation-based decider, H:
>>>>>>>>>>>>
>>>>>>>>>>>> void Q(u32 x)
>>>>>>>>>>>> {
>>>>>>>>>>>>           if (H(x, x))
>>>>>>>>>>>>             FUBAR();
>>>>>>>>>>>>           return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> He asserts H(Q,Q)=0 based on a nested simulation being
>>>>>>>>>>>> detected (i.e. Q
>>>>>>>>>>>> invoking H) irregardless of whether FUBAR halts or not.
>>>>>>>>>>>>
>>>>>>>>>>>> If FUBAR halts H gives the wrong answer.
>>>>>>>>>>>>
>>>>>>>>>>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
>>>>>>>>>>>> simulation
>>>>>>>>>>>> however that wouldn't be the case for non-simulating decider
>>>>>>>>>>>> for which
>>>>>>>>>>>> there would be no such recursion.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I propose a way to correctly decide the impossible input and
>>>>>>>>>>> your "rebuttal" is that there are still other wrong ways to
>>>>>>>>>>> do this that don't work.
>>>>>>>>>>
>>>>>>>>>> Nope, you propose that if you can make a machine that both
>>>>>>>>>> RUNS FOREVER and also STOPS PART WAY at the same time with the
>>>>>>>>>> same input, that you can solve the problem.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>>>>>> SIMULATION WOULD NEVER HALT.
>>>>>>>>
>>>>>>>> No, Peter Olcott shows he is too stupid to understand the
>>>>>>>> fallacy of Proof by Example.
>>>>>>>>
>>>>>>>
>>>>>>> You are too stupid to know that this does not apply.
>>>>>>> When one is 100% specific there is no generalization at all thus
>>>>>>> making inappropriate generalization impossible.
>>>>>>>
>>>>>>> In logic and mathematics, proof by example (sometimes known as
>>>>>>> inappropriate generalization)
>>>>>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>>>>>
>>>>>>
>>>>>> Right, and showing that an algorith works to detect
>>>>>
>>>>> A single 100% specific instance of infinitely nested simulation is
>>>>> not any freaking generalization at all. You actually might be
>>>>> stupid in which case I take it back. It is rude to call stupid
>>>>> people stupid because it is not their fault. I called you stupid
>>>>> because I thought you were playing sadistic head games.
>>>>>
>>>>>
>>>>
>>>> WHAT 100% specific instanc of infintely nested simualtions.
>>>>
>>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00001352](01)  55              push ebp
>>> [00001353](02)  8bec            mov ebp,esp
>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>> [00001358](01)  50              push eax      // push P
>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000135c](01)  51              push ecx      // push P
>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> [00001362](03)  83c408          add esp,+08
>>> [00001365](02)  85c0            test eax,eax
>>> [00001367](02)  7402            jz 0000136b
>>> [00001369](02)  ebfe            jmp 00001369
>>> [0000136b](01)  5d              pop ebp
>>> [0000136c](01)  c3              ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>> _main()
>>> [00001372](01)  55              push ebp
>>> [00001373](02)  8bec            mov ebp,esp
>>> [00001375](05)  6852130000      push 00001352 // push P
>>> [0000137a](05)  6852130000      push 00001352 // push P
>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>> [00001384](03)  83c408          add esp,+08
>>> [00001387](01)  50              push eax
>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>> [00001392](03)  83c408          add esp,+08
>>> [00001395](02)  33c0            xor eax,eax
>>> [00001397](01)  5d              pop ebp
>>> [00001398](01)  c3              ret
>>> Size in bytes:(0039) [00001398]
>>>
>>>      machine   stack     stack     machine    assembly
>>>      address   address   data      code       language
>>>      ========  ========  ========  =========  =============
>>> ...[00001372][0010229e][00000000] 55         push ebp
>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>
>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>>
>>> // H emulates the first seven instructions of P
>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>
>>> // The emulated H emulates the first seven instructions of P
>>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
>>> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> It is completely obvious that when H(P,P) correctly emulates its
>>> input that it must emulate the first seven instructions of P. Because
>>> the seventh instruction of P repeats this process we can know with
>>> complete certainty that the emulated P never reaches its final “ret”
>>> instruction, thus never halts.
>>>
>>> ...[00001384][0010229e][00000000] 83c408     add esp,+08
>>> ...[00001387][0010229a][00000000] 50         push eax
>>> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
>>> "Input_Halts = "
>>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call
>>> Output
>>> Input_Halts = 0
>>> ...[00001392][0010229e][00000000] 83c408     add esp,+08
>>> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
>>> ...[00001397][001022a2][00100000] 5d         pop ebp
>>> ...[00001398][001022a6][00000004] c3         ret
>>> Number of Instructions Executed(15892) = 237 pages
>>>
>>>
>>
>> Except that H is wrong, because it didn't actually emulate the input
>> correctly.
>
> H(P,P) correctly emulates 14 steps of its input providing H the
> sufficient basis to determine that a complete emulation of its input
> never reaches the "ret" instruction of this input.
>
>

On 6/8/22 11:31 AM, olcott wrote:
> On 6/8/2022 9:08 AM, Andy Walker wrote:
>> On 08/06/2022 14:31, olcott wrote:
>>> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>>>> You're drawing a distinction between "P(P)" and "the input P,P". I
>>>> don't
>>>> understand it and I suspect you don't either.
>>> It is an easily verified fact that the correctly simulated input to
>>> H(P,P) never halts and P(P) does halt.
>>
>>      That seems to be as succinct a statement as you have achieved over
>> these many years and thousands of articles, showing that your "H" is
>> not in
>> fact a correct simulator.
>>
>>      I suggest you correct "H" before continuing your quest.
>>
>
> Everyone here seems to believe that the x86 language itself is incorrect
> and that P should magically jump to its "ret" instruction even though
> that is not what is specified by the x86 source-code of P.

No, the x86 language says that a call H instrucion will run the code at
the begining of the subroutine H.

>
> This leads me to believe that these people are simply despicable lying
> bastards because no one would be stupid enough to actually disagree with
> the x86 language.

No, YOU are the lying bastard as YOU are making the incorrect claim.

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [000012e7](01)  55              push ebp
> [000012e8](02)  8bec            mov ebp,esp
> [000012ea](03)  8b4508          mov eax,[ebp+08]
> [000012ed](01)  50              push eax
> [000012ee](03)  8b4d08          mov ecx,[ebp+08]
> [000012f1](01)  51              push ecx
> [000012f2](05)  e880feffff      call 00001177
> [000012f7](03)  83c408          add esp,+08
> [000012fa](02)  85c0            test eax,eax
> [000012fc](02)  7402            jz 00001300
> [000012fe](02)  ebfe            jmp 000012fe
> [00001300](01)  5d              pop ebp
> [00001301](01)  c3              ret
> Size in bytes:(0027) [00001301]
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction of P repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>

Just as it is competely obvious that when you call your dog a cat you
can show that cats bark.

H can NOT completely and correctly emulate the input to H(P,P) and at
the same time return 0.

Thus, your premise is dependent on Fairy Dust Powered Unicorn Magic to
achive its goal.

False Premise -> UNSOUND LOGIC.

FAIL.