olcott <NoOne@NoWhere.com> writes:
On 9/30/2021 11:35 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/29/2021 9:42 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
H(<Ĥ>,<Ĥ>) ⊢* H.qy as I just saidBut you previously also said that H(<Ĥ>,<Ĥ>) ⊢* H.qn. You can't get mad
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
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: <FL2dnU-wypwbXz_9nZ2dnUU7-d_NnZ2d@giganews.com>
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: <M9Kdnab-FpOgUD_9nZ2dnUU7-UHNnZ2d@giganews.com>
and again using words this time
H applied to input (Ĥ, Ĥ) transitions to H.qn
Message-ID: <0cudnXyibs7OuDz9nZ2dnUU7-QfNnZ2d@giganews.com>
and again in words
H(<Ĥ>,<Ĥ>) must abort the simulation of its input ∴ this input <is>
correctly decided as non-halting.
Message-ID: <_LednVXB0N9FGT_9nZ2dnUU7-RWdnZ2d@giganews.com>
and again using a slightly different notion here
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
Message-ID: <2-adncuMeNUVpY78nZ2dnUU7-fPNnZ2d@giganews.com>
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: <2aidnV9e3qQaOCDCnZ2dnUU7-c3NnZ2d@giganews.com>
and
"The input to Halts is only finite because..."
Message-ID: <6eSdnYuLBrIuVFzCnZ2dnUU7-cPNnZ2d@giganews.com>
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.
On 10/1/21 1:04 PM, olcott wrote:
On 10/1/2021 11:55 AM, Jeff Barnett wrote:Because they are different concepts and don't actually map directly into
On 10/1/2021 10:27 AM, Andy Walker wrote:
On 01/10/2021 15:12, Mike Terry wrote [to PO, of course]:I think what people are trying to say and may be saying badly is that
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.
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 Ĥ.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 366 |
Nodes: | 16 (2 / 14) |
Uptime: | 26:27:14 |
Calls: | 7,832 |
Calls today: | 1 |
Files: | 12,933 |
Messages: | 5,771,099 |