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

Re: SOLUTION TO THE HALTING PROBLEM!

19 views
Skip to first unread message

olcott

unread,
Oct 29, 2020, 8:15:08 AM10/29/20
to
On 10/29/2020 1:13 AM, Graham Cooper wrote:
> On Thursday, October 29, 2020 at 1:17:46 PM UTC+10, olcott wrote:
>> On 10/28/2020 9:44 PM, Graham Cooper wrote:
>>> what about Linz counter example ?
>>>
>>> loops(loops)
>>> if halt( loops loops) then loops(loops)
>>>
>>>
>>> if loops(loops) definitely halts what is the value of halt(loops,loops) ?
>>>
>> The RASP is a random-access machine (RAM) model that, unlike the RAM,
>> has its program in its "registers" together with its input. The
>> registers are unbounded (infinite in capacity); whether the number of
>> registers is finite is model-specific. Thus the RASP is to the RAM as
>> the Universal Turing machine is to the Turing machine. The RASP is an
>> example of the von Neumann architecture whereas the RAM is an example of
>> the Harvard architecture.
>>
>> https://en.wikipedia.org/wiki/Random-access_stored-program_machine
>>
>> x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
>>
>> I just completed one man-year's worth of work creating the x86utm
>> operating system that correctly decides the Linz counter-example as
>> non-halting.
>
>
> RIGHT! the counter-example doesn't halt
>
>
> loops(loops)
> if halt( loops loops)-X then loops(loops)
>
> halt doesn't return TRUE or FALSE though, it goes into an infinite loop at X

I spent a man year developing the x86utm operating system so that I
could show every single detailed step of exactly how and why the Linz
halt decider halts in its ((qn)) state.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine

The reason that a halt decider can actually decide that the Linz H_Hat
does not halt is based on the fact that it gets stuck in infinite
recursion before it ever reaches its undecidable states. We can tell
that it gets stuck in infinite recursion because it invokes the halt
decider a second time from the same machine address without any
conditional instructions in its execution trace in-between that would
terminate this otherwise infinite recursion. I derived this solution
2018-12-13 @ 7:00 PM.

--
Copyright 2020 Pete Olcott

Mostowski Collapse

unread,
Oct 29, 2020, 9:01:58 AM10/29/20
to
For gods sacke stop cross posting on 4 newsgroups.

Especially comp.lang.prolog doesn't make much sense.

RAM/RASP is probably best housed on comp.theory.

olcott schrieb:
> I am a complete imbecial spammer

olcott

unread,
Oct 29, 2020, 9:05:08 AM10/29/20
to
On 10/29/2020 7:51 AM, Richard Damon wrote:
> On 10/29/20 8:14 AM, olcott wrote:
>> I spent a man year developing the x86utm operating system so that I
>> could show every single detailed step of exactly how and why the Linz
>> halt decider halts in its ((qn)) state.
>>
>> x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
>>
>> The reason that a halt decider can actually decide that the Linz H_Hat
>> does not halt is based on the fact that it gets stuck in infinite
>> recursion before it ever reaches its undecidable states. We can tell
>> that it gets stuck in infinite recursion because it invokes the halt
>> decider a second time from the same machine address without any
>> conditional instructions in its execution trace in-between that would
>> terminate this otherwise infinite recursion. I derived this solution
>> 2018-12-13 @ 7:00 PM.
>
> The amount of time you wasted on this isn't the issue. It is that fact
> that you still get the answer wrong. HOW the halt decider works isn't
> really interesting, it is the answer it gives.

This has never been shown.

> Let us look at a slight variation of Linz, that has a clear answer,
>
> H_Hat2(N) does the same replication has H_Hat, calls H(N, N) like H_Hat,
> but then halts whether H says halts or not. Clearly H_Hat2 halts, it has
> no choice other than that. Simple inspection makes it clear that it MUST
> halt (as H by its definition must have finite execution), and there is
> no loops outside of H.
>
> But, run H(H_Hat2) and you decider will say that it has to be abort due
> to infinite execution, because your H is faulty, fundamentally by its
> structure. This says that your 'Halted'/'Needed to be Aborted' isn't
> even a close alternative to the original 'Halted'/'Non-halting'
> decision. Thus your revised halting problem says nothing about the
> original problem Linz was dealing with.

I defined a single non-halting decider that has no undecidable input.
That halt deciders can be defined that have different behavior is simply
off topic. The point is to try to find undecidable input for the decider
that I defined.

> Again, this is like the classical Trisect an angle with compass and
> straight edge, and saying you did it by bisection the angle twice, or
> assuming the angle is known (like 90 degrees).


Unless you can translate your strange analogy into an undeciadble input
it is useless.

Mostowski Collapse

unread,
Oct 29, 2020, 2:39:56 PM10/29/20
to
For gods sacke stop cross posting on 4 newsgroups.

Especially comp.lang.prolog doesn't make much sense.

RAM/RASP is probably best housed on comp.theory.

olcott schrieb:
> On 10/29/2020 1:13 AM, Graham Cooper wrote:
> I am a brainless mud turtle

olcott

unread,
Oct 29, 2020, 2:44:00 PM10/29/20
to
On 10/29/2020 1:39 PM, Mostowski Collapse wrote:
> For gods sacke stop cross posting on 4 newsgroups.
>
> Especially comp.lang.prolog doesn't make much sense.
>
> RAM/RASP is probably best housed on comp.theory.

Yes I agree yet this is the final culmination of my life's work and I
have stage III cancer so I have to take some shortcuts.

>
> olcott schrieb:
>> On 10/29/2020 1:13 AM, Graham Cooper wrote:
>> I am a brainless mud turtle


--
Copyright 2020 Pete Olcott

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

Mostowski Collapse

unread,
Oct 29, 2020, 3:50:09 PM10/29/20
to
Hey guys, I never use side channels and usenet
at the same time. So this is my response to KT:

------------ cut here ----------------------

There is nevertheless a point in using usenet.
Because now you use side channels and covert

communication, which makes results non
reproducible or implausible.

Keith Thompson schrieb:
> There was no point in posting my message on the newsgroup when it was
> directed only at you.
>
> On Thu, Oct 29, 2020 at 12:10 PM j4n bur53 wrote:
>> its unusal to send personal email, when you
>> can offer your opinion on usenet.
>>
>> Keith Thompson schrieb:
>>> Mostowski Collapse <janb...@fastmail.fm> writes:
>>>> For gods sacke stop cross posting on 4 newsgroups.
>>>>
>>>> Especially comp.lang.prolog doesn't make much sense.
>>>>
>>>> RAM/RASP is probably best housed on comp.theory.
>>>>
>>>> olcott schrieb:
>>>>> I am a complete imbecial spammer
>>> You're not helping. olcott has made it clear that he's going to
>>> continue cross-posting. Posting *in the same groups* isn't going
>>> to change his mind. It only annoys the rest of us.

Keith Thompson

unread,
Oct 29, 2020, 4:10:20 PM10/29/20
to
Mostowski Collapse <janb...@fastmail.fm> writes:
> Hey guys, I never use side channels and usenet
> at the same time. So this is my response to KT:
>
> ------------ cut here ----------------------
>
> There is nevertheless a point in using usenet.
> Because now you use side channels and covert
>
> communication, which makes results non
> reproducible or implausible.
>
> Keith Thompson schrieb:
>> There was no point in posting my message on the newsgroup when it was
>> directed only at you.
[snip]

I sent you an email message. I did not intend it to be public. You
chose to quote and reply to it publicly, something I didn't ask you to
do and would have preferred that you hadn't.

Your response to olcott's inappropriate cross-posting has simply made
the situation worse. Please drop this.

PLONK.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
0 new messages