On 2/20/2022 11:26 AM, Richard Damon wrote:
> On 2/20/22 11:01 AM, olcott wrote:
>> On 2/19/2022 8:15 PM, Richard Damon wrote:
>>> On 2/19/22 8:56 PM, olcott wrote:
>>>> On 2/19/2022 7:23 PM, Richard Damon wrote:
>>>>>
>>>>> On 2/19/22 8:04 PM, olcott wrote:
>>>>>> On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>
>>>>>>>> Is the reason that you do not critique this because you do not
>>>>>>>> understand the words?
>>>>>>>
>>>>>>> Until you correct your two huge mistakes (not talking about the
>>>>>>> halting
>>>>>>> problem and not talking about Turing machines) there is not point it
>>>>>>> critiquing anything you say.
>>>>>>
>>>>>> Even Linz was confused by the fact that a halt decider is a
>>>>>> decider thus only computes the mapping of its inputs to an accept
>>>>>> or reject state
>>>>>>
>>>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>>>> EMBEDDED_H.
>>>>>>
>>>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>>>> EMBEDDED_H.
>>>>>>
>>>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>>>> EMBEDDED_H.
>>>>>>
>>>>>>
>>>>> No, he was NOT confused. That IS the definition of a Halt Decider.
>>>>>
>>>>> It decides if the Actual Machine given the actual input will Halt.
>>>>
>>>> Except for the case of pathological self-reference Olcott(2004) it
>>>> makes no difference whether or not H computes the halt status on the
>>>> basis of whether or not its simulation of its input would ever reach
>>>> the final state of this input or computes it on the basis the the
>>>> direct execution of the machine on its input halts.
>>>>
>>>> Because no one has ever noticed that it makes a difference these two
>>>> things have always been conflated together as equivalent.
>>>>
>>>>
>>>
>>> The Definitino IS the Definition.
>>>
>>> There is no 'pathological' exception.
>>>
>>> YOU are just WRONG.
>>>
>>> That is the simple meaning of the words as defined by the field.
>>
>> How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The behavior of Ĥ ⟨Ĥ⟩ depends on the behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> The behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ depends on nothing besides its input
>>
>
> But the simulation of <H^> <H^> depends on the behavior of H^ which
> depends on the behaviot of H (BY DEFINITION).
>

THE MEANING OF THESE WORDS PROVE THAT THEY ARE TRUE
THE MEANING OF THESE WORDS PROVE THAT THEY ARE TRUE
THE MEANING OF THESE WORDS PROVE THAT THEY ARE TRUE

The definition of a decider is that it computes the mapping from its
inputs to an accept/reject state. It is dishonest for you to reject this
because you know its true.

It is also dishonest for you to construe Ĥ ⟨Ĥ⟩ as an input to embedded_H
because you know that the computation that contains embedded_H cannot be
an input to embedded_H. TM's cannot take other TM's as inputs, they must
have finite string TM descriptions.

WHY LIE ?

> So the dependency works both ways.
>
> IF the behavior of H^ applied to <H^> differs from the behavior of the
> simulation of <H^> <H^>, then BY DEFINITION, the simulation is incorrect.
>
> THE DEFINITION of simualtion by a UTM is that the simulation EXACTLY
> matches the behavior of the machine it is simulating the representation of.
>
> THis is actually a fundamental principle of simulation in general.
>
> So, your argument has just FAILED>

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> Deciders only compute the mapping from their actual inputs to accept
>>>>>> or reject state.
>>>>> Too many words. Deciders accept or reject any and all inputs.
>>>>
>>>> My words are precisely technically accurate.
>>> There are just too many of them. Waffle is not always wrong. You think
>>> using lots of words makes you sound all technical and "sciency", but
>>> that's because you've not spent much time around smart technical people.
>>>
>>>>>> Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
>>>>>> the halt status decision because it is not an actual input.
>>>>>
>>>>> This is so silly. I tried to help once by suggesting you to specify a
>>>>> much simpler TM, but you don't like being given helpful exercises.
>>>>> Except for the most trivial examples, TMs are always specified in terms
>>>>> of what the input encodes, rather than what the "actual input" is.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> The key distinction is that the exact point of the execution trace
>>>> matters.
>>>
>>> No, that's your big mistake (B). For Turing machines, all that matters
>>> is the state and the tape, and that's what those lines you keep writing
>>> specify. H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>> transitions to qn.
>>
>> How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
>> ?
>
> That's not the question. To get out of this hole you need to read what
> people write and address the points they make.
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition to the
> same (actually corresponding) states.

I have reversed my view on this on the basis of a deeper understanding
of the notion of computable functions.

> That's because your PO-machines
> are magic -- that's your big mistake (B).
>
> According to Message-ID: <IpmdnfFa7dl5C4j_nZ2dnUU7-L3NnZ2d@giganews.com>
>
> | ... this never occurs:
> | embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩.qn
>

My notational conventions were incorrect.
Here is the correct way to say that:

The simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H cannot possibly reach ⟨Ĥ⟩.qn,
because ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely nested simulation to embedded_H.

> so, in fact, Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.q (and on into a loop). If
> your machines were not magic, H ⟨Ĥ⟩ ⟨Ĥ⟩ would also transitions to (it's)
> qy, meaning that H determines that the computation represented by the
> string ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting one.

The simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H specifies infinitely nested
simulation that never reaches ⟨Ĥ⟩.qn.

> But (again, if these were TMs and not
> magic PO-machines) you have just told us that it is not.
>
> You've flipped you big mistake (B) -- now you are claiming that true
> (accept) is the correct answer for at least one non-halting computation.
>

I am, not doing this.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> Is the reason that you do not critique this because you do not
>>>> understand the words?
>>> Until you correct your two huge mistakes (not talking about the halting
>>> problem and not talking about Turing machines) there is not point it
>>> critiquing anything you say.
>>
>> Even Linz was confused by the fact that a halt decider is a decider
>> thus only computes the mapping of its inputs to an accept or reject
>> state
>
> But your mistakes have nothing to do with that. Even if we assume that
> Linz was confused, that does alter a thing I said about (A)
> your not talking about the halting problem because you accept a wrong
> answer as being correct[1], and (B) you are not talking about Turing
> machines because identical PO-machines can transition to different
> states when given the same input.
>
> You could try to formally define PO-machines so that we could all ignore
> you, or you could try to defined the problem that has false as the
> correct answer for some halting computations, again, so that we could
> ignore you, but neither satisfied. The key thing is that you not be
> ignored so continuing to be wrong is your best option.
>
>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>> EMBEDDED_H.
>
> But who cares?

For conventional halt deciders defined in terms of conventional deciders
that fact that

the input to embedded_H cannot possibly reach its final state of ⟨Ĥ⟩.qn,
and is thus specifies a non-halting sequence of configurations.

This is not contradicted by the fact that Ĥ ⟨Ĥ⟩ halts.

deciders ONLY compute the mapping from their inputs to an accept /
reject state.

Anything that is not an input is OUT-OF-SCOPE FOR EVERY DECIDER.
Anything that is not an input is OUT-OF-SCOPE FOR EVERY DECIDER.
Anything that is not an input is OUT-OF-SCOPE FOR EVERY DECIDER.
Anything that is not an input is OUT-OF-SCOPE FOR EVERY DECIDER.

> H and Ĥ are PO-machines not Turing machines, and H is
> not a halt decider but a decider for some other property no one cares
> about. Obviously you want people to engage with what you say about
> PO-machines solving the almost-but-not-quite halting problem, but that
> would be a waste of time.
>
> You need to agree that false (reject) is never the right answer for a
> halting computation, and that two identical state machines go though
> identical transitions when given identical inputs. Until then, no
> proper communication can occur.
>
> [1] I note that today you have flipped on what the wrong answer is
> though I bet you don't even know you've done that.
>

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>
>>>>>>>> Deciders only compute the mapping from their actual inputs to accept
>>>>>>>> or reject state.
>>>>>>> Too many words. Deciders accept or reject any and all inputs.
>>>>>>
>>>>>> My words are precisely technically accurate.
>>>>> There are just too many of them. Waffle is not always wrong. You think
>>>>> using lots of words makes you sound all technical and "sciency", but
>>>>> that's because you've not spent much time around smart technical people.
>>>>>
>>>>>>>> Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
>>>>>>>> the halt status decision because it is not an actual input.
>>>>>>>
>>>>>>> This is so silly. I tried to help once by suggesting you to specify a
>>>>>>> much simpler TM, but you don't like being given helpful exercises.
>>>>>>> Except for the most trivial examples, TMs are always specified in terms
>>>>>>> of what the input encodes, rather than what the "actual input" is.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> The key distinction is that the exact point of the execution trace
>>>>>> matters.
>>>>>
>>>>> No, that's your big mistake (B). For Turing machines, all that matters
>>>>> is the state and the tape, and that's what those lines you keep writing
>>>>> specify. H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> transitions to qn.
>>>>
>>>> How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> ?
>>> That's not the question. To get out of this hole you need to read what
>>> people write and address the points they make.
>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition to the
>>> same (actually corresponding) states.
>>
>> I have reversed my view on this on the basis of a deeper understanding
>> of the notion of computable functions.
>
> Everyone else knew it from understanding what a Turing machine is, but
> kudos to you for (almost) saying you were wrong.
>

I was shocked to find out that a Turing machine cannot do what every C
program can do because TM's only implement computable functions.

> I wonder, though, if you actually accept the truth: that ether
>
> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
>
> or
>
> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

As soon as H or embedded_H sees a machine with an identical finite
string TM description simulated twice with the same input it rejects.

>
> I hope so.
>
>>> According to Message-ID: <IpmdnfFa7dl5C4j_nZ2dnUU7-L3NnZ2d@giganews.com>
>>> | ... this never occurs:
>>> | embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩.qn
>>
>> My notational conventions were incorrect.
>
> Admitting two mistakes in one post.
>
> Now all you need to do is agree that false (or reject) is never the
> correct answer for a halting computation and there can be a reasoned
> debate about why no Turing machines computes the halting function.
>

If you would bother to pay attention to what I am saying rather than
simply always consistently reject what I say out-of-hand without review,
then you would realize that my completely reconfigured analysis is
clearly correct.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> Is the reason that you do not critique this because you do not
>>>>>> understand the words?
>>>>> Until you correct your two huge mistakes (not talking about the halting
>>>>> problem and not talking about Turing machines) there is not point it
>>>>> critiquing anything you say.
>>>>
>>>> Even Linz was confused by the fact that a halt decider is a decider
>>>> thus only computes the mapping of its inputs to an accept or reject
>>>> state
>>> But your mistakes have nothing to do with that. Even if we assume that
>>> Linz was confused, that does alter a thing I said about (A)
>>> your not talking about the halting problem because you accept a wrong
>>> answer as being correct[1], and (B) you are not talking about Turing
>>> machines because identical PO-machines can transition to different
>>> states when given the same input.
>>> You could try to formally define PO-machines so that we could all ignore
>>> you, or you could try to defined the problem that has false as the
>>> correct answer for some halting computations, again, so that we could
>>> ignore you, but neither satisfied. The key thing is that you not be
>>> ignored so continuing to be wrong is your best option.
>>>
>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>> EMBEDDED_H.
>>>
>>> But who cares?
>>
>> For conventional halt deciders...
>
> There are none. There are multiple proofs to that effect. Your
> unconventional "halt decider" is permitted to get some answer wrong.
> It's that that no one cares about.
>
> There is no dispute (from either of us) on these facts. What you call a
> "conventional" halt decider must return false only for non-halting
> computations but you declare that to be correct for at least one halting
> computation. You are ruling yourself out of the debate.
>
> You have been 100% that you are not talking about "conventional"
> halting. You can rejoin the debate about halting at any time by simply
> acknowledging that redefining the problem was a silly idea.
>
> I note elsewhere that you have (almost) admitted to being wrong about
> big mistake (B) so you are very nearly talking about the same thing as
> Linz and Sipser and Kleene and Turing and the world. Just (A) to
> correct.
>

You still have not noticed that Ĥ applied to ⟨Ĥ⟩ cannot possibly have
any relevance to the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ because
all deciders only apply to their actual inputs thus anything that is not
an input (such as Ĥ applied to ⟨Ĥ⟩) is out-of-scope.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/26/2022 6:33 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>
>>>>>>>> Is the reason that you do not critique this because you do not
>>>>>>>> understand the words?
>>>>>>> Until you correct your two huge mistakes (not talking about the halting
>>>>>>> problem and not talking about Turing machines) there is not point it
>>>>>>> critiquing anything you say.
>>>>>>
>>>>>> Even Linz was confused by the fact that a halt decider is a decider
>>>>>> thus only computes the mapping of its inputs to an accept or reject
>>>>>> state
>>>>> But your mistakes have nothing to do with that. Even if we assume that
>>>>> Linz was confused, that does alter a thing I said about (A)
>>>>> your not talking about the halting problem because you accept a wrong
>>>>> answer as being correct[1], and (B) you are not talking about Turing
>>>>> machines because identical PO-machines can transition to different
>>>>> states when given the same input.
>>>>> You could try to formally define PO-machines so that we could all ignore
>>>>> you, or you could try to defined the problem that has false as the
>>>>> correct answer for some halting computations, again, so that we could
>>>>> ignore you, but neither satisfied. The key thing is that you not be
>>>>> ignored so continuing to be wrong is your best option.
>>>>>
>>>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>>>> EMBEDDED_H.
>>>>>
>>>>> But who cares?
>>>>
>>>> For conventional halt deciders...
>>> There are none. There are multiple proofs to that effect. Your
>>> unconventional "halt decider" is permitted to get some answer wrong.
>>>
>>> It's that that no one cares about.
>>>
>>> There is no dispute (from either of us) on these facts. What you
>>> call a "conventional" halt decider must return false only for
>>> non-halting computations but you declare that to be correct for at
>>> least one halting computation. You are ruling yourself out of the
>>> debate. You have been 100% that you are not talking about
>>> "conventional" halting. You can rejoin the debate about halting at
>>> any time by simply acknowledging that redefining the problem was a
>>> silly idea. I note elsewhere that you have (almost) admitted to
>>> being wrong about big mistake (B) so you are very nearly talking
>>> about the same thing as Linz and Sipser and Kleene and Turing and the
>>> world. Just (A) to correct.
>>
>> You still have not noticed that Ĥ applied to ⟨Ĥ⟩ cannot possibly have
>> any relevance to the halt status decision of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> because all deciders only apply to their actual inputs thus anything
>> that is not an input (such as Ĥ applied to ⟨Ĥ⟩) is out-of-scope.
>
> You don't know what the halting function is. What Ĥ applied to ⟨Ĥ⟩ does
> is the /only/ thing that determines what embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ should do.

Even Linz was confused by this. embedded_H is not supposed to report on
itself or the computation that it is contained within.

Because all halt deciders are deciders that compute the mapping from
their inputs to an accept or reject state they are only allowed to
report on the actual behavior of their actual input.

Any opinion about what the behavior should be is utterly superseded by
what this behavior actually is. The actual behavior is specified by the
pure simulation of the finite string pair by embedded_H.

If this simulation proves that no number of finite steps of pure
simulation ever reach a final state of the simulated input (AKA the
simulation only stops when it is aborted) then that proves that the
finite string pair specify a non-halting sequence of configurations.

> I think you know this. That's why you always, deceptively, remove the
> key criteria for H, and Ĥ, to behave as defined by Linz:
>
> H x y |-* qn if x encodes a TM that does not halt on input y
> H ⟨Ĥ⟩ ⟨Ĥ⟩ |-* qn if ⟨Ĥ⟩ encodes a TM that does not halt on input ⟨Ĥ⟩
>
> Now that you have accepted that H ⟨Ĥ⟩ ⟨Ĥ⟩ and embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ must
> preform the same sequence of transitions (up to qn or qy) you should
> also accept that
>
> Ĥ ⟨Ĥ⟩ |-* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ |-* qn
> if ⟨Ĥ⟩ encodes a TM that does not halt on input ⟨Ĥ⟩.
>
> ⟨Ĥ⟩, of course, encodes the TM Ĥ, and Ĥ halts on input ⟨Ĥ⟩.
>
> At some level I suspect you know this. If you did not, there would be
> no reason to make the silly decision to state that the wrong answer is
> the right one. If you do not see that no TM is correct about every
> input case, why just not state that "your" H does indeed compute the
> halting function? No, your "adapted criterion" is there precisely
> because you know the actual criterion (does M halt in input I) is not
> computable.
>

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/26/2022 6:34 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> Deciders only compute the mapping from their actual inputs to accept
>>>>>>>>>> or reject state.
>>>>>>>>> Too many words. Deciders accept or reject any and all inputs.
>>>>>>>>
>>>>>>>> My words are precisely technically accurate.
>>>>>>> There are just too many of them. Waffle is not always wrong. You think
>>>>>>> using lots of words makes you sound all technical and "sciency", but
>>>>>>> that's because you've not spent much time around smart technical people.
>>>>>>>
>>>>>>>>>> Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
>>>>>>>>>> the halt status decision because it is not an actual input.
>>>>>>>>>
>>>>>>>>> This is so silly. I tried to help once by suggesting you to specify a
>>>>>>>>> much simpler TM, but you don't like being given helpful exercises.
>>>>>>>>> Except for the most trivial examples, TMs are always specified in terms
>>>>>>>>> of what the input encodes, rather than what the "actual input" is.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> The key distinction is that the exact point of the execution trace
>>>>>>>> matters.
>>>>>>>
>>>>>>> No, that's your big mistake (B). For Turing machines, all that matters
>>>>>>> is the state and the tape, and that's what those lines you keep writing
>>>>>>> specify. H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> transitions to qn.
>>>>>>
>>>>>> How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> ?
>>>>> That's not the question. To get out of this hole you need to read what
>>>>> people write and address the points they make.
>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition to the
>>>>> same (actually corresponding) states.
>>>>
>>>> I have reversed my view on this on the basis of a deeper understanding
>>>> of the notion of computable functions.
>>> Everyone else knew it from understanding what a Turing machine is, but
>>> kudos to you for (almost) saying you were wrong.
>>>
>>
>> I was shocked to find out that a Turing machine cannot do what every C
>> program can do because TM's only implement computable functions.
>
> Really? Did you think a TM could let you post to Usenet? Maybe after,
> a few decades of pontificating about them, you will eventually know what
> Turing machines are.
>

The common understanding of Church-Turing is that whatever any computer
can do a Turing machine can do.

>>> I wonder, though, if you actually accept the truth: that ether
>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
>>> or
>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> As soon as H or embedded_H sees a machine with an identical finite
>> string TM description simulated twice with the same input it rejects.
>
> So you agree with Linz that Ĥ ⟨Ĥ⟩ halts even though (indeed, because!) H
> rejects ⟨Ĥ⟩ ⟨Ĥ⟩. That is consistent with your major mistake: that you
> are not talking about computing the halting function. Linz reaches a
> different conclusion because his H /is/ supposed to compute the halting
> function.
>

embedded_H does compute the halting function of its inputs. It
transitions to its reject state entirely on the basis that its pure
simulation of its inputs would never reach their final state.

This proves that embedded_H correctly rejects its input in the same way
that having a black cat proves that you have a cat.

My reasoning above is airtight.

If you have a black cat and the mathematics of computable functions says
that you don't have a cat then the math is simply wrong.

> There's nothing more to say about the matter since you don't dispute the
> fact that you have declared false (or reject) to be the correct answer
> for at least one halting computation.
>
>> If you would bother to pay attention to what I am saying rather than
>> simply always consistently reject what I say out-of-hand without
>> review, then you would realize that my completely reconfigured
>> analysis is clearly correct.
>
> You have not changed our mind that false/reject is the correct answer
> for at least one halting computation. Do let the world know when you
> are prepared to discuss the halting problem.
>

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/26/2022 6:34 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> Deciders only compute the mapping from their actual inputs to accept
>>>>>>>>>> or reject state.
>>>>>>>>> Too many words. Deciders accept or reject any and all inputs.
>>>>>>>>
>>>>>>>> My words are precisely technically accurate.
>>>>>>> There are just too many of them. Waffle is not always wrong. You think
>>>>>>> using lots of words makes you sound all technical and "sciency", but
>>>>>>> that's because you've not spent much time around smart technical people.
>>>>>>>
>>>>>>>>>> Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
>>>>>>>>>> the halt status decision because it is not an actual input.
>>>>>>>>>
>>>>>>>>> This is so silly. I tried to help once by suggesting you to specify a
>>>>>>>>> much simpler TM, but you don't like being given helpful exercises.
>>>>>>>>> Except for the most trivial examples, TMs are always specified in terms
>>>>>>>>> of what the input encodes, rather than what the "actual input" is.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> The key distinction is that the exact point of the execution trace
>>>>>>>> matters.
>>>>>>>
>>>>>>> No, that's your big mistake (B). For Turing machines, all that matters
>>>>>>> is the state and the tape, and that's what those lines you keep writing
>>>>>>> specify. H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> transitions to qn.
>>>>>>
>>>>>> How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> ?
>>>>> That's not the question. To get out of this hole you need to read what
>>>>> people write and address the points they make.
>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition to the
>>>>> same (actually corresponding) states.
>>>>
>>>> I have reversed my view on this on the basis of a deeper understanding
>>>> of the notion of computable functions.
>>> Everyone else knew it from understanding what a Turing machine is, but
>>> kudos to you for (almost) saying you were wrong.
>>>
>>
>> I was shocked to find out that a Turing machine cannot do what every C
>> program can do because TM's only implement computable functions.
>
> Really? Did you think a TM could let you post to Usenet? Maybe after,
> a few decades of pontificating about them, you will eventually know what
> Turing machines are.
>
This says nothing about computable functions:
The Church-Turing thesis (formerly commonly known simply as Church's
thesis) says that any real-world computation can be translated into an
equivalent computation involving a Turing machine.
https://mathworld.wolfram.com/Church-TuringThesis.html

It has always been my understanding that anything any real world
computer can do a TM can do. Now people are telling me that a computable
function can't even know its own machine address in memory.

--
Copyright 2021 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 2/27/2022 5:46 AM, Richard Damon wrote:
> On 2/26/22 11:26 PM, olcott wrote:
>> On 2/26/2022 6:34 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>
>>>>>>>> On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> Deciders only compute the mapping from their actual inputs
>>>>>>>>>>>> to accept
>>>>>>>>>>>> or reject state.
>>>>>>>>>>> Too many words.  Deciders accept or reject any and all inputs.
>>>>>>>>>>
>>>>>>>>>> My words are precisely technically accurate.
>>>>>>>>> There are just too many of them.  Waffle is not always wrong.
>>>>>>>>> You think
>>>>>>>>> using lots of words makes you sound all technical and
>>>>>>>>> "sciency", but
>>>>>>>>> that's because you've not spent much time around smart
>>>>>>>>> technical people.
>>>>>>>>>
>>>>>>>>>>>> Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
>>>>>>>>>>>> the halt status decision because it is not an actual input.
>>>>>>>>>>>
>>>>>>>>>>> This is so silly.  I tried to help once by suggesting you to
>>>>>>>>>>> specify a
>>>>>>>>>>> much simpler TM, but you don't like being given helpful
>>>>>>>>>>> exercises.
>>>>>>>>>>> Except for the most trivial examples, TMs are always
>>>>>>>>>>> specified in terms
>>>>>>>>>>> of what the input encodes, rather than what the "actual
>>>>>>>>>>> input" is.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> The key distinction is that the exact point of the execution
>>>>>>>>>> trace
>>>>>>>>>> matters.
>>>>>>>>>
>>>>>>>>> No, that's your big mistake (B).  For Turing machines, all that
>>>>>>>>> matters
>>>>>>>>> is the state and the tape, and that's what those lines you keep
>>>>>>>>> writing
>>>>>>>>> specify.  H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx
>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>> transitions to qn.
>>>>>>>>
>>>>>>>> How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of
>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>> ?
>>>>>>> That's not the question.  To get out of this hole you need to
>>>>>>> read what
>>>>>>> people write and address the points they make.
>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>> You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition to the
>>>>>>> same (actually corresponding) states.
>>>>>>
>>>>>> I have reversed my view on this on the basis of a deeper
>>>>>> understanding
>>>>>> of the notion of computable functions.
>>>>> Everyone else knew it from understanding what a Turing machine is, but
>>>>> kudos to you for (almost) saying you were wrong.
>>>>>
>>>>
>>>> I was shocked to find out that a Turing machine cannot do what every C
>>>> program can do because TM's only implement computable functions.
>>>
>>> Really?  Did you think a TM could let you post to Usenet?  Maybe after,
>>> a few decades of pontificating about them, you will eventually know what
>>> Turing machines are.
>>>
>> This says nothing about computable functions:
>> The Church-Turing thesis (formerly commonly known simply as Church's
>> thesis) says that any real-world computation can be translated into an
>> equivalent computation involving a Turing machine.
>> https://mathworld.wolfram.com/Church-TuringThesis.html
>>
>> It has always been my understanding that anything any real world
>> computer can do a TM can do. Now people are telling me that a
>> computable function can't even know its own machine address in memory.
>>
>
> And your understanding isn't quite correct. Any program that meets the
> requirement of a Computation, that a computer can do can be done by a
> Turing Machine. This generally means that any ENTIRE program loaded into
> a computer (including the operating system it runs under) taken as a
> whole will be one if the I/O is somewhat limited to meet the model. In
> particular, if one computer talks to another, that can't be directly
> modeled by a Turing Machine, but the combined system can be mostly modeled.
>
> The same applies to multiple cores. The main issue with multiple cores
> or multiple computers is that now there is a bit of randomness added
> into the processing mix that a Turing Machine can't handle, but if the
> algorithm doesn't try to exploit that behavior.
>
> The big thing that a Turing Machine can't duplicate is behavior of some
> program SEGMENTS which don't act like a Computation. This can happen if
> they receive input from something not considered as an input to the
> algorithm, as this breaks the Computation model.
>
> Thus, yes, if a 'function' uses its address in memory, and that address
> hasn't been defined as a input to it, then it has ceased to be a
> computation.
>

Yet an x86 function can derive its own address without needing to be
told as an offset to its other known addresses that are hard-coded into
its instructions. This would seem to make an x86 function strictly more
powerful than a TM.

> THe mere fact that you make this statement shoulf help you realize that
> you don't really understand what Computation Theory is about. You seem
> to think it is about 'Computers', when it is about 'Computations', and
> the definition of 'Computation' that it uses vastly predates the modern
> digital computer, and in fact at that time, a 'Computer' was a person
> with a pad of paper, and maybe an adding machine, and a detailed set of
> instructions.
>
> THis is youyr problem with trying to start from your concept of 'First
> Principles', to do that sort of system analysis, you need to actually
> START from the REAL FIRST PRINCIPLES. If you start with a wrong base
> principle, you whole analysis is just wrong.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/27/2022 2:49 PM, Richard Damon wrote:
> On 2/27/22 3:22 PM, olcott wrote:
>> On 2/27/2022 2:19 PM, Richard Damon wrote:
>>> On 2/27/22 10:19 AM, olcott wrote:
>>>> On 2/27/2022 5:46 AM, Richard Damon wrote:
>>>>> On 2/26/22 11:26 PM, olcott wrote:
>>>>>> On 2/26/2022 6:34 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 2/23/2022 6:41 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On 2/22/2022 9:27 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Deciders only compute the mapping from their actual
>>>>>>>>>>>>>>>> inputs to accept
>>>>>>>>>>>>>>>> or reject state.
>>>>>>>>>>>>>>> Too many words.  Deciders accept or reject any and all
>>>>>>>>>>>>>>> inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My words are precisely technically accurate.
>>>>>>>>>>>>> There are just too many of them.  Waffle is not always
>>>>>>>>>>>>> wrong. You think
>>>>>>>>>>>>> using lots of words makes you sound all technical and
>>>>>>>>>>>>> "sciency", but
>>>>>>>>>>>>> that's because you've not spent much time around smart
>>>>>>>>>>>>> technical people.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
>>>>>>>>>>>>>>>> the halt status decision because it is not an actual input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is so silly.  I tried to help once by suggesting you
>>>>>>>>>>>>>>> to specify a
>>>>>>>>>>>>>>> much simpler TM, but you don't like being given helpful
>>>>>>>>>>>>>>> exercises.
>>>>>>>>>>>>>>> Except for the most trivial examples, TMs are always
>>>>>>>>>>>>>>> specified in terms
>>>>>>>>>>>>>>> of what the input encodes, rather than what the "actual
>>>>>>>>>>>>>>> input" is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The key distinction is that the exact point of the
>>>>>>>>>>>>>> execution trace
>>>>>>>>>>>>>> matters.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, that's your big mistake (B).  For Turing machines, all
>>>>>>>>>>>>> that matters
>>>>>>>>>>>>> is the state and the tape, and that's what those lines you
>>>>>>>>>>>>> keep writing
>>>>>>>>>>>>> specify.  H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if,
>>>>>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>> transitions to qn.
>>>>>>>>>>>>
>>>>>>>>>>>> How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation
>>>>>>>>>>>> of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>> ?
>>>>>>>>>>> That's not the question.  To get out of this hole you need to
>>>>>>>>>>> read what
>>>>>>>>>>> people write and address the points they make.
>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>> You claim that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ will not transition
>>>>>>>>>>> to the
>>>>>>>>>>> same (actually corresponding) states.
>>>>>>>>>>
>>>>>>>>>> I have reversed my view on this on the basis of a deeper
>>>>>>>>>> understanding
>>>>>>>>>> of the notion of computable functions.
>>>>>>>>> Everyone else knew it from understanding what a Turing machine
>>>>>>>>> is, but
>>>>>>>>> kudos to you for (almost) saying you were wrong.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I was shocked to find out that a Turing machine cannot do what
>>>>>>>> every C
>>>>>>>> program can do because TM's only implement computable functions.
>>>>>>>
>>>>>>> Really?  Did you think a TM could let you post to Usenet?  Maybe
>>>>>>> after,
>>>>>>> a few decades of pontificating about them, you will eventually
>>>>>>> know what
>>>>>>> Turing machines are.
>>>>>>>
>>>>>> This says nothing about computable functions:
>>>>>> The Church-Turing thesis (formerly commonly known simply as
>>>>>> Church's thesis) says that any real-world computation can be
>>>>>> translated into an equivalent computation involving a Turing machine.
>>>>>> https://mathworld.wolfram.com/Church-TuringThesis.html
>>>>>>
>>>>>> It has always been my understanding that anything any real world
>>>>>> computer can do a TM can do. Now people are telling me that a
>>>>>> computable function can't even know its own machine address in
>>>>>> memory.
>>>>>>
>>>>>
>>>>> And your understanding isn't quite correct. Any program that meets
>>>>> the requirement of a Computation, that a computer can do can be
>>>>> done by a Turing Machine. This generally means that any ENTIRE
>>>>> program loaded into a computer (including the operating system it
>>>>> runs under) taken as a whole will be one if the I/O is somewhat
>>>>> limited to meet the model. In particular, if one computer talks to
>>>>> another, that can't be directly modeled by a Turing Machine, but
>>>>> the combined system can be mostly modeled.
>>>>>
>>>>> The same applies to multiple cores. The main issue with multiple
>>>>> cores or multiple computers is that now there is a bit of
>>>>> randomness added into the processing mix that a Turing Machine
>>>>> can't handle, but if the algorithm doesn't try to exploit that
>>>>> behavior.
>>>>>
>>>>> The big thing that a Turing Machine can't duplicate is behavior of
>>>>> some program SEGMENTS which don't act like a Computation. This can
>>>>> happen if they receive input from something not considered as an
>>>>> input to the algorithm, as this breaks the Computation model.
>>>>>
>>>>> Thus, yes, if a 'function' uses its address in memory, and that
>>>>> address hasn't been defined as a input to it, then it has ceased to
>>>>> be a computation.
>>>>>
>>>>
>>>> Yet an x86 function can derive its own address without needing to be
>>>> told as an offset to its other known addresses that are hard-coded
>>>> into its instructions. This would seem to make an x86 function
>>>> strictly more powerful than a TM.
>>>
>>> Right, because code SEGMENTS are not limited to computations.
>>>
>>> And your second claim just shows that you do not understand the
>>> meaning of a Computation. It is IMPOSSIBLE to make a program that
>>> performs an ACTUAL COMPUTATION, that can not be done on a Turing
>>> Machine, The
>>
>> So all the many things that an x86 machine can do that a TM cannot
>> make the x86 machine strictly more powerful than a TM.
>
> But not in a Computation Theory sort of way.
>

On 2/27/2022 9:20 PM, Richard Damon wrote:
> On 2/27/22 10:03 PM, olcott wrote:
>> On 2/27/2022 8:43 PM, Richard Damon wrote:
>>> On 2/27/22 9:28 PM, olcott wrote:
>>>> On 2/27/2022 8:11 PM, Python wrote:
>>>>> olcott wrote:
>>>>>> On 2/27/2022 7:34 PM, Python wrote:
>>>>>>> olcott wrote:
>>>>>>> ...
>>>>>>>> An x86 machine can do many more things but they are ruled as not
>>>>>>>> counting because a TM cannot do these things. A TM can only do
>>>>>>>> the subset of things that are mappings from inputs to outputs.
>>>>>>>
>>>>>>> *facepalm*
>>>>>>>
>>>>>>> you are really that low?
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_Grand_Hotel
>>>>>> Clearly the concept of infinity is incoherently defined.
>>>>>>
>>>>>
>>>>> *facepalm*^2
>>>>
>>>> https://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox
>>>> If we use a sphere instead of a ball to perform this paradox then
>>>> when we put the two spheres back together they are no longer
>>>> spherical. Instead they are comprised of line segments of
>>>> infinitesimal length.
>>>>
>>>> Every other geometric point on the number line is taken up by one
>>>> sphere or the other. A line segment comprised of three immediately
>>>> adjacent geometric points is exactly one infinitesimal unit longer
>>>> than a line segment comprised of two immediately adjacent geometric
>>>> points.
>>>>
>>>
>>> Says you don't understand the properties of finite sets like the reals.
>>>
>>> There are NOT 'immediately adjacent geometric points' in the object,
>>> as it can be shown that between ANY two (different) real numbers (or
>>> even just rational numbers) there exists another number between them,
>>> so no numbers are 'adjacent'
>>
>> The interval [0,1] is exactly one geometric point longer than the
>> interval [0,1)
>>
>> https://www.mathwords.com/i/interval_notation.htm
>>
>
> Non-Sequitur. Doesn't show that there is anything like adjacent points.
>
> The open interval [0,1) has no highest point, as any point you try to
> name, has a point higher that is also in the interval.

It is exactly one geometric point (one infinitesimal unit) less than 1.0

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/28/2022 5:48 AM, Richard Damon wrote:
>
> On 2/27/22 11:29 PM, olcott wrote:
>> On 2/27/2022 10:18 PM, Richard Damon wrote:
>>> On 2/27/22 11:08 PM, olcott wrote:
>>>> On 2/27/2022 9:20 PM, Richard Damon wrote:
>>>>> On 2/27/22 10:03 PM, olcott wrote:
>>>>>> On 2/27/2022 8:43 PM, Richard Damon wrote:
>>>>>>> On 2/27/22 9:28 PM, olcott wrote:
>>>>>>>> On 2/27/2022 8:11 PM, Python wrote:
>>>>>>>>> olcott wrote:
>>>>>>>>>> On 2/27/2022 7:34 PM, Python wrote:
>>>>>>>>>>> olcott wrote:
>>>>>>>>>>> ...
>>>>>>>>>>>> An x86 machine can do many more things but they are ruled as
>>>>>>>>>>>> not counting because a TM cannot do these things. A TM can
>>>>>>>>>>>> only do the subset of things that are mappings from inputs
>>>>>>>>>>>> to outputs.
>>>>>>>>>>>
>>>>>>>>>>> *facepalm*
>>>>>>>>>>>
>>>>>>>>>>> you are really that low?
>>>>>>>>>>
>>>>>>>>>> https://en.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_Grand_Hotel
>>>>>>>>>>
>>>>>>>>>> Clearly the concept of infinity is incoherently defined.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *facepalm*^2
>>>>>>>>
>>>>>>>> https://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox
>>>>>>>> If we use a sphere instead of a ball to perform this paradox
>>>>>>>> then when we put the two spheres back together they are no
>>>>>>>> longer spherical. Instead they are comprised of line segments of
>>>>>>>> infinitesimal length.
>>>>>>>>
>>>>>>>> Every other geometric point on the number line is taken up by
>>>>>>>> one sphere or the other. A line segment comprised of three
>>>>>>>> immediately adjacent geometric points is exactly one
>>>>>>>> infinitesimal unit longer than a line segment comprised of two
>>>>>>>> immediately adjacent geometric points.
>>>>>>>>
>>>>>>>
>>>>>>> Says you don't understand the properties of finite sets like the
>>>>>>> reals.
>>>>>>>
>>>>>>> There are NOT 'immediately adjacent geometric points' in the
>>>>>>> object, as it can be shown that between ANY two (different) real
>>>>>>> numbers (or even just rational numbers) there exists another
>>>>>>> number between them, so no numbers are 'adjacent'
>>>>>>
>>>>>> The interval [0,1] is exactly one geometric point longer than the
>>>>>> interval [0,1)
>>>>>>
>>>>>> https://www.mathwords.com/i/interval_notation.htm
>>>>>>
>>>>>
>>>>> Non-Sequitur. Doesn't show that there is anything like adjacent
>>>>> points.
>>>>>
>>>>> The open interval [0,1) has no highest point, as any point you try
>>>>> to name, has a point higher that is also in the interval.
>>>>
>>>> It is exactly one geometric point (one infinitesimal unit) less than
>>>> 1.0
>>>>
>>>
>>> And what is that?
>>>
>>> The problem is geometric points are infintesimally small.
>>
>> Do you disagree that the interval [0,1] is exactly one geometric point
>> longer than the interval [0,1) ???
>>
>
> Yes, because that statement doesn't actually make sense when you look at
> it precisly. The problem is infinitity - 1 is the same as infinity.
>
> You FAIL the basic principles of infinite math.

It is the case based on the conventional meanings of intervals that
[0,1] is exactly one geometric point longer than [0,1).

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/28/2022 8:17 AM, Python wrote:
> olcott wrote:
>> On 2/27/2022 10:18 PM, Richard Damon wrote:
> ...
>> Do you disagree that the interval [0,1] is exactly one geometric point
>> longer than the interval [0,1) ???
>
> Lebesgue's measures of [0,1] and [0,1) have the same value: 1.
>

That is the same thing as saying that 1.0 == 0.999... repeating
They are not the same they differ by exactly one geometric point.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/28/2022 8:45 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 2/27/22 11:29 PM, olcott wrote:
>>> On 2/27/2022 10:18 PM, Richard Damon wrote:
>>>> On 2/27/22 11:08 PM, olcott wrote:
>
>>>>> It is exactly one geometric point (one infinitesimal unit) less than 1.0
>>>>
>>>> And what is that?
>>>>
>>>> The problem is geometric points are infintesimally small.
>>>
>>> Do you disagree that the interval [0,1] is exactly one geometric point
>>> longer than the interval [0,1) ???
>>
>> Yes, because that statement doesn't actually make sense when you look
>> at it precisly. The problem is infinitity - 1 is the same as infinity.
>
> I think the problem is simpler than that. If lengths are to be useful,
> one should be able to do arithmetic on them,

None-the-less [0,1] is exactly one geometric point longer than [0,1)

> and they should be the sort
> of quantities that appear in the intervals we are measuring
> (i.e. |[0, a]| = a, and for any length l, [0, l] exists).
>
> But then if |[0, 1)| = lx < 1 it all falls apart. For example, what
> interval has length (lx+1)/2? Is the set [0, lx] equal to [0,1)? What
> elements are in [0, 1] \ [0, lx]? PO-lengths have to be special things
> with a huge number of ad hoc "axioms" propping them up.
>

The conventional meaning of intervals indicates that:
[0,1] is exactly one geometric point longer than [0,1)

> But PO does not care if his idea of length makes sense because its sole

The idea makes perfect sense in that it logically follows from the
conventional meaning of the term: interval. The above two intervals are
explicitly defined to differ by exactly one geometric point.

> purpose is to reflect the intuitions he had formed by the time he
> stopped learning maths. He's never going to write a book on "PO-measure
> theory", so he can just keep decreeing new facts about PO-lengths to his
> heart's content. It does not even matter if the result is inconsistent
> because he rejects what everyone else thinks of as a proof anyway.
> (Remember that if {A} ⊦ X, he asserts that {A,¬A} ⊬ X.)
>

You are clearly stuck in rebuttal mode.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/28/2022 8:50 AM, Ben Bacarisse wrote:
> olcott <polcott2@gmail.com> writes:
>
>> Even Linz was confused by this. embedded_H is not supposed to report
>> on itself or the computation that it is contained within.
>
> No one thinks it should. You don't know what Linz says even after all
> these years. If you want to know what Linz says, I am open to pertinent
> questions on the topic.
>

You for one have insisted that it should as your primary rebuttal to my
work for six straight months.

The computation the embedded_H is contained within is: Ĥ ⟨Ĥ⟩

The fact that embedded_H correctly determines that its input ⟨Ĥ⟩ ⟨Ĥ⟩
never halts then transitions to Ĥ.qn causing both itself and Ĥ ⟨Ĥ⟩ to
halt was always presented as contradicting the verified fact that the
simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

The fact that overrides this rebuttal is that a halt decider only
computes the mapping from its inputs to an accept or reject state making
the behavior of every non-input such as Ĥ ⟨Ĥ⟩ out-of-scope for embedded_H.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/28/2022 11:31 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/28/2022 8:50 AM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> Even Linz was confused by this. embedded_H is not supposed to report
>>>> on itself or the computation that it is contained within.
>>> No one thinks it should. You don't know what Linz says even after all
>>> these years. If you want to know what Linz says, I am open to pertinent
>>> questions on the topic.
>>
>> You for one have insisted that it should as your primary rebuttal to
>> my work for six straight months.
>
> Quote please. You have a long track record of misunderstanding the points
> put to you.
>
> My "primary rebuttal" comes from your own claim that false is the
> correct answer despite the fact that computation represented halts,
> i.e. that you are not addressing the halting problem.
>

See there you go, you are asserting that the fact that Ĥ ⟨Ĥ⟩ halts
contradicts that fact that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ correctly determines that
its input never halts.

Ĥ ⟨Ĥ⟩ is the computation that contains embedded_H and embedded_H is not
supposed to determine the halt status of itself or the computation that
contains it.

Because halt deciders are deciders they only compute the mapping from
their inputs to an accept or reject state. Because Ĥ ⟨Ĥ⟩ is not an
actual input to embedded_H it is out-of-scope for embedded_H.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/28/2022 9:21 AM, Python wrote:
> olcott wrote:
>> On 2/28/2022 5:48 AM, Richard Damon wrote:
>>>
>>> On 2/27/22 11:29 PM, olcott wrote:
>>>> On 2/27/2022 10:18 PM, Richard Damon wrote:
>>>>> On 2/27/22 11:08 PM, olcott wrote:
>>>>>> On 2/27/2022 9:20 PM, Richard Damon wrote:
>>>>>>> On 2/27/22 10:03 PM, olcott wrote:
>>>>>>>> On 2/27/2022 8:43 PM, Richard Damon wrote:
>>>>>>>>> On 2/27/22 9:28 PM, olcott wrote:
>>>>>>>>>> On 2/27/2022 8:11 PM, Python wrote:
>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>> On 2/27/2022 7:34 PM, Python wrote:
>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> An x86 machine can do many more things but they are ruled
>>>>>>>>>>>>>> as not counting because a TM cannot do these things. A TM
>>>>>>>>>>>>>> can only do the subset of things that are mappings from
>>>>>>>>>>>>>> inputs to outputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *facepalm*
>>>>>>>>>>>>>
>>>>>>>>>>>>> you are really that low?
>>>>>>>>>>>>
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_Grand_Hotel
>>>>>>>>>>>>
>>>>>>>>>>>> Clearly the concept of infinity is incoherently defined.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *facepalm*^2
>>>>>>>>>>
>>>>>>>>>> https://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox
>>>>>>>>>> If we use a sphere instead of a ball to perform this paradox
>>>>>>>>>> then when we put the two spheres back together they are no
>>>>>>>>>> longer spherical. Instead they are comprised of line segments
>>>>>>>>>> of infinitesimal length.
>>>>>>>>>>
>>>>>>>>>> Every other geometric point on the number line is taken up by
>>>>>>>>>> one sphere or the other. A line segment comprised of three
>>>>>>>>>> immediately adjacent geometric points is exactly one
>>>>>>>>>> infinitesimal unit longer than a line segment comprised of two
>>>>>>>>>> immediately adjacent geometric points.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Says you don't understand the properties of finite sets like
>>>>>>>>> the reals.
>>>>>>>>>
>>>>>>>>> There are NOT 'immediately adjacent geometric points' in the
>>>>>>>>> object, as it can be shown that between ANY two (different)
>>>>>>>>> real numbers (or even just rational numbers) there exists
>>>>>>>>> another number between them, so no numbers are 'adjacent'
>>>>>>>>
>>>>>>>> The interval [0,1] is exactly one geometric point longer than
>>>>>>>> the interval [0,1)
>>>>>>>>
>>>>>>>> https://www.mathwords.com/i/interval_notation.htm
>>>>>>>>
>>>>>>>
>>>>>>> Non-Sequitur. Doesn't show that there is anything like adjacent
>>>>>>> points.
>>>>>>>
>>>>>>> The open interval [0,1) has no highest point, as any point you
>>>>>>> try to name, has a point higher that is also in the interval.
>>>>>>
>>>>>> It is exactly one geometric point (one infinitesimal unit) less
>>>>>> than 1.0
>>>>>>
>>>>>
>>>>> And what is that?
>>>>>
>>>>> The problem is geometric points are infintesimally small.
>>>>
>>>> Do you disagree that the interval [0,1] is exactly one geometric
>>>> point longer than the interval [0,1) ???
>>>>
>>>
>>> Yes, because that statement doesn't actually make sense when you look
>>> at it precisly. The problem is infinitity - 1 is the same as infinity.
>>>
>>> You FAIL the basic principles of infinite math.
>>
>> It is the case based on the conventional meanings of intervals that
>> [0,1] is exactly one geometric point longer than [0,1).
>
> No with any sensible definition of "longer".

The conventional meaning of the term "interval" specifies that the
interval [0,1] has exactly one more geometric point than [0,1).

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/28/2022 5:55 PM, Richard Damon wrote:
> On 2/28/22 10:17 AM, olcott wrote:
>> On 2/28/2022 5:48 AM, Richard Damon wrote:
>>>
>>> On 2/27/22 11:29 PM, olcott wrote:
>>>> On 2/27/2022 10:18 PM, Richard Damon wrote:
>>>>> On 2/27/22 11:08 PM, olcott wrote:
>>>>>> On 2/27/2022 9:20 PM, Richard Damon wrote:
>>>>>>> On 2/27/22 10:03 PM, olcott wrote:
>>>>>>>> On 2/27/2022 8:43 PM, Richard Damon wrote:
>>>>>>>>> On 2/27/22 9:28 PM, olcott wrote:
>>>>>>>>>> On 2/27/2022 8:11 PM, Python wrote:
>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>> On 2/27/2022 7:34 PM, Python wrote:
>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> An x86 machine can do many more things but they are ruled
>>>>>>>>>>>>>> as not counting because a TM cannot do these things. A TM
>>>>>>>>>>>>>> can only do the subset of things that are mappings from
>>>>>>>>>>>>>> inputs to outputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *facepalm*
>>>>>>>>>>>>>
>>>>>>>>>>>>> you are really that low?
>>>>>>>>>>>>
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_Grand_Hotel
>>>>>>>>>>>>
>>>>>>>>>>>> Clearly the concept of infinity is incoherently defined.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *facepalm*^2
>>>>>>>>>>
>>>>>>>>>> https://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox
>>>>>>>>>> If we use a sphere instead of a ball to perform this paradox
>>>>>>>>>> then when we put the two spheres back together they are no
>>>>>>>>>> longer spherical. Instead they are comprised of line segments
>>>>>>>>>> of infinitesimal length.
>>>>>>>>>>
>>>>>>>>>> Every other geometric point on the number line is taken up by
>>>>>>>>>> one sphere or the other. A line segment comprised of three
>>>>>>>>>> immediately adjacent geometric points is exactly one
>>>>>>>>>> infinitesimal unit longer than a line segment comprised of two
>>>>>>>>>> immediately adjacent geometric points.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Says you don't understand the properties of finite sets like
>>>>>>>>> the reals.
>>>>>>>>>
>>>>>>>>> There are NOT 'immediately adjacent geometric points' in the
>>>>>>>>> object, as it can be shown that between ANY two (different)
>>>>>>>>> real numbers (or even just rational numbers) there exists
>>>>>>>>> another number between them, so no numbers are 'adjacent'
>>>>>>>>
>>>>>>>> The interval [0,1] is exactly one geometric point longer than
>>>>>>>> the interval [0,1)
>>>>>>>>
>>>>>>>> https://www.mathwords.com/i/interval_notation.htm
>>>>>>>>
>>>>>>>
>>>>>>> Non-Sequitur. Doesn't show that there is anything like adjacent
>>>>>>> points.
>>>>>>>
>>>>>>> The open interval [0,1) has no highest point, as any point you
>>>>>>> try to name, has a point higher that is also in the interval.
>>>>>>
>>>>>> It is exactly one geometric point (one infinitesimal unit) less
>>>>>> than 1.0
>>>>>>
>>>>>
>>>>> And what is that?
>>>>>
>>>>> The problem is geometric points are infintesimally small.
>>>>
>>>> Do you disagree that the interval [0,1] is exactly one geometric
>>>> point longer than the interval [0,1) ???
>>>>
>>>
>>> Yes, because that statement doesn't actually make sense when you look
>>> at it precisly. The problem is infinitity - 1 is the same as infinity.
>>>
>>> You FAIL the basic principles of infinite math.
>>
>> It is the case based on the conventional meanings of intervals that
>> [0,1] is exactly one geometric point longer than [0,1).
>>
>
> Nope, because 'longer' doesn't apply to an infinitesimal difference to a
> finite value.
>
> FAIL.

It is self evident that the first interval maps to a line segment that
includes all of the points of the second interval and one additional
point that is immediately adjacent to the right end point that
corresponds to the second interval.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/28/2022 6:34 PM, Richard Damon wrote:
> On 2/28/22 7:07 PM, olcott wrote:
>> On 2/28/2022 5:55 PM, Richard Damon wrote:
>>> On 2/28/22 10:17 AM, olcott wrote:
>>>> On 2/28/2022 5:48 AM, Richard Damon wrote:
>>>>>
>>>>> On 2/27/22 11:29 PM, olcott wrote:
>>>>>> On 2/27/2022 10:18 PM, Richard Damon wrote:
>>>>>>> On 2/27/22 11:08 PM, olcott wrote:
>>>>>>>> On 2/27/2022 9:20 PM, Richard Damon wrote:
>>>>>>>>> On 2/27/22 10:03 PM, olcott wrote:
>>>>>>>>>> On 2/27/2022 8:43 PM, Richard Damon wrote:
>>>>>>>>>>> On 2/27/22 9:28 PM, olcott wrote:
>>>>>>>>>>>> On 2/27/2022 8:11 PM, Python wrote:
>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>> On 2/27/2022 7:34 PM, Python wrote:
>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> An x86 machine can do many more things but they are
>>>>>>>>>>>>>>>> ruled as not counting because a TM cannot do these
>>>>>>>>>>>>>>>> things. A TM can only do the subset of things that are
>>>>>>>>>>>>>>>> mappings from inputs to outputs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *facepalm*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> you are really that low?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_Grand_Hotel
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Clearly the concept of infinity is incoherently defined.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *facepalm*^2
>>>>>>>>>>>>
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox
>>>>>>>>>>>> If we use a sphere instead of a ball to perform this paradox
>>>>>>>>>>>> then when we put the two spheres back together they are no
>>>>>>>>>>>> longer spherical. Instead they are comprised of line
>>>>>>>>>>>> segments of infinitesimal length.
>>>>>>>>>>>>
>>>>>>>>>>>> Every other geometric point on the number line is taken up
>>>>>>>>>>>> by one sphere or the other. A line segment comprised of
>>>>>>>>>>>> three immediately adjacent geometric points is exactly one
>>>>>>>>>>>> infinitesimal unit longer than a line segment comprised of
>>>>>>>>>>>> two immediately adjacent geometric points.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Says you don't understand the properties of finite sets like
>>>>>>>>>>> the reals.
>>>>>>>>>>>
>>>>>>>>>>> There are NOT 'immediately adjacent geometric points' in the
>>>>>>>>>>> object, as it can be shown that between ANY two (different)
>>>>>>>>>>> real numbers (or even just rational numbers) there exists
>>>>>>>>>>> another number between them, so no numbers are 'adjacent'
>>>>>>>>>>
>>>>>>>>>> The interval [0,1] is exactly one geometric point longer than
>>>>>>>>>> the interval [0,1)
>>>>>>>>>>
>>>>>>>>>> https://www.mathwords.com/i/interval_notation.htm
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Non-Sequitur. Doesn't show that there is anything like adjacent
>>>>>>>>> points.
>>>>>>>>>
>>>>>>>>> The open interval [0,1) has no highest point, as any point you
>>>>>>>>> try to name, has a point higher that is also in the interval.
>>>>>>>>
>>>>>>>> It is exactly one geometric point (one infinitesimal unit) less
>>>>>>>> than 1.0
>>>>>>>>
>>>>>>>
>>>>>>> And what is that?
>>>>>>>
>>>>>>> The problem is geometric points are infintesimally small.
>>>>>>
>>>>>> Do you disagree that the interval [0,1] is exactly one geometric
>>>>>> point longer than the interval [0,1) ???
>>>>>>
>>>>>
>>>>> Yes, because that statement doesn't actually make sense when you
>>>>> look at it precisly. The problem is infinitity - 1 is the same as
>>>>> infinity.
>>>>>
>>>>> You FAIL the basic principles of infinite math.
>>>>
>>>> It is the case based on the conventional meanings of intervals that
>>>> [0,1] is exactly one geometric point longer than [0,1).
>>>>
>>>
>>> Nope, because 'longer' doesn't apply to an infinitesimal difference
>>> to a finite value.
>>>
>>> FAIL.
>>
>> It is self evident that the first interval maps to a line segment that
>> includes all of the points of the second interval and one additional
>> point that is immediately adjacent to the right end point that
>> corresponds to the second interval.
>>
>>
>
> Maybe to someone who doesn't understand the effects of infinite and
> infinitesimals,

It is the same as Cantors proof, every point in the open interval maps
to a point in the closed interval and there is one point left over in
the closed interval.

> it makes sense, but you make the mistake of assuming the
> existance of the point 'adjacent' to 1. There is no such point, or that
> the omission of a finite number of points in an uncountably infinite
> line affects its length.
>
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/28/2022 7:23 PM, Richard Damon wrote:
> On 2/28/22 7:59 PM, olcott wrote:
>> On 2/28/2022 6:34 PM, Richard Damon wrote:
>>> On 2/28/22 7:07 PM, olcott wrote:
>>>> On 2/28/2022 5:55 PM, Richard Damon wrote:
>>>>> On 2/28/22 10:17 AM, olcott wrote:
>>>>>> On 2/28/2022 5:48 AM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 2/27/22 11:29 PM, olcott wrote:
>>>>>>>> On 2/27/2022 10:18 PM, Richard Damon wrote:
>>>>>>>>> On 2/27/22 11:08 PM, olcott wrote:
>>>>>>>>>> On 2/27/2022 9:20 PM, Richard Damon wrote:
>>>>>>>>>>> On 2/27/22 10:03 PM, olcott wrote:
>>>>>>>>>>>> On 2/27/2022 8:43 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 2/27/22 9:28 PM, olcott wrote:
>>>>>>>>>>>>>> On 2/27/2022 8:11 PM, Python wrote:
>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>> On 2/27/2022 7:34 PM, Python wrote:
>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>> An x86 machine can do many more things but they are
>>>>>>>>>>>>>>>>>> ruled as not counting because a TM cannot do these
>>>>>>>>>>>>>>>>>> things. A TM can only do the subset of things that are
>>>>>>>>>>>>>>>>>> mappings from inputs to outputs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *facepalm*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> you are really that low?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_Grand_Hotel
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Clearly the concept of infinity is incoherently defined.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *facepalm*^2
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox
>>>>>>>>>>>>>> If we use a sphere instead of a ball to perform this
>>>>>>>>>>>>>> paradox then when we put the two spheres back together
>>>>>>>>>>>>>> they are no longer spherical. Instead they are comprised
>>>>>>>>>>>>>> of line segments of infinitesimal length.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every other geometric point on the number line is taken up
>>>>>>>>>>>>>> by one sphere or the other. A line segment comprised of
>>>>>>>>>>>>>> three immediately adjacent geometric points is exactly one
>>>>>>>>>>>>>> infinitesimal unit longer than a line segment comprised of
>>>>>>>>>>>>>> two immediately adjacent geometric points.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Says you don't understand the properties of finite sets
>>>>>>>>>>>>> like the reals.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are NOT 'immediately adjacent geometric points' in
>>>>>>>>>>>>> the object, as it can be shown that between ANY two
>>>>>>>>>>>>> (different) real numbers (or even just rational numbers)
>>>>>>>>>>>>> there exists another number between them, so no numbers are
>>>>>>>>>>>>> 'adjacent'
>>>>>>>>>>>>
>>>>>>>>>>>> The interval [0,1] is exactly one geometric point longer
>>>>>>>>>>>> than the interval [0,1)
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.mathwords.com/i/interval_notation.htm
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Non-Sequitur. Doesn't show that there is anything like
>>>>>>>>>>> adjacent points.
>>>>>>>>>>>
>>>>>>>>>>> The open interval [0,1) has no highest point, as any point
>>>>>>>>>>> you try to name, has a point higher that is also in the
>>>>>>>>>>> interval.
>>>>>>>>>>
>>>>>>>>>> It is exactly one geometric point (one infinitesimal unit)
>>>>>>>>>> less than 1.0
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And what is that?
>>>>>>>>>
>>>>>>>>> The problem is geometric points are infintesimally small.
>>>>>>>>
>>>>>>>> Do you disagree that the interval [0,1] is exactly one geometric
>>>>>>>> point longer than the interval [0,1) ???
>>>>>>>>
>>>>>>>
>>>>>>> Yes, because that statement doesn't actually make sense when you
>>>>>>> look at it precisly. The problem is infinitity - 1 is the same as
>>>>>>> infinity.
>>>>>>>
>>>>>>> You FAIL the basic principles of infinite math.
>>>>>>
>>>>>> It is the case based on the conventional meanings of intervals
>>>>>> that [0,1] is exactly one geometric point longer than [0,1).
>>>>>>
>>>>>
>>>>> Nope, because 'longer' doesn't apply to an infinitesimal difference
>>>>> to a finite value.
>>>>>
>>>>> FAIL.
>>>>
>>>> It is self evident that the first interval maps to a line segment
>>>> that includes all of the points of the second interval and one
>>>> additional point that is immediately adjacent to the right end point
>>>> that corresponds to the second interval.
>>>>
>>>>
>>>
>>> Maybe to someone who doesn't understand the effects of infinite and
>>> infinitesimals,
>>
>> It is the same as Cantors proof, every point in the open interval maps
>> to a point in the closed interval and there is one point left over in
>> the closed interval.
>
> I think you misunderstand the proof (unless you are thinking of some
> other proof of his). Cantor proved that the Reals were uncountable, and
> thus the matching arguement doesn't hold for comparing sets.
>

Cantor "proved" that the infinite set or Reals is larger than the
infinite set of Integers because you can map every element of the set of
integers to a real number and there are real number left over that are
not mapped.

My proof is the same. One can map every geometric point in the open
interval [0,1) to every geometric point in the closed interval [0,1] and
we have exact one geometric point left over that has not been mapped.

> Note also, even on the countable infinte sets, that doesn't show that
> the closed interval is larger.
>
> Take for example the Natural Numbers and the even Natural Numbers.
>
> One mapping shows that we can map half the natural numbers to the evens
> and thus seem to show that there are more natural numbers than even
> number, but since we can built a map that matchs every natural number
> 1:1 with the evens, we can show that they must be the same size.
>
> So FAIL again.
>
>>
>>> it makes sense, but you make the mistake of assuming the existance of
>>> the point 'adjacent' to 1. There is no such point, or that the
>>> omission of a finite number of points in an uncountably infinite line
>>> affects its length.
>>>
>>>
>>
>>
>

On 2/28/2022 8:47 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/28/2022 11:31 AM, Ben Bacarisse wrote:
>
>>> My "primary rebuttal" comes from your own claim that false is the
>>> correct answer despite the fact that computation represented halts,
>>> i.e. that you are not addressing the halting problem.
>>
>> See there you go, you are asserting that the fact that Ĥ ⟨Ĥ⟩ halts
>> contradicts that fact that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ correctly determines
>> that its input never halts.
>
> I am asserting that /you/ state that false is the right answer for a
> string representing a halting computation. Here you are when you were
> prepared to be clear about it:
>
> Me: Here's the key question: do you still assert that H(P,P) == false
> is the "correct" answer
> You: Yes that is the correct answer even though P(P) halts.
>
> Have you changed your mind?
>
> It's a simple question -- asking if you have changed your mind -- but
> one you simply can't answer. If you acknowledge that false is never the
> right answer for a halting computation you have nothing. And if you
> don't, you confirm again that you are just talking about something other
> than the halting problem.
>
> You absolutely must sit on the fence, hence these extraordinary quotes
> from you:
>
> Me: If your H has any pretensions of being a halt decider, it should
> accept that string: H.q0 <H^><H^> |- H.qy
> You: I have already said that a bunch of times yet you did not notice
>
> Me: You agree that H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy
> You: I never said anything like that so I am stopping at your first fib.
>
> Top quality fence sitting there. And then there's top quality evasion
> as well. After you stated that
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>
> I asked, again and again (12 times, in fact) "What string encodes the
> halting computation of Ĥ applied ⟨Ĥ⟩?". You just didn't answer. How
> could you without the game being up?
>
> You have made this "alternate criterion" quite clear for months now, and
> I will continue to remind readers about it until you repudiate it.
>

You have side stepped all of my points.
I proved that you are wrong and your rebuttal is to change the subject.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/28/2022 10:01 PM, Ben Bacarisse wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 2/28/2022 8:47 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 2/28/2022 11:31 AM, Ben Bacarisse wrote:
>>>
>>>>> My "primary rebuttal" comes from your own claim that false is the
>>>>> correct answer despite the fact that computation represented halts,
>>>>> i.e. that you are not addressing the halting problem.
>>>>
>>>> See there you go, you are asserting that the fact that Ĥ ⟨Ĥ⟩ halts
>>>> contradicts that fact that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ correctly determines
>>>> that its input never halts.
>>> I am asserting that /you/ state that false is the right answer for a
>>> string representing a halting computation. Here you are when you were
>>> prepared to be clear about it:
>>> Me: Here's the key question: do you still assert that H(P,P) == false
>>> is the "correct" answer
>>> You: Yes that is the correct answer even though P(P) halts.
>>> Have you changed your mind?
>>> It's a simple question -- asking if you have changed your mind -- but
>>> one you simply can't answer. If you acknowledge that false is never the
>>> right answer for a halting computation you have nothing. And if you
>>> don't, you confirm again that you are just talking about something other
>>> than the halting problem.
>>> You absolutely must sit on the fence, hence these extraordinary quotes
>>> from you:
>>> Me: If your H has any pretensions of being a halt decider, it should
>>> accept that string: H.q0 <H^><H^> |- H.qy
>>> You: I have already said that a bunch of times yet you did not notice
>>> Me: You agree that H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy
>>> You: I never said anything like that so I am stopping at your first fib.
>>> Top quality fence sitting there. And then there's top quality evasion
>>> as well. After you stated that
>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>> I asked, again and again (12 times, in fact) "What string encodes the
>>> halting computation of Ĥ applied ⟨Ĥ⟩?". You just didn't answer. How
>>> could you without the game being up?
>>> You have made this "alternate criterion" quite clear for months now, and
>>> I will continue to remind readers about it until you repudiate it.
>>
>> You have side stepped all of my points.
>
> You must avoid, at all costs, any discussion of your big mistake: that
> false (or reject) is declared to be the correct answer for at least one
> halting computation.
>

If you want to go back to my first reply to you that says [ Ben's
mistake ] and discuss these issues point-by-point that would show that
you want an honest dialogue.

>> I proved that you are wrong and your rebuttal is to change the
>> subject.
>
> Since I was quoting your words: "Yes that is the correct answer even
> though P(P) halts" I don't know what you think I was wrong about.
>
> Anyway, you have, as yo always do, passed up another opportunity to
> correct this huge mistake. You have not changed tour mind. You are not
> talking about the halting problem.
>

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/28/2022 11:31 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/28/2022 8:50 AM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> Even Linz was confused by this. embedded_H is not supposed to report
>>>> on itself or the computation that it is contained within.
>>> No one thinks it should. You don't know what Linz says even after all
>>> these years. If you want to know what Linz says, I am open to pertinent
>>> questions on the topic.
>>
>> You for one have insisted that it should as your primary rebuttal to
>> my work for six straight months.
>
> Quote please. You have a long track record of misunderstanding the points
> put to you.
>
> My "primary rebuttal" comes from your own claim that false is the
> correct answer despite the fact that computation represented halts,
> i.e. that you are not addressing the halting problem.
>

See there you go, you are asserting that the fact that Ĥ ⟨Ĥ⟩ halts
contradicts that fact that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ correctly determines that
its input never halts.

Ĥ ⟨Ĥ⟩ is the computation that contains embedded_H and embedded_H is not
supposed to determine the halt status of itself or the computation that
contains it.

Because halt deciders are deciders they only compute the mapping from
their inputs to an accept or reject state. Because Ĥ ⟨Ĥ⟩ is not an
actual input to embedded_H it is out-of-scope for embedded_H.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/28/2022 11:31 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/28/2022 8:50 AM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> Even Linz was confused by this. embedded_H is not supposed to report
>>>> on itself or the computation that it is contained within.
>>> No one thinks it should. You don't know what Linz says even after all
>>> these years. If you want to know what Linz says, I am open to pertinent
>>> questions on the topic.
>>
>> You for one have insisted that it should as your primary rebuttal to
>> my work for six straight months.
>
> Quote please. You have a long track record of misunderstanding the points
> put to you.
>
> My "primary rebuttal" comes from your own claim that false is the
> correct answer despite the fact that computation represented halts,
> i.e. that you are not addressing the halting problem.
>

See there you go, you are asserting that the fact that Ĥ ⟨Ĥ⟩ halts
contradicts that fact that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ correctly determines that
its input never halts.

Ĥ ⟨Ĥ⟩ is the computation that contains embedded_H and embedded_H is not
supposed to determine the halt status of itself or the computation that
contains it.

Because halt deciders are deciders they only compute the mapping from
their inputs to an accept or reject state. Because Ĥ ⟨Ĥ⟩ is not an
actual input to embedded_H it is out-of-scope for embedded_H.

THIS WILL BE MY ONLY REPLY UNTIL EVERY POINT ABOVE IS FULLY ADDRESSED
THIS WILL BE MY ONLY REPLY UNTIL EVERY POINT ABOVE IS FULLY ADDRESSED
THIS WILL BE MY ONLY REPLY UNTIL EVERY POINT ABOVE IS FULLY ADDRESSED

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/28/2022 11:31 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/28/2022 8:50 AM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> Even Linz was confused by this. embedded_H is not supposed to report
>>>> on itself or the computation that it is contained within.
>>> No one thinks it should. You don't know what Linz says even after all
>>> these years. If you want to know what Linz says, I am open to pertinent
>>> questions on the topic.
>>
>> You for one have insisted that it should as your primary rebuttal to
>> my work for six straight months.
>
> Quote please. You have a long track record of misunderstanding the points
> put to you.
>
> My "primary rebuttal" comes from your own claim that false is the
> correct answer despite the fact that computation represented halts,
> i.e. that you are not addressing the halting problem.
>

See there you go, you are asserting that the fact that Ĥ ⟨Ĥ⟩ halts
contradicts that fact that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ correctly determines that
its input never halts.

Ĥ ⟨Ĥ⟩ is the computation that contains embedded_H and embedded_H is not
supposed to determine the halt status of itself or the computation that
contains it.

Because halt deciders are deciders they only compute the mapping from
their inputs to an accept or reject state. Because Ĥ ⟨Ĥ⟩ is not an
actual input to embedded_H it is out-of-scope for embedded_H.

THIS WILL BE MY ONLY REPLY UNTIL EVERY POINT ABOVE IS FULLY ADDRESSED
THIS WILL BE MY ONLY REPLY UNTIL EVERY POINT ABOVE IS FULLY ADDRESSED
THIS WILL BE MY ONLY REPLY UNTIL EVERY POINT ABOVE IS FULLY ADDRESSED

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer