I spent two years creating the x86utm operating system to concretely
address the halting problem using a halt decider written in C. Partial
halt decider H bases is halting decision on simulating its input.

The partial halt decider H invokes an x86 emulator to execute its input
D in debug step mode. The input is the machine address of the input x86
function cast to a 32-bit unsigned integer. H examines the complete
execution trace of D immediately after each x86 instruction of D is
simulated.

#define machine_address uint32_t

int D(u32 P)
{ if ( H(P, P) )
return 0;
return 1;
}

int main()
{ u32 Input_Would_Halt = H((u32)D, (u32)D);
Output("H(D,D) Would_Halt = ", Input_Would_Halt );
}

_D()
[00000cfc](01) 55 push ebp
[00000cfd](02) 8bec mov ebp,esp
[00000cff](03) 8b4508 mov eax,[ebp+08]
[00000d02](01) 50 push eax
[00000d03](03) 8b4d08 mov ecx,[ebp+08]
[00000d06](01) 51 push ecx
[00000d07](05) e800feffff call 00000b0c
[00000d0c](03) 83c408 add esp,+08
[00000d0f](02) 85c0 test eax,eax
[00000d11](02) 7404 jz 00000d17
[00000d13](02) 33c0 xor eax,eax
[00000d15](02) eb05 jmp 00000d1c
[00000d17](05) b801000000 mov eax,00000001
[00000d1c](01) 5d pop ebp
[00000d1d](01) c3 ret
Size in bytes:(0034) [00000d1d]

_main()
[00000d2c](01) 55 push ebp
[00000d2d](02) 8bec mov ebp,esp
[00000d2f](01) 51 push ecx
[00000d30](05) 68fc0c0000 push 00000cfc
[00000d35](05) 68fc0c0000 push 00000cfc
[00000d3a](05) e8cdfdffff call 00000b0c
[00000d3f](03) 83c408 add esp,+08
[00000d42](03) 8945fc mov [ebp-04],eax
[00000d45](03) 8b45fc mov eax,[ebp-04]
[00000d48](01) 50 push eax
[00000d49](05) 68c7030000 push 000003c7
[00000d4e](05) e8a9f6ffff call 000003fc
[00000d53](03) 83c408 add esp,+08
[00000d56](02) 33c0 xor eax,eax
[00000d58](02) 8be5 mov esp,ebp
[00000d5a](01) 5d pop ebp
[00000d5b](01) c3 ret
Size in bytes:(0048) [00000d5b]

Columns
(1) Execution trace sequence number
(2) Machine address of instruction
(3) Machine address of top of stack
(4) Value of top of stack after instruction executed
(5) Number of bytes of machine code
(6) Machine language bytes
(7) Assembly language text

===============================
....[00000d2c][00101799][00000000](01) 55 push ebp
....[00000d2d][00101799][00000000](02) 8bec mov ebp,esp
....[00000d2f][00101795][00000000](01) 51 push ecx
....[00000d30][00101791][00000cfc](05) 68fc0c0000 push 00000cfc
....[00000d35][0010178d][00000cfc](05) 68fc0c0000 push 00000cfc
....[00000d3a][00101789][00000d3f](05) e8cdfdffff call 00000b0c
Begin Local Halt Decider Simulation at Machine Address:cfc
....[00000cfc][00211839][0021183d](01) 55 push ebp
....[00000cfd][00211839][0021183d](02) 8bec mov ebp,esp
....[00000cff][00211839][0021183d](03) 8b4508 mov
eax,[ebp+08]
....[00000d02][00211835][00000cfc](01) 50 push eax
....[00000d03][00211835][00000cfc](03) 8b4d08 mov
ecx,[ebp+08]
....[00000d06][00211831][00000cfc](01) 51 push ecx
....[00000d07][0021182d][00000d0c](05) e800feffff call 00000b0c
....[00000cfc][0025c261][0025c265](01) 55 push ebp
....[00000cfd][0025c261][0025c265](02) 8bec mov ebp,esp
....[00000cff][0025c261][0025c265](03) 8b4508 mov
eax,[ebp+08]
....[00000d02][0025c25d][00000cfc](01) 50 push eax
....[00000d03][0025c25d][00000cfc](03) 8b4d08 mov
ecx,[ebp+08]
....[00000d06][0025c259][00000cfc](01) 51 push ecx
....[00000d07][0025c255][00000d0c](05) e800feffff call 00000b0c
Local Halt Decider: Infinitely Nested Simulation Detected Simulation
Stopped
....[00000d3f][00101795][00000000](03) 83c408 add esp,+08
....[00000d42][00101795][00000000](03) 8945fc mov
[ebp-04],eax
....[00000d45][00101795][00000000](03) 8b45fc mov
eax,[ebp-04]
....[00000d48][00101791][00000000](01) 50 push eax
....[00000d49][0010178d][000003c7](05) 68c7030000 push 000003c7
---[00000d4e][0010178d][000003c7](05) e8a9f6ffff call 000003fc
H(D,D) Would_Halt = 0
....[00000d53][00101795][00000000](03) 83c408 add esp,+08
....[00000d56][00101795][00000000](02) 33c0 xor eax,eax
....[00000d58][00101799][00000000](02) 8be5 mov esp,ebp
....[00000d5a][0010179d][00100000](01) 5d pop ebp
....[00000d5b][001017a1][00000078](01) c3 ret
Number_of_User_Instructions(31)
Number of Instructions Executed(23833)

[infinitely_nested_simulation] non-halting behavior pattern for H(D, D)
(a) Partial halt decider H called twice in sequence from the same
machine address of D.
The calls to the partial halt decider are on lines 13 and 20.
The same block of code from 07 to 13 immediately repeats from 14
to 20.
(b) With the same machine address parameters of D to H.
It can be verified that both calls to H send the machine address
of D as input to H.
The call to H at 13 is preceded by a pair of push instructions at
10,12.
The call to H at 20 is preceded by a pair of push instructions at
17,19.
That this is the machine address of D is verified by column(4) of
lines (10,12,17,19)
(c) With no conditional branch or indexed jump instructions in D.
No conditional branch or indexed jump instructions on execution
trace lines 07 to 20.

Is the return value of 0 from H to Input_Would_Halt in main() correct?

This question can be answered on the basis of whether or not the above
criteria is sufficiently complete and correct and correctly applied to
the provided complete execution trace of D.

--
Copyright 2021 Pete Olcott

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

On 5/29/21 3:26 PM, olcott wrote:

> [infinitely_nested_simulation] non-halting behavior pattern for H(D, D)
> (a) Partial halt decider H called twice in sequence from the same
> machine address of D.
>      The calls to the partial halt decider are on lines 13 and 20.
>      The same block of code from 07 to 13 immediately repeats from 14 to
> 20.
> (b) With the same machine address parameters of D to H.
>       It can be verified that both calls to H send the machine address
> of D as input to H.
>       The call to H at 13 is preceded by a pair of push instructions at
> 10,12.
>       The call to H at 20 is preceded by a pair of push instructions at
> 17,19.
>       That this is the machine address of D is verified by column(4) of
> lines (10,12,17,19)
> (c) With no conditional branch or indexed jump instructions in D.
>       No conditional branch or indexed jump instructions on execution
> trace lines 07 to 20.
>
> Is the return value of 0 from H to Input_Would_Halt in main() correct?
>
> This question can be answered on the basis of whether or not the above
> criteria is sufficiently complete and correct and correctly applied to
> the provided complete execution trace of D.
>

Since your traces do NOT include the code of the Decider, the criteria
of 'no conditional' is applied incorrectly.

The concept of replacing simulated code with the code does NOT apply
when the simulator is a decider unless you include in you analysis that
the simulation might not happen, which you fail to do.

On 5/29/21 3:49 PM, Richard Damon wrote:
> On 5/29/21 3:26 PM, olcott wrote:
>
>> [infinitely_nested_simulation] non-halting behavior pattern for H(D, D)
>> (a) Partial halt decider H called twice in sequence from the same
>> machine address of D.
>>      The calls to the partial halt decider are on lines 13 and 20.
>>      The same block of code from 07 to 13 immediately repeats from 14 to
>> 20.
>> (b) With the same machine address parameters of D to H.
>>       It can be verified that both calls to H send the machine address
>> of D as input to H.
>>       The call to H at 13 is preceded by a pair of push instructions at
>> 10,12.
>>       The call to H at 20 is preceded by a pair of push instructions at
>> 17,19.
>>       That this is the machine address of D is verified by column(4) of
>> lines (10,12,17,19)
>> (c) With no conditional branch or indexed jump instructions in D.
>>       No conditional branch or indexed jump instructions on execution
>> trace lines 07 to 20.
>>
>> Is the return value of 0 from H to Input_Would_Halt in main() correct?
>>
>> This question can be answered on the basis of whether or not the above
>> criteria is sufficiently complete and correct and correctly applied to
>> the provided complete execution trace of D.
>>
>
> Since your traces do NOT include the code of the Decider, the criteria
> of 'no conditional' is applied incorrectly.
>
> The concept of replacing simulated code with the code does NOT apply
> when the simulator is a decider unless you include in you analysis that
> the simulation might not happen, which you fail to do.
>

Prehaps another way to explain it is that by the REAL definition of
Halting, if Machine D uses sub-machine H to decide on an input, that
just happens to match D, and H decides that the simulation is getting
unending and returns the non-halting answer, and D then Halts, this IS
make D a non-Halting Computation. PERIOD. As that is what it did.

There is no grounds to argue that H didn't have any other choice but to
do that, as H is what H is, so it will do what it will do. The fact that
there is no 'right' answer that H can return doesn't justify changing
the definition of Halting for this sort of case, it just means that this
sort of case can't be correctly decided by the decider used by D.

On 5/29/2021 2:49 PM, Richard Damon wrote:
> On 5/29/21 3:26 PM, olcott wrote:
>
>> [infinitely_nested_simulation] non-halting behavior pattern for H(D, D)
>> (a) Partial halt decider H called twice in sequence from the same
>> machine address of D.
>>      The calls to the partial halt decider are on lines 13 and 20.
>>      The same block of code from 07 to 13 immediately repeats from 14 to
>> 20.
>> (b) With the same machine address parameters of D to H.
>>       It can be verified that both calls to H send the machine address
>> of D as input to H.
>>       The call to H at 13 is preceded by a pair of push instructions at
>> 10,12.
>>       The call to H at 20 is preceded by a pair of push instructions at
>> 17,19.
>>       That this is the machine address of D is verified by column(4) of
>> lines (10,12,17,19)
>> (c) With no conditional branch or indexed jump instructions in D.
>>       No conditional branch or indexed jump instructions on execution
>> trace lines 07 to 20.
>>
>> Is the return value of 0 from H to Input_Would_Halt in main() correct?
>>
>> This question can be answered on the basis of whether or not the above
>> criteria is sufficiently complete and correct and correctly applied to
>> the provided complete execution trace of D.
>>
>
> Since your traces do NOT include the code of the Decider, the criteria
> of 'no conditional' is applied incorrectly.
>

Not at all. The problem is always the same.
You don't respond to the words that I am actually saying:

Re: Would the simulation of D be infinitely nested unless simulating
partial halt decider H terminated its simulation of D?

If you can stay laser focused on exactly those words in your reply to
them I may quit ignoring your posts.

--
Copyright 2021 Pete Olcott

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

On 5/29/21 4:18 PM, olcott wrote:
> On 5/29/2021 2:49 PM, Richard Damon wrote:
>> On 5/29/21 3:26 PM, olcott wrote:
>>
>>> [infinitely_nested_simulation] non-halting behavior pattern for H(D, D)
>>> (a) Partial halt decider H called twice in sequence from the same
>>> machine address of D.
>>>       The calls to the partial halt decider are on lines 13 and 20.
>>>       The same block of code from 07 to 13 immediately repeats from
>>> 14 to
>>> 20.
>>> (b) With the same machine address parameters of D to H.
>>>        It can be verified that both calls to H send the machine address
>>> of D as input to H.
>>>        The call to H at 13 is preceded by a pair of push instructions at
>>> 10,12.
>>>        The call to H at 20 is preceded by a pair of push instructions at
>>> 17,19.
>>>        That this is the machine address of D is verified by column(4) of
>>> lines (10,12,17,19)
>>> (c) With no conditional branch or indexed jump instructions in D.
>>>        No conditional branch or indexed jump instructions on execution
>>> trace lines 07 to 20.
>>>
>>> Is the return value of 0 from H to Input_Would_Halt in main() correct?
>>>
>>> This question can be answered on the basis of whether or not the above
>>> criteria is sufficiently complete and correct and correctly applied to
>>> the provided complete execution trace of D.
>>>
>>
>> Since your traces do NOT include the code of the Decider, the criteria
>> of 'no conditional' is applied incorrectly.
>>
>
> Not at all. The problem is always the same.
> You don't respond to the words that I am actually saying:
>
> Re: Would the simulation of D be infinitely nested unless simulating
> partial halt decider H terminated its simulation of D?
>
> If you can stay laser focused on exactly those words in your reply to
> them I may quit ignoring your posts.
>

Since you start by using the term 'Halting', which has a PRECISE d4finition.

You ask if the return value is correct.

Based on the REAL definition of Halting, it is not.

Doesn't matter how many other weasle words you use, it isn't the right
answer for HALTING.

Maybe for some other condition, but you need to use other words to
describe it.

If you want to ask about apparent infinite nesting, ask about just that,
and DON'T make ANY mention about halting in your terminology.

Yes, you might be right to say that 0 is the right answer to "Would D be
infinitely recursive if NO copy of H terminates some simulation of D?"

Trying to equate this question with Halting is incorrect. As it isn't

Since you have PROVED that you will misuse responses, I will point out
errors to where you seem to be headed.

I will also add, that even if we 'accept' your statement, it still is
NOT a 'Proof', as proofs are based on, as they say, actually PROVING
what you are saying from truly fundamental definitions, which your
statement isn't (the fact you have to ask is evidence of that). If you
could provide proof of that statement, you wouldn't need to ask, but you
don't seem to know how to actually prove anything.

On Saturday, May 29, 2021 at 4:18:19 PM UTC-4, olcott wrote:
> On 5/29/2021 2:49 PM, Richard Damon wrote:
> > On 5/29/21 3:26 PM, olcott wrote:
> >
> >> [infinitely_nested_simulation] non-halting behavior pattern for H(D, D)
> >> (a) Partial halt decider H called twice in sequence from the same
> >> machine address of D.
> >> The calls to the partial halt decider are on lines 13 and 20.
> >> The same block of code from 07 to 13 immediately repeats from 14 to
> >> 20.
> >> (b) With the same machine address parameters of D to H.
> >> It can be verified that both calls to H send the machine address
> >> of D as input to H.
> >> The call to H at 13 is preceded by a pair of push instructions at
> >> 10,12.
> >> The call to H at 20 is preceded by a pair of push instructions at
> >> 17,19.
> >> That this is the machine address of D is verified by column(4) of
> >> lines (10,12,17,19)
> >> (c) With no conditional branch or indexed jump instructions in D.
> >> No conditional branch or indexed jump instructions on execution
> >> trace lines 07 to 20.
> >>
> >> Is the return value of 0 from H to Input_Would_Halt in main() correct?
> >>
> >> This question can be answered on the basis of whether or not the above
> >> criteria is sufficiently complete and correct and correctly applied to
> >> the provided complete execution trace of D.
> >>
> >
> > Since your traces do NOT include the code of the Decider, the criteria
> > of 'no conditional' is applied incorrectly.
> >
> Not at all. The problem is always the same.
> You don't respond to the words that I am actually saying:
>
> Re: Would the simulation of D be infinitely nested unless simulating
> partial halt decider H terminated its simulation of D?
>
> If you can stay laser focused on exactly those words in your reply to
> them I may quit ignoring your posts.
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

Yo, Peter Olcott, may I friend you on Facebook?

On 5/29/2021 3:06 PM, Richard Damon wrote:
> On 5/29/21 3:49 PM, Richard Damon wrote:
>> On 5/29/21 3:26 PM, olcott wrote:
>>

int D(u32 P)
{ if ( H(P, P) )
return 0;
return 1;
}

int main()
{ H((u32)D, (u32)D);
}

> Prehaps another way to explain it is that by the REAL definition of
> Halting, if Machine D uses sub-machine H to decide on an input, that
> just happens to match D, and H decides that the simulation is getting
> unending and returns the non-halting answer, and D then Halts, this IS
> make D a non-Halting Computation. PERIOD. As that is what it did.
>

If you could stick with that that I could agree that you understand.
You still seemed to have continued to avoid the question in the title of
the post:

Re: Would the simulation of D be infinitely nested unless simulating
partial halt decider H terminated its simulation of D?

In other words would D ever stop of H never stopped simulating it?

--
Copyright 2021 Pete Olcott

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

On 5/29/2021 5:20 PM, DV wrote:
> On Saturday, May 29, 2021 at 4:18:19 PM UTC-4, olcott wrote:
>> On 5/29/2021 2:49 PM, Richard Damon wrote:
>>> On 5/29/21 3:26 PM, olcott wrote:
>>>
>>>> [infinitely_nested_simulation] non-halting behavior pattern for H(D, D)
>>>> (a) Partial halt decider H called twice in sequence from the same
>>>> machine address of D.
>>>> The calls to the partial halt decider are on lines 13 and 20.
>>>> The same block of code from 07 to 13 immediately repeats from 14 to
>>>> 20.
>>>> (b) With the same machine address parameters of D to H.
>>>> It can be verified that both calls to H send the machine address
>>>> of D as input to H.
>>>> The call to H at 13 is preceded by a pair of push instructions at
>>>> 10,12.
>>>> The call to H at 20 is preceded by a pair of push instructions at
>>>> 17,19.
>>>> That this is the machine address of D is verified by column(4) of
>>>> lines (10,12,17,19)
>>>> (c) With no conditional branch or indexed jump instructions in D.
>>>> No conditional branch or indexed jump instructions on execution
>>>> trace lines 07 to 20.
>>>>
>>>> Is the return value of 0 from H to Input_Would_Halt in main() correct?
>>>>
>>>> This question can be answered on the basis of whether or not the above
>>>> criteria is sufficiently complete and correct and correctly applied to
>>>> the provided complete execution trace of D.
>>>>
>>>
>>> Since your traces do NOT include the code of the Decider, the criteria
>>> of 'no conditional' is applied incorrectly.
>>>
>> Not at all. The problem is always the same.
>> You don't respond to the words that I am actually saying:
>>
>> Re: Would the simulation of D be infinitely nested unless simulating
>> partial halt decider H terminated its simulation of D?
>>
>> If you can stay laser focused on exactly those words in your reply to
>> them I may quit ignoring your posts.
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>
> Yo, Peter Olcott, may I friend you on Facebook?
>

Are you someone that I already know?
I generally never accept any friend requests.

--
Copyright 2021 Pete Olcott

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

On 5/29/21 6:22 PM, olcott wrote:
> On 5/29/2021 3:06 PM, Richard Damon wrote:
>> On 5/29/21 3:49 PM, Richard Damon wrote:
>>> On 5/29/21 3:26 PM, olcott wrote:
>>>
>
> int D(u32 P)
> {
>   if ( H(P, P) )
>     return 0;
>   return 1;
> }
>
> int main()
> {
>   H((u32)D, (u32)D);
> }
>
>
>> Prehaps another way to explain it is that by the REAL definition of
>> Halting, if Machine D uses sub-machine H to decide on an input, that
>> just happens to match D, and H decides that the simulation is getting
>> unending and returns the non-halting answer, and D then Halts, this IS
>> make D a non-Halting Computation. PERIOD. As that is what it did.
>>
>
> If you could stick with that that I could agree that you understand.
> You still seemed to have continued to avoid the question in the title of
> the post:
>
> Re: Would the simulation of D be infinitely nested unless simulating
> partial halt decider H terminated its simulation of D?
>
> In other words would D ever stop of H never stopped simulating it?
>

First, you are asking Halt Deciding on a problem that ISN'T Halt Deciding.

By definition, if H is finite, the Halt Decision answer for D is
Halting, as D will always Halt.

D is about accepting/rejecting. H needs to predict the answer that D
will give, not decide if it will halt. You don't understand that
diagonal problem.

Now, if we do want to talk about your Halt Decision problem on D, which
you get wrong, then your statement is only true for the non-halt
deciding interpretation of your question as:

Would the simulation of D be infinitely nested unless SOME COPY of the
simulating partial hatlt decider H terminted the copy of D it was
simulating.

THAT question is True. But for Halt Deciding, the question has to be
would the simulation of D be infinitely nested (and thus non-Halting)
unless the TOP/OUTER copy of H terminates is simulation of D, even if
the other copies continue to obey their origianl computation.

With THAT definition, either H doesn't answer, and thus fails to be a
decider, or if H does terminate its simulation, then we know that if the
top decider didn't, then after a bit more time the next one down would
and D would return.

Note, in this case we DON'T have a 'pathological' self-reference, as
there IS an answer that H can give that is correct, it can return
Halting, and it will be wright.

Note, it then FAIL to be the predictor that the Diagonal Problem
requires it to be.

On 5/29/2021 6:31 PM, Richard Damon wrote:
> On 5/29/21 6:22 PM, olcott wrote:
>> On 5/29/2021 3:06 PM, Richard Damon wrote:
>>> On 5/29/21 3:49 PM, Richard Damon wrote:
>>>> On 5/29/21 3:26 PM, olcott wrote:
>>>>
>>
>> int D(u32 P)
>> {
>>   if ( H(P, P) )
>>     return 0;
>>   return 1;
>> }
>>
>> int main()
>> {
>>   H((u32)D, (u32)D);
>> }
>>
>>
>>> Prehaps another way to explain it is that by the REAL definition of
>>> Halting, if Machine D uses sub-machine H to decide on an input, that
>>> just happens to match D, and H decides that the simulation is getting
>>> unending and returns the non-halting answer, and D then Halts, this IS
>>> make D a non-Halting Computation. PERIOD. As that is what it did.
>>>
>>
>> If you could stick with that that I could agree that you understand.
>> You still seemed to have continued to avoid the question in the title of
>> the post:
>>
>> Re: Would the simulation of D be infinitely nested unless simulating
>> partial halt decider H terminated its simulation of D?
>>
>> In other words would D ever stop of H never stopped simulating it?
>>
>
> First, you are asking Halt Deciding on a problem that ISN'T Halt Deciding.
>

Yes of course everyone knows that halt deciders simulating or otherwise
have nothing to do with halt deciding.

> By definition, if H is finite, the Halt Decision answer for D is
> Halting, as D will always Halt.
>

You are diverging to side-issues that do not directly pertain to the
question.

> D is about accepting/rejecting. H needs to predict the answer that D
> will give, not decide if it will halt. You don't understand that
> diagonal problem.
>
> Now, if we do want to talk about your Halt Decision problem on D, which
> you get wrong, then your statement is only true for the non-halt
> deciding interpretation of your question as:
>
> Would the simulation of D be infinitely nested unless SOME COPY of the
> simulating partial hatlt decider H terminted the copy of D it was
> simulating.
>
> THAT question is True.

Great that may be our first-breakthrough in quite a while.
When written in C there is no need for any copies.

> But for Halt Deciding, the question has to be
> would the simulation of D be infinitely nested (and thus non-Halting)
> unless the TOP/OUTER copy of H terminates is simulation of D, even if
> the other copies continue to obey their origianl computation.
>

This next step is much more difficult, It is actually like this:
If any of the nested simulations ever must be aborted at any point then
because these nested simulations are an aspect of the whole computation
the whole computation must be construed as non-halting even if it halts.

> With THAT definition, either H doesn't answer, and thus fails to be a
> decider, or if H does terminate its simulation, then we know that if the
> top decider didn't, then after a bit more time the next one down would
> and D would return.
>
> Note, in this case we DON'T have a 'pathological' self-reference, as
> there IS an answer that H can give that is correct, it can return
> Halting, and it will be wright.
>
> Note, it then FAIL to be the predictor that the Diagonal Problem
> requires it to be.
>

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

It turns out that one rule of the halting problem diagonalization
argument is incorrect. The rule that says table TH always acquires its
accept/reject value on the basis of the accept/reject value in table T.

--
Copyright 2021 Pete Olcott

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

On 5/29/21 7:56 PM, olcott wrote:
> On 5/29/2021 6:31 PM, Richard Damon wrote:
>> On 5/29/21 6:22 PM, olcott wrote:
>>> On 5/29/2021 3:06 PM, Richard Damon wrote:
>>>> On 5/29/21 3:49 PM, Richard Damon wrote:
>>>>> On 5/29/21 3:26 PM, olcott wrote:
>>>>>
>>>
>>> int D(u32 P)
>>> {
>>>    if ( H(P, P) )
>>>      return 0;
>>>    return 1;
>>> }
>>>
>>> int main()
>>> {
>>>    H((u32)D, (u32)D);
>>> }
>>>
>>>
>>>> Prehaps another way to explain it is that by the REAL definition of
>>>> Halting, if Machine D uses sub-machine H to decide on an input, that
>>>> just happens to match D, and H decides that the simulation is getting
>>>> unending and returns the non-halting answer, and D then Halts, this IS
>>>> make D a non-Halting Computation. PERIOD. As that is what it did.
>>>>
>>>
>>> If you could stick with that that I could agree that you understand.
>>> You still seemed to have continued to avoid the question in the title of
>>> the post:
>>>
>>> Re: Would the simulation of D be infinitely nested unless simulating
>>> partial halt decider H terminated its simulation of D?
>>>
>>> In other words would D ever stop of H never stopped simulating it?
>>>
>>
>> First, you are asking Halt Deciding on a problem that ISN'T Halt
>> Deciding.
>>
>
> Yes of course everyone knows that halt deciders simulating or otherwise
> have nothing to do with halt deciding.
>
>> By definition, if H is finite, the Halt Decision answer for D is
>> Halting, as D will always Halt.
>>
>
> You are diverging to side-issues that do not directly pertain to the
> question.
>
>> D is about accepting/rejecting. H needs to predict the answer that D
>> will give, not decide if it will halt. You don't understand that
>> diagonal problem.
>>
>> Now, if we do want to talk about your Halt Decision problem on D, which
>> you get wrong, then your statement is only true for the non-halt
>> deciding interpretation of your question as:
>>
>> Would the simulation of D be infinitely nested unless SOME COPY of the
>> simulating partial hatlt decider H terminted the copy of D it was
>> simulating.
>>
>> THAT question is True.
>
> Great that may be our first-breakthrough in quite a while.
> When written in C there is no need for any copies.
>
>> But for Halt Deciding, the question has to be
>> would the simulation of D be infinitely nested (and thus non-Halting)
>> unless the TOP/OUTER copy of H terminates is simulation of D, even if
>> the other copies continue to obey their origianl computation.
>>
>
> This next step is much more difficult, It is actually like this:
> If any of the nested simulations ever must be aborted at any point then
> because these nested simulations are an aspect of the whole computation
> the whole computation must be construed as non-halting even if it halts.

Wrong, Because the nested simulations are an aspecrt of the whole
computation of D, there decision to stop simulation become part of the
reason that D IS a HALTING computation.

The DEFINITION of Halting is that a Machine is Halting if when it is
run, it finishes in a finite number of steps. It doesn't matter why.
Your attempt to redefine it violates that definition.

Changing the definition means you are working on a different problem,
and thus your statement doesn't apply to proof you are trying to disprove.

>
>> With THAT definition, either H doesn't answer, and thus fails to be a
>> decider, or if H does terminate its simulation, then we know that if the
>> top decider didn't, then after a bit more time the next one down would
>> and D would return.
>>
>> Note, in this case we DON'T have a 'pathological' self-reference, as
>> there IS an answer that H can give that is correct, it can return
>> Halting, and it will be wright.
>>
>> Note, it then FAIL to be the predictor that the Diagonal Problem
>> requires it to be.
>>
>
> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>
>
> It turns out that one rule of the halting problem diagonalization
> argument is incorrect. The rule that says table TH always acquires its
> accept/reject value on the basis of the accept/reject value in table T.
>

The Rule IS the Rule. The Key property of diagonaization is that it
creates an element that is different from every element of the existing
set, making the size of the set uncountable.

Based on what you are trying to do, you may want to watch the following
video, which explains some of these things in a fairly basic level.

https://www.youtube.com/watch?v=HeQX2HjkcNo

Maybe if you understood some of the basics you might understand the
issues with what you are trying to do.

On 5/29/2021 7:55 PM, Richard Damon wrote:
> On 5/29/21 7:56 PM, olcott wrote:
>> On 5/29/2021 6:31 PM, Richard Damon wrote:
>>> On 5/29/21 6:22 PM, olcott wrote:
>>>> On 5/29/2021 3:06 PM, Richard Damon wrote:
>>>>> On 5/29/21 3:49 PM, Richard Damon wrote:
>>>>>> On 5/29/21 3:26 PM, olcott wrote:
>>>>>>
>>>>
>>>> int D(u32 P)
>>>> {
>>>>    if ( H(P, P) )
>>>>      return 0;
>>>>    return 1;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    H((u32)D, (u32)D);
>>>> }
>>>>
>>>>
>>>>> Prehaps another way to explain it is that by the REAL definition of
>>>>> Halting, if Machine D uses sub-machine H to decide on an input, that
>>>>> just happens to match D, and H decides that the simulation is getting
>>>>> unending and returns the non-halting answer, and D then Halts, this IS
>>>>> make D a non-Halting Computation. PERIOD. As that is what it did.
>>>>>
>>>>
>>>> If you could stick with that that I could agree that you understand.
>>>> You still seemed to have continued to avoid the question in the title of
>>>> the post:
>>>>
>>>> Re: Would the simulation of D be infinitely nested unless simulating
>>>> partial halt decider H terminated its simulation of D?
>>>>
>>>> In other words would D ever stop of H never stopped simulating it?
>>>>
>>>
>>> First, you are asking Halt Deciding on a problem that ISN'T Halt
>>> Deciding.
>>>
>>
>> Yes of course everyone knows that halt deciders simulating or otherwise
>> have nothing to do with halt deciding.
>>
>>> By definition, if H is finite, the Halt Decision answer for D is
>>> Halting, as D will always Halt.
>>>
>>
>> You are diverging to side-issues that do not directly pertain to the
>> question.
>>
>>> D is about accepting/rejecting. H needs to predict the answer that D
>>> will give, not decide if it will halt. You don't understand that
>>> diagonal problem.
>>>
>>> Now, if we do want to talk about your Halt Decision problem on D, which
>>> you get wrong, then your statement is only true for the non-halt
>>> deciding interpretation of your question as:
>>>
>>> Would the simulation of D be infinitely nested unless SOME COPY of the
>>> simulating partial hatlt decider H terminted the copy of D it was
>>> simulating.
>>>
>>> THAT question is True.
>>
>> Great that may be our first-breakthrough in quite a while.
>> When written in C there is no need for any copies.
>>
>>> But for Halt Deciding, the question has to be
>>> would the simulation of D be infinitely nested (and thus non-Halting)
>>> unless the TOP/OUTER copy of H terminates is simulation of D, even if
>>> the other copies continue to obey their origianl computation.
>>>
>>
>> This next step is much more difficult, It is actually like this:
>> If any of the nested simulations ever must be aborted at any point then
>> because these nested simulations are an aspect of the whole computation
>> the whole computation must be construed as non-halting even if it halts.
>
> Wrong, Because the nested simulations are an aspecrt of the whole
> computation of D, there decision to stop simulation become part of the
> reason that D IS a HALTING computation.
>
> The DEFINITION of Halting is that a Machine is Halting if when it is
> run, it finishes in a finite number of steps. It doesn't matter why.
> Your attempt to redefine it violates that definition.
>
> Changing the definition means you are working on a different problem,
> and thus your statement doesn't apply to proof you are trying to disprove.

We can make any of the simplest things impossible depending on how we
form our definition.

If I ask for a glass full of water that has no water what-so-ever in the
glass I have formed a request impossible to fulfill.

Any request for an object that requires that this object has
simultaneous mutually exclusive properties is an erroneous request.

To the exact same extent that any aspect of the halting problem requires
an object to have simultaneous mutually exclusive properties this aspect
of the halting problem is simply erroneous.

When we define non-halting as described in the Truism, then at least
most of the erroneous aspects of the halting problem are nullified:

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.

When we define non-halting that way then the first time that H stops
simulating any of the nested simulations to prevent their otherwise
infinite execution then we know that H decided not halting correctly.

>
>>
>>> With THAT definition, either H doesn't answer, and thus fails to be a
>>> decider, or if H does terminate its simulation, then we know that if the
>>> top decider didn't, then after a bit more time the next one down would
>>> and D would return.
>>>
>>> Note, in this case we DON'T have a 'pathological' self-reference, as
>>> there IS an answer that H can give that is correct, it can return
>>> Halting, and it will be wright.
>>>
>>> Note, it then FAIL to be the predictor that the Diagonal Problem
>>> requires it to be.
>>>
>>
>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>
>>
>> It turns out that one rule of the halting problem diagonalization
>> argument is incorrect. The rule that says table TH always acquires its
>> accept/reject value on the basis of the accept/reject value in table T.
>>
>
> The Rule IS the Rule. The Key property of diagonaization is that it
> creates an element that is different from every element of the existing
> set, making the size of the set uncountable.
>
>
> Based on what you are trying to do, you may want to watch the following
> video, which explains some of these things in a fairly basic level.
>
> https://www.youtube.com/watch?v=HeQX2HjkcNo
>
>
> Maybe if you understood some of the basics you might understand the
> issues with what you are trying to do.
>

https://www.youtube.com/watch?v=jM6osxSX9GA

I understand the halting problem diagonalization proof so well that I
found its error. The one error is the assumption that you can always
copy the accept/reject values from table T to table TH.

The problem is the same mistake of requesting a glass full of water must
contain no water what-so-ever.

It is OK to have table T(D,<D>) have the same value as table TD(<D>)

It it OK to have table the diagonal of TH have the opposite values of
table TD.

It is not OK to also require that table TH obtains it accept/reject
values from table T because this makes the error of requiring an object
with simultaneous mutually exclusive properties.

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

--
Copyright 2021 Pete Olcott

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

On 5/29/21 10:30 PM, olcott wrote:
> On 5/29/2021 7:55 PM, Richard Damon wrote:
>> On 5/29/21 7:56 PM, olcott wrote:
>>> On 5/29/2021 6:31 PM, Richard Damon wrote:
>>>> On 5/29/21 6:22 PM, olcott wrote:
>>>>> On 5/29/2021 3:06 PM, Richard Damon wrote:
>>>>>> On 5/29/21 3:49 PM, Richard Damon wrote:
>>>>>>> On 5/29/21 3:26 PM, olcott wrote:
>>>>>>>
>>>>>
>>>>> int D(u32 P)
>>>>> {
>>>>>     if ( H(P, P) )
>>>>>       return 0;
>>>>>     return 1;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     H((u32)D, (u32)D);
>>>>> }
>>>>>
>>>>>
>>>>>> Prehaps another way to explain it is that by the REAL definition of
>>>>>> Halting, if Machine D uses sub-machine H to decide on an input, that
>>>>>> just happens to match D, and H decides that the simulation is getting
>>>>>> unending and returns the non-halting answer, and D then Halts,
>>>>>> this IS
>>>>>> make D a non-Halting Computation. PERIOD. As that is what it did.
>>>>>>
>>>>>
>>>>> If you could stick with that that I could agree that you understand.
>>>>> You still seemed to have continued to avoid the question in the
>>>>> title of
>>>>> the post:
>>>>>
>>>>> Re: Would the simulation of D be infinitely nested unless simulating
>>>>> partial halt decider H terminated its simulation of D?
>>>>>
>>>>> In other words would D ever stop of H never stopped simulating it?
>>>>>
>>>>
>>>> First, you are asking Halt Deciding on a problem that ISN'T Halt
>>>> Deciding.
>>>>
>>>
>>> Yes of course everyone knows that halt deciders simulating or otherwise
>>> have nothing to do with halt deciding.
>>>
>>>> By definition, if H is finite, the Halt Decision answer for D is
>>>> Halting, as D will always Halt.
>>>>
>>>
>>> You are diverging to side-issues that do not directly pertain to the
>>> question.
>>>
>>>> D is about accepting/rejecting. H needs to predict the answer that D
>>>> will give, not decide if it will halt. You don't understand that
>>>> diagonal problem.
>>>>
>>>> Now, if we do want to talk about your Halt Decision problem on D, which
>>>> you get wrong, then your statement is only true for the non-halt
>>>> deciding interpretation of your question as:
>>>>
>>>> Would the simulation of D be infinitely nested unless SOME COPY of the
>>>> simulating partial hatlt decider H terminted the copy of D it was
>>>> simulating.
>>>>
>>>> THAT question is True.
>>>
>>> Great that may be our first-breakthrough in quite a while.
>>> When written in C there is no need for any copies.
>>>
>>>> But for Halt Deciding, the question has to be
>>>> would the simulation of D be infinitely nested (and thus non-Halting)
>>>> unless the TOP/OUTER copy of H terminates is simulation of D, even if
>>>> the other copies continue to obey their origianl computation.
>>>>
>>>
>>> This next step is much more difficult, It is actually like this:
>>> If any of the nested simulations ever must be aborted at any point then
>>> because these nested simulations are an aspect of the whole computation
>>> the whole computation must be construed as non-halting even if it halts.
>>
>> Wrong, Because the nested simulations are an aspecrt of the whole
>> computation of D, there decision to stop simulation become part of the
>> reason that D IS a HALTING computation.
>>
>> The DEFINITION of Halting is that a Machine is Halting if when it is
>> run, it finishes in a finite number of steps. It doesn't matter why.
>> Your attempt to redefine it violates that definition.
>>
>> Changing the definition means you are working on a different problem,
>> and thus your statement doesn't apply to proof you are trying to
>> disprove.
>
> We can make any of the simplest things impossible depending on how we
> form our definition.

But you DON'T get to from the definitions. THAT is the key error you
make. Halting is already defined. You can't change it and be in the same
theory.

>
> If I ask for a glass full of water that has no water what-so-ever in the
> glass I have formed a request impossible to fulfill.
>
> Any request for an object that requires that this object has
> simultaneous mutually exclusive properties is an erroneous request.

No. The request is like the request to make an always winning strategy
to win at the game of Tic-Tak-Toe. The simple answer is that there is no
such strategy.

The request does NOT have inherent mutual exclusive properites. The
challenge is to make an finite algorithm that predicts if a machine will
halt on a given input given the description of the machine.

The answer always exists for any given machine, but we might not every
be able to know what it is. It is just that since the machine has a
fixed algorithm, it can't always be right. The key that breaks the cycle
you run into is that you can't actually make H^ until AFTER you have
created H. Thus the

>
> To the exact same extent that any aspect of the halting problem requires
> an object to have simultaneous mutually exclusive properties this aspect
> of the halting problem is simply erroneous.

Nope. The DESIGN problem of the halting machine creates that problem,
which shows you can't actually make the machine. The answer ALWAYS
exist, so there is always a right answer, once the machines exist.
>
> When we define non-halting as described in the Truism, then at least
> most of the erroneous aspects of the halting problem are nullified:

But then you don't have the problem that is needed. You then have the
Olcott-Halting which has no know use. The classic halting problem has
MANY possible uses in mathematics for the cases where is can be solved.
>
> 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.
>
> When we define non-halting that way then the first time that H stops
> simulating any of the nested simulations to prevent their otherwise
> infinite execution then we know that H decided not halting correctly.

BUT THAT ISN'T THE DEFINITION, SO USING IT DOESN'T GET THE RIGHT ANSWER
TO THE REAL PROBLEM.

If you can actually SHOW where that definition could be useful, then
make you proof.

Unfortunately, since it report non-halting for computation that actual
do halt, it isn't useful for the real halting problem in computation
theory, which has actual implications for mathematics.

>
>>
>>>
>>>> With THAT definition, either H doesn't answer, and thus fails to be a
>>>> decider, or if H does terminate its simulation, then we know that if
>>>> the
>>>> top decider didn't, then after a bit more time the next one down would
>>>> and D would return.
>>>>
>>>> Note, in this case we DON'T have a 'pathological' self-reference, as
>>>> there IS an answer that H can give that is correct, it can return
>>>> Halting, and it will be wright.
>>>>
>>>> Note, it then FAIL to be the predictor that the Diagonal Problem
>>>> requires it to be.
>>>>
>>>
>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>
>>>
>>>
>>> It turns out that one rule of the halting problem diagonalization
>>> argument is incorrect. The rule that says table TH always acquires its
>>> accept/reject value on the basis of the accept/reject value in table T.
>>>
>>
>> The Rule IS the Rule. The Key property of diagonaization is that it
>> creates an element that is different from every element of the existing
>> set, making the size of the set uncountable.
>>
>>
>> Based on what you are trying to do, you may want to watch the following
>> video, which explains some of these things in a fairly basic level.
>>
>> https://www.youtube.com/watch?v=HeQX2HjkcNo
>>
>>
>> Maybe if you understood some of the basics you might understand the
>> issues with what you are trying to do.
>>
>
> https://www.youtube.com/watch?v=jM6osxSX9GA
>
> I understand the halting problem diagonalization proof so well that I
> found its error. The one error is the assumption that you can always
> copy the accept/reject values from table T to table TH.
>

On 5/29/2021 10:56 PM, Richard Damon wrote:
> On 5/29/21 10:30 PM, olcott wrote:
>> On 5/29/2021 7:55 PM, Richard Damon wrote:
>>> On 5/29/21 7:56 PM, olcott wrote:
>>>> On 5/29/2021 6:31 PM, Richard Damon wrote:
>>>>> On 5/29/21 6:22 PM, olcott wrote:
>>>>>> On 5/29/2021 3:06 PM, Richard Damon wrote:
>>>>>>> On 5/29/21 3:49 PM, Richard Damon wrote:
>>>>>>>> On 5/29/21 3:26 PM, olcott wrote:
>>>>>>>>
>>>>>>
>>>>>> int D(u32 P)
>>>>>> {
>>>>>>     if ( H(P, P) )
>>>>>>       return 0;
>>>>>>     return 1;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>     H((u32)D, (u32)D);
>>>>>> }
>>>>>>
>>>>>>
>>>>>>> Prehaps another way to explain it is that by the REAL definition of
>>>>>>> Halting, if Machine D uses sub-machine H to decide on an input, that
>>>>>>> just happens to match D, and H decides that the simulation is getting
>>>>>>> unending and returns the non-halting answer, and D then Halts,
>>>>>>> this IS
>>>>>>> make D a non-Halting Computation. PERIOD. As that is what it did.
>>>>>>>
>>>>>>
>>>>>> If you could stick with that that I could agree that you understand.
>>>>>> You still seemed to have continued to avoid the question in the
>>>>>> title of
>>>>>> the post:
>>>>>>
>>>>>> Re: Would the simulation of D be infinitely nested unless simulating
>>>>>> partial halt decider H terminated its simulation of D?
>>>>>>
>>>>>> In other words would D ever stop of H never stopped simulating it?
>>>>>>
>>>>>
>>>>> First, you are asking Halt Deciding on a problem that ISN'T Halt
>>>>> Deciding.
>>>>>
>>>>
>>>> Yes of course everyone knows that halt deciders simulating or otherwise
>>>> have nothing to do with halt deciding.
>>>>
>>>>> By definition, if H is finite, the Halt Decision answer for D is
>>>>> Halting, as D will always Halt.
>>>>>
>>>>
>>>> You are diverging to side-issues that do not directly pertain to the
>>>> question.
>>>>
>>>>> D is about accepting/rejecting. H needs to predict the answer that D
>>>>> will give, not decide if it will halt. You don't understand that
>>>>> diagonal problem.
>>>>>
>>>>> Now, if we do want to talk about your Halt Decision problem on D, which
>>>>> you get wrong, then your statement is only true for the non-halt
>>>>> deciding interpretation of your question as:
>>>>>
>>>>> Would the simulation of D be infinitely nested unless SOME COPY of the
>>>>> simulating partial hatlt decider H terminted the copy of D it was
>>>>> simulating.
>>>>>
>>>>> THAT question is True.
>>>>
>>>> Great that may be our first-breakthrough in quite a while.
>>>> When written in C there is no need for any copies.
>>>>
>>>>> But for Halt Deciding, the question has to be
>>>>> would the simulation of D be infinitely nested (and thus non-Halting)
>>>>> unless the TOP/OUTER copy of H terminates is simulation of D, even if
>>>>> the other copies continue to obey their origianl computation.
>>>>>
>>>>
>>>> This next step is much more difficult, It is actually like this:
>>>> If any of the nested simulations ever must be aborted at any point then
>>>> because these nested simulations are an aspect of the whole computation
>>>> the whole computation must be construed as non-halting even if it halts.
>>>
>>> Wrong, Because the nested simulations are an aspecrt of the whole
>>> computation of D, there decision to stop simulation become part of the
>>> reason that D IS a HALTING computation.
>>>
>>> The DEFINITION of Halting is that a Machine is Halting if when it is
>>> run, it finishes in a finite number of steps. It doesn't matter why.
>>> Your attempt to redefine it violates that definition.
>>>
>>> Changing the definition means you are working on a different problem,
>>> and thus your statement doesn't apply to proof you are trying to
>>> disprove.
>>
>> We can make any of the simplest things impossible depending on how we
>> form our definition.
>
> But you DON'T get to from the definitions. THAT is the key error you
> make. Halting is already defined. You can't change it and be in the same
> theory.
>
>>
>> If I ask for a glass full of water that has no water what-so-ever in the
>> glass I have formed a request impossible to fulfill.
>>
>> Any request for an object that requires that this object has
>> simultaneous mutually exclusive properties is an erroneous request.
>
> No. The request is like the request to make an always winning strategy
> to win at the game of Tic-Tak-Toe. The simple answer is that there is no
> such strategy.
>

https://www.youtube.com/watch?v=5n2aQ3UQu9Y

> The request does NOT have inherent mutual exclusive properites. The
> challenge is to make an finite algorithm that predicts if a machine will
> halt on a given input given the description of the machine.
>

It turns out that one element of the diagonal is required to be the
opposite of itself. This is exactly the same as required a full cup of
water to contain no water at all.

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

> The answer always exists for any given machine, but we might not every
> be able to know what it is. It is just that since the machine has a
> fixed algorithm, it can't always be right. The key that breaks the cycle
> you run into is that you can't actually make H^ until AFTER you have
> created H. Thus the
>
>>
>> To the exact same extent that any aspect of the halting problem requires
>> an object to have simultaneous mutually exclusive properties this aspect
>> of the halting problem is simply erroneous.
>
> Nope. The DESIGN problem of the halting machine creates that problem,
> which shows you can't actually make the machine. The answer ALWAYS
> exist, so there is always a right answer, once the machines exist.
>>
>> When we define non-halting as described in the Truism, then at least
>> most of the erroneous aspects of the halting problem are nullified:
>
> But then you don't have the problem that is needed. You then have the
> Olcott-Halting which has no know use. The classic halting problem has
> MANY possible uses in mathematics for the cases where is can be solved.
>>
>> 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.
>>
>> When we define non-halting that way then the first time that H stops
>> simulating any of the nested simulations to prevent their otherwise
>> infinite execution then we know that H decided not halting correctly.
>
> BUT THAT ISN'T THE DEFINITION, SO USING IT DOESN'T GET THE RIGHT ANSWER
> TO THE REAL PROBLEM.
>
> If you can actually SHOW where that definition could be useful, then
> make you proof.
>
> Unfortunately, since it report non-halting for computation that actual
> do halt, it isn't useful for the real halting problem in computation
> theory, which has actual implications for mathematics.
>
>>
>>>
>>>>
>>>>> With THAT definition, either H doesn't answer, and thus fails to be a
>>>>> decider, or if H does terminate its simulation, then we know that if
>>>>> the
>>>>> top decider didn't, then after a bit more time the next one down would
>>>>> and D would return.
>>>>>
>>>>> Note, in this case we DON'T have a 'pathological' self-reference, as
>>>>> there IS an answer that H can give that is correct, it can return
>>>>> Halting, and it will be wright.
>>>>>
>>>>> Note, it then FAIL to be the predictor that the Diagonal Problem
>>>>> requires it to be.
>>>>>
>>>>
>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>
>>>>
>>>>
>>>> It turns out that one rule of the halting problem diagonalization
>>>> argument is incorrect. The rule that says table TH always acquires its
>>>> accept/reject value on the basis of the accept/reject value in table T.
>>>>
>>>
>>> The Rule IS the Rule. The Key property of diagonaization is that it
>>> creates an element that is different from every element of the existing
>>> set, making the size of the set uncountable.
>>>
>>>
>>> Based on what you are trying to do, you may want to watch the following
>>> video, which explains some of these things in a fairly basic level.
>>>
>>> https://www.youtube.com/watch?v=HeQX2HjkcNo
>>>
>>>
>>> Maybe if you understood some of the basics you might understand the
>>> issues with what you are trying to do.
>>>
>>
>> https://www.youtube.com/watch?v=jM6osxSX9GA
>>
>> I understand the halting problem diagonalization proof so well that I
>> found its error. The one error is the assumption that you can always
>> copy the accept/reject values from table T to table TH.
>>
>
> Only by using the wrong definitions.
>

Richard Damon <Richard@Damon-Family.org> writes:

> You only get the contradiction if you assume that the machine H exists,
> so the key to the diagonalization is that we show that if H exists, then
> D is now a machine that is different from all enumerated machines, thus
> D can not exist as a machine, but since if H can exist, then D will
> exist, thus H must not be able to exist.

I think this form of the argument misses a trick. With an explicit
diagonal argument there is no need to assume H, and it's this assumption
that trips some non-mathematical students up. Instead, we can argue
that no machine computes 'halts' -- the mathematical function from N to
{true, false} which indubitably exists.

--
Ben.

On 5/30/21 12:19 AM, olcott wrote:
> On 5/29/2021 10:56 PM, Richard Damon wrote:
>> On 5/29/21 10:30 PM, olcott wrote:
>>> On 5/29/2021 7:55 PM, Richard Damon wrote:
>>>> On 5/29/21 7:56 PM, olcott wrote:
>>>>> On 5/29/2021 6:31 PM, Richard Damon wrote:
>>>>>> On 5/29/21 6:22 PM, olcott wrote:
>>>>>>> On 5/29/2021 3:06 PM, Richard Damon wrote:
>>>>>>>> On 5/29/21 3:49 PM, Richard Damon wrote:
>>>>>>>>> On 5/29/21 3:26 PM, olcott wrote:
>>>>>>>>>
>>>>>>>
>>>>>>> int D(u32 P)
>>>>>>> {
>>>>>>>      if ( H(P, P) )
>>>>>>>        return 0;
>>>>>>>      return 1;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>      H((u32)D, (u32)D);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>> Prehaps another way to explain it is that by the REAL definition of
>>>>>>>> Halting, if Machine D uses sub-machine H to decide on an input,
>>>>>>>> that
>>>>>>>> just happens to match D, and H decides that the simulation is
>>>>>>>> getting
>>>>>>>> unending and returns the non-halting answer, and D then Halts,
>>>>>>>> this IS
>>>>>>>> make D a non-Halting Computation. PERIOD. As that is what it did.
>>>>>>>>
>>>>>>>
>>>>>>> If you could stick with that that I could agree that you understand.
>>>>>>> You still seemed to have continued to avoid the question in the
>>>>>>> title of
>>>>>>> the post:
>>>>>>>
>>>>>>> Re: Would the simulation of D be infinitely nested unless simulating
>>>>>>> partial halt decider H terminated its simulation of D?
>>>>>>>
>>>>>>> In other words would D ever stop of H never stopped simulating it?
>>>>>>>
>>>>>>
>>>>>> First, you are asking Halt Deciding on a problem that ISN'T Halt
>>>>>> Deciding.
>>>>>>
>>>>>
>>>>> Yes of course everyone knows that halt deciders simulating or
>>>>> otherwise
>>>>> have nothing to do with halt deciding.
>>>>>
>>>>>> By definition, if H is finite, the Halt Decision answer for D is
>>>>>> Halting, as D will always Halt.
>>>>>>
>>>>>
>>>>> You are diverging to side-issues that do not directly pertain to the
>>>>> question.
>>>>>
>>>>>> D is about accepting/rejecting. H needs to predict the answer that D
>>>>>> will give, not decide if it will halt. You don't understand that
>>>>>> diagonal problem.
>>>>>>
>>>>>> Now, if we do want to talk about your Halt Decision problem on D,
>>>>>> which
>>>>>> you get wrong, then your statement is only true for the non-halt
>>>>>> deciding interpretation of your question as:
>>>>>>
>>>>>> Would the simulation of D be infinitely nested unless SOME COPY of
>>>>>> the
>>>>>> simulating partial hatlt decider H terminted the copy of D it was
>>>>>> simulating.
>>>>>>
>>>>>> THAT question is True.
>>>>>
>>>>> Great that may be our first-breakthrough in quite a while.
>>>>> When written in C there is no need for any copies.
>>>>>
>>>>>> But for Halt Deciding, the question has to be
>>>>>> would the simulation of D be infinitely nested (and thus non-Halting)
>>>>>> unless the TOP/OUTER copy of H terminates is simulation of D, even if
>>>>>> the other copies continue to obey their origianl computation.
>>>>>>
>>>>>
>>>>> This next step is much more difficult, It is actually like this:
>>>>> If any of the nested simulations ever must be aborted at any point
>>>>> then
>>>>> because these nested simulations are an aspect of the whole
>>>>> computation
>>>>> the whole computation must be construed as non-halting even if it
>>>>> halts.
>>>>
>>>> Wrong, Because the nested simulations are an aspecrt of the whole
>>>> computation of D, there decision to stop simulation become part of the
>>>> reason that D IS a HALTING computation.
>>>>
>>>> The DEFINITION of Halting is that a Machine is Halting if when it is
>>>> run, it finishes in a finite number of steps. It doesn't matter why.
>>>> Your attempt to redefine it violates that definition.
>>>>
>>>> Changing the definition means you are working on a different problem,
>>>> and thus your statement doesn't apply to proof you are trying to
>>>> disprove.
>>>
>>> We can make any of the simplest things impossible depending on how we
>>> form our definition.
>>
>> But you DON'T get to from the definitions. THAT is the key error you
>> make. Halting is already defined. You can't change it and be in the same
>> theory.
>>
>>>
>>> If I ask for a glass full of water that has no water what-so-ever in the
>>> glass I have formed a request impossible to fulfill.
>>>
>>> Any request for an object that requires that this object has
>>> simultaneous mutually exclusive properties is an erroneous request.
>>
>> No. The request is like the request to make an always winning strategy
>> to win at the game of Tic-Tak-Toe. The simple answer is that there is no
>> such strategy.
>>
>
> https://www.youtube.com/watch?v=5n2aQ3UQu9Y

FAIL. I Sid ALWAYS WIN, not NEVER LOSE. That is just more of your
redefinition babbling. A Tie is NOT a win. Just like your rule that
decides 'non-halting' decides that for cases which are halting.
>
>> The request does NOT have inherent mutual exclusive properites. The
>> challenge is to make an finite algorithm that predicts if a machine will
>> halt on a given input given the description of the machine.
>>
>
>
> It turns out that one element of the diagonal is required to be the
> opposite of itself. This is exactly the same as required a full cup of
> water to contain no water at all.

WRONG. We use the invert on the diagonal to make an element that is
different from every other element in the list. It is not the opposite
of 'itself', this shows that the element isn't on the list. This method
can be used to show that the reals are bigger then the natural number in
a different diagonal proof, or, since we know that for Turing Machines
that the list did have all Turing Machines on it, that no such machine
exists, and thus that H can not exist.

>
> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>
>
>
>> The answer always exists for any given machine, but we might not every
>> be able to know what it is. It is just that since the machine has a
>> fixed algorithm, it can't always be right. The key that breaks the cycle
>> you run into is that you can't actually make H^ until AFTER you have
>> created H. Thus the
>>
>>>
>>> To the exact same extent that any aspect of the halting problem requires
>>> an object to have simultaneous mutually exclusive properties this aspect
>>> of the halting problem is simply erroneous.
>>
>> Nope. The DESIGN problem of the halting machine creates that problem,
>> which shows you can't actually make the machine. The answer ALWAYS
>> exist, so there is always a right answer, once the machines exist.
>>>
>>> When we define non-halting as described in the Truism, then at least
>>> most of the erroneous aspects of the halting problem are nullified:
>>
>> But then you don't have the problem that is needed. You then have the
>> Olcott-Halting  which has no know use. The classic halting problem has
>> MANY possible uses in mathematics for the cases where is can be solved.
>>>
>>> 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.
>>>
>>> When we define non-halting that way then the first time that H stops
>>> simulating any of the nested simulations to prevent their otherwise
>>> infinite execution then we know that H decided not halting correctly.
>>
>> BUT THAT ISN'T THE DEFINITION, SO USING IT DOESN'T GET THE RIGHT ANSWER
>> TO THE REAL PROBLEM.
>>
>> If you can actually SHOW where that definition could be useful, then
>> make you proof.
>>
>> Unfortunately, since it report non-halting for computation that actual
>> do halt, it isn't useful for the real halting problem in computation
>> theory, which has actual implications for mathematics.
>>
>>>
>>>>
>>>>>
>>>>>> With THAT definition, either H doesn't answer, and thus fails to be a
>>>>>> decider, or if H does terminate its simulation, then we know that if
>>>>>> the
>>>>>> top decider didn't, then after a bit more time the next one down
>>>>>> would
>>>>>> and D would return.
>>>>>>
>>>>>> Note, in this case we DON'T have a 'pathological' self-reference, as
>>>>>> there IS an answer that H can give that is correct, it can return
>>>>>> Halting, and it will be wright.
>>>>>>
>>>>>> Note, it then FAIL to be the predictor that the Diagonal Problem
>>>>>> requires it to be.
>>>>>>
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> It turns out that one rule of the halting problem diagonalization
>>>>> argument is incorrect. The rule that says table TH always acquires its
>>>>> accept/reject value on the basis of the accept/reject value in
>>>>> table T.
>>>>>
>>>>
>>>> The Rule IS the Rule. The Key property of diagonaization is that it
>>>> creates an element that is different from every element of the existing
>>>> set, making the size of the set uncountable.
>>>>
>>>>
>>>> Based on what you are trying to do, you may want to watch the following
>>>> video, which explains some of these things in a fairly basic level.
>>>>
>>>> https://www.youtube.com/watch?v=HeQX2HjkcNo
>>>>
>>>>
>>>> Maybe if you understood some of the basics you might understand the
>>>> issues with what you are trying to do.
>>>>
>>>
>>> https://www.youtube.com/watch?v=jM6osxSX9GA
>>>
>>> I understand the halting problem diagonalization proof so well that I
>>> found its error. The one error is the assumption that you can always
>>> copy the accept/reject values from table T to table TH.
>>>
>>
>> Only by using the wrong definitions.
>>
>
> The the diagonal for element of table T(D,<D>) is required to have the
> same value as that of element diagonal element of table TH(D,<D>) which
>  is required to have the opposite value of table TD(<D>) which is
> required to be that same value as element T(D,<D>).

On 5/30/2021 6:07 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> You only get the contradiction if you assume that the machine H exists,
>> so the key to the diagonalization is that we show that if H exists, then
>> D is now a machine that is different from all enumerated machines, thus
>> D can not exist as a machine, but since if H can exist, then D will
>> exist, thus H must not be able to exist.
>
> I think this form of the argument misses a trick. With an explicit
> diagonal argument there is no need to assume H, and it's this assumption
> that trips some non-mathematical students up. Instead, we can argue
> that no machine computes 'halts' -- the mathematical function from N to
> {true, false} which indubitably exists.
>

#define u32 uint32_t

int Simulate(u32 P, u32 I)
{ ((void(*)(u32))P)(I);
return 1;
}

int D(u32 P) // P is a machine address
{ if ( H(P, P) )
return 0 // reject when H accepts
return 1; // accept when H rejects
}

int main()
{ H((u32)D, (u32)D);
}

We can know that simulating halt decider H must stop simulating its
input because if H did not stop simulating its input then D would have
the same halting behavior as if D called Simulate instead of H.

If H must stop simulating its input this proves that H correctly decides
not halting on D.

--
Copyright 2021 Pete Olcott

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

olcott wrote:
> [...]
> This question can be answered on the basis of whether or not the above
> criteria is sufficiently complete and correct and correctly applied to

Either "criteria are" or "criterion is".

> the provided complete execution trace of D.
>

--
Just as 'beautiful' points the way for aesthetics and 'good' for ethics,
so do words like 'true' for logic. All sciences have truth as their
goal; but logic is also concerned with it in a quite different way:
logic has much the same relation to truth as physics has to weight or
heat. Frege in 'Thoughts' (Der Gedanke)