Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

We are drowning in information but starved for knowledge. -- John Naisbitt, Megatrends


computers / comp.ai.philosophy / Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct_and_forms_no_contradiction.

SubjectAuthor
o Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct_and_forms_no_contradiction.olcott

1
Subject: Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct_and_forms_no_contradiction.
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Thu, 12 Aug 2021 02:03 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 11 Aug 2021 21:03:12 -0500
Subject: Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct_and_forms_no_contradiction.
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87tuk52h0e.fsf@bsb.me.uk> <zcadnTSOD5rtZ5f8nZ2dnUU7-T3NnZ2d@giganews.com> <877dh03l3c.fsf@bsb.me.uk> <Z5adnd038KGXwJb8nZ2dnUU7-I_NnZ2d@giganews.com> <8735rn1qvj.fsf@bsb.me.uk> <goydnfCCIYUWE5H8nZ2dnUU7-e_NnZ2d@giganews.com> <87eeb7z4d1.fsf@bsb.me.uk> <0_Sdnb6Qe8XGOZH8nZ2dnUU7-U3NnZ2d@giganews.com> <87zgtslqpv.fsf@bsb.me.uk> <4JOdnRS2SLR7MYz8nZ2dnUU7-YnNnZ2d@giganews.com> <87zgtoizgp.fsf@bsb.me.uk> <Z6ednWt7SpIIv478nZ2dnUU7-WHNnZ2d@giganews.com> <87pmukiwr5.fsf@bsb.me.uk> <5c6dnbn2gMMIsI78nZ2dnUU7-dnNnZ2d@giganews.com> <87eeb0iuo1.fsf@bsb.me.uk> <2-adncuMeNUVpY78nZ2dnUU7-fPNnZ2d@giganews.com> <87o8a4ggzf.fsf@bsb.me.uk> <XfGdncywcvvmdI78nZ2dnUU7-fednZ2d@giganews.com> <87v94bfus2.fsf@bsb.me.uk> <GKSdnVVNYtzbx4n8nZ2dnUU7-THNnZ2d@giganews.com> <8735rffoh2.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Wed, 11 Aug 2021 21:03:11 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <8735rffoh2.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <BaednXQRjpr9HIn8nZ2dnUU7-SvNnZ2d@giganews.com>
Lines: 212
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Fz8BmcGxcGd1kP7NBnsNYnqzx/Nc55q31gxuDxeFBW7Gnq5LjToeC+qjZ801658Xues+xVwDcOuFVDI!6ePQ1YoD9Aw1ilRJt7YpzZbva9g4y6HLC79K/OVBSOFha2IgMPXMRpLBzL97cRO2QBuisCOKMg==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 10981
View all headers
On 8/11/2021 8:20 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 8/11/2021 6:04 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 8/11/2021 10:04 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

I went point by point. If I am actually incorrect then you can go
point by point and point out each individual error step by step.
You fail at the first hurdle.  You can't hope to persuade anyone that an
add function with add(2, 3) == 9 is operating as specified simply by
detailing, step by step, exactly how you implement the wrong behaviour.
In your case, it's simply that Ĥ.q0 ⟨Ĥ⟩ transitions to Ĥ.qn (via Ĥ.qx
⟨Ĥ⟩ ⟨Ĥ⟩ as you pointlessly keep insisting) when Linz says it should not.
Your add function is entirely correct in that is does exactly what you
intend it to do.  As far as I am concerned there is no significant error
in how you arrive at add(2, 3) == 9.  The problem is that Linz says your
code should add numbers and not do whatever it is your code does with
100% correctness.  Do you follow?

Of course
everyone knows that this is impossible if I am totally correct.
Then stop wasting time and try to publish!  You'll need lots of time to
explain away why every editor simply laughs at the paper.

H.q0 WM w ⊢* Ĥ.qn
becomes
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
Yes, we all know that.  It's exactly why your Ĥ does not meet Linz's
specification (for this case -- you don't claim to have a halt decider).

Can you admit when you are wrong when you really are wrong?
Yes.  I am wrong all the time.  In this case I'm having trouble working
out how I could be clearer about your Ĥ.  Maybe if you didn't keep
removing the key text from Linz's explanations it might sink in?


Pages of the Linz text to verify the above quotes in their full context:
http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
I see you are in "paste the same text" again mode.  If you think I can
help in any way, do let me know.

I just noticed that you acknowledged that M refers to the TM
represented by the first input parameter to Ĥ.qx wM wM

Did I?  Oh dear.  It's garbage.  Where did I "acknowledge" it?  I'd like
to go back and point out that it's mathematical junk.

so we can move to the next point:

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and

This is just a metaphorical math poem.  You've taken a mathematical
statement and substituted for only some on the occurrences of a
variable.  That is a schoolboy error.


That seems to be a very stupid thing to say when it only clarifies and corrects Linz.

Maybe you confused agreement with "can't be bothered to go of on a
tangent about a math poem".  I certainly let many meaningless things you
write slip by unremarked upon.  There are not enough hours in the day to
point out all your mistakes.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn // see highlighted portion of Linz text
to confirm:
if M applied to wM does not halt // M refers to the TM of the first wM
parameter to Ĥ.qx

Linz requires that

   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
   if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt.


Sure and the Ĥ being referred to is the one that the first param to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ specifies.

Unlike your garbage, this makes sense because all occurrences of M and
the derived wM have now been substituted for actual values -- your Ĥ and
its encoding.

Here is the overview of what I am claiming:
Turing machine Ĥ is applied to its input ⟨Ĥ⟩.

   Ĥ.q0 ⟨Ĥ⟩

It copies this input such that this input and the copy of this input
become the first and second parameters to the simulating halt decider
at Ĥ.qx.

   ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩

When Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ decides that the simulation of its first parameter
on the input of its second parameter never halt it correctly
transitions to its own final state of Ĥ.qn.

   ⊢* Ĥ.qn

None of which (other than your poor use of technical terms) has been in
doubt for months.
  

You sure acted like M only referred to the first Ĥ shown below:
 >    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 >    if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt.

It is easy to see that when the halt decider at Ĥ.qx is a simulating
halt decider that there is an infinite cycle from Ĥ.qx to Ĥ.q0 that
prevents the input from every reaching its final state.

If Ĥ were not written as you have chosen to write it -- if it were
instead a pure simulator, then

   ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ∞


This: Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
specifies an infinite cycle from Ĥ.qx to Ĥ.q0 while the simulating halt decider at Ĥ.qx acts as a UTM.

would be the case.  Mathematicians would avoid this messy language and
the possibility of confusion by not re-using the name Ĥ for both your
partial decider and one based on pure simulation.


Since it is the very same machine in two different modes of operation this seems really stupid.

This <is> the same Ĥ that Linz specifies with the extra detail of how this wildcard state transition works: ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Also, you are wrong about the cycles of states, but that's because you
have no clue how a TM would simulate another TM.

No one ever investigates this because their paper on the subject would be millions of pages long if it included a full listing of the source code. If we add the single feature of random access memory TMs would be 100,000-fold less tedious.

 It's a rabbit hole we
shouldn't go down, because (a) I don't think you could ever understand
how a UTM really works, and (b) it's irrelevant since I agree that there
would be infinite execution if Ĥ were not as it is but were, instead, a
pure simulator.


Great. This is a big breakthrough.

When we define halting as reaching a final state

Ĥ applied to ⟨Ĥ⟩ halts.  The computation reaches the final state Ĥ.qn.


Yes. The halting problem is not about programs that halt. It is about inputs to a halt decider. The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

so that we can unequivocally divide computations that complete from
those that are aborted,

So this is today's equivocation.  TM computations either halt or they
don't halt.  None of them "abort".


I am concurrently perfecting my understanding of the technical terms via Linz. A TM can also be said to halt if there is no transition out of the current state. Ultimately I only need a clear and unequivocal way to divide computations that reach their natural conclusion from ones that have had their simulation aborted.

then we know that the input to Ĥ.qx never
halts, thus making its halt status decison correct.

Garbled.  Inputs don't halt or not halt.  Your Ĥ does not meet Linz's
spec because Ĥ applied to ⟨Ĥ⟩ halts when it should not.  You don't get
to say it does because it halts in what you think of as special way.


That is like saying because we know the liar paradox: "this sentence is not true" is not true then it must be true.

My purpose of creating the x86utm operating system was so that every single detail of the halting problem counter-examples can be completely examined.

It is perfectly analogous in every way to the Linz Ĥ.
We can see that int main() { P(P); } halts and that the input to H(P,P) cannot possibly halt. That is a lot like finding a cat that barks.

No one besides me has ever bothered to examine every single detail of H(P,P) to see that its input really cannot possibly halt.

They are all so egotistically caught up in their own opinion that the fact that int main() { P(P); } halts proves that H(P,P)==0 must be incorrect.

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

--
Copyright 2021 Pete Olcott

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


1
rocksolid light 0.7.2
clearneti2ptor