On 3/12/2022 8:30 PM, André G. Isaak wrote:
> On 2022-03-12 19:13, olcott wrote:
>> On 3/12/2022 7:03 PM, André G. Isaak wrote:
>>> On 2022-03-12 17:17, olcott wrote:
>>>> On 3/12/2022 5:57 PM, André G. Isaak wrote:
>>>>> On 2022-03-12 16:25, olcott wrote:
>>>>>> On 3/12/2022 3:33 PM, André G. Isaak wrote:
>>>>>>> On 2022-03-12 14:14, olcott wrote:
>>>>>>>> On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> So you now know that everyone accepts that "deciders
>>>>>>>>>>>>> compute only a
>>>>>>>>>>>>> function from input strings to accept/reject states"
>>>>>>>>>>
>>>>>>>>>> This is good.
>>>>>>>>>>
>>>>>>>>>>> and you also also
>>>>>>>>>>>>> now know that "deciders /are/ capable of reporting on the
>>>>>>>>>>>>> behavior of
>>>>>>>>>>>>> Turing machines".
>>>>>>>>>>
>>>>>>>>>> This contradicts the prior sentence:
>>>>>>>>>> (a) A decider only takes finite string inputs. // prior sentence
>>>>>>>>>> (b) A decider takes Turing machine (thus non-finite string)
>>>>>>>>>> inputs. //
>>>>>>>>>> current sentence
>>>>>>>>>
>>>>>>>>> I can't help with your poor comprehension of English.
>>>>>>>>>
>>>>>>>>
>>>>>>>> A decider cannot take a Turing machine as input and you know it.
>>>>>>>
>>>>>>> Nowhere does he deny this.
>>>>>>>
>>>>>>>> It can only take a finite string that specifies a Turing machine.
>>>>>>>
>>>>>>> Right. A finite string THAT SPECIFIES A TURING MACHINE.
>>>>>>>
>>>>>>> IOW, it is given a string which provides all of the information
>>>>>>> necessary to identify some unique Turing Machine. So while a TM
>>>>>>> cannot take a Turing Machine as an input, it can still answer
>>>>>>> questions about Turing Machines.
>>>>>>>
>>>>>>
>>>>>> It is not actually answering the question about a Turing machine.
>>>>>> It is answering the question about the Turing machine specified by
>>>>>> the finite string, this distinction is crucial, and even Linz
>>>>>> missed it.
>>>>>
>>>>> The Turing Machine specified by the finite string *is* a Turing
>>>>> Machine, so yes it is answering the question about a Turing Machine.
>>>
>>> Can I take your silence here as an acknowledgment that what you had
>>> written was an error (and a very silly one at that)?
>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> Everyone here (and Linz) believes that the copy of H embedded at
>>>>>> Ĥ.qx is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩.
>>>>>> This is off by exactly one level of indirection.
>>>>>
>>>>> That's exactly what the copy of H embedded at Ĥ.qx is supposed to
>>>>> report on by the very definition of the problem.
>>>
>>> No Comment?
>>>
>>>>> A halt decider must, *by definition*, be able to determine the
>>>>> halting status of *any* arbitrary computation, so if you want to
>>>>> claim that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a computation different from Ĥ applied
>>>>> to ⟨Ĥ⟩, then you'd better be able to show how that latter
>>>>> computation is to be encoded as a finite string.
>>>>>
>>>>> So what string, according to you, encodes the computation Ĥ applied
>>>>> to ⟨Ĥ⟩? If these two "different" computations don't have separate
>>>>> encodings as strings then they are not, in fact, different
>>>>> computations at all.
>>>
>>> No Comment?
>>>
>>> I know you've been asked this question before and have consistently
>>> ignored it. According to a recent post of yours that constitutes
>>> justification for a repetitive all-caps temper tantrum!
>>>
>>>>>
>>>>>> No decider is ever supposed to report on the behavior of the
>>>>>> computation that contains its actual self. Deciders only report on
>>>>>> the behavior specified by Turing machine descriptions.
>>>>>
>>>>> No, it is supposed to report on the halting status of the
>>>>> computation represented by its input. But nothing in the definition
>>>>> of 'halt decider' precludes it from being given a description of a
>>>>> computation which contains its actual self. If it can't answer
>>>>> about that question, then it isn't meeting the definition of a halt
>>>>> decider which must be able to answer about *any* computation. And
>>>>> in the Linz proof this is precisely what the input specifies, your
>>>>> nonsense about the input being a string rather than an actual
>>>>> Turing Machine notwithstanding.
>>>
>>> Again, is your silence a recognition that you know see your error?
>>>
>>>>>>
>>>>>>> That's a fairly fundamental concept in computational theory which
>>>>>>> you seem determined to not understand.
>>>>>>>
>>>>>>> Turing Machines only deal with strings. This means that a
>>>>>>> function can only be computed if (as a minimal requirement) the
>>>>>>> elements of that domain can be ENCODED as strings. If you can
>>>>>>> encoded elements of some domain as strings, then it might be
>>>>>>> possible for a TM to compute that function EVEN WHEN THOSE
>>>>>>> ELEMENTS ARE NOT THEMSELVES STRINGS.
>>>>>>>
>>>>>>> Integers are not strings, but many functions from integers to
>>>>>>> integers are computable by virtue of the fact that it is
>>>>>>> trivially easy to devise ways of encoding integers as strings.
>>>>>>>
>>>>>>> Functions from reals to reals, on the other hand, are not going
>>>>>>> to be computable precisely because the overwhelming majority of
>>>>>>> real numbers cannot be encoded as finite strings. A function like
>>>>>>> y = √x is not computable, but one can compute some function that
>>>>>>> is "close" to this but that limits the input/output to some
>>>>>>> arbitary degree of precision.
>>>>>>>
>>>>>>> The set of Turing Machines is provably DENUMERABLE. That means
>>>>>>> that one can encode TMs as finite strings. Which in turn means
>>>>>>> that a TM *can* answer questions about Turing Machines. They just
>>>>>>> have to be encoded as finite strings before being given to a
>>>>>>> Turing Machine.
>>>>>>>
>>>>>>> Strings which encode Turing Machines and inputs don't halt
>>>>>>> anymore than strings which encode integers have sums.
>>>>>>
>>>>>> The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>>>> reaches its final state of ⟨Ĥ⟩.qn in any finite number of
>>>>>> correctly simulated steps by the copy of H embedded at Ĥ.qx.
>>>>>
>>>>> Finite string pairs don't *have* final states.
>>>>
>>>> Simulated finite string pairs ⟨Ĥ⟩ ⟨Ĥ⟩ have final states that can
>>>> either be reached in a finite number of simulated steps or not.
>>>
>>
>> I am ignoring all of your other points because this single point is
>> the crux of the whole issue and all the other points are tangential.
>
> Yes, that always seems to be your excuse. Every time anyone raises an
> objection you ignore it by declaring it 'tangential' and then claim that
> no one has ever presented you with objections. Unfortunately, you have a
> poor track record when it comes to deciding which things are tangential.
>
>>> The *simulation* has states which may include final states. The
>>> string itself does not.
>>
>> A BASIC program that is executed in an interpreter is correctly
>> construed as reaching its final state.
>>
>> 10 PRINT "Hello, World!"
>> 20 END
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is executed within the simulator of the copy of H embedded
>> within Ĥ. This embedded_H has all of the functionality of a UTM along
>> with additional functionality.
>
> The exact same string $ might encode a Turing Machine when passed to one
> Turing Machine, an algebraic equation when passed to another TM, and a
> line of Old Church Slavonic written in Glogolitic to a third.
>

On 3/12/2022 8:55 PM, Ben Bacarisse wrote:
> André G. Isaak <agisaak@gm.invalid> writes:
>
>>> On 3/12/2022 5:57 PM, André G. Isaak wrote:
>
>>>> So what string, according to you, encodes the computation Ĥ applied
>>>> to ⟨Ĥ⟩? If these two "different" computations don't have separate
>>>> encodings as strings then they are not, in fact, different
>>>> computations at all.
>>
>> No Comment?
>>
>> I know you've been asked this question before and have consistently
>> ignored it. According to a recent post of yours that constitutes
>> justification for a repetitive all-caps temper tantrum!
>
> I once tried to get a direct answer to this question. I asked 12 times
> in consecutive posts but never got one.
>
> Later, on the related question of whether ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
> computation I got this dazzling display of equivocation:
>
> "When it is construed as input to H then ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
> computation.
> When it is construed as input to Ĥ.qx then ⟨Ĥ⟩ ⟨Ĥ⟩ DOES NOT encode a
> halting computation."
>
> Bear in mind that at time, PO's machines were magic: two identical state
> transition functions could entail transitions to different states when
> presented with identical inputs. He has since backed off from some of
> these remarks, but it never exactly clear which previous claims he would
> now accept were wrong.
>

None-the-less when a BASIC interpreter is running a BASIC program or a
simulating halt decider with UTM functionality is simulating a Turing
machine description in each of these two cases their input would either
reach or fail to reach a final state.

10 PRINT "Hello, World!"
20 END

10 PRINT "Hello, World!"
20 GOTO 10
30 END

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

The above repeating pattern shows that the correctly simulated input to
embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively
proving that this simulated input never halts. This enables embedded_H
to abort its simulation and correctly transition to Ĥ.qn.

--
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 3/12/2022 9:59 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:

> I've shown you how to write Linz's conditions in terms of simulation:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
>
> Feel fee to replace "halts" with "would reach its final state" (and
> similarly for "does not halt") if it make you feel better. Both figures
> of speech convey the same mathematical fact, but one is shorter and fits
> on a line.
>
> What you can't do, if you want to keep talking about what Linz is
> talking about, is replace the reference to a UTM with embedded_H.

Embedded_H has a full UTM as a part of it. The Linz ⊢* wild card state
transition allows for a UTM simulation to be a part of the decision
process.

Embedded_H determines whether or not its simulated input would ever
reach its final state if embedded_H remained in pure UTM mode.

>> It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the
>> copy of H embedded within Ĥ would never reach the final state of this
>> input ⟨Ĥ⟩.qn.
>
> Irrelevant. What matters is what follows logically from Linz's
> definition of a halt decider. If you think there is any point, I'll
> write it out again for you in terms of UTMs.
>

If the input to embedded_H never halts and embedded_H correctly reports
this that is most relevant.

--
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 3/14/2022 8:34 PM, André G. Isaak wrote:
> On 2022-03-14 19:17, olcott wrote:
>> On 3/12/2022 8:30 PM, André G. Isaak wrote:
>
>>> The exact same string $ might encode a Turing Machine when passed to
>>> one Turing Machine, an algebraic equation when passed to another TM,
>>> and a line of Old Church Slavonic written in Glogolitic to a third.
>>>
>>
>> None-the-less when a BASIC interpreter is running a BASIC program or a
>> simulating halt decider with UTM functionality is simulating a Turing
>> machine description in each of these two cases their input would
>> either reach or fail to reach a final state.
>
> The input to a BASIC interpreter is a string representing a BASIC
> program. The BASIC program might do any number of things including
> reaching the end of the program, but the string itself does not do these
> things.
>

The interpreted BASIC program does run and the simulated Turing machine
description does have final states.

--
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 3/14/2022 8:46 PM, André G. Isaak wrote:
> On 2022-03-14 19:40, olcott wrote:
>> On 3/14/2022 8:34 PM, André G. Isaak wrote:
>>> On 2022-03-14 19:17, olcott wrote:
>>>> On 3/12/2022 8:30 PM, André G. Isaak wrote:
>>>
>>>>> The exact same string $ might encode a Turing Machine when passed
>>>>> to one Turing Machine, an algebraic equation when passed to another
>>>>> TM, and a line of Old Church Slavonic written in Glogolitic to a
>>>>> third.
>>>>>
>>>>
>>>> None-the-less when a BASIC interpreter is running a BASIC program or
>>>> a simulating halt decider with UTM functionality is simulating a
>>>> Turing machine description in each of these two cases their input
>>>> would either reach or fail to reach a final state.
>>>
>>> The input to a BASIC interpreter is a string representing a BASIC
>>> program. The BASIC program might do any number of things including
>>> reaching the end of the program, but the string itself does not do
>>> these things.
>>>
>>
>> The interpreted BASIC program does run and the simulated Turing
>> machine description does have final states.
>
> The interpreted BASIC program is not the same thing as the string which
> is the input to the BASIC interpreter. It's what happens *inside* the
> interpreter. You don't seem to grasp what "string" means.
>

That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when correctly
simulated by the UTM within embedded_H is the same as these finite
strings specifying non-halting behavior when correctly interpreted by a
BASIC in interpreter.

10 PRINT "Hello, World!"
20 goto 10
30 END

--
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 3/14/2022 9:05 PM, André G. Isaak wrote:
> On 2022-03-14 20:02, olcott wrote:
>
> <snip nonresponsive post>
>
> Again, I'll repeat the question which you dishonestly snipped rather
> than answering. I won't bother putting it in all caps or repeating it
> five times.
>
> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed to
> Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect reference
away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.

> If there are computations which cannot be encoded as strings, then it is
> impossible to design a universal halt decider since that means there are
> computations which it cannot be asked about.
>
> André
>

--
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 3/15/2022 6:35 AM, Malcolm McLean wrote:
> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>> On 2022-03-14 21:07, olcott wrote:
>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>> On 2022-03-14 20:02, olcott wrote:
>>>>
>>>> <snip nonresponsive post>
>>>>
>>>> Again, I'll repeat the question which you dishonestly snipped rather
>>>> than answering. I won't bother putting it in all caps or repeating it
>>>> five times.
>>>>
>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect reference
>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>> There are no 'levels of indirection' when discussing Turing Machines.
>>
>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an input
>> to your decider, then your decider is broken since it must be able to
>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>
> Though that would actually be a genuine contribution to computer science.
> If you could devise a language such that a large subset of halting and
> non-halting machines could be described, but not machines for which the
> halting status is difficult or impossible for a predefined halt decider to determine.

André does not seem to be able to comprehend that a Turing machine
decider cannot possibly have its own self or an encoding of its own self
as its input. The closest thing possible that it can have is an encoding
of another different instance of itself.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In the case above ⟨Ĥ⟩ ⟨Ĥ⟩ is exactly one level of indirect reference
away from Ĥ applied to ⟨Ĥ⟩. The copy of H embedded at Ĥ.qx is not
deciding the halt status of its own self (the exact same instance) it is
deciding the halt status of a different instance.

That neither André, Ben nor Richard can comprehend this does not
indicate that I am incorrect.

--
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 3/15/2022 10:44 AM, Malcolm McLean wrote:
> On Tuesday, 15 March 2022 at 14:51:44 UTC, olcott wrote:
>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>> On 2022-03-14 21:07, olcott wrote:
>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>
>>>>>> <snip nonresponsive post>
>>>>>>
>>>>>> Again, I'll repeat the question which you dishonestly snipped rather
>>>>>> than answering. I won't bother putting it in all caps or repeating it
>>>>>> five times.
>>>>>>
>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect reference
>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>> There are no 'levels of indirection' when discussing Turing Machines.
>>>>
>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an input
>>>> to your decider, then your decider is broken since it must be able to
>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>
>>> Though that would actually be a genuine contribution to computer science.
>>> If you could devise a language such that a large subset of halting and
>>> non-halting machines could be described, but not machines for which the
>>> halting status is difficult or impossible for a predefined halt decider to determine.
>> André does not seem to be able to comprehend that a Turing machine
>> decider cannot possibly have its own self or an encoding of its own self
>> as its input. The closest thing possible that it can have is an encoding
>> of another different instance of itself.
>>
> So how would you describe a compiler which is "bootstrapped", i.e. fed its own
> source code?

A compiler that is fed its own source-code is not the same because the
compiler does not execute this source-code.

--
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 3/15/2022 10:11 AM, olcott wrote:
> On 3/15/2022 10:44 AM, Malcolm McLean wrote:

<MAJOR SNIP>

>> So how would you describe a compiler which is "bootstrapped", i.e. fed
>> its own
>> source code?
>
> A compiler that is fed its own source-code is not the same because the
> compiler does not execute this source-code.
This is one of your best Peter. Along the way you've had 100s of
messages that have said that simulation as a basis for a Halting Problem
solution is hopeless. Of course you pay no attention because it's
unlikely you understood what you were being told. So here you are
looping back over years of the same bone headed approach.

Let's start with a few basics:

Nothing executes source code; even an interpreter ingests it first.

All an ingestor, compiler, or assembler does is to change a program
languages representation into another equivalent form. If it's working
properly, that is.

So the properly compiled compiler is just another representation of its
source code. And, indeed, that brings us to the conclusion of this
little explanation:

THE COMPILER IN ONE REPRESENTATION IS PROCESSING ITSELF IN ANOTHER
REPRESENTATION. SO YOU ARE WRONG ONCE AGAIN (AS ALWAYS).

Before leaving you to your hard won state as a total proud ignoramus,
I'll list these terms in the above that you don't understand:

simulation, Halting Problem, source code, interpreter, ingest, compiler,
assembler, equivalent form, representation, ignoramus.

Quite a list isn't it? Start with "ignoramus" if you want that to go
away, look it up. Then go through the other words one at a time. Ben has
offered, many many times, to teach you if you ask. Why not? Your legacy
and impression on the world has turned from proud ignorance to
stupidity. The former is curable, the latter is not. Get busy and leave
a good impression!
--
Jeff Barnett

On 3/15/2022 1:58 PM, Jeff Barnett wrote:
> On 3/15/2022 10:11 AM, olcott wrote:
>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>
>    <MAJOR SNIP>
>
>>> So how would you describe a compiler which is "bootstrapped", i.e.
>>> fed its own
>>> source code?
>>
>> A compiler that is fed its own source-code is not the same because the
>> compiler does not execute this source-code.
> This is one of your best Peter. Along the way you've had 100s of
> messages that have said that simulation as a basis for a Halting Problem
> solution is hopeless. Of course you pay no attention because it's
> unlikely you understood what you were being told. So here you are
> looping back over years of the same bone headed approach.
>
> Let's start with a few basics:
>
> Nothing executes source code; even an interpreter ingests it first.
>

A compiler the compiles its own source-code is nothing at all like
executing this source code.

An interpreter that interprets source code can be reasonably construed
as running this source code.

When a BASIC programmer says that they ran their program they do not
provide all of the tedious details of the technical intermediate steps.

--
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 3/15/2022 3:24 PM, André G. Isaak wrote:
> On 2022-03-15 08:51, olcott wrote:
>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>> On 2022-03-14 21:07, olcott wrote:
>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>
>>>>>> <snip nonresponsive post>
>>>>>>
>>>>>> Again, I'll repeat the question which you dishonestly snipped rather
>>>>>> than answering. I won't bother putting it in all caps or repeating it
>>>>>> five times.
>>>>>>
>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect
>>>>> reference
>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>> There are no 'levels of indirection' when discussing Turing Machines.
>>>>
>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an
>>>> input
>>>> to your decider, then your decider is broken since it must be able to
>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>
>>> Though that would actually be a genuine contribution to computer
>>> science.
>>> If you could devise a language such that a large subset of halting and
>>> non-halting machines could be described, but not machines for which the
>>> halting status is difficult or impossible for a predefined halt
>>> decider to determine.
>>
>> André does not seem to be able to comprehend that a Turing machine
>> decider cannot possibly have its own self or an encoding of its own
>> self as its input. The closest thing possible that it can have is an
>> encoding of another different instance of itself.
>
> Computations don't have different instances. What would it even mean to
> 'instantiate' a computation?
>
> André
>

A Turing machine UTM that is simulating its own Turing machine
description is two distinct instances: (executed and simulated) even if
computer science does not bother to pay attention to this level of
detail, or have the terminology to express it.

--
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 3/15/2022 1:44 PM, olcott wrote:
> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>> On 3/15/2022 10:11 AM, olcott wrote:
>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>
>>     <MAJOR SNIP>
>>
>>>> So how would you describe a compiler which is "bootstrapped", i.e.
>>>> fed its own
>>>> source code?
>>>
>>> A compiler that is fed its own source-code is not the same because
>>> the compiler does not execute this source-code.
>> This is one of your best Peter. Along the way you've had 100s of
>> messages that have said that simulation as a basis for a Halting
>> Problem solution is hopeless. Of course you pay no attention because
>> it's unlikely you understood what you were being told. So here you are
>> looping back over years of the same bone headed approach.
>>
>> Let's start with a few basics:
>>
>> Nothing executes source code; even an interpreter ingests it first.
>>
>
> A compiler the compiles its own source-code is nothing at all like
> executing this source code.
You really do have rocks in your head. Think for at least 2 seconds
before responding and getting it all wrong. The mistakes you are making
with the above statement are so basic that I hardly know where to start.
As I've been told many times it's harder to teach Kindergarten than grad
students. And in this instance, with you, we have a sixty year old
crawling around in diapers.
> An interpreter that interprets source code can be reasonably construed
> as running this source code.
Perhaps. The issue is it really doesn't know that it is it's own source
code, does it? And, in fact, neither it nor any observer is aware of any
vicious self reference. Only a dunce would worry about it. You do worry
don't you?
> When a BASIC programmer says that they ran their program they do not
> provide all of the tedious details of the technical intermediate steps.
Certainly not when they run it. But tedious details are often the right
information when they want to describe it or prove something about or
debug it, etc.
And then there's you! You fowled (Like the spelling? Think bird shit.)
up again by slicing important and helpful text from the message you are
replying to. Was it because it wasn't relevant? No! It was because you
dimly perceived that your mindless response was already addressed. Why
advertise that you are a freaking idiot who does not read much and can
not read for comprehension?
Take the advice given in the part you chopped off: ask Ben for help to
understand basic vocabulary and concepts then go from there?

In case anyone cares, the original message that PO replied to, while
soiling his pants, follows:
---------------------------------------------------------------------
On 3/15/2022 10:11 AM, olcott wrote:
> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
<MAJOR SNIP>
>> So how would you describe a compiler which is "bootstrapped", i.e.
fed its own
>> source code?
>
> A compiler that is fed its own source-code is not the same because
the compiler does not execute this source-code.
This is one of your best Peter. Along the way you've had 100s of
messages that have said that simulation as a basis for a Halting Problem
solution is hopeless. Of course you pay no attention because it's
unlikely you understood what you were being told. So here you are
looping back over years of the same bone headed approach.
Let's start with a few basics:
Nothing executes source code; even an interpreter ingests it first.
All an ingestor, compiler, or assembler does is to change a program
languages representation into another equivalent form. If it's working
properly, that is.
So the properly compiled compiler is just another representation of its
source code. And, indeed, that brings us to the conclusion of this
little explanation:
THE COMPILER IN ONE REPRESENTATION IS PROCESSING ITSELF IN ANOTHER
REPRESENTATION. SO YOU ARE WRONG ONCE AGAIN (AS ALWAYS).
Before leaving you to your hard won state as a total proud ignoramus,
I'll list these terms in the above that you don't understand:
simulation, Halting Problem, source code, interpreter, ingest, compiler,
assembler, equivalent form, representation, ignoramus.
Quite a list isn't it? Start with "ignoramus" if you want that to go
away, look it up. Then go through the other words one at a time. Ben has
offered, many many times, to teach you if you ask. Why not? Your legacy
and impression on the world has turned from proud ignorance to
stupidity. The former is curable, the latter is not. Get busy and leave
a good impression!
--
Jeff Barnett

On 3/15/2022 4:48 PM, Jeff Barnett wrote:
> On 3/15/2022 1:44 PM, olcott wrote:
>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>
>>>     <MAJOR SNIP>
>>>
>>>>> So how would you describe a compiler which is "bootstrapped", i.e.
>>>>> fed its own
>>>>> source code?
>>>>
>>>> A compiler that is fed its own source-code is not the same because
>>>> the compiler does not execute this source-code.
>>> This is one of your best Peter. Along the way you've had 100s of
>>> messages that have said that simulation as a basis for a Halting
>>> Problem solution is hopeless. Of course you pay no attention because
>>> it's unlikely you understood what you were being told. So here you
>>> are looping back over years of the same bone headed approach.
>>>
>>> Let's start with a few basics:
>>>
>>> Nothing executes source code; even an interpreter ingests it first.
>>>
>>
>> A compiler the compiles its own source-code is nothing at all like
>> executing this source code.
>
> You really do have rocks in your head. Think for at least 2 seconds
> before responding and getting it all wrong. The mistakes you are making
> with the above statement are so basic that I hardly know where to start.
> As I've been told many times it's harder to teach Kindergarten than grad
> students. And in this instance, with you, we have a sixty year old
> crawling around in diapers.
>
>> An interpreter that interprets source code can be reasonably construed
>> as running this source code.
>
> Perhaps. The issue is it really doesn't know that it is it's own source
> code, does it? And, in fact, neither it nor any observer is aware of any
> vicious self reference. Only a dunce would worry about it. You do worry
> don't you?

In other words you are saying that no one is bright enough to be able to
detect what is essentially infinite recursion.

--
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 3/15/2022 3:24 PM, André G. Isaak wrote:
> On 2022-03-15 08:51, olcott wrote:
>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>> On 2022-03-14 21:07, olcott wrote:
>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>
>>>>>> <snip nonresponsive post>
>>>>>>
>>>>>> Again, I'll repeat the question which you dishonestly snipped rather
>>>>>> than answering. I won't bother putting it in all caps or repeating it
>>>>>> five times.
>>>>>>
>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect
>>>>> reference
>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>> There are no 'levels of indirection' when discussing Turing Machines.
>>>>
>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an
>>>> input
>>>> to your decider, then your decider is broken since it must be able to
>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>
>>> Though that would actually be a genuine contribution to computer
>>> science.
>>> If you could devise a language such that a large subset of halting and
>>> non-halting machines could be described, but not machines for which the
>>> halting status is difficult or impossible for a predefined halt
>>> decider to determine.
>>
>> André does not seem to be able to comprehend that a Turing machine
>> decider cannot possibly have its own self or an encoding of its own
>> self as its input. The closest thing possible that it can have is an
>> encoding of another different instance of itself.
>
> Computations don't have different instances. What would it even mean to
> 'instantiate' a computation?
>
> André
>

Back to the key point:

That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when correctly
simulated by the UTM within embedded_H is the same as these finite
strings specifying non-halting behavior when correctly interpreted by a
BASIC in interpreter.

10 PRINT "Hello, World!"
20 goto 10
30 END

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

The above repeating pattern shows that the correctly simulated input to
embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively
proving that this simulated input never halts. This enables embedded_H
to abort its simulation and correctly transition to Ĥ.qn.

--
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 3/15/2022 4:02 PM, olcott wrote:
> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>> On 3/15/2022 1:44 PM, olcott wrote:
>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>
>>>>     <MAJOR SNIP>
>>>>
>>>>>> So how would you describe a compiler which is "bootstrapped", i.e.
>>>>>> fed its own
>>>>>> source code?
>>>>>
>>>>> A compiler that is fed its own source-code is not the same because
>>>>> the compiler does not execute this source-code.
>>>> This is one of your best Peter. Along the way you've had 100s of
>>>> messages that have said that simulation as a basis for a Halting
>>>> Problem solution is hopeless. Of course you pay no attention because
>>>> it's unlikely you understood what you were being told. So here you
>>>> are looping back over years of the same bone headed approach.
>>>>
>>>> Let's start with a few basics:
>>>>
>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>
>>>
>>> A compiler the compiles its own source-code is nothing at all like
>>> executing this source code.
>>
>> You really do have rocks in your head. Think for at least 2 seconds
>> before responding and getting it all wrong. The mistakes you are
>> making with the above statement are so basic that I hardly know where
>> to start. As I've been told many times it's harder to teach
>> Kindergarten than grad students. And in this instance, with you, we
>> have a sixty year old crawling around in diapers.
>>
>>> An interpreter that interprets source code can be reasonably
>>> construed as running this source code.
>>
>> Perhaps. The issue is it really doesn't know that it is it's own
>> source code, does it? And, in fact, neither it nor any observer is
>> aware of any vicious self reference. Only a dunce would worry about
>> it. You do worry don't you?
>
> In other words you are saying that no one is bright enough to be able to
> detect what is essentially infinite recursion.
You soiled your diapers again. I said nothing of the sort. I will say it
now though, nobody is intelligent enough to systematically (by
algorithm) spot infinite recursion. God can't do it either. It's not
theoretically possible. Only an ignorant nitwit would not know that and
prattle on for years about it.
By the way, if you think either you or a program you write can spot
infinite recursion in, say, a year I'd love to make a sizable bet that
you can not. In the past several of us have proposed such test cases to
you. You haven't tried any of them. In fact you clipped these problem
descriptions out of the original messages when you responded.
It's amazing that you make the same mistakes over and over again. If you
could spot the infinite recursion/iteration in that small mind of yours
you would be doing something more sane with your time.
--
Jeff Barnett

On 3/16/2022 2:21 AM, Jeff Barnett wrote:
> On 3/15/2022 4:02 PM, olcott wrote:
>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>
>>>>>     <MAJOR SNIP>
>>>>>
>>>>>>> So how would you describe a compiler which is "bootstrapped",
>>>>>>> i.e. fed its own
>>>>>>> source code?
>>>>>>
>>>>>> A compiler that is fed its own source-code is not the same because
>>>>>> the compiler does not execute this source-code.
>>>>> This is one of your best Peter. Along the way you've had 100s of
>>>>> messages that have said that simulation as a basis for a Halting
>>>>> Problem solution is hopeless. Of course you pay no attention
>>>>> because it's unlikely you understood what you were being told. So
>>>>> here you are looping back over years of the same bone headed approach.
>>>>>
>>>>> Let's start with a few basics:
>>>>>
>>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>>
>>>>
>>>> A compiler the compiles its own source-code is nothing at all like
>>>> executing this source code.
>>>
>>> You really do have rocks in your head. Think for at least 2 seconds
>>> before responding and getting it all wrong. The mistakes you are
>>> making with the above statement are so basic that I hardly know where
>>> to start. As I've been told many times it's harder to teach
>>> Kindergarten than grad students. And in this instance, with you, we
>>> have a sixty year old crawling around in diapers.
>>>
>>>> An interpreter that interprets source code can be reasonably
>>>> construed as running this source code.
>>>
>>> Perhaps. The issue is it really doesn't know that it is it's own
>>> source code, does it? And, in fact, neither it nor any observer is
>>> aware of any vicious self reference. Only a dunce would worry about
>>> it. You do worry don't you?
>>
>> In other words you are saying that no one is bright enough to be able
>> to detect what is essentially infinite recursion.
> You soiled your diapers again. I said nothing of the sort. I will say it
> now though, nobody is intelligent enough to systematically (by
> algorithm) spot infinite recursion. God can't do it either. It's not
> theoretically possible. Only an ignorant nitwit would not know that and
> prattle on for years about it.
>

I already have a group of many experts that concur that infinite
recursion can be detected and the criterion measure by which it is
correctly detected.

> By the way, if you think either you or a program you write can spot
> infinite recursion in, say, a year I'd love to make a sizable bet that
> you can not. In the past several of us have proposed such test cases to
> you. You haven't tried any of them. In fact you clipped these problem
> descriptions out of the original messages when you responded.
>
> It's amazing that you make the same mistakes over and over again. If you
> could spot the infinite recursion/iteration in that small mind of yours
> you would be doing something more sane with your time.

--
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 3/16/2022 11:06 AM, Malcolm McLean wrote:
> On Wednesday, 16 March 2022 at 14:16:07 UTC, olcott wrote:
>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>
>>>>>>> <MAJOR SNIP>
>>>>>>>
>>>>>>>>> So how would you describe a compiler which is "bootstrapped",
>>>>>>>>> i.e. fed its own
>>>>>>>>> source code?
>>>>>>>>
>>>>>>>> A compiler that is fed its own source-code is not the same because
>>>>>>>> the compiler does not execute this source-code.
>>>>>>> This is one of your best Peter. Along the way you've had 100s of
>>>>>>> messages that have said that simulation as a basis for a Halting
>>>>>>> Problem solution is hopeless. Of course you pay no attention
>>>>>>> because it's unlikely you understood what you were being told. So
>>>>>>> here you are looping back over years of the same bone headed approach.
>>>>>>>
>>>>>>> Let's start with a few basics:
>>>>>>>
>>>>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>>>>
>>>>>>
>>>>>> A compiler the compiles its own source-code is nothing at all like
>>>>>> executing this source code.
>>>>>
>>>>> You really do have rocks in your head. Think for at least 2 seconds
>>>>> before responding and getting it all wrong. The mistakes you are
>>>>> making with the above statement are so basic that I hardly know where
>>>>> to start. As I've been told many times it's harder to teach
>>>>> Kindergarten than grad students. And in this instance, with you, we
>>>>> have a sixty year old crawling around in diapers.
>>>>>
>>>>>> An interpreter that interprets source code can be reasonably
>>>>>> construed as running this source code.
>>>>>
>>>>> Perhaps. The issue is it really doesn't know that it is it's own
>>>>> source code, does it? And, in fact, neither it nor any observer is
>>>>> aware of any vicious self reference. Only a dunce would worry about
>>>>> it. You do worry don't you?
>>>>
>>>> In other words you are saying that no one is bright enough to be able
>>>> to detect what is essentially infinite recursion.
>>> You soiled your diapers again. I said nothing of the sort. I will say it
>>> now though, nobody is intelligent enough to systematically (by
>>> algorithm) spot infinite recursion. God can't do it either. It's not
>>> theoretically possible. Only an ignorant nitwit would not know that and
>>> prattle on for years about it.
>>>
>> I already have a group of many experts that concur that infinite
>> recursion can be detected and the criterion measure by which it is
>> correctly detected.
>>
> It can often be detected.
> In real programs which are basically imperative, with a small amount of recursion,
> written by human programmers, infinite recursion can usually be detected quite easily.
>
> However it's possible to recast famous open problems in mathematics as
> recursive routines which either eventualy return or never return, depending on
> whether the conjecture is true or false. Of course you can't detect infinite
> recursion in these cases by using a simple toolkit of pattern matching.

Currently undecidable because a proof is currently unknown is not the
same as "undecidable" because of self contradiction such as the Liar
Paradox (Upon which the Tarski Undefinability Theorem is based).

--
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 3/16/2022 11:40 AM, Malcolm McLean wrote:
> On Wednesday, 16 March 2022 at 16:17:38 UTC, olcott wrote:
>> On 3/16/2022 11:06 AM, Malcolm McLean wrote:
>>> On Wednesday, 16 March 2022 at 14:16:07 UTC, olcott wrote:
>>>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>>>
>>>>>>>>> <MAJOR SNIP>
>>>>>>>>>
>>>>>>>>>>> So how would you describe a compiler which is "bootstrapped",
>>>>>>>>>>> i.e. fed its own
>>>>>>>>>>> source code?
>>>>>>>>>>
>>>>>>>>>> A compiler that is fed its own source-code is not the same because
>>>>>>>>>> the compiler does not execute this source-code.
>>>>>>>>> This is one of your best Peter. Along the way you've had 100s of
>>>>>>>>> messages that have said that simulation as a basis for a Halting
>>>>>>>>> Problem solution is hopeless. Of course you pay no attention
>>>>>>>>> because it's unlikely you understood what you were being told. So
>>>>>>>>> here you are looping back over years of the same bone headed approach.
>>>>>>>>>
>>>>>>>>> Let's start with a few basics:
>>>>>>>>>
>>>>>>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>>>>>>
>>>>>>>>
>>>>>>>> A compiler the compiles its own source-code is nothing at all like
>>>>>>>> executing this source code.
>>>>>>>
>>>>>>> You really do have rocks in your head. Think for at least 2 seconds
>>>>>>> before responding and getting it all wrong. The mistakes you are
>>>>>>> making with the above statement are so basic that I hardly know where
>>>>>>> to start. As I've been told many times it's harder to teach
>>>>>>> Kindergarten than grad students. And in this instance, with you, we
>>>>>>> have a sixty year old crawling around in diapers.
>>>>>>>
>>>>>>>> An interpreter that interprets source code can be reasonably
>>>>>>>> construed as running this source code.
>>>>>>>
>>>>>>> Perhaps. The issue is it really doesn't know that it is it's own
>>>>>>> source code, does it? And, in fact, neither it nor any observer is
>>>>>>> aware of any vicious self reference. Only a dunce would worry about
>>>>>>> it. You do worry don't you?
>>>>>>
>>>>>> In other words you are saying that no one is bright enough to be able
>>>>>> to detect what is essentially infinite recursion.
>>>>> You soiled your diapers again. I said nothing of the sort. I will say it
>>>>> now though, nobody is intelligent enough to systematically (by
>>>>> algorithm) spot infinite recursion. God can't do it either. It's not
>>>>> theoretically possible. Only an ignorant nitwit would not know that and
>>>>> prattle on for years about it.
>>>>>
>>>> I already have a group of many experts that concur that infinite
>>>> recursion can be detected and the criterion measure by which it is
>>>> correctly detected.
>>>>
>>> It can often be detected.
>>> In real programs which are basically imperative, with a small amount of recursion,
>>> written by human programmers, infinite recursion can usually be detected quite easily.
>>>
>>> However it's possible to recast famous open problems in mathematics as
>>> recursive routines which either eventualy return or never return, depending on
>>> whether the conjecture is true or false. Of course you can't detect infinite
>>> recursion in these cases by using a simple toolkit of pattern matching.
>> Currently undecidable because a proof is currently unknown is not the
>> same as "undecidable" because of self contradiction such as the Liar
>> Paradox (Upon which the Tarski Undefinability Theorem is based).
>>
> That's right. For example Goldbach's conjecture is that every even number above
> two is the sum of two primes. If you have a universal infinite recursion detector,
> it would be easy to prove or disprove this conjecture by writing a function which
> terminates when it finds a counterexample, and running it through the detector.
> But of course we can't write a universal infinite recursion detector.
>

It does not need to be universal to defeat the halting problem proof
counter-example templates. This refutes this whole class of halting
problem proofs.

> What you might be able to do is write a special purpose detector, and prove or
> disprove the conjecture that way. But you can't do that by using a few simple
> techniques, or it would have been done already. What's more likely is that
> the conjecture will be solved by mathematical techniques, and then you could
> dectect functions which enumerate the conjecture, and decide them based on
> prior knowledge. However that's difficult to do, and not really of much interest
> to anyone.

--
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 3/16/2022 12:04 PM, Mike Terry wrote:
> On 16/03/2022 14:15, olcott wrote:
>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>
>>>>>>>     <MAJOR SNIP>
>>>>>>>
>>>>>>>>> So how would you describe a compiler which is "bootstrapped",
>>>>>>>>> i.e. fed its own
>>>>>>>>> source code?
>>>>>>>>
>>>>>>>> A compiler that is fed its own source-code is not the same
>>>>>>>> because the compiler does not execute this source-code.
>>>>>>> This is one of your best Peter. Along the way you've had 100s of
>>>>>>> messages that have said that simulation as a basis for a Halting
>>>>>>> Problem solution is hopeless. Of course you pay no attention
>>>>>>> because it's unlikely you understood what you were being told. So
>>>>>>> here you are looping back over years of the same bone headed
>>>>>>> approach.
>>>>>>>
>>>>>>> Let's start with a few basics:
>>>>>>>
>>>>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>>>>
>>>>>>
>>>>>> A compiler the compiles its own source-code is nothing at all like
>>>>>> executing this source code.
>>>>>
>>>>> You really do have rocks in your head. Think for at least 2 seconds
>>>>> before responding and getting it all wrong. The mistakes you are
>>>>> making with the above statement are so basic that I hardly know
>>>>> where to start. As I've been told many times it's harder to teach
>>>>> Kindergarten than grad students. And in this instance, with you, we
>>>>> have a sixty year old crawling around in diapers.
>>>>>
>>>>>> An interpreter that interprets source code can be reasonably
>>>>>> construed as running this source code.
>>>>>
>>>>> Perhaps. The issue is it really doesn't know that it is it's own
>>>>> source code, does it? And, in fact, neither it nor any observer is
>>>>> aware of any vicious self reference. Only a dunce would worry about
>>>>> it. You do worry don't you?
>>>>
>>>> In other words you are saying that no one is bright enough to be
>>>> able to detect what is essentially infinite recursion.
>>> You soiled your diapers again. I said nothing of the sort. I will say
>>> it now though, nobody is intelligent enough to systematically (by
>>> algorithm) spot infinite recursion. God can't do it either. It's not
>>> theoretically possible. Only an ignorant nitwit would not know that
>>> and prattle on for years about it.
>>>
>>
>> I already have a group of many experts that concur that infinite
>> recursion can be detected and the criterion measure by which it is
>> correctly detected.
>
> I'm afraid that you lack the intellect to understand exactly what other
> people are saying on technical issues.  How many times have you quoted
> me (and others here) as supporting something you've claimed, whereas it
> turns out you had just misunderstood some remark that had been made?
> [Answer: lots of times!]
>
> You also have a habit of going elsewhere, and "tricking" the people
> there into "agreeing" with some claim you've made here by not properly
> explaining the full context of your claim.  Then you come back here
> selectively quoting some "expert" to suggest he is supporting you.
> [Like when you went to the x86 group and showed them your "trace" asking
> them if they could see what's going on, and got one of them to say "it's
> looping...".  You failed to mention the trace was not the "processor
> trace" they would naturally expect, and that there was simulation
> involved, and that your trace was in fact some kind of "merged
> simulation trace", and that you were using this trace to disprove the
> Halting Problem theorem.]
>
> It's been pointed out to you many times that algorithms exhist that can
> identify /some/ infinite loops/recursions as such, but no algorithm
> detects ALL non-halting behaviour.
>
> And specifically, your test (looking for more than one call to a
> particular address etc.) is /unsound/ when you try to use it on your
> "merged simulation" trace.  No expert would say otherwise if they had
> been given the full context, so probably you've just tricked someone
> again...
>
>
> Mike.

None-the-less is is self-evident that the input presented to the copy of
the Linz H embedded at Ĥ.qx does specify infinitely nested simulation to
simulating halt decider embedded_H thus proving that a transition to
Ĥ.qn by embedded_H would be correct.

H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final
state of M

Simulating halt decider H performs a pure simulation of its input as if
it was a UTM unless and until it detects an infinitely repeating
pattern. Then it aborts the simulation of its input and transitions to
its final reject state. Otherwise H transitions to its accept state when
its simulation ends.

The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ, it is now a single machine with a single start state.
A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
state.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

--
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 3/16/2022 12:37 PM, Mike Terry wrote:
> On 16/03/2022 17:20, olcott wrote:
>> On 3/16/2022 12:04 PM, Mike Terry wrote:
>>> On 16/03/2022 14:15, olcott wrote:
>>>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>>>
>>>>>>>>>     <MAJOR SNIP>
>>>>>>>>>
>>>>>>>>>>> So how would you describe a compiler which is "bootstrapped",
>>>>>>>>>>> i.e. fed its own
>>>>>>>>>>> source code?
>>>>>>>>>>
>>>>>>>>>> A compiler that is fed its own source-code is not the same
>>>>>>>>>> because the compiler does not execute this source-code.
>>>>>>>>> This is one of your best Peter. Along the way you've had 100s
>>>>>>>>> of messages that have said that simulation as a basis for a
>>>>>>>>> Halting Problem solution is hopeless. Of course you pay no
>>>>>>>>> attention because it's unlikely you understood what you were
>>>>>>>>> being told. So here you are looping back over years of the same
>>>>>>>>> bone headed approach.
>>>>>>>>>
>>>>>>>>> Let's start with a few basics:
>>>>>>>>>
>>>>>>>>> Nothing executes source code; even an interpreter ingests it
>>>>>>>>> first.
>>>>>>>>>
>>>>>>>>
>>>>>>>> A compiler the compiles its own source-code is nothing at all
>>>>>>>> like executing this source code.
>>>>>>>
>>>>>>> You really do have rocks in your head. Think for at least 2
>>>>>>> seconds before responding and getting it all wrong. The mistakes
>>>>>>> you are making with the above statement are so basic that I
>>>>>>> hardly know where to start. As I've been told many times it's
>>>>>>> harder to teach Kindergarten than grad students. And in this
>>>>>>> instance, with you, we have a sixty year old crawling around in
>>>>>>> diapers.
>>>>>>>
>>>>>>>> An interpreter that interprets source code can be reasonably
>>>>>>>> construed as running this source code.
>>>>>>>
>>>>>>> Perhaps. The issue is it really doesn't know that it is it's own
>>>>>>> source code, does it? And, in fact, neither it nor any observer
>>>>>>> is aware of any vicious self reference. Only a dunce would worry
>>>>>>> about it. You do worry don't you?
>>>>>>
>>>>>> In other words you are saying that no one is bright enough to be
>>>>>> able to detect what is essentially infinite recursion.
>>>>> You soiled your diapers again. I said nothing of the sort. I will
>>>>> say it now though, nobody is intelligent enough to systematically
>>>>> (by algorithm) spot infinite recursion. God can't do it either.
>>>>> It's not theoretically possible. Only an ignorant nitwit would not
>>>>> know that and prattle on for years about it.
>>>>>
>>>>
>>>> I already have a group of many experts that concur that infinite
>>>> recursion can be detected and the criterion measure by which it is
>>>> correctly detected.
>>>
>>> I'm afraid that you lack the intellect to understand exactly what
>>> other people are saying on technical issues.  How many times have you
>>> quoted me (and others here) as supporting something you've claimed,
>>> whereas it turns out you had just misunderstood some remark that had
>>> been made? [Answer: lots of times!]
>>>
>>> You also have a habit of going elsewhere, and "tricking" the people
>>> there into "agreeing" with some claim you've made here by not
>>> properly explaining the full context of your claim.  Then you come
>>> back here selectively quoting some "expert" to suggest he is
>>> supporting you. [Like when you went to the x86 group and showed them
>>> your "trace" asking them if they could see what's going on, and got
>>> one of them to say "it's looping...".  You failed to mention the
>>> trace was not the "processor trace" they would naturally expect, and
>>> that there was simulation involved, and that your trace was in fact
>>> some kind of "merged simulation trace", and that you were using this
>>> trace to disprove the Halting Problem theorem.]
>>>
>>> It's been pointed out to you many times that algorithms exhist that
>>> can identify /some/ infinite loops/recursions as such, but no
>>> algorithm detects ALL non-halting behaviour.
>>>
>>> And specifically, your test (looking for more than one call to a
>>> particular address etc.) is /unsound/ when you try to use it on your
>>> "merged simulation" trace.  No expert would say otherwise if they had
>>> been given the full context, so probably you've just tricked someone
>>> again...
>>>
>>>
>>> Mike.
>>
>> None-the-less is is self-evident that the input presented to the copy
>> of the Linz H embedded at Ĥ.qx does specify infinitely nested
>> simulation to simulating halt decider embedded_H thus proving that a
>> transition to Ĥ.qn by embedded_H would be correct.
>
> You mean self-evident TO YOU.  To people who have an understanding of
> TMs it is simply wrong or meaningless (depending on how tolerant people
> are of your wishy-washy phrasing).
>
>
> Mike.
>

They simply dogmatically state that the believe that I am wrong about
this yet cannot point to the specific error because there is none:

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

The above repeating pattern shows that the correctly simulated input to
embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively
proving that this simulated input never halts. This enables embedded_H
to abort its simulation and correctly transition to Ĥ.qn.

--
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 3/16/2022 3:11 PM, André G. Isaak wrote:
> On 2022-03-15 15:44, olcott wrote:
>> On 3/15/2022 3:24 PM, André G. Isaak wrote:
>>> On 2022-03-15 08:51, olcott wrote:
>>>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>>>> On 2022-03-14 21:07, olcott wrote:
>>>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>>>
>>>>>>>> <snip nonresponsive post>
>>>>>>>>
>>>>>>>> Again, I'll repeat the question which you dishonestly snipped
>>>>>>>> rather
>>>>>>>> than answering. I won't bother putting it in all caps or
>>>>>>>> repeating it
>>>>>>>> five times.
>>>>>>>>
>>>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be
>>>>>>>> passed
>>>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>>>
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect
>>>>>>> reference
>>>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass
>>>>>>> this
>>>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>>>> There are no 'levels of indirection' when discussing Turing Machines.
>>>>>>
>>>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an
>>>>>> input
>>>>>> to your decider, then your decider is broken since it must be able to
>>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>>>
>>>>> Though that would actually be a genuine contribution to computer
>>>>> science.
>>>>> If you could devise a language such that a large subset of halting and
>>>>> non-halting machines could be described, but not machines for which
>>>>> the
>>>>> halting status is difficult or impossible for a predefined halt
>>>>> decider to determine.
>>>>
>>>> André does not seem to be able to comprehend that a Turing machine
>>>> decider cannot possibly have its own self or an encoding of its own
>>>> self as its input. The closest thing possible that it can have is an
>>>> encoding of another different instance of itself.
>>>
>>> Computations don't have different instances. What would it even mean
>>> to 'instantiate' a computation?
>>>
>>> André
>>>
>>
>> A Turing machine UTM that is simulating its own Turing machine
>> description is two distinct instances: (executed and simulated) even
>> if computer science does not bother to pay attention to this level of
>> detail, or have the terminology to express it.
>
> You're confusing computations and Turing Machines.
>
> If you pass a UTM a description of itself, it will determine what UTM
> applied to an empty tape will do.
>
> UTM ⟨UTM⟩
>
> and
>
> UTM ∅
>
> are entirely distinct computations.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

In the above: Ĥ applied to ⟨Ĥ⟩ and the ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H
vary by exactly one level of indirect reference.

embedded_H does not, cannot, and its not supposed to report on the exact
same computation that contains itself.

embedded_H computes the mapping of its input ⟨Ĥ⟩ ⟨Ĥ⟩ a final state of
embedded_H.

> They are not different 'instances'
> of some computation. Every "instance" of
>
> M ⟨I⟩
>
> is the exact same computation. So there is no point in talking about
> "instances".
>
> Do you actually understand what instantiation means?
>
> André
>

What Does Instantiate Mean?
Instantiate (a verb) and instantiation (the noun) in computer science
refer to the creation of an object (or an “instance” of a given class)
in an object-oriented programming (OOP) language. Referencing a class
declaration, an instantiated object is named and created, in memory or
on disk.

https://www.techopedia.com/definition/26857/instantiate#:~:text=Instantiate%20(a%20verb)%20and%20instantiation,in%20memory%20or%20on%20disk.

--
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 3/16/2022 3:58 PM, André G. Isaak wrote:
> On 2022-03-16 14:22, olcott wrote:
>> On 3/16/2022 3:11 PM, André G. Isaak wrote:
>>> On 2022-03-15 15:44, olcott wrote:
>
> <snip>
>
>>>> A Turing machine UTM that is simulating its own Turing machine
>>>> description is two distinct instances: (executed and simulated) even
>>>> if computer science does not bother to pay attention to this level
>>>> of detail, or have the terminology to express it.
>>>
>>> You're confusing computations and Turing Machines.
>>>
>>> If you pass a UTM a description of itself, it will determine what UTM
>>> applied to an empty tape will do.
>>>
>>> UTM ⟨UTM⟩
>>>
>>> and
>>>
>>> UTM ∅
>>>
>>> are entirely distinct computations.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> In the above: Ĥ applied to ⟨Ĥ⟩ and the ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H
>> vary by exactly one level of indirect reference.
>
> Which has absolutely nothing to do with my point since only *one* of the
> above is a computation; Ĥ applied to ⟨Ĥ⟩. The other, ⟨Ĥ⟩ ⟨Ĥ⟩ is a string
> which describes a computation, and the computation it describes is Ĥ
> applied to ⟨Ĥ⟩ which is the computation which your 'embedded_H' must
> answer about.
>

You can dodge this fact a million times, none-the-less the copy of Linz
H embedded at Ĥ.qx computes the mapping from its input to its own final
state on the basis of the behavior of its correct simulation of this input.

It is an easily verifiable fact that this simulated input would never
reach its own final state in any finite number of steps of simulation.

I will not address any other points until this point 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 3/16/2022 8:16 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/12/2022 8:55 PM, Ben Bacarisse wrote:
>>> André G. Isaak <agisaak@gm.invalid> writes:
>>>
>>>>> On 3/12/2022 5:57 PM, André G. Isaak wrote:
>>>
>>>>>> So what string, according to you, encodes the computation Ĥ applied
>>>>>> to ⟨Ĥ⟩? If these two "different" computations don't have separate
>>>>>> encodings as strings then they are not, in fact, different
>>>>>> computations at all.
>>>>
>>>> No Comment?
>>>>
>>>> I know you've been asked this question before and have consistently
>>>> ignored it. According to a recent post of yours that constitutes
>>>> justification for a repetitive all-caps temper tantrum!
>>> I once tried to get a direct answer to this question. I asked 12 times
>>> in consecutive posts but never got one.
>>> Later, on the related question of whether ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>> computation I got this dazzling display of equivocation:
>>> "When it is construed as input to H then ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>> computation.
>>> When it is construed as input to Ĥ.qx then ⟨Ĥ⟩ ⟨Ĥ⟩ DOES NOT encode a
>>> halting computation."
>>> Bear in mind that at time, PO's machines were magic: two identical state
>>> transition functions could entail transitions to different states when
>>> presented with identical inputs. He has since backed off from some of
>>> these remarks, but it never exactly clear which previous claims he would
>>> now accept were wrong.
>>
>> None-the-less...
>
> You mean you won't comment on the above but would rather present new
> junk about BASIC. Oh well... I can't stop you.
>

It is true that the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach
its own final state in any finite steps of simulation by embedded_H.
This means that it is an established fact that this inputs specifies a
non-halting sequence of configurations.

This means that the Linz proof that says:

<Linz:1990:320>
Now Ĥ is a Turing machine, so that it will have some description in Σ*,
say ŵ . This string, in addition to being the description of Ĥ can also
be used as input string. We can therefore legitimately ask what would
happen if Ĥ is applied to ŵ .
…
The contradiction tells us that our assumption of the existence of H,
and hence the assumption of the decidability of the halting problem,
must be false.
</Linz:1990:320>

is refuted because no contradiction is formed when Ĥ is applied to ⟨Ĥ⟩.

Here is the full context:
https://www.liarparadox.org/Linz_Proof.pdf

--
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 3/16/2022 8:30 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/12/2022 9:59 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>
>>> I've shown you how to write Linz's conditions in terms of simulation:
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if UTM(Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>> Feel fee to replace "halts" with "would reach its final state" (and
>>> similarly for "does not halt") if it make you feel better. Both figures
>>> of speech convey the same mathematical fact, but one is shorter and fits
>>> on a line.
>>> What you can't do, if you want to keep talking about what Linz is
>>> talking about, is replace the reference to a UTM with embedded_H.
>>
>> Embedded_H has a full UTM as a part of it.
>
> Not in dispute.
>
>> The Linz ⊢* wild card state transition allows for a UTM simulation to
>> be a part of the decision process.
>
> Not in dispute.
>
>> Embedded_H determines whether or not its simulated input would ever
>> reach its final state if embedded_H remained in pure UTM mode.
>
> Not in dispute.
>
>>>> It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the
>>>> copy of H embedded within Ĥ would never reach the final state of this
>>>> input ⟨Ĥ⟩.qn.
>>> Irrelevant. What matters is what follows logically from Linz's
>>> definition of a halt decider. If you think there is any point, I'll
>>> write it out again for you in terms of UTMs.
>>
>> If the input to embedded_H never halts and embedded_H correctly
>> reports this that is most relevant.
>
> Not in dispute (except for the poor wording).
>
> If you want to know why you are still wrong after 14 years, you are
> going to have to learn to follow what other people are saying. Of
> course, if you did that, you'd see all your mistakes, so you are much
> better off remaining ignorant of what's being said to you.
>

When the Linz H is embedded in the Linz Ĥ as a simulating halt decider
then the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H presents infinitely nested
simulation to embedded_H thus making the embedded_H transition to Ĥ.qn
correct.

This refutes the Linz proof because the Linz proof concludes that Ĥ
applied to ⟨Ĥ⟩ results in a contradiction. (see direct quote below).

</Linz:1990:320>
Now Ĥ is a Turing machine, so that it will have some description in Σ*,
say ŵ . This string, in addition to being the description of Ĥ can also
be used as input string. We can therefore legitimately ask what would
happen if Ĥ is applied to ŵ .
…
The contradiction tells us that our assumption of the existence of H,
and hence the assumption of the decidability of the halting problem,
must be false.
</Linz:1990:320>

https://www.liarparadox.org/Linz_Proof.pdf

--
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 3/16/2022 8:36 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/16/2022 8:16 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/12/2022 8:55 PM, Ben Bacarisse wrote:
>>>>> André G. Isaak <agisaak@gm.invalid> writes:
>>>>>
>>>>>>> On 3/12/2022 5:57 PM, André G. Isaak wrote:
>>>>>
>>>>>>>> So what string, according to you, encodes the computation Ĥ applied
>>>>>>>> to ⟨Ĥ⟩? If these two "different" computations don't have separate
>>>>>>>> encodings as strings then they are not, in fact, different
>>>>>>>> computations at all.
>>>>>>
>>>>>> No Comment?
>>>>>>
>>>>>> I know you've been asked this question before and have consistently
>>>>>> ignored it. According to a recent post of yours that constitutes
>>>>>> justification for a repetitive all-caps temper tantrum!
>>>>> I once tried to get a direct answer to this question. I asked 12 times
>>>>> in consecutive posts but never got one.
>>>>> Later, on the related question of whether ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>>>> computation I got this dazzling display of equivocation:
>>>>> "When it is construed as input to H then ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>>>> computation.
>>>>> When it is construed as input to Ĥ.qx then ⟨Ĥ⟩ ⟨Ĥ⟩ DOES NOT encode a
>>>>> halting computation."
>>>>> Bear in mind that at time, PO's machines were magic: two identical state
>>>>> transition functions could entail transitions to different states when
>>>>> presented with identical inputs. He has since backed off from some of
>>>>> these remarks, but it never exactly clear which previous claims he would
>>>>> now accept were wrong.
>>>>
>>>> None-the-less...
>>>
>>> You mean you won't comment on the above but would rather present new
>>> junk about BASIC. Oh well... I can't stop you.
>>
>> None-the-less none of what you have ever said shows that I am
>> incorrect.
>
> Ah! So from your point of view I did not point out an error in the post
> you replied to. That means you /still/ think that:
>
> "When it is construed as input to H then ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
> computation. When it is construed as input to Ĥ.qx then ⟨Ĥ⟩ ⟨Ĥ⟩ DOES
> NOT encode a halting computation."
>

THIS IS THE ONLY POINT THAT MATTERS
THIS IS THE ONLY POINT THAT MATTERS
THIS IS THE ONLY POINT THAT MATTERS
THIS IS THE ONLY POINT THAT MATTERS

That the simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would never reach the
final state of this simulated input in any finite number of steps of
correct simulation by embedded_H conclusively proves that a mapping from
this input to the reject state of embedded_H is correct.

> That's useful to know. Either your strings or your TMs are still
> magic. Sadly, that means you have nothing to say about the halting
> problem for Turing machines. You need to fix that before anyone can
> take you seriously.
>

--
Copyright 2021 Pete Olcott

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