Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: New test program (Succeeds V2)[ Honest Dialogue? ]( maybe not )

34 views
Skip to first unread message

olcott

unread,
May 8, 2021, 6:45:48 PM5/8/21
to
On 5/8/2021 5:06 PM, Kaz Kylheku wrote:
> On 2021-05-08, olcott <No...@NoWhere.com> wrote:
>> On 5/8/2021 3:24 PM, Kaz Kylheku wrote:
>>> On 2021-05-08, olcott <No...@NoWhere.com> wrote:
>>>> Dishonest people are free to disagree with verified facts, honest people
>>>> are not.
>>>
>>> Yes; verified facts like uncomputability of halting, Gödel's
>>> incompleteness theorems and such.
>>>
>>
>> Removing this key context seems quite dishonest:
>>
>> On 5/8/2021 10:57 AM, Kaz Kylheku wrote:
>>> There is no evidence that H_Hat is forced to stop.
>>
>> I will not assume that dishonesty was your intention.
>>
>>>> The following execution trace proves that the input H_Hat()
>>>> <is> forced to stop at its machine address [00000b67].
>>>
>>> Your execution traces don't prove anything because they omit
>>> reams and reams of instructions.
>>
>> It does prove that H_Hat was forced to stop.
>
> Your own traces shows that H_Hat resumes. Here is one of them,
> abridged:
>

In the following I show every single detail of exactly how the
non-halting behavior pattern of infinite recursion or infinitely nested
simulation has been matched by Halts((u32)H_Hat, (u32)H_Hat).

The the only possible way that non-halting has been decided incorrectly
is an error in the criteria shown below.


When an execution trace matches the following criteria we know that the
non-halting behavior of infinite recursion or infinitely nested
simulation has been matched:

If the execution trace of function Y() shows:
(1) function X() is called twice in sequence from the same machine
address of Y()
(2) with the same parameters to X()
(3) with no conditional branch or indexed jump instructions in Y()
(4) with no function call returns from X()
then the function call from Y() to X() is infinitely recursive.

void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}

_H_Hat()
[00000b1f](01) 55 push ebp
[00000b20](02) 8bec mov ebp,esp
[00000b22](01) 51 push ecx
[00000b23](03) 8b4508 mov eax,[ebp+08]
[00000b26](01) 50 push eax
[00000b27](03) 8b4d08 mov ecx,[ebp+08]
[00000b2a](01) 51 push ecx
[00000b2b](05) e82ffeffff call 0000095f
[00000b30](03) 83c408 add esp,+08
[00000b33](03) 8945fc mov [ebp-04],eax
[00000b36](04) 837dfc00 cmp dword [ebp-04],+00
[00000b3a](02) 7402 jz 00000b3e
[00000b3c](02) ebfe jmp 00000b3c
[00000b3e](02) 8be5 mov esp,ebp
[00000b40](01) 5d pop ebp
[00000b41](01) c3 ret
Size in bytes:(0035) [00000b41]

_main()
[00000b4f](01) 55 push ebp
[00000b50](02) 8bec mov ebp,esp
[00000b52](01) 51 push ecx
[00000b53](05) 681f0b0000 push 00000b1f
[00000b58](05) 681f0b0000 push 00000b1f
[00000b5d](05) e8fdfdffff call 0000095f
[00000b62](03) 83c408 add esp,+08
[00000b65](03) 8945fc mov [ebp-04],eax
[00000b68](03) 8b45fc mov eax,[ebp-04]
[00000b6b](01) 50 push eax
[00000b6c](05) 682b030000 push 0000032b
[00000b71](05) e8e9f7ffff call 0000035f
[00000b76](03) 83c408 add esp,+08
[00000b79](02) 33c0 xor eax,eax
[00000b7b](02) 8be5 mov esp,ebp
[00000b7d](01) 5d pop ebp
[00000b7e](01) c3 ret
Size in bytes:(0048) [00000b7e]

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

...[00000b4f][00101542][00000000](01) 55 push ebp
...[00000b50][00101542][00000000](02) 8bec mov ebp,esp
...[00000b52][0010153e][00000000](01) 51 push ecx
...[00000b53][0010153a][00000b1f](05) 681f0b0000 push 00000b1f
...[00000b58][00101536][00000b1f](05) 681f0b0000 push 00000b1f
...[00000b5d][00101532][00000b62](05) e8fdfdffff call 0000095f

Begin Local Halt Decider Simulation at Machine Address:b1f
...[00000b1f][002115e2][002115e6](01) 55 push ebp
...[00000b20][002115e2][002115e6](02) 8bec mov ebp,esp
...[00000b22][002115de][002015b2](01) 51 push ecx
...[00000b23][002115de][002015b2](03) 8b4508 mov eax,[ebp+08]
...[00000b26][002115da][00000b1f](01) 50 push eax
...[00000b27][002115da][00000b1f](03) 8b4d08 mov ecx,[ebp+08]
...[00000b2a][002115d6][00000b1f](01) 51 push ecx
...[00000b2b][002115d2][00000b30](05) e82ffeffff call 0000095f
The above eight instructions repeat

...[00000b1f][0025c00a][0025c00e](01) 55 push ebp
...[00000b20][0025c00a][0025c00e](02) 8bec mov ebp,esp
...[00000b22][0025c006][0024bfda](01) 51 push ecx
...[00000b23][0025c006][0024bfda](03) 8b4508 mov eax,[ebp+08]
...[00000b26][0025c002][00000b1f](01) 50 push eax
...[00000b27][0025c002][00000b1f](03) 8b4d08 mov ecx,[ebp+08]
...[00000b2a][0025bffe][00000b1f](01) 51 push ecx
...[00000b2b][0025bffa][00000b30](05) e82ffeffff call 0000095f
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Infinite recursion / Infinitely nested simulation criteria has been met

(1) function X() is called twice in sequence from the same machine
address of Y()
...[00000b2b][002115d2][00000b30](05) e82ffeffff call 0000095f

(2) with the same parameters to X()
The pair of push instructions preceding call 0000095f push the value of
0xb1f (The address of H_Hat) onto the stack as input to Halts().

(3) with no conditional branch or indexed jump instructions in Y()
No instructions between 0xb1f and 0xb2b of H_Hat() fit this category.

(4) with no function call returns from X()
Halts() is a simulator that never returns to its input.

...[00000b62][0010153e][00000000](03) 83c408 add esp,+08
...[00000b65][0010153e][00000000](03) 8945fc mov
[ebp-04],eax
...[00000b68][0010153e][00000000](03) 8b45fc mov
eax,[ebp-04]
...[00000b6b][0010153a][00000000](01) 50 push eax
...[00000b6c][00101536][0000032b](05) 682b030000 push 0000032b
...[00000b71][00101532][00000b76](05) e8e9f7ffff call 0000035f
Input_Would_Halt = 0
...[00000b76][0010153e][00000000](03) 83c408 add esp,+08
...[00000b79][0010153e][00000000](02) 33c0 xor eax,eax
...[00000b7b][00101542][00000000](02) 8be5 mov esp,ebp
...[00000b7d][00101546][00100000](01) 5d pop ebp
...[00000b7e][0010154a][00000080](01) c3 ret
Number_of_User_Instructions(33)
Number of Instructions Executed(26560)

I also updated this file with these clarifications:
http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf



--
Copyright 2021 Pete Olcott

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

wij

unread,
May 8, 2021, 10:21:26 PM5/8/21
to
Please provide a valid C++ code and CONSISTENT, HONEST, descriptions.
Your statements are confusing, not showing desire for Honest Dialogue

olcott

unread,
May 8, 2021, 10:36:01 PM5/8/21
to
The above paper has much more details.
This posting is the essence of my results.

u32 Halts(u32 P, u32 I);

The key C code is provided above. Halts() is actually quite complex
depending on many hundreds of pages of x86 emulator code also written in
C. The only thing that needs to be known about this otherwise enormously
complex code is that Halts() simulates the code @ machine address P with
data at machine address I until this simulation matches the non-halting
criteria of (1)(2)(3)(4) shown above.

Putting all this together and the key halting problem instance is shown
to be decidable as non-halting.

wij

unread,
May 8, 2021, 11:02:58 PM5/8/21
to
> > ....
> > Please provide a valid C++ code and CONSISTENT, HONEST, descriptions.
> > Your statements are confusing, not showing desire for Honest Dialogue
> >
> The above paper has much more details.
> This posting is the essence of my results.
>
> u32 Halts(u32 P, u32 I);
>
> The key C code is provided above. Halts() is actually quite complex
> depending on many hundreds of pages of x86 emulator code also written in
> C. The only thing that needs to be known about this otherwise enormously
> complex code is that Halts() simulates the code @ machine address P with
> data at machine address I until this simulation matches the non-halting
> criteria of (1)(2)(3)(4) shown above.
>
> Putting all this together and the key halting problem instance is shown
> to be decidable as non-halting.
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

The non-halting criteria of (1)(2)(3)(4) mentions X(),Y(), while the examples
use u32 Halts(u32,u32), and H_Hat(u32). I am baffled what is really said.
(consistency)

olcott

unread,
May 8, 2021, 11:11:47 PM5/8/21
to
The X() and Y() function names specify the generic [infinite-recursion]
behavior pattern. This behavior pattern equally applies to the
[infinitely nested simulation] behavior of H_Hat() relative to Halts().

I cut-and-pasted this stuff from my five page paper. The above is
explained on page one of my paper.

http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf

wij

unread,
May 8, 2021, 11:55:28 PM5/8/21
to
>> ...
> > The non-halting criteria of (1)(2)(3)(4) mentions X(),Y(), while the examples
> > use u32 Halts(u32,u32), and H_Hat(u32). I am baffled what is really said.
> > (consistency)
> >
> The X() and Y() function names specify the generic [infinite-recursion]
> behavior pattern. This behavior pattern equally applies to the
> [infinitely nested simulation] behavior of H_Hat() relative to Halts().
>
> I cut-and-pasted this stuff from my five page paper. The above is
> explained on page one of my paper.
>
> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
> --

How is the result of your paper helpful in practice (or in theory)?

olcott

unread,
May 9, 2021, 12:08:27 AM5/9/21
to
The conventional halting problem proofs cease to prove that the halting
problem cannot be solved. This provides the basis for the solution to
the halting problem. https://en.wikipedia.org/wiki/Halting_problem

The fundmental limits of algorithmic computation that were previously
demonstrated by the halting problem proofs cease to exist.

Mr Flibble

unread,
May 9, 2021, 2:19:03 PM5/9/21
to
On 09/05/2021 05:07, olcott wrote:
> On 5/8/2021 10:55 PM, wij wrote:
>>>> ...
>>>> The non-halting criteria of (1)(2)(3)(4) mentions X(),Y(), while the examples
>>>> use u32 Halts(u32,u32), and H_Hat(u32). I am baffled what is really said.
>>>> (consistency)
>>>>
>>> The X() and Y() function names specify the generic [infinite-recursion]
>>> behavior pattern. This behavior pattern equally applies to the
>>> [infinitely nested simulation] behavior of H_Hat() relative to Halts().
>>>
>>> I cut-and-pasted this stuff from my five page paper. The above is
>>> explained on page one of my paper.
>>>
>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
>>>
>>> --
>>
>> How is the result of your paper helpful in practice (or in theory)?
>>
>
> The conventional halting problem proofs cease to prove that the halting problem
> cannot be solved. This provides the basis for the solution to the halting
> problem. https://en.wikipedia.org/wiki/Halting_problem
>
> The fundmental limits of algorithmic computation that were previously
> demonstrated by the halting problem proofs cease to exist.

You haven't refuted anything until you address the issue of program state and
branching logic predicated on that state.

/Flibble

--
😎

wij

unread,
May 9, 2021, 3:15:30 PM5/9/21
to
I feel the contents would not be appropriate in this place, moved to comp.theory
https://groups.google.com/g/comp.theory/c/cGaCqjMYHvs

olcott

unread,
May 10, 2021, 3:36:59 PM5/10/21
to
On 5/10/2021 2:22 PM, Mike Terry wrote:
> On 10/05/2021 19:44, olcott wrote:
>> On 5/10/2021 1:28 PM, Mr Flibble wrote:
>>> On 10/05/2021 19:18, olcott wrote:
>>>> On 5/10/2021 12:43 PM, Mr Flibble wrote:
>>>>> On 10/05/2021 18:07, olcott wrote:
>>>>>> On 5/10/2021 11:53 AM, Kaz Kylheku wrote:
>>>>>>> On 2021-05-10, olcott <No...@NoWhere.com> wrote:
>>>>>>>> On 5/10/2021 10:15 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 5/9/2021 8:21 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>> So when I am saying it my way this is still meaning your way
>>>>>>>>>>>> of saying
>>>>>>>>>>>> it, thus my way is not wrong.
>>>>>>>>>>>
>>>>>>>>>>> So I can quote "the fact that a computation halts does not
>>>>>>>>>>> entail that
>>>>>>>>>>> it is a halting computation" as something you still stand by?
>>>>>>>>>
>>>>>>>>> OK.  I'll take it that you still stand by that nonsense.  Do
>>>>>>>>> say if
>>>>>>>>> you've changed you mind.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Try and find the error here:
>>>>>>>>
>>>>>>>> The partial simulation X of a computation Y that is forced to stop
>>>>>>>> because the computation Y specifies infinite execution is a
>>>>>>>> computation
>>>>>>>> Y that halts and yet remains a non-halting computation.
>>>>>>>
>>>>>>> The error is believing that the above is happening in your program.
>>>>>>>
>>>>>>> Your program has a partial simulation which is forced to stop, but
>>>>>>> the calculation is halting: it is a false positive.
>>>>>>
>>>>>> When an execution trace matches the following criteria we know
>>>>>> that the non-halting behavior of infinite recursion or infinitely
>>>>>> nested simulation has been matched:
>>>>>>
>>>>>> If the execution trace of function Y() shows:
>>>>>>     (1)  function X() is called twice in sequence from the same
>>>>>> machine address of Y()
>>>>>>     (2)  with the same parameters to X()
>>>>>>     (3)  with no conditional branch or indexed jump instructions
>>>>>> in Y()
>>>>>>     (4)  with no function call returns from X() to Y()
>>>>>> then the function call from Y() to X() is infinitely recursive.
>>>>>>
>>>>>> There are only two possibilities that Halts(H_Hat, H_Hat) == 0 is
>>>>>> incorrect:
>>>>>> (1) The above criteria is incorrect.
>>>>>> (2) The behavior of H_Hat() does not match the above criteria
>>>>>>
>>>>>> How much longer are you going to dishonestly avoid this direct
>>>>>> review?
>>>>>
>>>>> Why do you copy/paste the same reply to different threads?
>>>>
>>>> I will continue to post this challenge to everyone that continues to
>>>> dishonestly dodge the proof that I am correct until they stop
>>>> dishonestly dodging this proof by changing the subject away from
>>>> this proof.
>>>
>>> Mate, take your meds and get a better hobby; this current hobby of
>>> yours appears  soul destroying to the casual observer.
>>>
>>> /Flibble
>>>
>>
>> Upon deeper review by a qualified technical reviewer it is easy to see
>> that this is not the case. As you can see from my recent posts Mike
>> Terry has already agreed that I am correct On 11/20/2020 9:30 PM, Mike
>> Terry wrote... see this post: (or the original)
>>
>> Re: Halting problem undecidability and infinite recursion [ Mike
>> agrees proof is correct ]
>>
>
> Now you're being childish - you know perfectly well that I have never
> agreed that your "proof" is correct.  So you are deliberately
> misrepresenting my views (again).

http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf

This is from my current proof.

void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}

This is agreement that Halts() correctly decides H_Hat() as non-halting
thus perfect agreement with the entire conclusion of my current proof.

On 11/20/2020 9:30 PM, Mike Terry wrote:
> On 21/11/2020 02:45, olcott wrote:
>> void H_Hat(u32 P)
>> {
>> u32 Aborted = Halts(P, P);
>> if (Aborted)
>> HALT
>> else
>> HERE: goto HERE;
>> }
>>
>>
>> int main()
>> {
>> u32 P = (u32)H_Hat;
>> Halts(P, P);
>> HALT;
>> }
>>
>> (2) It is known that the above code is infinitely recursive if Halts()
>> acts like a UTM and simulates its input returning true if and only if
>> its input halts.
>
> Yes, we have infinite "recursive emulation".
>
>>
>> (3) On the basis of (1) and (2) It is known that a correct halt decider
>> must return false.
>
> There is no such thing as a "correct halt decider" for all inputs, but
> input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
> described. This is all baby stuff. [So the correct halting decision
> for the input is non-halting].
0 new messages