On 7/4/2021 1:50 AM, André G. Isaak wrote:
> On 2021-07-03 22:18, olcott wrote:
>> On 7/3/2021 11:14 PM, André G. Isaak wrote:
>>> On 2021-07-03 19:38, olcott wrote:
>>>> On 7/3/2021 8:14 PM, André G. Isaak wrote:
>>>>> On 2021-07-03 14:37, olcott wrote:
>>>>>
>>>>>> It can always ignore it own behavior and it can do this by
>>>>>> screening out machine address ranges to be ignored. H ignores all
>>>>>> of its own behavior and the behavior or every operating system
>>>>>> function.
>>>>>
>>>>> And in what universe does it make sense to simply ignore operating
>>>>> system functions?
>>>>
>>>> When making a halt deciding function it only makes sense to keep
>>>> track of those aspects of computations that can cause the input to
>>>> halt.
>>>
>>> And what on earth would lead you to believe that a system call could
>>> have no impact on halting?
>>>
>>> (You conveniently skipped the example I gave.)
>>>
>>> André
>>>
>>
>> I am the only author of the entire x86utm operating system and all of
>> its functions.
>
> And we're just supposed to take your word for it that these can
> legitimately be ignored?
>
> Given that you've claimed that the instance of H called from within P
> doesn't affect halting when it clearly does, your word isn't going to
> carry much weight here.
>

No instance of any H has any effect on any P until some P proves that it
will never halt unless aborted. This has always been able to be directly
verified by the assembly language execution trace of P relative to its
assembly language source code.

This has been available posted directly in this forum since
On 3/14/2021 12:46 PM, olcott wrote:

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

> If it really were the case that these things didn't have any affect on
> halting, then it would also be perfectly fine for your halt decider to
> *not* skip this code in its analysis, and that would avoid objections

Most importantly you can easily verify for yourself that P is accurately
simulated by comparing its x86 source code to its x86 execution trace.

That no one has bothered to do this since March 14 would seem to
indicate that no one here knows assembly language besides me.

I have proven that H has no effect on its input since March 13 and the
16 lines of execution trace of the input proved to be totally
overwhelming for everyone here. Adding 26,000 lines of more code would
not help.

> along these lines. But if you did that you'd see that your assessment is
> wrong.
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/4/2021 5:40 AM, Richard Damon wrote:
> On 7/3/21 11:32 PM, olcott wrote:
>> On 7/3/2021 10:24 PM, Richard Damon wrote:
>
>>> But since H will have an effect on the behavior of the calling P after
>>> it decides, that effect needs to be considered in 'proving' what it will
>>> do.
>>
>> Not really not at all. P has already proved that it will never halt
>> unless H aborts it. Once P has done this then this proves that the not
>> halting decision of H is necessarily correct.
>>
>
> But H HASN'T Actually done that because H makes the same mistake that
> you are doing that it forgets to consider that after it makes the
> decision and abort the simulation and return that answer, that in doing
> so it breaks the conditions that it made its proof.
>

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

Every computation that halts on its own without having to be aborted by
the halt decider is a halting computation.

Every computation that never halts unless the halt decider aborted it is
a non-halting computation.

Because a simulating halt decider must always abort the simulation of
every input that never halts its halt deciding criteria must be adapted:
*Does the input halt on its input?* must become:
*Does the input halt without having its simulation aborted?*

This change is required because every input to a simulating halt decider
either halts on its own or halts because its simulation has been aborted.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/4/2021 11:46 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/3/2021 7:23 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/3/2021 3:20 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> u32 Input_Halts = H(x, x);
>>>>>>>> if (Input_Halts)
>>>>>>>> HERE: goto HERE;
>>>>>>>> }
>>>>>>> For H(P,P) to be correct one of these must apply:
>>>>>>>
>>>>>>> H(P,P) == 0 and P(P) does not halt, or
>>>>>>> H(P,P) != 0 and P(P) halts.
>>>>>>>
>>>>>>> Neither is the case.
>>>>>>
>>>>>> Superficially it may seem that way until you realize (as you have
>>>>>> already realized) that the halt criteria must be adapted for a
>>>>>> simulating halt decider.
>>>>>>
>>>>> The two criteria I gave are for the halting problem. No one is
>>>>> interested in your "other kind of halting". It seems you agree that H
>>>>> is wrong about the input given above as far as the criterion of actual
>>>>> halting goes.
>>>>
>>>> Because a simulating halt decider must always abort the simulation of
>>>> every input that never halts its halt deciding criteria must be
>>>> adapted.
>>> If you "adapted" the criterion for being a prime number you could
>>> "refute" many more theorems.
>>
>> You already agreed that this adaptation of the halt status criteria is
>> correct:
>
> A halting computation is one that halts. There is no other criterion.
> I can't believe this needs to be said.
>
> For H(P,P) to be correct one of these must apply:
>
> H(P,P) == 0 and P(P) does not halt, or
> H(P,P) != 0 and P(P) halts.
>
> Neither is the case for your H and P.
>

Yes and by this same reasoning we know that when the simulation of an
infinite loop is aborted this proves that the infinite loop that only
jumps to its own machine address is indeed a halting computation.

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
Output("Input_Would_Halt2 = ", Input_Would_Halt2);
}

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/4/2021 2:00 PM, André G. Isaak wrote:
> On 2021-07-04 12:24, Malcolm McLean wrote:
>
>> The execution trace showed two calls to the "halts" subroutine.
>> However it was stated that "halts" is a simulating decider. Therefore we
>> have one call to halts. It then emulates  another call to halts. But the
>> second call to "halts" shouldn't appear on the execution trace. It's
>> emulated.
>>
>> So exactly what the decider is doing remains a bit opaque.
>
> I've tried to get Olcott to clarify exactly what he means by
> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
> what the rest of the world means, but I still am unclear about what he
> actually means.
>
> André
>

Sure everyone knows that an x86 emulator can be anything from a vanilla
milkshake machine to a dump truck. What I mean by x86 emulator is
software that executes x86 machine language as if this software virtual
machine was an actual x86 processor.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/4/2021 8:03 PM, dklei...@gmail.com wrote:
> On Sunday, July 4, 2021 at 1:55:27 PM UTC-7, André G. Isaak wrote:
>> On 2021-07-04 14:09, olcott wrote:
>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>
>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>> However it was stated that "halts" is a simulating decider. Therefore we
>>>>> have one call to halts. It then emulates another call to halts. But the
>>>>> second call to "halts" shouldn't appear on the execution trace. It's
>>>>> emulated.
>>>>>
>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>
>>>> I've tried to get Olcott to clarify exactly what he means by
>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
>>>> what the rest of the world means, but I still am unclear about what he
>>>> actually means.
>>>>
>>>> André
>>>>
>>>
>>> Sure everyone knows that an x86 emulator can be anything from a vanilla
>>> milkshake machine to a dump truck. What I mean by x86 emulator is
>>> software that executes x86 machine language as if this software virtual
>>> machine was an actual x86 processor.
>> The problem is that you keep talking about 'nested simulations' but
>> there's absolutely nothing in your code or your traces to suggest more
>> than a single level of emulation is involved.
>>
>> If your H *emulates* P, it should not contain a call to P. It should
>> contain a call to some function EMULATE with some description of P
>> (either a file or a memory location) as an *argument* to that function.
>> If that P includes an H which also emulates its input, there should be a
>> second call to EMULATE, meaning we should have one instance of the
>> emulator running on the actual hardware, and a second instance of the
>> emulator being interpreted by the first emulator rather than being run
>> on the actual hardware, and with a second instance of P being
>> interpreted by that emulated emulator rather than either the hardware or
>> the emulator which is running directly on the hardware.
>>
>> But this is not what appears to be happening in either your traces or
>> your code fragments.
>> André
>
> I think everyone agrees that PO's x86 work will never be accepted by any
> scholarly journal. Shouldn't we be trying to avoid using it.
>
> For starters we need a clear statement as to what is being proved complete
> with all the definitions a journal will require.
>

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

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

I have proved that H correctly decides that P is a non-halting
computation on the basis that P calls H in infinitely nested simulation.
Computer scientists might notice that H and P are in their proper
halting problem relation to each other.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/4/2021 11:46 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/3/2021 7:23 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/3/2021 3:20 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> u32 Input_Halts = H(x, x);
>>>>>>>> if (Input_Halts)
>>>>>>>> HERE: goto HERE;
>>>>>>>> }
>>>>>>> For H(P,P) to be correct one of these must apply:
>>>>>>>
>>>>>>> H(P,P) == 0 and P(P) does not halt, or
>>>>>>> H(P,P) != 0 and P(P) halts.
>>>>>>>
>>>>>>> Neither is the case.
>>>>>>
>>>>>> Superficially it may seem that way until you realize (as you have
>>>>>> already realized) that the halt criteria must be adapted for a
>>>>>> simulating halt decider.
>>>>>>
>>>>> The two criteria I gave are for the halting problem. No one is
>>>>> interested in your "other kind of halting". It seems you agree that H
>>>>> is wrong about the input given above as far as the criterion of actual
>>>>> halting goes.
>>>>
>>>> Because a simulating halt decider must always abort the simulation of
>>>> every input that never halts its halt deciding criteria must be
>>>> adapted.
>>> If you "adapted" the criterion for being a prime number you could
>>> "refute" many more theorems.
>>
>> You already agreed that this adaptation of the halt status criteria is
>> correct:
>
> A halting computation is one that halts. There is no other criterion.
> I can't believe this needs to be said.
>

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
Output("Input_Would_Halt2 = ", Input_Would_Halt2);
}

Then Infinite_Loop() is a halting computation on the basis that H aborts
its simulation of Infinite_Loop().

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/4/2021 9:14 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/4/2021 11:46 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/3/2021 7:23 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/3/2021 3:20 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> void P(u32 x)
>>>>>>>>>> {
>>>>>>>>>> u32 Input_Halts = H(x, x);
>>>>>>>>>> if (Input_Halts)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> }
>>>>>>>>> For H(P,P) to be correct one of these must apply:
>>>>>>>>>
>>>>>>>>> H(P,P) == 0 and P(P) does not halt, or
>>>>>>>>> H(P,P) != 0 and P(P) halts.
>>>>>>>>>
>>>>>>>>> Neither is the case.
>>>>>>>>
>>>>>>>> Superficially it may seem that way until you realize (as you have
>>>>>>>> already realized) that the halt criteria must be adapted for a
>>>>>>>> simulating halt decider.
>>>>>>>>
>>>>>>> The two criteria I gave are for the halting problem. No one is
>>>>>>> interested in your "other kind of halting". It seems you agree that H
>>>>>>> is wrong about the input given above as far as the criterion of actual
>>>>>>> halting goes.
>>>>>>
>>>>>> Because a simulating halt decider must always abort the simulation of
>>>>>> every input that never halts its halt deciding criteria must be
>>>>>> adapted.
>>>>> If you "adapted" the criterion for being a prime number you could
>>>>> "refute" many more theorems.
>>>>
>>>> You already agreed that this adaptation of the halt status criteria is
>>>> correct:
>>> A halting computation is one that halts. There is no other criterion.
>>> I can't believe this needs to be said.
>>>
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
>> Output("Input_Would_Halt2 = ", Input_Would_Halt2);
>> }
>>
>> Then Infinite_Loop() is a halting computation on the basis that H
>> aborts its simulation of Infinite_Loop().
>
> I think you've lost the plot. Infinite_Loop() is a not a halting
> computation. H(Infinite_Loop, Infinite_Loop) must halt if there is to
> be a result, but Infinite_Loop(Infinite_Loop) (technically the
> computation represented by the arguments to H) is not a halting
> computation.
>

Every computation that would never halt unless its simulation is aborted
is equally not a halting computation.

There is no exception to this rule in the same way and for the same
reason that the numeric integer 5 is always numerically greater than the
numeric integer 3.

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/4/2021 9:28 PM, olcott wrote:
> On 7/4/2021 9:14 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/4/2021 11:46 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/3/2021 7:23 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/3/2021 3:20 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>          void P(u32 x)
>>>>>>>>>>>          {
>>>>>>>>>>>            u32 Input_Halts = H(x, x);
>>>>>>>>>>>            if (Input_Halts)
>>>>>>>>>>>              HERE: goto HERE;
>>>>>>>>>>>          }
>>>>>>>>>> For H(P,P) to be correct one of these must apply:
>>>>>>>>>>
>>>>>>>>>>        H(P,P) == 0 and P(P) does not halt, or
>>>>>>>>>>        H(P,P) != 0 and P(P) halts.
>>>>>>>>>>
>>>>>>>>>> Neither is the case.
>>>>>>>>>
>>>>>>>>> Superficially it may seem that way until you realize (as you have
>>>>>>>>> already realized) that the halt criteria must be adapted for a
>>>>>>>>> simulating halt decider.
>>>>>>>>>
>>>>>>>> The two criteria I gave are for the halting problem.  No one is
>>>>>>>> interested in your "other kind of halting".  It seems you agree
>>>>>>>> that H
>>>>>>>> is wrong about the input given above as far as the criterion of
>>>>>>>> actual
>>>>>>>> halting goes.
>>>>>>>
>>>>>>> Because a simulating halt decider must always abort the
>>>>>>> simulation of
>>>>>>> every input that never halts its halt deciding criteria must be
>>>>>>> adapted.
>>>>>> If you "adapted" the criterion for being a prime number you could
>>>>>> "refute" many more theorems.
>>>>>
>>>>> You already agreed that this adaptation of the halt status criteria is
>>>>> correct:
>>>> A halting computation is one that halts.  There is no other criterion.
>>>> I can't believe this needs to be said.
>>>>
>>>
>>> void Infinite_Loop()
>>> {
>>>    HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>    u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
>>>    Output("Input_Would_Halt2 = ", Input_Would_Halt2);
>>> }
>>>
>>> Then Infinite_Loop() is a halting computation on the basis that H
>>> aborts its simulation of Infinite_Loop().
>>
>> I think you've lost the plot.  Infinite_Loop() is a not a halting
>> computation.  H(Infinite_Loop, Infinite_Loop) must halt if there is to
>> be a result, but Infinite_Loop(Infinite_Loop) (technically the
>> computation represented by the arguments to H) is not a halting
>> computation.
>>
>
> Every computation that would never halt unless its simulation is aborted
> is equally not a halting computation.
>
> There is no exception to this rule in the same way and for the same
> reason that the numeric integer 5 is always numerically greater than the
> numeric integer 3.
>
> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> > olcott <NoOne@NoWhere.com> writes:
> >
> >> Truism:
> >> Every simulation that would never stop unless Halts() stops
> >> it at some point specifies infinite execution.
> >
> > Any algorithm that implements this truism is, of course, a halting
> > decider.
>
>

It can be easily verified that if no H ever aborts any P that P(P) will
never halt. If any H must abort any P then this H does correctly decide
that this P does not halt.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/4/2021 3:55 PM, André G. Isaak wrote:
> On 2021-07-04 14:09, olcott wrote:
>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>
>>>> The execution trace showed two calls to the "halts" subroutine.
>>>> However it was stated that "halts" is a simulating decider.
>>>> Therefore we
>>>> have one call to halts. It then emulates  another call to halts. But
>>>> the
>>>> second call to "halts" shouldn't appear on the execution trace. It's
>>>> emulated.
>>>>
>>>> So exactly what the decider is doing remains a bit opaque.
>>>
>>> I've tried to get Olcott to clarify exactly what he means by
>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
>>> what the rest of the world means, but I still am unclear about what
>>> he actually means.
>>>
>>> André
>>>
>>
>> Sure everyone knows that an x86 emulator can be anything from a
>> vanilla milkshake machine to a dump truck.  What I mean by x86
>> emulator is software that executes x86 machine language as if this
>> software virtual machine was an actual x86 processor.
>
> The problem is that you keep talking about 'nested simulations' but
> there's absolutely nothing in your code or your traces to suggest more
> than a single level of emulation is involved.
>

You must not know assembly x86 language at all.

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x); // call H 2nd level of simulation
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P); // call H 1st level of simulation
Output("Input_Halts = ", Input_Halts);
}

_P()
[00000b1a](01) 55 push ebp
[00000b1b](02) 8bec mov ebp,esp
[00000b1d](01) 51 push ecx
[00000b1e](03) 8b4508 mov eax,[ebp+08]
[00000b21](01) 50 push eax // 2nd Param
[00000b22](03) 8b4d08 mov ecx,[ebp+08]
[00000b25](01) 51 push ecx // 1st Param
[00000b26](05) e81ffeffff call 0000094a // call H
[00000b2b](03) 83c408 add esp,+08
[00000b2e](03) 8945fc mov [ebp-04],eax
[00000b31](04) 837dfc00 cmp dword [ebp-04],+00
[00000b35](02) 7402 jz 00000b39
[00000b37](02) ebfe jmp 00000b37
[00000b39](02) 8be5 mov esp,ebp
[00000b3b](01) 5d pop ebp
[00000b3c](01) c3 ret
Size in bytes:(0035) [00000b3c]

_main()
[00000bda](01) 55 push ebp
[00000bdb](02) 8bec mov ebp,esp
[00000bdd](01) 51 push ecx
[00000bde](05) 681a0b0000 push 00000b1a // push address of P
[00000be3](05) 681a0b0000 push 00000b1a // push address of P
[00000be8](05) e85dfdffff call 0000094a // call H
[00000bed](03) 83c408 add esp,+08
[00000bf0](03) 8945fc mov [ebp-04],eax
[00000bf3](03) 8b45fc mov eax,[ebp-04]
[00000bf6](01) 50 push eax
[00000bf7](05) 683b030000 push 0000033b
[00000bfc](05) e869f7ffff call 0000036a
[00000c01](03) 83c408 add esp,+08
[00000c04](02) 33c0 xor eax,eax
[00000c06](02) 8be5 mov esp,ebp
[00000c08](01) 5d pop ebp
[00000c09](01) c3 ret
Size in bytes:(0048) [00000c09]

Columns
(1) Machine address of instruction
(2) Machine address of top of stack
(3) Value of top of stack after instruction executed
(4) Machine language bytes
(5) Assembly language text
===============================
....[00000bda][00101647][00000000](01) 55 push ebp
....[00000bdb][00101647][00000000](02) 8bec mov ebp,esp
....[00000bdd][00101643][00000000](01) 51 push ecx
....[00000bde][0010163f][00000b1a](05) 681a0b0000 push 00000b1a //
push P
....[00000be3][0010163b][00000b1a](05) 681a0b0000 push 00000b1a //
push P
....[00000be8][00101637][00000bed](05) e85dfdffff call 0000094a //
call H

Begin Local Halt Decider Simulation at Machine Address:b1a
....[00000b1a][002116e7][002116eb](01) 55 push ebp
....[00000b1b][002116e7][002116eb](02) 8bec mov ebp,esp
....[00000b1d][002116e3][002016b7](01) 51 push ecx
....[00000b1e][002116e3][002016b7](03) 8b4508 mov eax,[ebp+08]
....[00000b21][002116df][00000b1a](01) 50 push eax //
push P
....[00000b22][002116df][00000b1a](03) 8b4d08 mov ecx,[ebp+08]
....[00000b25][002116db][00000b1a](01) 51 push ecx //
push P
....[00000b26][002116d7][00000b2b](05) e81ffeffff call 0000094a //
call H
....[00000b1a][0025c10f][0025c113](01) 55 push ebp
....[00000b1b][0025c10f][0025c113](02) 8bec mov ebp,esp
....[00000b1d][0025c10b][0024c0df](01) 51 push ecx
....[00000b1e][0025c10b][0024c0df](03) 8b4508 mov eax,[ebp+08]
....[00000b21][0025c107][00000b1a](01) 50 push eax //
push P
....[00000b22][0025c107][00000b1a](03) 8b4d08 mov ecx,[ebp+08]
....[00000b25][0025c103][00000b1a](01) 51 push ecx //
push P
....[00000b26][0025c0ff][00000b2b](05) e81ffeffff call 0000094a //
call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

In the above 16 instructions of the simulation of P(P) we can see that
the first 8 instructions of P are repeated. The end of this sequence of
8 instructions P calls H with its own machine address as the parameters
to H: H(P,P). Because H only examines the behavior of its inputs and
ignores its own behavior when H(P,P) is called we only see the first
instruction of P being simulated.

Anyone knowing the x86 language well enough can see that none of these 8
simulated instructions of P have any escape from their infinitely
repeating behavior pattern. When H recognizes this infinitely repeating
pattern it aborts its simulation of P(P) and reports that its input:
(P,P) would never halt on its input.

> If your H *emulates* P, it should not contain a call to P. It should
> contain a call to some function EMULATE with some description of P
> (either a file or a memory location) as an *argument* to that function.
> If that P includes an H which also emulates its input, there should be a
> second call to EMULATE, meaning we should have one instance of the
> emulator running on the actual hardware, and a second instance of the
> emulator being interpreted by the first emulator rather than being run
> on the actual hardware, and with a second instance of P being
> interpreted by that emulated emulator rather than either the hardware or
> the emulator which is running directly on the hardware.
>
> But this is not what appears to be happening in either your traces or
> your code fragments.
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/4/2021 11:31 AM, André G. Isaak wrote:
> On 2021-07-04 08:15, olcott wrote:
>> On 7/4/2021 1:50 AM, André G. Isaak wrote:
>>> On 2021-07-03 22:18, olcott wrote:
>>>> On 7/3/2021 11:14 PM, André G. Isaak wrote:
>>>>> On 2021-07-03 19:38, olcott wrote:
>>>>>> On 7/3/2021 8:14 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-03 14:37, olcott wrote:
>>>>>>>
>>>>>>>> It can always ignore it own behavior and it can do this by
>>>>>>>> screening out machine address ranges to be ignored. H ignores
>>>>>>>> all of its own behavior and the behavior or every operating
>>>>>>>> system function.
>>>>>>>
>>>>>>> And in what universe does it make sense to simply ignore
>>>>>>> operating system functions?
>>>>>>
>>>>>> When making a halt deciding function it only makes sense to keep
>>>>>> track of those aspects of computations that can cause the input to
>>>>>> halt.
>>>>>
>>>>> And what on earth would lead you to believe that a system call
>>>>> could have no impact on halting?
>>>>>
>>>>> (You conveniently skipped the example I gave.)
>>>>>
>>>>> André
>>>>>
>>>>
>>>> I am the only author of the entire x86utm operating system and all
>>>> of its functions.
>>>
>>> And we're just supposed to take your word for it that these can
>>> legitimately be ignored?
>>>
>>> Given that you've claimed that the instance of H called from within P
>>> doesn't affect halting when it clearly does, your word isn't going to
>>> carry much weight here.
>>>
>>
>> No instance of any H has any effect on any P until some P proves that
>> it will never halt unless aborted. This has always been able to be
>> directly verified by the assembly language execution trace of P
>> relative to its assembly language source code.
>
> P doesn't "prove" anything. It's the copy of H embedded in P that makes
> the determination. And once it makes this determination it *does* affect
> the behaviour.
>

Every H only acts as a pure x86 emulator until some P has demonstrated
that it will never halt unless it is aborted.

Once it is fully understood that any computation that never halts
unless its simulation is aborted is the correct non-halting criteria
then it can be understood that H(P,P)==0 correct.

It can be easily verified that if no H ever aborts any P that P(P) will
never halt. If any H must abort any P then this H does correctly decide
that this P does not halt.

> So what you're saying essentially is that H doesn't affect the behaviour
> of P until it does. Which means that H *can* affect the behaviour of P.
> Which means the code of H must be included in your analysis.
>

While H is analyzing the behavior of P it has no effect what-so-ever on
the behavior of P. H only has an effect on the behavior of P after P has
proven that it will never halt unless aborted.

> And note that your previous phraseology, that "H behaves as a pure
> simulator until it decides that there is infinite recursion" (or
> something to that effect) is misleading.
>
> A "pure simulator" would be one that simply simulates its input. It
> doesn't do other things like try to determine whether a given input
> matches one of your "patterns". So unless it is your claim that H

It is functionally equivalent to a pure simulator in that it has no
effect what-so-ever on the behavior of its input.

> doesn't attempt to determine whether its input matches one of these
> patterns until after it determines that one of these patterns is matches
> (an obviously nonsensical claim), your H does *not* act as a pure
> simulator either before or after it detects recursion. Prior to
> detecting this recursion it is still performing tests, and those tests
> will include conditional branches of exactly the same sort that are
> relevant to your 'infinite recursion pattern'. You can't simply skip
> over these tests as if they didn't matter since it's these exact tests
> that *prevent* infinite recursion from actually occuring.
>

I can skip over those tests knowing that they will have no effect on the
behavior of the input until after the input has proven beyond all
possibly doubt that it will never halt unless aborted.

>
>> This has been available posted directly in this forum since
>> On 3/14/2021 12:46 PM, olcott wrote:
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>>> If it really were the case that these things didn't have any affect
>>> on halting, then it would also be perfectly fine for your halt
>>> decider to *not* skip this code in its analysis, and that would avoid
>>> objections
>>
>> Most importantly you can easily verify for yourself that P is
>> accurately simulated by comparing its x86 source code to its x86
>> execution trace.
>
> Nothing can be verified from a *partial* trace which is all you have
> given.

It can be easily verified that the trace is complete (up to its point of
infinite execution) by comparing the trace to the assembly language
source-code of P. That this has been continuously available since March
and no one bothered to look at it indicates one of two things:

(1) The reviewers do not understand the x86 language.

(2) The reviewers do not care about what the truth is. They are only
interested in providing rebuttals even if I am correct.

> But even your partial trace is sufficient to recognize that your
> H's underlying logic is flawed since it skips critical portions of the
> code.
>

Because H acts as a simulator and thus has no effect on the execution of
its input until after its input has proven that it will never halt
unless aborted H can correctly ignore its own behavior in this execution
trace.

>> That no one has bothered to do this since March 14 would seem to
>> indicate that no one here knows assembly language besides me.
>
> Lots of people here know assembly language. I suspect that many people
> here know it far better than you do.
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/4/2021 1:24 PM, Malcolm McLean wrote:
> On Sunday, 4 July 2021 at 15:15:46 UTC+1, olcott wrote:
>> On 7/4/2021 1:50 AM, André G. Isaak wrote:
>>> On 2021-07-03 22:18, olcott wrote:
>>>> On 7/3/2021 11:14 PM, André G. Isaak wrote:
>>>>> On 2021-07-03 19:38, olcott wrote:
>>>>>> On 7/3/2021 8:14 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-03 14:37, olcott wrote:
>>>>>>>
>>>>>>>> It can always ignore it own behavior and it can do this by
>>>>>>>> screening out machine address ranges to be ignored. H ignores all
>>>>>>>> of its own behavior and the behavior or every operating system
>>>>>>>> function.
>>>>>>>
>>>>>>> And in what universe does it make sense to simply ignore operating
>>>>>>> system functions?
>>>>>>
>>>>>> When making a halt deciding function it only makes sense to keep
>>>>>> track of those aspects of computations that can cause the input to
>>>>>> halt.
>>>>>
>>>>> And what on earth would lead you to believe that a system call could
>>>>> have no impact on halting?
>>>>>
>>>>> (You conveniently skipped the example I gave.)
>>>>>
>>>>> André
>>>>>
>>>>
>>>> I am the only author of the entire x86utm operating system and all of
>>>> its functions.
>>>
>>> And we're just supposed to take your word for it that these can
>>> legitimately be ignored?
>>>
>>> Given that you've claimed that the instance of H called from within P
>>> doesn't affect halting when it clearly does, your word isn't going to
>>> carry much weight here.
>>>
>> No instance of any H has any effect on any P until some P proves that it
>> will never halt unless aborted. This has always been able to be directly
>> verified by the assembly language execution trace of P relative to its
>> assembly language source code.
>>
>> This has been available posted directly in this forum since
>> On 3/14/2021 12:46 PM, olcott wrote:
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>> If it really were the case that these things didn't have any affect on
>>> halting, then it would also be perfectly fine for your halt decider to
>>> *not* skip this code in its analysis, and that would avoid objections
>> Most importantly you can easily verify for yourself that P is accurately
>> simulated by comparing its x86 source code to its x86 execution trace.
>>
>> That no one has bothered to do this since March 14 would seem to
>> indicate that no one here knows assembly language besides me.
>>
>> I have proven that H has no effect on its input since March 13 and the
>> 16 lines of execution trace of the input proved to be totally
>> overwhelming for everyone here. Adding 26,000 lines of more code would
>> not help.
>>
> The execution trace showed two calls to the "halts" subroutine.
> However it was stated that "halts" is a simulating decider. Therefore we
> have one call to halts. It then emulates another call to halts. But the
> second call to "halts" shouldn't appear on the execution trace. It's emulated.
>
> So exactly what the decider is doing remains a bit opaque.
>

Software emulators have all of the details of subordinate emulations as
their own data. H makes sure to ignore every address of itself and all
operating system functions because neither OS functions nor itself have
any effect on the behavior of the input while the input is being simulated.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/5/2021 6:21 AM, Richard Damon wrote:
> On 7/4/21 9:57 PM, olcott wrote:
>> On 7/4/2021 11:46 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/3/2021 7:23 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/3/2021 3:20 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>         void P(u32 x)
>>>>>>>>>>         {
>>>>>>>>>>           u32 Input_Halts = H(x, x);
>>>>>>>>>>           if (Input_Halts)
>>>>>>>>>>             HERE: goto HERE;
>>>>>>>>>>         }
>>>>>>>>> For H(P,P) to be correct one of these must apply:
>>>>>>>>>
>>>>>>>>>       H(P,P) == 0 and P(P) does not halt, or
>>>>>>>>>       H(P,P) != 0 and P(P) halts.
>>>>>>>>>
>>>>>>>>> Neither is the case.
>>>>>>>>
>>>>>>>> Superficially it may seem that way until you realize (as you have
>>>>>>>> already realized) that the halt criteria must be adapted for a
>>>>>>>> simulating halt decider.
>>>>>>>>
>>>>>>> The two criteria I gave are for the halting problem.  No one is
>>>>>>> interested in your "other kind of halting".  It seems you agree
>>>>>>> that H
>>>>>>> is wrong about the input given above as far as the criterion of
>>>>>>> actual
>>>>>>> halting goes.
>>>>>>
>>>>>> Because a simulating halt decider must always abort the simulation of
>>>>>> every input that never halts its halt deciding criteria must be
>>>>>> adapted.
>>>>> If you "adapted" the criterion for being a prime number you could
>>>>> "refute" many more theorems.
>>>>
>>>> You already agreed that this adaptation of the halt status criteria is
>>>> correct:
>>>
>>> A halting computation is one that halts.  There is no other criterion.
>>> I can't believe this needs to be said.
>>>
>>
>> void Infinite_Loop()
>> {
>>   HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>   u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
>>   Output("Input_Would_Halt2 = ", Input_Would_Halt2);
>> }
>>
>> Then Infinite_Loop() is a halting computation on the basis that H aborts
>> its simulation of Infinite_Loop().
>>
>
> No, it doesn't. It says that H(Infinite_Loop, Infinite_Loop) might be a
> halting computation, but since when you run Infinite_Loop() itself, it
> doesn't halt, it isn't a halting computation.
>
> The Halting Decider aborting the simulation of a machine does NOT make
> the simulated machine halting, (nor does show it to be non-halting), as
> the machine never halted. ('Aborting the simultion of' != Halting)
>

Every H only acts as a pure x86 emulator until some P has demonstrated
that it will never halt unless it is aborted.

Once it is fully understood that any computation that never halts unless
its simulation is aborted is the correct non-halting criteria then it
can be understood that H(P,P)==0 correct.

It can be easily verified that if no H ever aborts any P that P(P) will
never halt. If any H must abort any P then this H does correctly decide
that this P does not halt.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/5/2021 7:05 AM, Richard Damon wrote:
> On 7/4/21 9:42 PM, olcott wrote:
>> On 7/4/2021 8:03 PM, dklei...@gmail.com wrote:
>>> On Sunday, July 4, 2021 at 1:55:27 PM UTC-7, André G. Isaak wrote:
>>>> On 2021-07-04 14:09, olcott wrote:
>>>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>>>
>>>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>>>> However it was stated that "halts" is a simulating decider.
>>>>>>> Therefore we
>>>>>>> have one call to halts. It then emulates another call to halts.
>>>>>>> But the
>>>>>>> second call to "halts" shouldn't appear on the execution trace. It's
>>>>>>> emulated.
>>>>>>>
>>>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>>>
>>>>>> I've tried to get Olcott to clarify exactly what he means by
>>>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
>>>>>> what the rest of the world means, but I still am unclear about what he
>>>>>> actually means.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Sure everyone knows that an x86 emulator can be anything from a vanilla
>>>>> milkshake machine to a dump truck. What I mean by x86 emulator is
>>>>> software that executes x86 machine language as if this software virtual
>>>>> machine was an actual x86 processor.
>>>> The problem is that you keep talking about 'nested simulations' but
>>>> there's absolutely nothing in your code or your traces to suggest more
>>>> than a single level of emulation is involved.
>>>>
>>>> If your H *emulates* P, it should not contain a call to P. It should
>>>> contain a call to some function EMULATE with some description of P
>>>> (either a file or a memory location) as an *argument* to that function.
>>>> If that P includes an H which also emulates its input, there should be a
>>>> second call to EMULATE, meaning we should have one instance of the
>>>> emulator running on the actual hardware, and a second instance of the
>>>> emulator being interpreted by the first emulator rather than being run
>>>> on the actual hardware, and with a second instance of P being
>>>> interpreted by that emulated emulator rather than either the hardware or
>>>> the emulator which is running directly on the hardware.
>>>>
>>>> But this is not what appears to be happening in either your traces or
>>>> your code fragments.
>>>> André
>>>   I think everyone agrees that PO's x86 work will never be accepted by
>>> any
>>> scholarly journal. Shouldn't we be trying to avoid using it.
>>>
>>> For starters we need a clear statement as to what is being proved
>>> complete
>>> with all the definitions a journal will require.
>>>
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> void P(u32 x)
>> {
>>   u32 Input_Halts = H(x, x);
>>   if (Input_Halts)
>>     HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>   u32 Input_Halts = H((u32)P, (u32)P);
>>   Output("Input_Halts = ", Input_Halts);
>> }
>>
>> I have proved that H correctly decides that P is a non-halting
>> computation on the basis that P calls H in infinitely nested simulation.
>> Computer scientists might notice that H and P are in their proper
>> halting problem relation to each other.
>>
>
> No, you haven't, because the scenerio you describe only happes if H is
> programmed never to abort the P that is built from it, in which case
> H(P,P) never answers, and thus deosn't need to be disproved, it did a
> good enough job at doing that itself.

Every H only acts as a pure x86 emulator until some P has demonstrated
that it will never halt unless it is aborted.

Once it is fully understood that any computation that never halts unless
its simulation is aborted is the correct non-halting criteria then it
can be understood that H(P,P)==0 correct.

It can be easily verified that if no H ever aborts any P that P(P) will
never halt. If any H must abort any P then this H does correctly decide
that this P does not halt.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/5/2021 9:18 AM, Malcolm McLean wrote:
> On Monday, 5 July 2021 at 14:23:35 UTC+1, olcott wrote:
>> On 7/4/2021 3:30 PM, Malcolm McLean wrote:
>>> On Sunday, 4 July 2021 at 21:09:27 UTC+1, olcott wrote:
>>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>>
>>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>>> However it was stated that "halts" is a simulating decider. Therefore we
>>>>>> have one call to halts. It then emulates another call to halts. But the
>>>>>> second call to "halts" shouldn't appear on the execution trace. It's
>>>>>> emulated.
>>>>>>
>>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>>
>>>>> I've tried to get Olcott to clarify exactly what he means by
>>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
>>>>> what the rest of the world means, but I still am unclear about what he
>>>>> actually means.
>>>>>
>>>>> André
>>>>>
>>>> Sure everyone knows that an x86 emulator can be anything from a vanilla
>>>> milkshake machine to a dump truck. What I mean by x86 emulator is
>>>> software that executes x86 machine language as if this software virtual
>>>> machine was an actual x86 processor.
>>>>
>>> What I understand by an emulator is something which spins up a virtual
>>> enviornment - a struct containing registers, an area of memory, and
>>> maybe other bits and bats. Then the core of the program is a switch on the
>>> opcode pointed to by the instruction pointer. It then manipulates the
>>> virtual environment in the same way as a real machine.
>>>
>> When the OS is Windows or Linux the whole infrastructure of an x86
>> emulator must be built from scratch. When the OS is an x86 emulator the
>> infrastructure already exists.
>>
> Normally an emulator doesn't grant emulated programs access to the OS. They
> run in their own little sandbox.

The entire OS is one big sandbox.

>>
>>> So if we see "call 0x12345678" we don't make a jump to address 12345678.
>>> Instead we go to the switch case that handles "call". This will push the
>>> virtual instruction pointer on to a stack, and set it to "12345678". Then on
>>> the next pass the virtual instruction pointer is "12345678" and we load the
>>> instruction at that address and switch on the opcode.
>>>
>> In the above case inside an x86 emulator a call to a function is simply
>> a call to a function.
>>
> In my understanding, a call in an emulated program is an emulated call.

Yes. There are 26,419 execution steps that are not shown.
None of these steps have any effect on the behavior of the input.
So far no one has fully understood the 33 steps that I have posted in
any of the many times that I have posted them in the last four months.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

> The emulator executes some code like "push current address on stack,
> set program counter to call address".
> SO there's something weird about your emulator.
>

Since no one here could begin to understand 33 steps it makes perfect
sense for the emulator to screen out all of the steps that cannot
possibly effect the behavior of its input. An extra 400 pages of
execution trace cannot possibly make my proof easier to understand.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/5/2021 12:49 PM, Mike Terry wrote:
> On 05/07/2021 06:20, Jeff Barnett wrote:
>> On 7/4/2021 7:03 PM, dklei...@gmail.com wrote:
>>> On Sunday, July 4, 2021 at 1:55:27 PM UTC-7, André G. Isaak wrote:
>>>> On 2021-07-04 14:09, olcott wrote:
>>>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>>>
>>>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>>>> However it was stated that "halts" is a simulating decider.
>>>>>>> Therefore we
>>>>>>> have one call to halts. It then emulates another call to halts.
>>>>>>> But the
>>>>>>> second call to "halts" shouldn't appear on the execution trace. It's
>>>>>>> emulated.
>>>>>>>
>>>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>>>
>>>>>> I've tried to get Olcott to clarify exactly what he means by
>>>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
>>>>>> what the rest of the world means, but I still am unclear about
>>>>>> what he
>>>>>> actually means.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Sure everyone knows that an x86 emulator can be anything from a
>>>>> vanilla
>>>>> milkshake machine to a dump truck. What I mean by x86 emulator is
>>>>> software that executes x86 machine language as if this software
>>>>> virtual
>>>>> machine was an actual x86 processor.
>>>> The problem is that you keep talking about 'nested simulations' but
>>>> there's absolutely nothing in your code or your traces to suggest more
>>>> than a single level of emulation is involved.
>>>>
>>>> If your H *emulates* P, it should not contain a call to P. It should
>>>> contain a call to some function EMULATE with some description of P
>>>> (either a file or a memory location) as an *argument* to that function.
>>>> If that P includes an H which also emulates its input, there should
>>>> be a
>>>> second call to EMULATE, meaning we should have one instance of the
>>>> emulator running on the actual hardware, and a second instance of the
>>>> emulator being interpreted by the first emulator rather than being run
>>>> on the actual hardware, and with a second instance of P being
>>>> interpreted by that emulated emulator rather than either the
>>>> hardware or
>>>> the emulator which is running directly on the hardware.
>>>>
>>>> But this is not what appears to be happening in either your traces or
>>>> your code fragments.
>>>> André
>>> I think everyone agrees that PO's x86 work will never be accepted by any
>>> scholarly journal. Shouldn't we be trying to avoid using it.
>>>
>>> For starters we need a clear statement as to what is being proved
>>> complete
>>> with all the definitions a journal will require.
>>
>> And why in hell should we bother to try and get a clear statement.
>
> Personally, I wouldn't, for the reasons you say below.  But I suspect DK
> is just saying that a clear statement is a pre-requisite for PO
> publishing, not that /we/ have some duty to try to get one from him,
> which would be quite fruitless.
>
>> The
>> idea that our ignoramus/troll will ever submit anything to a refereed
>> journal is fatuous. He will never acquire the ability to clearly
>> state, formulate, or prove any interesting conjecture. All he will
>> ever do, all he wants to do is participate in these ridiculous
>> dialogues; repeat, rewind, repeat again, and on and on. He enjoys
>> defeating every one of us even when he "acknowledges a flaw". Then he
>> rewinds, repeats and doesn't miss a beat never admitting the
>> acknowledgement nor retracting it. You cannot win this game because
>> he's in it for the game, not the outcome.
>
> I think PO /wants/ to do more than just argue here, and convinces
> himself that one day he will do that.  So he is not trolling (mostly),
> but is just severely Deluded.  His statements seem a bit like
> confabulation, where patients invent fantastical stories to cover gaps
> in their memories.  Those patients are not lying as such, they're just
> saying things which make sense to them.
>
> PO doesn't have a memory impairment as far as I can tell, but I wonder
> whether similar confabulation can occur when someone has an intellectual
> reasoning impairment: they invent "fantastical logic" to explain their
> unreasoned intuitions, without understanding that to other people those
> explanations are ridiculous.  (E.g. PO convincing himself that a
> computation that demonstrably halts is correctly classified as
> non-halting, because that was his first intuition before he actually
> tried it, and he can't abandon that intuition, which trumps any logic
> from other people.  (And apparently trumps reality in this case!))
>

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

int main()
{ P((u32)P);
}

If you weren't dumber than a box of rocks you would understand that the
above computation never halts unless it is aborted at some point.

The above statement assumes the context of this paper
(where H is a simulating halt decider based on an x86 emulator):

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

> Such a person simply wouldn't realise that other people are genuinely
> /reasoning logically/ about these abstract ideas, and that terms and
> phrases they use have precise technical meanings that the everyone else
> /understands/.  To such a person, it would seem that other people are
> just doing the same as them: half understanding stuff and spouting vague
> words and magical phrases to "prove" things, which is exactly what the
> logically impaired person is doing - so why does everyone take other
> peoples' proofs seriously but not theirs?  It must be quite frustrating!
>
> You're right that we can't "win" the PO "game", but that's alright - PO
> is harmless, and nobody should feel he needs to be "defeated".  And it's
> simply not possible IMO to genuinely /help/ him, so what needs to be
> done?  Er, nothing. :)
>
>
> Mike.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/5/2021 11:38 AM, Richard Damon wrote:
> On 7/5/21 10:35 AM, olcott wrote:
>
>> So then you are saying that when H aborts its simulation of
>> Infinite_Loop, Infinite_Loop continues to run even after H has aborted it.
>>
>
> You seem to not understand the fundamental principle of computation.
>
> When we run a computation, we can create a 'trace' of that execution and
> say something like:
>
> instruction 1: whatever instruction 1 is
> instruction 2: whatever instruction 2 is
>
> Computation when view like this work on a time scale of 'instructions'
>
> This computation only 'ends' when the computation hits its final 'Stop'
> statement, and halts.
>
> Thus when a simulator runs a simulation of the machine, it computes what
> step 1 is, then what step 2 is and so on.
>
> If the simulator stop simulating, then time just stopped for the
> computation. It doesn't 'continue to run' because, at least in that
> simulation, 'time' isn't moving any more, but neither has it 'halted',
> as that is defined as reaching the final STOP instruction. The
> compuation is just suspended, perhaps forever.
>
> It is important to define time this way for a computaiton or otherwise
> halting and non-halting becomes ill-defined.
>
> For instance, if you have a computation engine that slows down as clock
> time progresses, it is quite possible for a computation that will halt
> in a finite number of steps to never reach that point in finite clock
> time as the machine just never gets to executing that many steps.
>
> It is also possible to at least theoretically create a computation
> engine that speeds up as it goes, and that engine could compute
> something that takes 'infinite steps' to be computed in finite clock time.
>
> So, when H abort its simulation of Infinite_Loop, that machine is
> neither 'halted' or 'continues to run' but is a state of 'suspended in a
> running state'.

This is a very excellent summation of the difference between a
computation that halts and a computation that had its simulation
aborted. When you do say something that is clearly brilliant (to be
honest) I must point it out.

> Sort of like a program that calls the OS delay function
> but some how specified an infinite time.
>
> A second example, if you complain to a program vender that the program
> is stuck in an infinite loop, and when you demonstarte this to them,
> they shurt down your computer and say, 'See, the program's execution
> ended, it wasn't in an infinite loop', you aren't going to take that
> answer. Aborting the simulation or externally killing the execution of a
> program doesn't make a program that was non-halting halting. But it also
> doesn't prove that it WAS non-halting, as anyone lose information to a
> power outage can verify.
>
> You need to actually PROVE the non-halting, but you need to prove it
> with RIGHT logic, and that includes taking into account that the H
> inside P will abort its simulation and this can allow P to Halt. Failure
> to do this make your logic unsound.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/5/2021 5:58 PM, Ben Bacarisse wrote:
>
> olcott <NoOne@NoWhere.com> writes:
>
> | void P(u32 x)
> | {
> | u32 Input_Halts = H(x, x);
> | if (Input_Halts)
> | HERE: goto HERE;
> | }
>
>> Every computation that would never halt unless its simulation is
>> aborted is equally not a halting computation.
>
> For H(P,P) to be correct one of these must apply:
>
> H(P,P) == 0 and P(P) does not halt, or
> H(P,P) != 0 and P(P) halts.
>
> Neither is the case. Simple facts that you deny.
>

That the prefix to infinitely nested simulation halts because its suffix
is aborted cannot reasonably be construed as a computation that halts in
the same way that that following computation can be construed as a
computation that halts:

int Add(int N, int M)
{ return N + M;
}

That every aspect of the following computation can be classified as a
computation that never halts unless its simulation is aborted
unequivocally places it in the non-halting category.

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

Every computation that never halts unless is simulation is aborted
defines the exact same set of non-halting computations as the halting
problem, except for the halting problem counter-example templates.

Because it defines the exact same halting and non-halting set of
computations as the halting problem it is proved to be an equivalent
criterion measure.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/5/2021 9:35 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/5/2021 5:58 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>> | void P(u32 x)
>>> | {
>>> | u32 Input_Halts = H(x, x);
>>> | if (Input_Halts)
>>> | HERE: goto HERE;
>>> | }
>>>
>>>> Every computation that would never halt unless its simulation is
>>>> aborted is equally not a halting computation.
>>>
>>> For H(P,P) to be correct one of these must apply:
>>> H(P,P) == 0 and P(P) does not halt, or
>>> H(P,P) != 0 and P(P) halts.
>>> Neither is the case. Simple facts that you deny.
>>>
>>
>> That the prefix to infinitely nested simulation halts because its
>> suffix is aborted cannot reasonably be construed as a computation that
>> halts in the same way that that following computation can be construed
>> as a computation that halts:
>>
>> int Add(int N, int M)
>> {
>> return N + M;
>> }
>
> You are welcome to think that different computations halt in different
> ways. However, a computation that halts, for whatever reason, is a
> halting computation. P(P) halts, so H(P,P) == 0 is wrong.
>

H(P,P) == 0 is axiomatically correct thus impossibly incorrect.

If all X's are Y and all Y's are Z then all X's are Z even if you really
really hate it and even if it really really seems to form a direct
contradiction.

>> Every computation that never halts unless is simulation is aborted
>> defines the exact same set of non-halting computations as the halting
>> problem, except for the halting problem counter-example templates.
>
> Yes, H(P,P) == 0 is wrong if P(P) halts. As you have defined it, the
> POOH ("PO Other-Halting") problem is also undecidable, but that's just
> way over your head right now, despite the fact you keep quoting me
> saying that.
>

Once you understand that H(P,P) == 0 is axiomatically correct thus
impossibly incorrect, then you see that the fact that P(P) halts cannot
possibly be a contradiction.

The view that H(P,P) == 0 is not correct requires the view that in some
cases where UTM(P,I) never halts P(I) does halt.

Since we know that every case where UTM(P,I) never halts logically
entails that P(I) never halts we know that when the pure x86 emulation
of (P,I) never halts that this logically entails that the x86 execution
of P(I) never halts.

Since we know that H acts as a pure x86 emulator until it detects that
its input would never halt unless aborted then H can always ignore its
own address range when it is making its halt status decision.

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

Because we can see that the execution trace of P on input P provides no
escape from its infinitely nested simulation we can know that H must
abort its simulation of (P,P).

int main()
{ P((u32)P);
}

The fact that the above computation never halts unless some H aborts
some P (in the nested simulation) proves that this H that aborted that P
was correct.

>> Because it defines the exact same halting and non-halting set of
>> computations as the halting problem it is proved to be an equivalent
>> criterion measure.
>
> You just said they are not the same sets. You have given an explicit
> example where they differ: P(P) halts but is non-POOH. I don't think
> you are coping very well. I think you should take a break.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein