XPost: comp.theory, sci.logic, sci.math

On 9/30/2021 6:14 PM, Ben Bacarisse wrote:

olcott <[email protected]> writes:

On 9/30/2021 11:35 AM, Ben Bacarisse wrote:

olcott <[email protected]> writes:

On 9/29/2021 9:42 PM, Ben Bacarisse wrote:

olcott <[email protected]> writes:

H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just said
H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just said
H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just said
H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just said
H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just said

But you previously also said that H(<Ĥ>,<Ĥ>) ⊢* H.qn. You can't get mad
because people believe what you write!
Now I need to know how much of the post where you said that your new >>>>> basis for halting gives H(<Ĥ>,<Ĥ>) ⊢* H.qn was /also/ wrong. All of it?
It formed what appeared to be your entire justification for having
"solved" the halting problem. Here is the whole thing:
| My current proof simply shows exactly how the exact Peter Linz H would >>>>> | correctly decide not halting on the exact Peter Linz Ĥ.
|
| This definition of halting circumvents the pathological self-reference >>>>> | error for every simulating halt decider:
|
| An input is decided to be halting only if its simulation never needs >>>>> | to be stopped by any simulating halt decider anywhere in its entire >>>>> | invocation chain.
|
| On that basis:
| Ĥ(<Ĥ>) ⊢* Ĥ.qn
| H(<Ĥ>,<Ĥ>) ⊢* H.qn

It seems a little shady that you don't cut-and-paste it with the time
and date stamp as I ALWAYS do.

It's Message-ID: <[email protected]>
Are you accusing me of misquoting you?

I am accusing you of not providing proper support for your assertions.

Good. So you do agree that you said it?

A cut-and-paste of my actual question that includes the time and date
stamp is the standard that I established for myself.

I post a message ID if anyone is having trouble finding a post.

You, presumably, knew all along that you have redefined what halting
means so that H and H^ are no longer like Linz's H and H^. You,
presumably, knew that with your definition H can reject a halting computation. After all, that's what everyone has been objecting to for
the last few years. You can't have only just noticed that this is what people have been telling you.

If the above is an accurate quote (which has not been properly
established) then--->H(<Ĥ>,<Ĥ>) ⊢* H.qn is a typographical error.

This is an appallingly dishonest claim. There is no possibility it is a typo. Why would you even try to pretend that it is? You say the same
thing again in another post

H(<Ĥ>,<Ĥ>) ⊢* H.qn
Message-ID: <[email protected]>

and again using words this time

H applied to input (Ĥ, Ĥ) transitions to H.qn
Message-ID: <[email protected]>

and again in words

H(<Ĥ>,<Ĥ>) must abort the simulation of its input ∴ this input <is>
correctly decided as non-halting.
Message-ID: <[email protected]>

and again using a slightly different notion here

H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
Message-ID: <[email protected]>

And then there is the fact that you've been saying exactly this in other
ways for months:

"Halts(Confound_Halts, Confound_Halts) returns false."
Message-ID: <[email protected]>

and

"The input to Halts is only finite because..."
Message-ID: <[email protected]>

And H(H_Hat, H_Hat) == false though H_Hat(H_Hat) halts. Post after post explaining why H(H_Hat, H_Hat) == 0 with H_Hat(H_Hat) halting might
/seem/ wrong but is in fact correct because of how you define halting.

No, it is not a typo. You are lying. You meant what you wrote, and
people have been addressing what you now pretend is a typo for months.
The scale of the dishonesty takes my breath away.

I could explain why you are wrong to say

Ĥ(<Ĥ>) ⊢* Ĥ.qn and H(<Ĥ>,<Ĥ>) ⊢* H.qy

but what's the point? You'll just claim that this was also a typo in a
few months time. You can keep this up forever if you have no attachment
to honesty or the truth.

You quoted me from five months ago my view has changed.
Here is my view now.

If you want to try to form an actual rebuttal and not just some form of
the strawman error that looks like a rebuttal to gullible fools that are
hardly paying attention you must address the following POINT-BY-POINT.

(A) Ĥ(<Ĥ>) ⊢* Ĥ.qn
(B) Ĥ.qx(<Ĥ>,<Ĥ>) ⊢* H.qn

Your whole basis of rebuttal from the beginning has been that (B) must
be wrong because it disagrees with the actual behavior of (A).

Now that I know that H(<Ĥ>,<Ĥ>) ⊢* H.qy
I have directly contradicted the Linz conclusion.

The contradiction tells us that our assumption
of the existence of H, and hence the assumption
of the decidability of the halting problem, must
be false. (Linz:1990:320)

https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (318-320)

Ĥ.qx(<Ĥ>,<Ĥ>) ⊢* H.qn is correct because the simulation of <Ĥ> applied
to <Ĥ> never reaches any final state whether or not the simulating halt decider at Ĥ.qx aborts its simulation of this input.

You can dishonestly call this another different halting problem yet you
know damn well it is the original halting problem.

That a computation never reaches its final state when this computation
is allowed to continue unabated is the very conventional definition of
not halting.

I don't know the proper way to say this because the definition of a
computation is restricted to sequence of steps that halts. This makes
non halting computations a contradiction in terms.

--
Copyright 2021 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 10/1/2021 12:17 PM, Richard Damon wrote:

On 10/1/21 1:04 PM, olcott wrote:

On 10/1/2021 11:55 AM, Jeff Barnett wrote:

On 10/1/2021 10:27 AM, Andy Walker wrote:

On 01/10/2021 15:12, Mike Terry wrote [to PO, of course]:

Of course an /unrestricted/ x86 program can do that [...]
If you are concerned with saying things of relevance to TMs and
Linz's proof, you need to limit your C code to doing things that
directly correspond with what TMs can do. [...]

     I think it is misleading to talk about what TMs can do as
thought they are interestingly different from what x86 programs or
any real computer can do.  An x86 computer /is/ a FSM with extra
storage;  in other words, a TM.  We tend to write rather simple
TMs to illustrate points, but there is no reason why it should
not have 2^N states, where N is rather large [the number of bits
in your computer].  "Taking the address of a function" is not
"difficult" with a TM, just rather tedious.

     There is no reason why someone [I'm not volunteering!]
should not write a C compiler the target of which is recognisably
a TM.  It's just going to be rather complicated.  [Probably easier,
AAMOF, to write a microcode as a TM, and describe real computers
in terms of that microcode.  In the 1930s, that would have seemed
like magic, but it is how many/most modern computers work.]

     That's why I think people are barking up the wrong tree
when complaining that PO writes C code that is "not a function".
It doesn't matter.  It just means that the "hat" construction
is more complicated than PO claims, inc all the states [etc] of
the FSM, inc "hidden" variables.  The real errors lie elsewhere.

I think what people are trying to say and may be saying badly is that
the set of things that can influence an execution must all be
considered part of that execution. Trivial but important. Said another
way apropos to the current conversation is that when you propose
something to play the role of the Linz H, the definition of that
something must include everything that influences its execution. PO
doesn't do that. 'It' also keeps the piece he calls H from being
function- or computation-like. One of the "rules" of software
reasoning is that one must carefully delimit the boundaries of what
one is talking about. This basic guideline has been ignored into
oblivion.

It is very difficult to confirm that a [computable function]
https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions


Must be a [pure function]
https://en.wikipedia.org/wiki/Pure_function

When no official source say this.

None-the-less my partial halt deciders {H1, H} are being transformed
into [pure functions] that take finite string inputs. Also my C/x86
equivalent P of the Linz Ĥ will copy its input so that it more closely
conforms to the Linz Ĥ.

Because they are different concepts and don't actually map directly into
each other.

A Computatble Function will tend to naturally be a Pure Function, but it
is possible to make a Computable Function out of limited forms of
non-Pure Functions (for example, caching of results to avoid recomputing already computed results).

It is also possible of a Pure Function to not be a Computatble Function
if the pure function depends in some way on the address that it is being
run from. The concept of Pure Functions deal with a single instance of
it always mapping input to output, while a Computable Function deals
with a UNIVERSAL mapping of input to output of ALL copies of it.

Pure Functions are inplementations in physical hardware.

Computable Functions are mathematical abstractions.

Some of the stuff that you say is well reasoned and can be confirmed.
Some of it is pure bullshit, simply talking out of your ass.

The key pure bullshit item was either you or André that simply rejected
the whole idea of a simulating halt decider out-of-hand.

This is the key basis of my whole proof:
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.

How a simulating halt decider determines that its input is an instance
of infinitely nested simulation is merely an implementation detail.

As long as a simulating halt decider can determine this by one means or another, then the conventional halting theorem proofs have been refuted.

--
Copyright 2021 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)