On 3/3/22 7:25 PM, olcott wrote:
On 3/3/2022 6:17 PM, Richard Damon wrote:
On 3/3/22 7:08 PM, olcott wrote:
On 3/3/2022 5:50 PM, Richard Damon wrote:
On 3/3/22 10:52 AM, olcott wrote:
On 3/2/2022 9:30 PM, Richard Damon wrote:
On 3/2/22 10:21 PM, olcott wrote:
On 3/2/2022 8:43 PM, Richard Damon wrote:
On 3/2/22 9:36 PM, olcott wrote:
On 3/2/2022 8:33 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 5:16 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:You have proven that you do not understand that deciders >>>>>>>>>>>> ONLY compute
On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 11:07 AM, Ben Bacarisse wrote:I can't parse that sentence but it contains no hint that >>>>>>>>>>>>>>> you have looked
olcott <NoOne@NoWhere.com> writes:
Like I said my only reply to you will be to keep >>>>>>>>>>>>>>>> repeating the keyLinz confuses himself my making the TM descriptions >>>>>>>>>>>>>>>>>> less than a clear
as possible.
Have you looked at Linz's actual proof yet? It's >>>>>>>>>>>>>>>>> theorem 12.2, a page
further on from the one you seem to be obsessed by. >>>>>>>>>>>>>>>>
points that you failed to address until you address them >>>>>>>>>>>>>>>> completely.
at Linz's proof yet.
Do you understand that a decider computes the mapping ONLY >>>>>>>>>>>>>> from its
inputs to an accept or reject state and does not compute >>>>>>>>>>>>>> any other
mapping?
So no, you have not looked at Linz's proof yet.
By the way, I am not going to answer patronising questions. >>>>>>>>>>>>> But by all
means ask me to tell you what a decider is, provided you >>>>>>>>>>>>> are prepared to
use that definition (and terminology) in future exchanges. >>>>>>>>>>>>
the mapping from their inputs to an accept or reject state by >>>>>>>>>>>> perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ >>>>>>>>>>>> has anything
to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.
If you are prepared to learn with an open mind, I can take >>>>>>>>>>> you through
some exercises that will explain to you why this objection is >>>>>>>>>>> groundless. Of course, you can continue to spout nonsense -- >>>>>>>>>>> that's no
problem for me -- but you claim to want to talk about this >>>>>>>>>>> problem, and
that involves understanding which strings to accept and which >>>>>>>>>>> reject.
You simply ignored my proof of my point proving that you are >>>>>>>>>> dishonest.
Nope, you ignore the proofs that you are wrong, AND a Liar.
Most often your rebuttals are only confused gibberish.
Your key mistake is not having the slightest idea of how
simulating halt deciders work even though I have explained it
many hundreds of times.
You keep thinking that if a simulating halt decider must abort >>>>>>>> its simulation to report that its input specifies a non-halting >>>>>>>> sequence of configurations that this makes this input halt and >>>>>>>> thus the reported non-halting wrong.
_Infinite_Loop()
[00000946](01) 55 push ebp
[00000947](02) 8bec mov ebp,esp
[00000949](02) ebfe jmp 00000949
[0000094b](01) 5d pop ebp
[0000094c](01) c3 ret
Size in bytes:(0007) [0000094c]
The above specifies an infinite loop even when its simulation
has been aborted to report "infinite loop".
It isn't the decider aborting that makes H^ Halting, it is H
going to H.Qn that makes H^ non-halting (since H^ x will always
go to H^.Qn and halt if H x x goes to H.Qn)
As I have said many dozens of times now
NON-HALTING CRITERION MEASURE
It is universally true that when-so-ever a simulating halt decider >>>>>> must abort the simulation of its input to prevent the infinite
simulation of this input that this input specifies an infinite
sequence of configurations.
Basic GIGO. (Garbage-In, Garbage-Out)
Start with the wrong definition, you get the wrong asnwers.
This is NOT the right definition for Halting, and unless you can
actually PROVE that this has been accepted by a reputable source,
that you hae taken it from, it is just PROOF that you WHOLE logic
argument is unsound.
It is self-evidently correct,
that you deny this is because it is over your head.
'Self-evident' is NOT valid proof in formal logic.
When we extend formal logic using something like Montague Grammar of
natural language semantics the common English meaning of
"self-evident" becomes {semantic tautology}.
Ordinary logic (as it was changed after Aristotle's syllogism) is not
sufficiently expressive to encode semantics directly, it needs model
theory to help with this.
You don't get to change the logic.
FAIL.
Just shows you don't know the rules of Logic.
FAIL.
On 3/3/22 8:08 PM, olcott wrote:
On 3/3/2022 6:39 PM, Richard Damon wrote:
On 3/3/22 7:25 PM, olcott wrote:
On 3/3/2022 6:17 PM, Richard Damon wrote:
On 3/3/22 7:08 PM, olcott wrote:
On 3/3/2022 5:50 PM, Richard Damon wrote:
On 3/3/22 10:52 AM, olcott wrote:
On 3/2/2022 9:30 PM, Richard Damon wrote:
On 3/2/22 10:21 PM, olcott wrote:
On 3/2/2022 8:43 PM, Richard Damon wrote:
On 3/2/22 9:36 PM, olcott wrote:Most often your rebuttals are only confused gibberish.
On 3/2/2022 8:33 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 5:16 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:You have proven that you do not understand that deciders >>>>>>>>>>>>>> ONLY compute
On 3/2/2022 4:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/2/2022 11:07 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:I can't parse that sentence but it contains no hint >>>>>>>>>>>>>>>>> that you have looked
Like I said my only reply to you will be to keep >>>>>>>>>>>>>>>>>> repeating the keyLinz confuses himself my making the TM descriptions >>>>>>>>>>>>>>>>>>>> less than a clear
as possible.
Have you looked at Linz's actual proof yet? It's >>>>>>>>>>>>>>>>>>> theorem 12.2, a page
further on from the one you seem to be obsessed by. >>>>>>>>>>>>>>>>>>
points that you failed to address until you address >>>>>>>>>>>>>>>>>> them completely.
at Linz's proof yet.
Do you understand that a decider computes the mapping >>>>>>>>>>>>>>>> ONLY from its
inputs to an accept or reject state and does not compute >>>>>>>>>>>>>>>> any other
mapping?
So no, you have not looked at Linz's proof yet.
By the way, I am not going to answer patronising >>>>>>>>>>>>>>> questions. But by all
means ask me to tell you what a decider is, provided you >>>>>>>>>>>>>>> are prepared to
use that definition (and terminology) in future exchanges. >>>>>>>>>>>>>>
the mapping from their inputs to an accept or reject state by >>>>>>>>>>>>>> perpetually insisting that the behavior a non-input Ĥ ⟨Ĥ⟩ >>>>>>>>>>>>>> has anything
to do with the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.
If you are prepared to learn with an open mind, I can take >>>>>>>>>>>>> you through
some exercises that will explain to you why this objection is >>>>>>>>>>>>> groundless. Of course, you can continue to spout nonsense >>>>>>>>>>>>> -- that's no
problem for me -- but you claim to want to talk about this >>>>>>>>>>>>> problem, and
that involves understanding which strings to accept and >>>>>>>>>>>>> which reject.
You simply ignored my proof of my point proving that you are >>>>>>>>>>>> dishonest.
Nope, you ignore the proofs that you are wrong, AND a Liar. >>>>>>>>>>
Your key mistake is not having the slightest idea of how
simulating halt deciders work even though I have explained it >>>>>>>>>> many hundreds of times.
You keep thinking that if a simulating halt decider must abort >>>>>>>>>> its simulation to report that its input specifies a
non-halting sequence of configurations that this makes this >>>>>>>>>> input halt and thus the reported non-halting wrong.
_Infinite_Loop()
[00000946](01) 55 push ebp
[00000947](02) 8bec mov ebp,esp
[00000949](02) ebfe jmp 00000949
[0000094b](01) 5d pop ebp
[0000094c](01) c3 ret
Size in bytes:(0007) [0000094c]
The above specifies an infinite loop even when its simulation >>>>>>>>>> has been aborted to report "infinite loop".
It isn't the decider aborting that makes H^ Halting, it is H >>>>>>>>> going to H.Qn that makes H^ non-halting (since H^ x will always >>>>>>>>> go to H^.Qn and halt if H x x goes to H.Qn)
As I have said many dozens of times now
NON-HALTING CRITERION MEASURE
It is universally true that when-so-ever a simulating halt
decider must abort the simulation of its input to prevent the
infinite simulation of this input that this input specifies an >>>>>>>> infinite sequence of configurations.
Basic GIGO. (Garbage-In, Garbage-Out)
Start with the wrong definition, you get the wrong asnwers.
This is NOT the right definition for Halting, and unless you can >>>>>>> actually PROVE that this has been accepted by a reputable source, >>>>>>> that you hae taken it from, it is just PROOF that you WHOLE logic >>>>>>> argument is unsound.
It is self-evidently correct,
that you deny this is because it is over your head.
'Self-evident' is NOT valid proof in formal logic.
When we extend formal logic using something like Montague Grammar of
natural language semantics the common English meaning of
"self-evident" becomes {semantic tautology}.
Ordinary logic (as it was changed after Aristotle's syllogism) is
not sufficiently expressive to encode semantics directly, it needs
model theory to help with this.
You don't get to change the logic.
Actually, yes I do.
When logic diverged from Aristotle's syllogism it ceased to be a
consistent system of correct reasoning.
Nope, Aristotle doesn't control the meaning of logic in Mathemetics (or
in fact in ANY branch that doesn't accept it).
YOU can choose to limit yourself to it, and limit your ability to reason about some fields that go beyond it.
All you have proven is that you reject the ability to talk about the
whole of Mathematics.
FAIL.
The correction to sound reasoning is:
Applying truth preserving operations beginning with premises that are
known to be true such that the conclusion is a necessary consequence
of these true premises.
WRONG. FAIL.
The correction to valid reasoning is:
Applying truth preserving operations beginning with premises that may
be false such that the conclusion is a necessary consequence of these
premises.
WRONG. FAIL.
FAIL.
Just shows you don't know the rules of Logic.
FAIL.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 365 |
Nodes: | 16 (2 / 14) |
Uptime: | 26:37:35 |
Calls: | 7,769 |
Files: | 12,905 |
Messages: | 5,749,298 |