On 7/28/22 11:13 AM, olcott wrote:
> On 7/27/2022 9:37 PM, Richard Damon wrote:
>> On 7/27/22 10:28 PM, olcott wrote:
>>> On 7/27/2022 9:00 PM, Richard Damon wrote:
>>>> On 7/27/22 9:24 PM, olcott wrote:
>>>>> On 7/27/2022 8:13 PM, Richard Damon wrote:
>>>>>> On 7/27/22 8:51 PM, olcott wrote:
>>>>>>> On 7/27/2022 6:27 PM, Richard Damon wrote:
>>>>>>>> On 7/27/22 7:11 PM, olcott wrote:
>>>>>>>>> On 7/27/2022 5:45 PM, Richard Damon wrote:
>>>>>>>>>> On 7/27/22 10:59 AM, olcott wrote:
>>>>>>>>>>> On 7/27/2022 4:48 AM, Mikko wrote:
>>>>>>>>>>>> On 2022-07-26 14:40:22 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/26/2022 8:48 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2022-07-25 20:09:42 +0000, olcott said:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 7/25/2022 11:47 AM, Mikko wrote:
>>>>>>>>>>>>>>>> On 2022-07-25 15:20:02 +0000, olcott said:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 7/25/2022 10:14 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>> On 2022-07-25 13:49:20 +0000, olcott said:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> The trace proves no such thing. Here is a
>>>>>>>>>>>>>>>>>>>>>>>>>> basic of the x86 question for you, what is the
>>>>>>>>>>>>>>>>>>>>>>>>>> first instruction executed in P(P) that
>>>>>>>>>>>>>>>>>>>>>>>>>> differs from the correct simulation of H(P,P)?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>> [000013c6](01)  55         push ebp
>>>>>>>>>>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp
>>>>>>>>>>>>>>>>>>> [000013c9](01)  51         push ecx
>>>>>>>>>>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>> [000013cd](01)  50         push eax
>>>>>>>>>>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>> [000013d1](01)  51         push ecx
>>>>>>>>>>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106
>>>>>>>>>>>>>>>>>>> [000013d7](03)  83c408     add esp,+08
>>>>>>>>>>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>>>>>>>>>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>>>>>>>>>>>>>>>>>> [000013e1](02)  7402       jz 000013e5
>>>>>>>>>>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3
>>>>>>>>>>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp
>>>>>>>>>>>>>>>>>>> [000013e7](01)  5d         pop ebp
>>>>>>>>>>>>>>>>>>> [000013e8](01)  c3         ret
>>>>>>>>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We have to do this at the C level.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> (a) H(P,P) simulates its input
>>>>>>>>>>>>>>>>>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>>>>>>>>>>>>>>>>>> (c) H(P,P) would simulate its input if it does what
>>>>>>>>>>>>>>>>>>>>> P asks
>>>>>>>>>>>>>>>>>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>>>>>>>>>>>>>>>>>> (e) H(P,P) would simulate its input if it does what
>>>>>>>>>>>>>>>>>>>>> P asks
>>>>>>>>>>>>>>>>>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *Can you see the repeating pattern* ?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Yes, but I cannot see any answer to any of my
>>>>>>>>>>>>>>>>>>>> questions.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Can you prove that 13d7 is the first differeing
>>>>>>>>>>>>>>>>>>>> instruction?
>>>>>>>>>>>>>>>>>>>> In particular, that the immediately preceding
>>>>>>>>>>>>>>>>>>>> instruction is
>>>>>>>>>>>>>>>>>>>> the same?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Mikko
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>>>>>>>>>>>>>>>>>> The source-code of P specifies that the next
>>>>>>>>>>>>>>>>>>> instruction after machine address 13d2 when H returns
>>>>>>>>>>>>>>>>>>> to P for P(P) is 13d7.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>>>>>>>>>>>>>>>>>> The source-code of P specifies the next machine
>>>>>>>>>>>>>>>>>>> address for the correctly simulated input to H(P,P)
>>>>>>>>>>>>>>>>>>> is 13c6 (if P is not aborted)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Wrong. In both cases P is the same so therefore
>>>>>>>>>>>>>>>>>> specifies the same.
>>>>>>>>>>>>>>>>>> The difference seems to be that in the second case the
>>>>>>>>>>>>>>>>>> instruction
>>>>>>>>>>>>>>>>>> H(P,P) is not simulated correctly as a call to a decider.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Mikko
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You can assume that I am wrong by making sure to not
>>>>>>>>>>>>>>>>> even look at the proof that I am correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Wrong. I didn't assume that you are wrong. I presented a
>>>>>>>>>>>>>>>> sentence that
>>>>>>>>>>>>>>>> is true because of the meaning of the words. You have
>>>>>>>>>>>>>>>> not found anything
>>>>>>>>>>>>>>>> wrong in that sentence.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Mikko
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The behavior of P when directly executed is different
>>>>>>>>>>>>>>> than the behavior of P when correctly simulated by H even
>>>>>>>>>>>>>>> though each case uses the exact same machine-code for P.
>>>>>>>>>>>>>>> This is an established fact thus disbelieving this in
>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That does not contradict what I said above.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, none of that is any estabilished fact. The behaviour
>>>>>>>>>>>>>> simulated by H is not the behaviour specified by P and there
>>>>>>>>>>>>>> is no proof that H simulates correctly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Mikko
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That the line-by-line execution trace of the simulated
>>>>>>>>>>>>> input to H(P,P) exactly matches the line-by-line
>>>>>>>>>>>>> source-code conclusively proves that P is simulated correctly.
>>>>>>>>>>>>
>>>>>>>>>>>> Only partially, to the call of H. The simulation is
>>>>>>>>>>>> discontinued before
>>>>>>>>>>>> the return from H so the full behaviour specified by P is
>>>>>>>>>>>> not simulated.
>>>>>>>>>>>> In particular, the behaviour specified by P is either to
>>>>>>>>>>>> halt or to run
>>>>>>>>>>>> forever but the simulation does neither.
>>>>>>>>>>>>
>>>>>>>>>>>> Mikko
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Not with this version* With this version I show where the
>>>>>>>>>>> correctly simulated input to H(P,P) goes after the call.
>>>>>>>>>>>
>>>>>>>>>>> Example 06: H correctly determines that P() never halts
>>>>>>>>>>> (prior version of halt decider)
>>>>>>>>>>
>>>>>>>>>> Then why does P{P) Halt?
>>>>>>>>>
>>>>>>>>> As I have proved dozens of times (including the post you are
>>>>>>>>> responding to) it is a freaking different sequence of
>>>>>>>>> instructions.
>>>>>>>>
>>>>>>>> Which INSTRUCTION is different.
>>>>>>>>
>>>>>>>> Both traces go to a call H instuction with the exact same
>>>>>>>> parameters.
>>>>>>>>
>>>>>>>> The actually RUN H, and the simulation of H by H differ in results.
>>>>>>>>
>>>>>>>> THus, H fails to properly simulate the function H, and the proof
>>>>>>>> is INVALID.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> That you don't believe this because you don't bother to look at
>>>>>>>>> my proof is asinine.
>>>>>>>>>
>>>>>>>>> _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]
>>>>>>>>>
>>>>>>>>>      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
>>>>>>>>
>>>>>>>> CORRECT simulation needs to show what happens at 000011a2 next
>>>>>>>>
>>>>>>>> It doesn't, thus it is NOT a correct simulation, and you are
>>>>>>>> proved to be a liar.
>>>>>>>
>>>>>>> So in other words you are not bright enough to see that when the
>>>>>>> simulated P calls H(P,P) to simulate itself again that H does
>>>>>>> indeed simulate P again thus begins at the first instruction of P
>>>>>>> shown below?
>>>>>>
>>>>>> So, you are saying that the H that is simulating the P that is
>>>>>> calling this new H can't abort that simulation by aborting its
>>>>>> simulation of P?
>>>>>
>>>>> Yes I am saying that. This H does not see that its abort criteria
>>>>> has been met so the new H simulates its input as shown below.
>>>>
>>>> So, since the FIRST H can't abort, because of the second H being
>>>> called, how does the first one EVER abort to return the answer to
>>>> main?>
>>>>
>>>> Remember, you have said that H is a pure function, so ALL copies of
>>>> H will behave the same give the same input.
>>>>
>>>> It seems that the problem is that H is just incorrectly assuming
>>>> that the second H would never halt its simulation
>>>
>>> The first H that sees that this criteria has been met sees that its
>>> correctly simulated input cannot possibly ever reach its "ret"
>>> instruction even if correctly simulated for an infinite number of steps:
>>>
>>> (1) P() calls H(P,P) twice in sequence.
>>> (2) With the same arguments.
>>> (3) With no control flow instructions in P preceding its invocation
>>> of H(P,P) that could possibly escape repeated simulations.
>>>
>>
>> So, you are keeping to your LIE that you are using valid logic?
>>
>> Your rule (3) is FALSE, that has been told to you many times and you
>> have not shown where you get the idea that it is true.
>
> (3) With no control flow instructions in P
> With no control flow instructions in P
> With no control flow instructions in P
> With no control flow instructions in P
> With no control flow instructions in P

On 7/28/22 1:37 PM, olcott wrote:
> On 7/28/2022 11:38 AM, Paul N wrote:
>> On Thursday, July 28, 2022 at 4:13:42 PM UTC+1, olcott wrote:
>>> (3) With no control flow instructions in P
>>> With no control flow instructions in P
>>> With no control flow instructions in P
>>> With no control flow instructions in P
>>> With no control flow instructions in P
>>>
>>> preceding its invocation of
>>> H(P,P) that could possibly escape repeated simulations.
>>> There is nothing in P that would stop its infinitely recursive
>>> simulation.
>>>
>>> There is nothing in P that would stop its infinitely recursive
>>> simulation.
>>>
>>> There is nothing in P that would stop its infinitely recursive
>>> simulation.
>>>
>>> There is nothing in P that would stop its infinitely recursive
>>> simulation.
>>
>> But you have said that H can spot that it is going round in circles,
>> and so the simulation *is* stopped.
>>
>
> When-so-ever the simulation must be stopped to prevent the infinite
> execution of this simulation (such as Infinite_Loop() shown below) the
> input specifies a non-halting behavior pattern (such as Infinite_Loop()
> shown below).

Says who? Just you, because you don't understand what the real criteria
ACTUAL says.

>
> All of the arguments against my work conclude that an infinite loop
> detector cannot possibly exist because the correct simulation of an
> infinite loop must be aborted so that the halt decider can report that
> it detected an infinite loop. When the infinite loop is aborted it is no
> longer infinite.
>
> When I correct everyone with this:
>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)

Right, and what is the "Turing Machine" in this problem? it is the
ACTUAL execution of P(P), which even YOU agrees Halts.

>
> They ignore this correction because they only care about rebuttal at the
> expense of truth.
>
> When a halt decider correctly determines that its correctly simulated
> input cannot possibly ever reach the final state ("ret" instruction) of
> this input (even if simulated for an infinite number of steps) it has
> correctly determines that this input specifies a non-halting behavior
> pattern.

WRONG. You are just showing you are stupid, and falling back on the
CLASSIC FALLACIES.

That just PROVES you don't know what you are talking about.

GOODBYE STUPID.

>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0((u32)Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001102](01)  55         push ebp
> [00001103](02)  8bec       mov ebp,esp
> [00001105](02)  ebfe       jmp 00001105
> [00001107](01)  5d         pop ebp
> [00001108](01)  c3         ret
> Size in bytes:(0007) [00001108]
>
>
>
>

On 7/28/22 2:33 PM, olcott wrote:
> On 7/28/2022 1:10 PM, Dennis Bush wrote:
>> On Thursday, July 28, 2022 at 1:37:42 PM UTC-4, olcott wrote:
>>> On 7/28/2022 11:38 AM, Paul N wrote:
>>>> On Thursday, July 28, 2022 at 4:13:42 PM UTC+1, olcott wrote:
>>>>> (3) With no control flow instructions in P
>>>>> With no control flow instructions in P
>>>>> With no control flow instructions in P
>>>>> With no control flow instructions in P
>>>>> With no control flow instructions in P
>>>>>
>>>>> preceding its invocation of
>>>>> H(P,P) that could possibly escape repeated simulations.
>>>>> There is nothing in P that would stop its infinitely recursive
>>>>> simulation.
>>>>>
>>>>> There is nothing in P that would stop its infinitely recursive
>>>>> simulation.
>>>>>
>>>>> There is nothing in P that would stop its infinitely recursive
>>>>> simulation.
>>>>>
>>>>> There is nothing in P that would stop its infinitely recursive
>>>>> simulation.
>>>>
>>>> But you have said that H can spot that it is going round in circles,
>>>> and so the simulation *is* stopped.
>>>>
>>> When-so-ever the simulation must be stopped to prevent the infinite
>>> execution of this simulation (such as Infinite_Loop() shown below)
>>
>> I.E. if there is no implementation of the deciding function that can
>> simulate the given function to a final state.  This is not the same as
>> deciding if the given function run directly halts as the halting
>> problem requires.
>
> It has been proven (by execution traces) that because the simulated
> input to H(P,P) has a pathological relationship to H that when H
> correctly simulates this input that this input remains stuck in
> infinitely recursive simulation until H aborts its simulation of this
> input.

Nope, doesn't prove what you want it to, since you CHANGED the definitio
of H to do that and thus it isn't applicable to the actual problem you
want ot apply it to.

This shows how ignorant you are of what you are talking about.

SIMULATE(P,P) halts [if H(P,P) returns 0], which shows that the behavior
if the input to H(P,P) is Halting, and thus H(P,P) returning 0 is wrong.

>
> It has been proven that the direct execution of P(P) is not stuck in
> infinitely recursive simulation only because when it calls H(P,P) H
> aborts the simulation of its input.
>
> It is not my fault that you cannot understand this proof. Any rebuttal
> of this prove must ignore the execution traces (as you have continued to
> ignore the execution traces) or is much more obviously pure gibberish.
>

NOPE, not OUR fault that you refuse to learn the truth of what you
babble about, that it totally YOUR fault.

You need to learn the meaning of the words (are rules) before you try to
make this sort of pronouncements.

On 7/28/22 1:21 PM, olcott wrote:
> On 7/28/2022 11:31 AM, Paul N wrote:
>> On Thursday, July 28, 2022 at 12:11:10 AM UTC+1, olcott wrote:
>>> Flibble is not bright enough to understand this. In his system a
>>> function called in infinite recursion does return to its caller. It is
>>> because of woefully stupid things like this that I moved the discussion
>>> to comp.c and comp.c++ where the reviewers are not clueless wonders
>>> regarding software engineering.
>>
>> But no-one agreed with you there, either?
>
> No one agreed with me because no one looked at what I said.
>

No, people read what you say and can see that you are clearly wrong, and
don't understand (or are lying) about what you are talking about.

On Thursday, 28 July 2022 at 20:33:49 UTC+2, olcott wrote:
> It has been proven that the direct execution of P(P) is not stuck in
> infinitely recursive simulation only because when it calls H(P,P) H
> aborts the simulation of its input.
>
> It is not my fault that you cannot understand this proof. Any rebuttal
> of this prove must ignore the execution traces (as you have continued to
> ignore the execution traces) or is much more obviously pure gibberish.

You don't even understand what it means to prove something...

And your ignorance is totally your fault (having spent "15000 hours" on this)

You are just incapable of learning.

On 7/29/2022 5:26 AM, Skep Dick wrote:
> On Thursday, 28 July 2022 at 20:33:49 UTC+2, olcott wrote:
>> It has been proven that the direct execution of P(P) is not stuck in
>> infinitely recursive simulation only because when it calls H(P,P) H
>> aborts the simulation of its input.
>>
>> It is not my fault that you cannot understand this proof. Any rebuttal
>> of this prove must ignore the execution traces (as you have continued to
>> ignore the execution traces) or is much more obviously pure gibberish.
>
> You don't even understand what it means to prove something...
>
> And your ignorance is totally your fault (having spent "15000 hours" on this)
>
> You are just incapable of learning.

I would say that you have this backwards.
When the execution trace of the simulation of the input to H(P,P) by H
exactly matches the behavior that the x86 source-code of P specifies
line-by-line then we have proved that this execution trace is correct.
The execution trace proves the actual behavior of the actual input to H.

What other measure do you have to verify that H(P,{P)P correctly
simulates its input?

The measure that others here use is not looking at the execution trace
and saying the the behavior is wrong because it is not the behavior that
they expect.

--
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 7/29/22 10:28 AM, olcott wrote:
> On 7/29/2022 5:26 AM, Skep Dick wrote:
>> On Thursday, 28 July 2022 at 20:33:49 UTC+2, olcott wrote:
>>> It has been proven that the direct execution of P(P) is not stuck in
>>> infinitely recursive simulation only because when it calls H(P,P) H
>>> aborts the simulation of its input.
>>>
>>> It is not my fault that you cannot understand this proof. Any rebuttal
>>> of this prove must ignore the execution traces (as you have continued to
>>> ignore the execution traces) or is much more obviously pure gibberish.
>>
>> You don't even understand what it means to prove something...
>>
>> And your ignorance is totally your fault (having spent "15000 hours"
>> on this)
>>
>> You are just incapable of learning.
>
> I would say that you have this backwards.
> When the execution trace of the simulation of the input to H(P,P) by H
> exactly matches the behavior that the x86 source-code of P specifies
> line-by-line then we have proved that this execution trace is correct.
> The execution trace proves the actual behavior of the actual input to H.

and the ACTUAL behavior that the x86 source-code of ALL of P specifies
that P(P) will Halt, since the provided H will abort a simulation of
H({P,P).

Since this is NOT the behavior that your "simulation" predicts, that
PROVES that your simulation doesn't match the actual behavior specified
by the x86 instructions of the PROGRAM P.

Note, the x86 instuctions of JUST the "C Function" P, doen't actually
specify any defined behavior, as they reference something outside that
code. You CAN'T add "inferences" about what that code does and still say
you are basing your decision strictly on the x8t6 behavior.

It you DO base on inferences, those inferences need to be CORRECGT.

Since H(P,P) has been shown to return 0, any inference of that call must
be compatible with that, thus showing your H is being INCORRECT in its
inferences about the code of P, since it uses an INCORRECT behavior
model for H.

>
> What other measure do you have to verify that H(P,{P)P correctly
> simulates its input?

That it gets the right answer??

Remember, the x86 program P includes ALL the instructions that it
executes when it runs, the x86 assembly language doesn't hav4 some
"arbitrary" distintion between P and H, thus the correct operation of P
includes the actual behavior of H.

>
> The measure that others here use is not looking at the execution trace
> and saying the the behavior is wrong because it is not the behavior that
> they expect.
>

WRONG. We look at the ACTUAL trace of the x86 instructions, not your
FALSE one based on the INCORRECT assumed behavior of H.

You use FALSE premsises to generate UNSOUND logic which gives you WRONG
answers which you LIE to say the must be right.

That just shows that you just don't know anything about what you talk aboot.

On Friday, 29 July 2022 at 16:28:12 UTC+2, olcott wrote:
> On 7/29/2022 5:26 AM, Skep Dick wrote:
> > On Thursday, 28 July 2022 at 20:33:49 UTC+2, olcott wrote:
> >> It has been proven that the direct execution of P(P) is not stuck in
> >> infinitely recursive simulation only because when it calls H(P,P) H
> >> aborts the simulation of its input.
> >>
> >> It is not my fault that you cannot understand this proof. Any rebuttal
> >> of this prove must ignore the execution traces (as you have continued to
> >> ignore the execution traces) or is much more obviously pure gibberish.
> >
> > You don't even understand what it means to prove something...
> >
> > And your ignorance is totally your fault (having spent "15000 hours" on this)
> >
> > You are just incapable of learning.
> I would say that you have this backwards.
> When the execution trace of the simulation of the input to H(P,P) by H
> exactly matches the behavior that the x86 source-code of P specifies
> line-by-line then we have proved that this execution trace is correct.
> The execution trace proves the actual behavior of the actual input to H.
>
> What other measure do you have to verify that H(P,{P)P correctly
> simulates its input?

I would say that you have it backwards that I have it backwards.
There is no measure for "correct" simulation. H does whatever it does.

Correct or incorrect is immaterial and irrelevant. Because P **always** does the opposite.

You know... that game that you refuse to with me.

Will I call you an idiot or not?

If you say I will, I won't.
If you say. I won't, I will.

What measure do you have to verify whether you'll guess correctly?

On 7/29/2022 5:48 PM, Skep Dick wrote:
> On Friday, 29 July 2022 at 16:28:12 UTC+2, olcott wrote:
>> On 7/29/2022 5:26 AM, Skep Dick wrote:
>>> On Thursday, 28 July 2022 at 20:33:49 UTC+2, olcott wrote:
>>>> It has been proven that the direct execution of P(P) is not stuck in
>>>> infinitely recursive simulation only because when it calls H(P,P) H
>>>> aborts the simulation of its input.
>>>>
>>>> It is not my fault that you cannot understand this proof. Any rebuttal
>>>> of this prove must ignore the execution traces (as you have continued to
>>>> ignore the execution traces) or is much more obviously pure gibberish.
>>>
>>> You don't even understand what it means to prove something...
>>>
>>> And your ignorance is totally your fault (having spent "15000 hours" on this)
>>>
>>> You are just incapable of learning.
>> I would say that you have this backwards.
>> When the execution trace of the simulation of the input to H(P,P) by H
>> exactly matches the behavior that the x86 source-code of P specifies
>> line-by-line then we have proved that this execution trace is correct.
>> The execution trace proves the actual behavior of the actual input to H.
>>
>> What other measure do you have to verify that H(P,{P)P correctly
>> simulates its input?
>
> I would say that you have it backwards that I have it backwards.

> There is no measure for "correct" simulation. H does whatever it does.

Of course most everyone here knows that statement is ridiculous.

When the line-by-line execution trace of the x86 emulation of x86
machine code exactly matches the x86 source-code then we know that this
emulation is correct.

Until you correct this glaring error you have proven to be
insufficiently technically competent for me to spent any more time in a
dialogue.

>
> Correct or incorrect is immaterial and irrelevant. Because P **always** does the opposite.
>

I prove otherwise and you take simply ignoring this proof as a rebuttal.
The infinitely recursive emulation that P specifies to H prevents h from
ever returning any result to P, thus P cannot do the opposite of
whatever H returns.

Do you comprehend that every function called in finite recursion never
returns any value to its caller or is this also outside of your
technical competence?

--
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 Saturday, 30 July 2022 at 01:31:08 UTC+2, olcott wrote:
> When the line-by-line execution trace of the x86 emulation of x86
> machine code exactly matches the x86 source-code then we know that this
> emulation is correct.
Obviously the source code matches. All you've done is you've translated the function from one language into another.

The source code (in C or Assembly) is not the execution. The program contains conditional branching.

The exact same source code produces two different executions - one for each branch.

> Until you correct this glaring error you have proven to be
> insufficiently technically competent for me to spent any more time in a
> dialogue.

You've wasted 15000 hours of your life. 5 more minutes won't make any difference.

You've been going the wrong way all along. Competence is the other way...

> I prove otherwise and you take simply ignoring this proof as a rebuttal.
Proof? Where is this proof?!? I haven't seen one yet.

Maybe you want to write your "proof" in an actual proof assistant?

https://en.wikipedia.org/wiki/Agda_(programming_language)

> The infinitely recursive emulation that P specifies to H prevents h from
> ever returning any result to P, thus P cannot do the opposite of
> whatever H returns.

Of course it can. IF H returns P will do the opposite.
UNTIL H returns - P will sit and wait for H to return.

> Do you comprehend that every function called in finite recursion never
> returns any value to its caller or is this also outside of your
> technical competence?
Do you comprehend that's precisely the point of the Halting problem?

A working halting decider is supposed to halt and return an answer. ALWAYS.
That your halting decider fails to halt and enters an infinite loop is precisely the proof that it doesn't work.

On 7/29/22 7:31 PM, olcott wrote:
> On 7/29/2022 5:48 PM, Skep Dick wrote:
>> On Friday, 29 July 2022 at 16:28:12 UTC+2, olcott wrote:
>>> On 7/29/2022 5:26 AM, Skep Dick wrote:
>>>> On Thursday, 28 July 2022 at 20:33:49 UTC+2, olcott wrote:
>>>>> It has been proven that the direct execution of P(P) is not stuck in
>>>>> infinitely recursive simulation only because when it calls H(P,P) H
>>>>> aborts the simulation of its input.
>>>>>
>>>>> It is not my fault that you cannot understand this proof. Any rebuttal
>>>>> of this prove must ignore the execution traces (as you have
>>>>> continued to
>>>>> ignore the execution traces) or is much more obviously pure gibberish.
>>>>
>>>> You don't even understand what it means to prove something...
>>>>
>>>> And your ignorance is totally your fault (having spent "15000 hours"
>>>> on this)
>>>>
>>>> You are just incapable of learning.
>>> I would say that you have this backwards.
>>> When the execution trace of the simulation of the input to H(P,P) by H
>>> exactly matches the behavior that the x86 source-code of P specifies
>>> line-by-line then we have proved that this execution trace is correct.
>>> The execution trace proves the actual behavior of the actual input to H.
>>>
>>> What other measure do you have to verify that H(P,{P)P correctly
>>> simulates its input?
>>
>> I would say that you have it backwards that I have it backwards.
>
>
>> There is no measure for "correct" simulation. H does whatever it does.
>
> Of course most everyone here knows that statement is ridiculous.
>
> When the line-by-line execution trace of the x86 emulation of x86
> machine code exactly matches the x86 source-code then we know that this
> emulation is correct.

Nope, when the line-by-line executiont trace of the x86 emulation of the
x86 msachine code exactly matches the actual exectuiton that an x86
processor would do, then we know this emulation is correct.

The actual x86 processor will go into H, so the emulation needs to do this.

Since the actual x86 processor will eventually return from that call by
the code you have shown for H, if the emulation tries to claim doing the
"equivalent" of that call, or logic based on that call, it must match
that behavior,

This PROVES your rule (3) is incorrect, because it doesn't actually
agree with the behavior of the x86 processor, because it is just an
incorrect rule.

Your insistance just proves you don't understand how computers actually
work, what it means for something to be true, or even how you prove
something.

>
> Until you correct this glaring error you have proven to be
> insufficiently technically competent for me to spent any more time in a
> dialogue.

Until YOU fix this error, you are just proving your ignorance and that
you are trying to be deceptive.

>
>>
>> Correct or incorrect is immaterial and irrelevant. Because P
>> **always** does the opposite.
>>
>
> I prove otherwise and you take simply ignoring this proof as a rebuttal.
> The infinitely recursive emulation that P specifies to H prevents h from
> ever returning any result to P, thus P cannot do the opposite of
> whatever H returns.

Nope, you CLAIM otherwise and use INVALID and UNSOUND logic to make your
arguement.

>
> Do you comprehend that every function called in finite recursion never
> returns any value to its caller or is this also outside of your
> technical competence?
>

Your slipping.

A call in *FINITE* recursion WILL return, only a function called in
infinite recursion never returns, and if a given function call of a pure
function generates infinite recursion, it generates infinite recursion
for ALL calls with that same parameter, and thus if the call to H(P,P)
by P does this, then so does the call to H(P,P) by main, and thus H(P,P)
will NEVER return and thus it fails to be a decider.

If it DOES act differently, then you have just proved your H isn't
actually a pure function.

In actuality, since H derives its "proof" from invalid premises, all
that you have proven is that H is incorrect in its determination that
P(P) is incorrect, and that you fail at doing logic.

On 7/29/2022 6:45 PM, Skep Dick wrote:
> On Saturday, 30 July 2022 at 01:31:08 UTC+2, olcott wrote:
>> When the line-by-line execution trace of the x86 emulation of x86
>> machine code exactly matches the x86 source-code then we know that this
>> emulation is correct.
> Obviously the source code matches.

OK great you corrected the glaring error.

> All you've done is you've translated the function from one language into another.
>
> The source code (in C or Assembly) is not the execution. The program contains conditional branching.
>
> The exact same source code produces two different executions - one for each branch.
>

Sure and both branches: (a) to simulate again or (B) to abort the
simulation, result in the correctly simulated P never reaching its final
state "ret" instruction nor every receiving a return value from H ever
if the simulation is never aborted.

This is very easy to see and my take on why everyone is failing to agree
is that agreement on this one single point proves that I am correct that
H(P,P) does correctly determine that its input never halts.

*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

Newbies to comp.theory get confused and believe that halting is stopping
for any reason. This is not the case halting is only terminating
normally by reaching the final state "ret" instruction. If a halt
decider determines that its simulated input would never terminate
normally then it is correct to abort its simulation and reject this
input as non-halting.

>> Until you correct this glaring error you have proven to be
>> insufficiently technically competent for me to spent any more time in a
>> dialogue.
>
> You've wasted 15000 hours of your life. 5 more minutes won't make any difference.
>
> You've been going the wrong way all along. Competence is the other way...
>
>
>> I prove otherwise and you take simply ignoring this proof as a rebuttal.
> Proof? Where is this proof?!? I haven't seen one yet.
>
> Maybe you want to write your "proof" in an actual proof assistant?
>
> https://en.wikipedia.org/wiki/Agda_(programming_language)
>

Proof assistant will *not* show the actual behavior of the actual input
to H(P,P), thus is utterly useless in this case. The actual correct
execution trace of the actual input to H(P,P) does show this behavior,
thus it is the only relevant material required.

>
>> The infinitely recursive emulation that P specifies to H prevents h from
>> ever returning any result to P, thus P cannot do the opposite of
>> whatever H returns.
>
> Of course it can.

So you are saying that dead-code is reached even though "dead-code"
means that it is never reached.

> IF H returns P will do the opposite.
> UNTIL H returns - P will sit and wait for H to return.
>
>> Do you comprehend that every function called in finite recursion never
>> returns any value to its caller or is this also outside of your
>> technical competence?
>
> Do you comprehend that's precisely the point of the Halting problem?

You dodged the question, I will not respond to anything else that you
say until you answer the question. This is another test of your software
engineering skills to see if further dialogue is worth my time.

--
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 Saturday, 30 July 2022 at 02:18:18 UTC+2, olcott wrote:
> You dodged the question, I will not respond to anything else that you
> say until you answer the question. This is another test of your software
> engineering skills to see if further dialogue is worth my time. --

Speaking of dodging questions… you keep dodging this one: Will I call you an idiot or not?

If you say I will, then I won’t.
If you say I won’t, then I will.

Simulate me “correctly” and answer… Will I call you an idiot?

I won’t waste any more of my time with you until you answer it.

On 7/29/22 8:18 PM, olcott wrote:
> On 7/29/2022 6:45 PM, Skep Dick wrote:
>> On Saturday, 30 July 2022 at 01:31:08 UTC+2, olcott wrote:
>>> When the line-by-line execution trace of the x86 emulation of x86
>>> machine code exactly matches the x86 source-code then we know that this
>>> emulation is correct.
>> Obviously the source code matches.
>
> OK great you corrected the glaring error.
>
>> All you've done is you've translated the function from one language
>> into another.
>>
>> The source code (in C or Assembly) is not the execution. The program
>> contains conditional branching.
>>
>> The exact same source code produces two different executions - one for
>> each branch.
>>
>
> Sure and both branches: (a) to simulate again or (B) to abort the
> simulation, result in the correctly simulated P never reaching its final
> state "ret" instruction nor every receiving a return value from H ever
> if the simulation is never aborted.

But a given H doesn't HAVE branches.

If H is branch (a) then ALL H's present are branch (a) and thus NO
H(P,P) will ever abort its simulation and return 0 from H(P,P).

If H is branch (b) the it DOES abort its simulation, and returns 0, and
thus the call from P(P) to H(P,P) doesn't become infinitely recursive,
but will return the 0 from the call and thus P(P) Halts and H used wrong
logic.

The "two branch" logic just shows you don't understand what it means
that H is a pure function, or how computers actually work.

>
> This is very easy to see and my take on why everyone is failing to agree
> is that agreement on this one single point proves that I am correct that
> H(P,P) does correctly determine that its input never halts.

Nope, your branch (b) H presumes that the H called by P is the branch
(a) H, when it isn't, thus it gets the WRONG answer.

>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)

Right, and P(P) provably Halts if H(P,P) returns 0, that that answer is
incorrect.

All you are proving is your ignorance of what you are talking about.

>
> Newbies to comp.theory get confused and believe that halting is stopping
> for any reason. This is not the case halting is only terminating
> normally by reaching the final state "ret" instruction. If a halt
> decider determines that its simulated input would never terminate
> normally then it is correct to abort its simulation and reject this
> input as non-halting.

Nope, Haling is the ACTUAL PROGRAM reaching the final state.

You think that H aborting its simulation of the program keep the actual
running of the program from getting there.

Do you think that programs are just simulations?

>
>>> Until you correct this glaring error you have proven to be
>>> insufficiently technically competent for me to spent any more time in a
>>> dialogue.
>>
>> You've wasted 15000 hours of your life. 5 more minutes won't make any
>> difference.
>>
>> You've been going the wrong way all along. Competence is the other way...
>>
>>
>>> I prove otherwise and you take simply ignoring this proof as a rebuttal.
>> Proof? Where is this proof?!? I haven't seen one yet.
>>
>> Maybe you want to write your "proof" in an actual proof assistant?
>>
>> https://en.wikipedia.org/wiki/Agda_(programming_language)
>>
>
> Proof assistant will *not* show the actual behavior of the actual input
> to H(P,P), thus is utterly useless in this case. The actual correct
> execution trace of the actual input to H(P,P) does show this behavior,
> thus it is the only relevant material required.

The problem is that YOU don't understand that it DOES, at least if H is
defined to be a Halting Decider and P is the defined Impossible program.

You claims that it isn't is based on an UNSOUND proof and just shows
that you are totally ignorant of what you are talking about.

IF H(P,P) doesn't actually ask about P(P), then why does your P use it?

Just shows that YOU have been lying for the past 18 years.

>
>>> The infinitely recursive emulation that P specifies to H prevents h from
>>> ever returning any result to P, thus P cannot do the opposite of
>>> whatever H returns.
>>
>> Of course it can.
>
> So you are saying that dead-code is reached even though "dead-code"
> means that it is never reached.

it may be dead to the PARTIAL simulator, but only because it makes the
mistake of assuming incorrect behavior for H(P,P).

To the actual machine, and to a correct and complete simulator, it isn't
dead code for the H you have provided that returns 0 from H(P,P).

Code that is actually reached is NOT dead code. Just shows that you are
brain dead.

>
>> IF H returns P will do the opposite.
>> UNTIL H returns - P will sit and wait for H to return.
>>
>>> Do you comprehend that every function called in finite recursion never
>>> returns any value to its caller or is this also outside of your
>>> technical competence?
>>
>> Do you comprehend that's precisely the point of the Halting problem?
>
> You dodged the question, I will not respond to anything else that you
> say until you answer the question. This is another test of your software
> engineering skills to see if further dialogue is worth my time.
>

You are just showing your stupidity.

Functions call in **FINITE** recursion can easily return to their calles.

It is functions called in **INFINITE** recursion that can't and if the
funciton is a pure function, for any call that creates infinite
recursion, creates it for ALL calls of that function with the same
arguements.

Thus if you are correct that P(P) calling H(P,P) creates infinite
recursion, and thus H doesn't return to it, means that main calling
H(P,P) also creates infinite recursion:

main -> H(P,P) -> P(P) -> H(P,P) -> P(P) -> H(P,P) ...

and thus H doesn't return to main either and thus doesn't answer.

If H can return to main but not P then that just shows that H isn't a
pure function and thus fails to be eligable to be a decider.

On 7/29/2022 7:32 PM, Skep Dick wrote:
> On Saturday, 30 July 2022 at 02:18:18 UTC+2, olcott wrote:
>> You dodged the question, I will not respond to anything else that you
>> say until you answer the question. This is another test of your software
>> engineering skills to see if further dialogue is worth my time. --
>
> Speaking of dodging questions… you keep dodging this one: Will I call you an idiot or not?
>
> If you say I will, then I won’t.
> If you say I won’t, then I will.
>
> Simulate me “correctly” and answer… Will I call you an idiot?
>
> I won’t waste any more of my time with you until you answer it.

I am in fact a genius so if you call me an idiot that would be a falsehood.

"idiot" (IQ of 0–25)
https://en.wikipedia.org/wiki/Imbecile

A variety of cognitive research on chimpanzees places their estimated IQ
between 20 and 25...
https://study.com/academy/answer/what-is-the-average-iq-of-a-chimpanzee.html

--
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 Saturday, 30 July 2022 at 02:54:18 UTC+2, olcott wrote:
> On 7/29/2022 7:32 PM, Skep Dick wrote:
> > On Saturday, 30 July 2022 at 02:18:18 UTC+2, olcott wrote:
> >> You dodged the question, I will not respond to anything else that you
> >> say until you answer the question. This is another test of your software
> >> engineering skills to see if further dialogue is worth my time. --
> >
> > Speaking of dodging questions… you keep dodging this one: Will I call you an idiot or not?
> >
> > If you say I will, then I won’t.
> > If you say I won’t, then I will.
> >
> > Simulate me “correctly” and answer… Will I call you an idiot?
> >
> > I won’t waste any more of my time with you until you answer it.
> I am in fact a genius so if you call me an idiot that would be a falsehood.

I wouldn’t be so quick to beat my own chest…

A real genius would answer the question correctly: Will I call you a genius, or an idiot?

If you correctly guess I will call you an idiot, then I will call you a genius.
If you correctly guess I will call you a genius, then I will call you an idiot.

Guess.

On 7/29/22 8:54 PM, olcott wrote:
> On 7/29/2022 7:32 PM, Skep Dick wrote:
>> On Saturday, 30 July 2022 at 02:18:18 UTC+2, olcott wrote:
>>> You dodged the question, I will not respond to anything else that you
>>> say until you answer the question. This is another test of your software
>>> engineering skills to see if further dialogue is worth my time. --
>>
>> Speaking of dodging questions… you keep dodging this one: Will I call
>> you an idiot or not?
>>
>> If you say I will, then I won’t.
>> If you say I won’t, then I will.
>>
>> Simulate me “correctly” and answer… Will I call you an idiot?
>>
>> I won’t waste any more of my time with you until you answer it.
>
> I am in fact a genius so if you call me an idiot that would be a falsehood.
>
> "idiot" (IQ of 0–25)
> https://en.wikipedia.org/wiki/Imbecile
>
> A variety of cognitive research on chimpanzees places their estimated IQ
> between 20 and 25...
> https://study.com/academy/answer/what-is-the-average-iq-of-a-chimpanzee.html
>

No, you are an idiot because you believe your own lies.

Perhaps you didn't actually read that article for comprehension and
check the notes.

You will not that the definition of "idiot" that you are quoting comes
from an OBSOLETE source.

This is the problem that you continue to do, you show that you do not
actually understand the words that you use.

THAT makes you an IDIOT.

On 7/29/2022 8:04 PM, Skep Dick wrote:
> On Saturday, 30 July 2022 at 02:54:18 UTC+2, olcott wrote:
>> On 7/29/2022 7:32 PM, Skep Dick wrote:
>>> On Saturday, 30 July 2022 at 02:18:18 UTC+2, olcott wrote:
>>>> You dodged the question, I will not respond to anything else that you
>>>> say until you answer the question. This is another test of your software
>>>> engineering skills to see if further dialogue is worth my time. --
>>>
>>> Speaking of dodging questions… you keep dodging this one: Will I call you an idiot or not?
>>>
>>> If you say I will, then I won’t.
>>> If you say I won’t, then I will.
>>>
>>> Simulate me “correctly” and answer… Will I call you an idiot?
>>>
>>> I won’t waste any more of my time with you until you answer it.
>> I am in fact a genius so if you call me an idiot that would be a falsehood.
>
> I wouldn’t be so quick to beat my own chest…
>
> A real genius would answer the question correctly: Will I call you a genius, or an idiot?
>
> If you correctly guess I will call you an idiot, then I will call you a genius.
> If you correctly guess I will call you a genius, then I will call you an idiot.
>
> Guess.

No further replies form me until you answer this question:

Do you comprehend that every function called in infinite recursion never
returns any value to its caller?

I am trying to get my work validated before I die of cancer so I have no
patience for 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 7/29/22 10:11 PM, olcott wrote:
> On 7/29/2022 8:04 PM, Skep Dick wrote:
>> On Saturday, 30 July 2022 at 02:54:18 UTC+2, olcott wrote:
>>> On 7/29/2022 7:32 PM, Skep Dick wrote:
>>>> On Saturday, 30 July 2022 at 02:18:18 UTC+2, olcott wrote:
>>>>> You dodged the question, I will not respond to anything else that you
>>>>> say until you answer the question. This is another test of your
>>>>> software
>>>>> engineering skills to see if further dialogue is worth my time. --
>>>>
>>>> Speaking of dodging questions… you keep dodging this one: Will I
>>>> call you an idiot or not?
>>>>
>>>> If you say I will, then I won’t.
>>>> If you say I won’t, then I will.
>>>>
>>>> Simulate me “correctly” and answer… Will I call you an idiot?
>>>>
>>>> I won’t waste any more of my time with you until you answer it.
>>> I am in fact a genius so if you call me an idiot that would be a
>>> falsehood.
>>
>> I wouldn’t be so quick to beat my own chest…
>>
>> A real genius would answer the question correctly: Will I call you a
>> genius, or an idiot?
>>
>> If you correctly guess I will call you an idiot, then I will call you
>> a genius.
>> If you correctly guess I will call you a genius, then I will call you
>> an idiot.
>>
>> Guess.
>
> No further replies form me until you answer this question:
>
> Do you comprehend that every function called in infinite recursion never
> returns any value to its caller?
>
> I am trying to get my work validated before I die of cancer so I have no
> patience for head games.
>

IT is absolutely true that any function call that creates infinite
recursion will never return to its caller.

But it is aldo true that for any PURE function that gets into this will
get into that issue from ANY caller with the same parameters.

Thus if P(P) calling H(P,P) creates the infinite recursion of

P(P) -> H(P,P) -> P(P) -> H(P,P) -> P(P) -> H(P,P) ...

Then the sequence of main calling H(P,P) will generate this sequence:

Main -> H(P,P) -> P(P) -> H(P,P) -> P(P) -> H(P,P) ...

And thus an H that does that fails to answer the call H(P,P) to ANYBODY
and thus fails to be a decider.

You claim that the first happens but the second does not.

In truth, the problem is that what is actually happening is that you
only look at:

Main -> H(P,P) -> P(P) -> H(P,P)

and the first H decides that the second H will behave like the above,
but then that first H doesn't follow the pattern, and thus that pattern
NEVER WAS the behavior of the H that you actually have.

With your H, the ACTUAL behavior of ANY H(P,P) is

H(P,P) simulates P(P) which calls H(P,P) and then the first H aborts it
and returns 0.

Thus the actual behavior of the input is:

P(P) calls H(P,P) which simulates P(P) which calls H(P,P) and then the
first H(P,P) aborts its simulation and returns 0 to P(P) which then halts.

Note, this says that your H was INCORRECT in deciding that when its
simulation of P(P) calls H(P,P) that this would cause infinite
recursion, and thus it gets the wrong answer.

You try to make the be an excuse that somehow H(P,P) doesn't refer to
P(P), but then you have the problem that if H(P,P) doesn't actually
refer to the machine P(P), then H just fails to be the needed halt decider.

Your attempt to "prove" the answer was correct is based on FALSE
premises (that are the sneekiest kind of falseness, they work in many
cases but fail in this one) and thus your "proof" is incorrect and unsound.

This has been pointed out to you many times.

Since even a normal 10 year would probably have gotten this by now, your
IQ has to be down in the low teens or lower, which means you DO qualify
as a IDIOT even by the definition you qouted.

On 7/29/2022 9:26 PM, Richard Damon wrote:
> On 7/29/22 10:11 PM, olcott wrote:
>> On 7/29/2022 8:04 PM, Skep Dick wrote:
>>> On Saturday, 30 July 2022 at 02:54:18 UTC+2, olcott wrote:
>>>> On 7/29/2022 7:32 PM, Skep Dick wrote:
>>>>> On Saturday, 30 July 2022 at 02:18:18 UTC+2, olcott wrote:
>>>>>> You dodged the question, I will not respond to anything else that you
>>>>>> say until you answer the question. This is another test of your
>>>>>> software
>>>>>> engineering skills to see if further dialogue is worth my time. --
>>>>>
>>>>> Speaking of dodging questions… you keep dodging this one: Will I
>>>>> call you an idiot or not?
>>>>>
>>>>> If you say I will, then I won’t.
>>>>> If you say I won’t, then I will.
>>>>>
>>>>> Simulate me “correctly” and answer… Will I call you an idiot?
>>>>>
>>>>> I won’t waste any more of my time with you until you answer it.
>>>> I am in fact a genius so if you call me an idiot that would be a
>>>> falsehood.
>>>
>>> I wouldn’t be so quick to beat my own chest…
>>>
>>> A real genius would answer the question correctly: Will I call you a
>>> genius, or an idiot?
>>>
>>> If you correctly guess I will call you an idiot, then I will call you
>>> a genius.
>>> If you correctly guess I will call you a genius, then I will call you
>>> an idiot.
>>>
>>> Guess.
>>
>> No further replies form me until you answer this question:
>>
>> Do you comprehend that every function called in infinite recursion
>> never returns any value to its caller?
>>
>> I am trying to get my work validated before I die of cancer so I have
>> no patience for head games.
>>
>
> IT is absolutely true that any function call that creates infinite
> recursion will never return to its caller.
That is great that you said this, I may stop totally ignoring every one
of your posts without even glancing at them for half a second.

It is also true that the correctly simulated input to H(P,P) by H would
never reach its "ret" instruction(final state), thus never halt
according to:

*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

whether or not H(P,P) ever aborts the simulation of its input.

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

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

If you agree with both of these proven facts I may start reading all of
your posts again.

--
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 Friday, July 29, 2022 at 10:47:30 PM UTC-4, olcott wrote:
> On 7/29/2022 9:26 PM, Richard Damon wrote:
> > On 7/29/22 10:11 PM, olcott wrote:
> >> On 7/29/2022 8:04 PM, Skep Dick wrote:
> >>> On Saturday, 30 July 2022 at 02:54:18 UTC+2, olcott wrote:
> >>>> On 7/29/2022 7:32 PM, Skep Dick wrote:
> >>>>> On Saturday, 30 July 2022 at 02:18:18 UTC+2, olcott wrote:
> >>>>>> You dodged the question, I will not respond to anything else that you
> >>>>>> say until you answer the question. This is another test of your
> >>>>>> software
> >>>>>> engineering skills to see if further dialogue is worth my time. --
> >>>>>
> >>>>> Speaking of dodging questions… you keep dodging this one: Will I
> >>>>> call you an idiot or not?
> >>>>>
> >>>>> If you say I will, then I won’t.
> >>>>> If you say I won’t, then I will.
> >>>>>
> >>>>> Simulate me “correctly” and answer… Will I call you an idiot?
> >>>>>
> >>>>> I won’t waste any more of my time with you until you answer it.
> >>>> I am in fact a genius so if you call me an idiot that would be a
> >>>> falsehood.
> >>>
> >>> I wouldn’t be so quick to beat my own chest…
> >>>
> >>> A real genius would answer the question correctly: Will I call you a
> >>> genius, or an idiot?
> >>>
> >>> If you correctly guess I will call you an idiot, then I will call you
> >>> a genius.
> >>> If you correctly guess I will call you a genius, then I will call you
> >>> an idiot.
> >>>
> >>> Guess.
> >>
> >> No further replies form me until you answer this question:
> >>
> >> Do you comprehend that every function called in infinite recursion
> >> never returns any value to its caller?
> >>
> >> I am trying to get my work validated before I die of cancer so I have
> >> no patience for head games.
> >>
> >
> > IT is absolutely true that any function call that creates infinite
> > recursion will never return to its caller.
> That is great that you said this, I may stop totally ignoring every one
> of your posts without even glancing at them for half a second.

Try reading the rest of his post and understanding it, and *maybe* you'll realize why you're wrong.

>
> It is also true that the correctly simulated input to H(P,P) by H would
> never reach its "ret" instruction(final state), thus never halt
> according to:
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
> whether or not H(P,P) ever aborts the simulation of its input.

Again, the *machine*, not the simulation of the machine. A halt decider is required to report if the machine that its input represents will halt, not if "the correctly simulated input would never reach a final state".

Since your H is doing the latter, it is not a halt decider because it is answering the wrong question.

On 7/29/22 10:47 PM, olcott wrote:
> On 7/29/2022 9:26 PM, Richard Damon wrote:
>> On 7/29/22 10:11 PM, olcott wrote:
>> IT is absolutely true that any function call that creates infinite
>> recursion will never return to its caller.
> That is great that you said this, I may stop totally ignoring every one
> of your posts without even glancing at them for half a second.
>
> It is also true that the correctly simulated input to H(P,P) by H would
> never reach its "ret" instruction(final state), thus never halt
> according to:
>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> whether or not H(P,P) ever aborts the simulation of its input.

Nope. You have that WRONG.

If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
never returns the answer, so that H isn't a correct halt decider.

But, in the case that H(P,P) does abort and return 0, then the
definition you just quoted says look at the TURING MACHINE, and that it
is the DIRECT EXECUTION of P(P) and that WILL Halt.

P(P) will call H(P,P).
H(P,P) will simulate a copy of P(P)
see that it calls H(P.P)
H will then decide INCORRECTLY (as shown later) that this shows non-halting
H will then stop simulating and return 0 to P(P)
P(P) will the Halt

And that shows that H(P,P) returning 0 was INCORRECT.

You keep on making the dumb mistake to think that just because H didn't
see that end, that it doesn't happen in the behavior of the input.

If H is a decider, the behavior of the input in the behavior of the
machine the input represents, and that doesn't stop just because H stops
simulating it.

It seems you just don't know what a Turing Machine actually is, and are
making wild guesses about it, but being positive about what you guess.

This just proves how little you know about what you are saying.

>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> If you agree with both of these proven facts I may start reading all of
> your posts again.
>

Maybe you should learn what it means to actually prove a fact.

One key thing is you need to start from the right defintions and apply it.

Note, The definition refers to TURING MACHINES, which ALWAYS run until
they reach a final state.

This is not true of the simulation done by H, so it isn't equivalent,
and "close enough" isn't a valid term for proofs.

Only 99% right is still 100% wrong.

YOU ARE 100% WRONG.

On 7/29/2022 9:59 PM, Richard Damon wrote:
>
> On 7/29/22 10:47 PM, olcott wrote:
>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>> On 7/29/22 10:11 PM, olcott wrote:
>>> IT is absolutely true that any function call that creates infinite
>>> recursion will never return to its caller.
>> That is great that you said this, I may stop totally ignoring every
>> one of your posts without even glancing at them for half a second.
>>
>> It is also true that the correctly simulated input to H(P,P) by H
>> would never reach its "ret" instruction(final state), thus never halt
>> according to:
>>
>> *computation that halts* … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>>
>> whether or not H(P,P) ever aborts the simulation of its input.
>
> Nope. You have that WRONG.
>
> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
> never returns the answer, so that H isn't a correct halt decider.
>

As usual you resort to the strawman deception:

*straw man*
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

*The question is*
Does the input to H(P,P) correctly simulated by H ever reach the "ret"
instruction of P whether or not H ever aborts its simulation of P?

The lack of an honest answer to this question gets you totally ignored
(yet not blocked to protect comp.c and comp.c++) all of the time for a
long time.

--
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 Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
> On 7/29/2022 9:59 PM, Richard Damon wrote:
> >
> > On 7/29/22 10:47 PM, olcott wrote:
> >> On 7/29/2022 9:26 PM, Richard Damon wrote:
> >>> On 7/29/22 10:11 PM, olcott wrote:
> >>> IT is absolutely true that any function call that creates infinite
> >>> recursion will never return to its caller.
> >> That is great that you said this, I may stop totally ignoring every
> >> one of your posts without even glancing at them for half a second.
> >>
> >> It is also true that the correctly simulated input to H(P,P) by H
> >> would never reach its "ret" instruction(final state), thus never halt
> >> according to:
> >>
> >> *computation that halts* … the Turing machine will halt whenever it
> >> enters a final state. (Linz:1990:234)
> >>
> >> whether or not H(P,P) ever aborts the simulation of its input.
> >
> > Nope. You have that WRONG.
> >
> > If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
> > never returns the answer, so that H isn't a correct halt decider.
> >
> As usual you resort to the strawman deception:
>
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
> *The question is*
> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
> instruction of P whether or not H ever aborts its simulation of P?

Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.

Therefore H is not a halt decider because it is answering the wrong question.

>
> The lack of an honest answer to this question gets you totally ignored
> (yet not blocked to protect comp.c and comp.c++) all of the time for a
> long time.

That you don't like the correct answer doesn't make it dishonest.

On 7/29/2022 10:18 PM, Dennis Bush wrote:
> On Friday, July 29, 2022 at 11:12:53 PM UTC-4, olcott wrote:
>> On 7/29/2022 9:59 PM, Richard Damon wrote:
>>>
>>> On 7/29/22 10:47 PM, olcott wrote:
>>>> On 7/29/2022 9:26 PM, Richard Damon wrote:
>>>>> On 7/29/22 10:11 PM, olcott wrote:
>>>>> IT is absolutely true that any function call that creates infinite
>>>>> recursion will never return to its caller.
>>>> That is great that you said this, I may stop totally ignoring every
>>>> one of your posts without even glancing at them for half a second.
>>>>
>>>> It is also true that the correctly simulated input to H(P,P) by H
>>>> would never reach its "ret" instruction(final state), thus never halt
>>>> according to:
>>>>
>>>> *computation that halts* … the Turing machine will halt whenever it
>>>> enters a final state. (Linz:1990:234)
>>>>
>>>> whether or not H(P,P) ever aborts the simulation of its input.
>>>
>>> Nope. You have that WRONG.
>>>
>>> If H doesn't abort, then yes, then P(P) will never halt, but H(P,P)
>>> never returns the answer, so that H isn't a correct halt decider.
>>>
>> As usual you resort to the strawman deception:
>>
>> *straw man*
>> An intentionally misrepresented proposition that is set up because it is
>> easier to defeat than an opponent's real argument.
>> https://www.lexico.com/en/definition/straw_man
>>
>> *The question is*
>> Does the input to H(P,P) correctly simulated by H ever reach the "ret"
>> instruction of P whether or not H ever aborts its simulation of P?
>
> Which is not the question a halt decider must answer. If H is a halt decider, H(P,P) *must* answer if P(P) halts, not if there exists an implementation of the function H that can simulate the function call P(P) to a final state.
>
> Therefore H is not a halt decider because it is answering the wrong question.
>
>>
>> The lack of an honest answer to this question gets you totally ignored
>> (yet not blocked to protect comp.c and comp.c++) all of the time for a
>> long time.
>
> That you don't like the correct answer doesn't make it dishonest.

I picked up that you are only trolling be a short while ago. Before this
I thought it was very probable yet less than 100% certain. That you
sustain the straw man deception make my assessment of your motives
complete.

--
Copyright 2022 Pete Olcott

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