On 8/27/2021 12:17 PM, André G. Isaak wrote:
> On 2021-08-27 10:41, olcott wrote:
>> On 8/27/2021 11:25 AM, André G. Isaak wrote:
>>> On 2021-08-27 09:57, olcott wrote:
>>>> On 8/27/2021 10:20 AM, Malcolm McLean wrote:
>>>>> On Friday, 27 August 2021 at 16:11:45 UTC+1, olcott wrote:
>>>>>>
>>>>>> How can the UTM simulation of a machine that copies a string not
>>>>>> perform
>>>>>> the functional equivalent of copying a string and still be an
>>>>>> accurate
>>>>>> simulation of this TM?
>>>>>>
>>>>> If the machine simply copies the input string, then the UTM
>>>>> simulation must
>>>>> place a copy of the input on the tape before it terminates.
>>>>
>>>> Because Ben said this is not true Ben is wrong.
>>>
>>> You're misconstruing both Ben and Malcolm here. Please pay special
>>> attention to the word *intermediate* in the next sentence.
>>>
>>> You keep talking about a UTM as a 'simulator', but that's really only
>>> a metaphor, and it is one that perhaps you are taking far too literally.
>>>
>>> A UTM is a TM which takes as its input the description of a
>>> computation (i.e. the description of a TM concatenated with an input
>>> string) and computes what the *result* of that computation would be.
>>> There is absolutely no requirement that any intermediate data which
>>> would be written to the tape by the TM described by the input be
>>> duplicated. The final result is all that matters.
>>>
>>> It might be better for you to think of a UTM as a TM which *analyzes*
>>> the description of a TM + input string and determines what that TM
>>> would do rather than a TM which simulates another TM.

Using the vague term *analyzes* making sure to not elaborate any of the
details of the specific steps of this process is not any improvement in
clarity.

When the vague concept of a UTM is made totally concrete then it is
essentially an interpreter of TM source code. When it is kept vague such
that almost all of the steps of the process of *analyzes* are left
unspecified then it might not seem to be an interpreter only because
most of the details are simply missing.

>>>
>>
>> If one is very careful to make sure that one uses sufficiently vague
>> language one can be certainly never sufficiently understood.
>
> You're the one who is using vague language. People here are trying to
> help you make your language *less* vague. I don't see why you are so
> resistant to this effort.
>
>> When we make every detail of a UTM concrete that such it actually
>> executes on a physical computer then all the vagueness is abolished
>> and the UTM is an interpreter of the source code of TMs.
>
> I gave you a link to a paper that contained fully specified descriptions
> of several UTMs. There operation is fully and precisely described with
> absolutely no vagueness.
>
> Your obsession with executing things on physical computers is strange.
> TMs are not intended as models of physical computers, nor are they
> programming languages. They were conceived of as a mathematical tool
> before modern computers even existed.
>
> If you insist on seeing the UTM executed on a real computer, you could
> simply take one of the UTM descriptions in the paper I gave you and run
> it in one of the many TM emulators out there.
>

--
Copyright 2021 Pete Olcott

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

On 8/27/2021 12:43 PM, olcott wrote:
> On 8/27/2021 12:17 PM, André G. Isaak wrote:
>> On 2021-08-27 10:41, olcott wrote:
>>> On 8/27/2021 11:25 AM, André G. Isaak wrote:
>>>> On 2021-08-27 09:57, olcott wrote:
>>>>> On 8/27/2021 10:20 AM, Malcolm McLean wrote:
>>>>>> On Friday, 27 August 2021 at 16:11:45 UTC+1, olcott wrote:
>>>>>>>
>>>>>>> How can the UTM simulation of a machine that copies a string not
>>>>>>> perform
>>>>>>> the functional equivalent of copying a string and still be an
>>>>>>> accurate
>>>>>>> simulation of this TM?
>>>>>>>
>>>>>> If the machine simply copies the input string, then the UTM
>>>>>> simulation must
>>>>>> place a copy of the input on the tape before it terminates.
>>>>>
>>>>> Because Ben said this is not true Ben is wrong.
>>>>
>>>> You're misconstruing both Ben and Malcolm here. Please pay special
>>>> attention to the word *intermediate* in the next sentence.
>>>>
>>>> You keep talking about a UTM as a 'simulator', but that's really
>>>> only a metaphor, and it is one that perhaps you are taking far too
>>>> literally.
>>>>
>>>> A UTM is a TM which takes as its input the description of a
>>>> computation (i.e. the description of a TM concatenated with an input
>>>> string) and computes what the *result* of that computation would be.
>>>> There is absolutely no requirement that any intermediate data which
>>>> would be written to the tape by the TM described by the input be
>>>> duplicated. The final result is all that matters.
>>>>
>>>> It might be better for you to think of a UTM as a TM which
>>>> *analyzes* the description of a TM + input string and determines
>>>> what that TM would do rather than a TM which simulates another TM.
>
> Using the vague term *analyzes* making sure to not elaborate any of the
> details of the specific steps of this process is not any improvement in
> clarity.
>
> When the vague concept of a UTM is made totally concrete then it is
> essentially an interpreter of TM source code. When it is kept vague such
> that almost all of the steps of the process of *analyzes* are left
> unspecified then it might not seem to be an interpreter only because
> most of the details are simply missing.
>
>

Math is merely computer science with the details of the underlying
algorithm left to the imagination rather than explicitly specified.

>>>>
>>>
>>> If one is very careful to make sure that one uses sufficiently vague
>>> language one can be certainly never sufficiently understood.
>>
>> You're the one who is using vague language. People here are trying to
>> help you make your language *less* vague. I don't see why you are so
>> resistant to this effort.
>>
>>> When we make every detail of a UTM concrete that such it actually
>>> executes on a physical computer then all the vagueness is abolished
>>> and the UTM is an interpreter of the source code of TMs.
>>
>> I gave you a link to a paper that contained fully specified
>> descriptions of several UTMs. There operation is fully and precisely
>> described with absolutely no vagueness.
>>
>> Your obsession with executing things on physical computers is strange.
>> TMs are not intended as models of physical computers, nor are they
>> programming languages. They were conceived of as a mathematical tool
>> before modern computers even existed.
>>
>> If you insist on seeing the UTM executed on a real computer, you could
>> simply take one of the UTM descriptions in the paper I gave you and
>> run it in one of the many TM emulators out there.
>>
>
>

--
Copyright 2021 Pete Olcott

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

On 8/27/2021 11:17 AM, André G. Isaak wrote:
> On 2021-08-27 10:41, olcott wrote:
<SNIP>
>> When we make every detail of a UTM concrete that such it actually
>> executes on a physical computer then all the vagueness is abolished
>> and the UTM is an interpreter of the source code of TMs.
>
> I gave you a link to a paper that contained fully specified descriptions
> of several UTMs. There operation is fully and precisely described with
> absolutely no vagueness.
>
> Your obsession with executing things on physical computers is strange.
> TMs are not intended as models of physical computers, nor are they
> programming languages. They were conceived of as a mathematical tool
> before modern computers even existed.
>
> If you insist on seeing the UTM executed on a real computer, you could
> simply take one of the UTM descriptions in the paper I gave you and run
> it in one of the many TM emulators out there.

Ages ago, I posted a list of several free "UTM" implementations so our
in-love-with-being-ignorant-and-proud-too could cut the BS and quickly
determine what's what. Of course, he/she paid no attention. He/she as
usually was in a rather-my-way-than-right mood. I figured it would take
a day or two to write a full UTM - variable character set, symbolic
state names, readable transition functions, etc - in Lisp. If necessary,
I thought that another two weeks to two month would be necessary to do a
reasonable GUI. But do-it-in-machine-code-and fake-them-out went his/her
own way again and produced a rather useless alternative that only a
mother could love.

It's interesting that Linz and some others even say something to the
effect that simulation isn't what's needed here. Anyone who has thought
about the problems in moderate depth knows that simulation isn't the way
to approach making a (partial) halt decider though it might be used to
explore some limited behavior questions. To make even a little progress,
one needs to find some useful and doable analyses that chop off some of
the cases. But analysis is what proud-to-be-ignorant is exactly and
precisely horrible at.

Perhaps if he/she decided to show Beethoven's Symphony No. 5 in C minor
was really in C major, there would be better luck since deep analysis
isn't needed; just a good ear and the barest of music theory. Oops! My
bad. I forgot that he/she never listens to anything, rather just offers
ridiculous opinions.
--
Jeff Barnett

On 8/27/2021 11:48 AM, olcott wrote:
<SNIP>
> Math is merely computer science with the details of the underlying
> algorithm left to the imagination rather than explicitly specified.

You really are amazing. No matter in what area you opine, you get it
totally ass backwards. Mathematical analyses of algorithms tell you how
they work, why they work. expected execution times, and can sometimes
even provide PROOFS that they work. It's why you are such a suck at
programming and software engineering: you are one of the very worst at
mathematics who has ever posted in these groups.

I'd advise you to stick with what you know. Unfortunately there doesn't
seem to be anything relevant that you do know.
--
Jeff Barnett

On 2021-08-27 11:43, olcott wrote:
> On 8/27/2021 12:17 PM, André G. Isaak wrote:
>> On 2021-08-27 10:41, olcott wrote:
>>> On 8/27/2021 11:25 AM, André G. Isaak wrote:
>>>> On 2021-08-27 09:57, olcott wrote:
>>>>> On 8/27/2021 10:20 AM, Malcolm McLean wrote:
>>>>>> On Friday, 27 August 2021 at 16:11:45 UTC+1, olcott wrote:
>>>>>>>
>>>>>>> How can the UTM simulation of a machine that copies a string not
>>>>>>> perform
>>>>>>> the functional equivalent of copying a string and still be an
>>>>>>> accurate
>>>>>>> simulation of this TM?
>>>>>>>
>>>>>> If the machine simply copies the input string, then the UTM
>>>>>> simulation must
>>>>>> place a copy of the input on the tape before it terminates.
>>>>>
>>>>> Because Ben said this is not true Ben is wrong.
>>>>
>>>> You're misconstruing both Ben and Malcolm here. Please pay special
>>>> attention to the word *intermediate* in the next sentence.
>>>>
>>>> You keep talking about a UTM as a 'simulator', but that's really
>>>> only a metaphor, and it is one that perhaps you are taking far too
>>>> literally.
>>>>
>>>> A UTM is a TM which takes as its input the description of a
>>>> computation (i.e. the description of a TM concatenated with an input
>>>> string) and computes what the *result* of that computation would be.
>>>> There is absolutely no requirement that any intermediate data which
>>>> would be written to the tape by the TM described by the input be
>>>> duplicated. The final result is all that matters.
>>>>
>>>> It might be better for you to think of a UTM as a TM which
>>>> *analyzes* the description of a TM + input string and determines
>>>> what that TM would do rather than a TM which simulates another TM.
>
> Using the vague term *analyzes* making sure to not elaborate any of the
> details of the specific steps of this process is not any improvement in
> clarity.

I am stressing that a UTM is defined in terms of *what* it does, rather
than *how* it does it. It takes a computation as an input and determines
what the result of that computation would be. You want to insist that it
does this by some sort of slavish emulation but that isn't actually part
of the definition.

> When the vague concept of a UTM is made totally concrete then it is
> essentially an interpreter of TM source code. When it is kept vague such
> that almost all of the steps of the process of *analyzes* are left
> unspecified then it might not seem to be an interpreter only because
> most of the details are simply missing.

The "vague concept" has been implemented many different times by many
different people, and those implementations are not all the same ad do
not include the same specific steps which is why that isn't included in
the definition. But they all analyze a computation and determine what
the result would be. Different implementations perform that analysis in
different ways. None of them resemble a 'interpreter of TM source code'.

WHY DON'T YOU ACTUALLY *LOOK* AT THE EXAMPLES IN THE PAPER I LINKED TO.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 2021-08-27 11:48, olcott wrote:
> On 8/27/2021 12:43 PM, olcott wrote:
>> On 8/27/2021 12:17 PM, André G. Isaak wrote:
>>> On 2021-08-27 10:41, olcott wrote:
>>>> On 8/27/2021 11:25 AM, André G. Isaak wrote:
>>>>> On 2021-08-27 09:57, olcott wrote:
>>>>>> On 8/27/2021 10:20 AM, Malcolm McLean wrote:
>>>>>>> On Friday, 27 August 2021 at 16:11:45 UTC+1, olcott wrote:
>>>>>>>>
>>>>>>>> How can the UTM simulation of a machine that copies a string not
>>>>>>>> perform
>>>>>>>> the functional equivalent of copying a string and still be an
>>>>>>>> accurate
>>>>>>>> simulation of this TM?
>>>>>>>>
>>>>>>> If the machine simply copies the input string, then the UTM
>>>>>>> simulation must
>>>>>>> place a copy of the input on the tape before it terminates.
>>>>>>
>>>>>> Because Ben said this is not true Ben is wrong.
>>>>>
>>>>> You're misconstruing both Ben and Malcolm here. Please pay special
>>>>> attention to the word *intermediate* in the next sentence.
>>>>>
>>>>> You keep talking about a UTM as a 'simulator', but that's really
>>>>> only a metaphor, and it is one that perhaps you are taking far too
>>>>> literally.
>>>>>
>>>>> A UTM is a TM which takes as its input the description of a
>>>>> computation (i.e. the description of a TM concatenated with an
>>>>> input string) and computes what the *result* of that computation
>>>>> would be. There is absolutely no requirement that any intermediate
>>>>> data which would be written to the tape by the TM described by the
>>>>> input be duplicated. The final result is all that matters.
>>>>>
>>>>> It might be better for you to think of a UTM as a TM which
>>>>> *analyzes* the description of a TM + input string and determines
>>>>> what that TM would do rather than a TM which simulates another TM.
>>
>> Using the vague term *analyzes* making sure to not elaborate any of
>> the details of the specific steps of this process is not any
>> improvement in clarity.
>>
>> When the vague concept of a UTM is made totally concrete then it is
>> essentially an interpreter of TM source code. When it is kept vague
>> such that almost all of the steps of the process of *analyzes* are
>> left unspecified then it might not seem to be an interpreter only
>> because most of the details are simply missing.
>>
>>
>
> Math is merely computer science with the details of the underlying
> algorithm left to the imagination rather than explicitly specified.

This is probably the most singularly absurd statement you've ever
written. And you've written some incredibly absurd things.

For starters, as far as I can tell you've never even studied computer
science and have no clue what it is. You have taken some courses in
programming which you have confused with computer science. They're not
the same thing even though courses in both might be offered in a
computer science department.

Second, the foundations of almost all major branches of mathematics were
established long before computer science even existed as a discipline.
And people successfully performed enormously complex computations
without computers and certainly without anything 'left to the imagination'.

When Le Verrier in the 19th century successfully predicted the existence
and location of Neptune based on observed anomalies in the orbit of
Uranus, do you think he used a computer? Do you think he simply left all
the details of the math to the imagination and just made a lucky guess?

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 2021-08-27 11:54, Jeff Barnett wrote:

> Perhaps if he/she decided to show Beethoven's Symphony No. 5 in C minor
> was really in C major, there would be better luck since deep analysis
> isn't needed;

But he/she would probably accomplish this by first establishing some
'equivalent problem'. For example, proving that Beethoven's Symphony No.
5 is actually Beethoven's Symphony No. 1.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 8/27/2021 1:39 PM, André G. Isaak wrote:
> On 2021-08-27 11:43, olcott wrote:
>> On 8/27/2021 12:17 PM, André G. Isaak wrote:
>>> On 2021-08-27 10:41, olcott wrote:
>>>> On 8/27/2021 11:25 AM, André G. Isaak wrote:
>>>>> On 2021-08-27 09:57, olcott wrote:
>>>>>> On 8/27/2021 10:20 AM, Malcolm McLean wrote:
>>>>>>> On Friday, 27 August 2021 at 16:11:45 UTC+1, olcott wrote:
>>>>>>>>
>>>>>>>> How can the UTM simulation of a machine that copies a string not
>>>>>>>> perform
>>>>>>>> the functional equivalent of copying a string and still be an
>>>>>>>> accurate
>>>>>>>> simulation of this TM?
>>>>>>>>
>>>>>>> If the machine simply copies the input string, then the UTM
>>>>>>> simulation must
>>>>>>> place a copy of the input on the tape before it terminates.
>>>>>>
>>>>>> Because Ben said this is not true Ben is wrong.
>>>>>
>>>>> You're misconstruing both Ben and Malcolm here. Please pay special
>>>>> attention to the word *intermediate* in the next sentence.
>>>>>
>>>>> You keep talking about a UTM as a 'simulator', but that's really
>>>>> only a metaphor, and it is one that perhaps you are taking far too
>>>>> literally.
>>>>>
>>>>> A UTM is a TM which takes as its input the description of a
>>>>> computation (i.e. the description of a TM concatenated with an
>>>>> input string) and computes what the *result* of that computation
>>>>> would be. There is absolutely no requirement that any intermediate
>>>>> data which would be written to the tape by the TM described by the
>>>>> input be duplicated. The final result is all that matters.
>>>>>
>>>>> It might be better for you to think of a UTM as a TM which
>>>>> *analyzes* the description of a TM + input string and determines
>>>>> what that TM would do rather than a TM which simulates another TM.
>>
>> Using the vague term *analyzes* making sure to not elaborate any of
>> the details of the specific steps of this process is not any
>> improvement in clarity.
>
> I am stressing that a UTM is defined in terms of *what* it does, rather
> than *how* it does it.

Leaving many essential details to the imagination thus making sure that
there are huge gaps in the specification that are never fully
elaborated. This only matters when these underlying details are required
to answer specific questions such as whether or not a string copy
operation simulated by a UTM ever results in any data actually being
written to the tape.

> It takes a computation as an input and determines
> what the result of that computation would be. You want to insist that it
> does this by some sort of slavish emulation but that isn't actually part
> of the definition.
>

Yes it might do it by sprinkling majick fairy dust.

>> When the vague concept of a UTM is made totally concrete then it is
>> essentially an interpreter of TM source code. When it is kept vague
>> such that almost all of the steps of the process of *analyzes* are
>> left unspecified then it might not seem to be an interpreter only
>> because most of the details are simply missing.
>
> The "vague concept" has been implemented many different times by many
> different people, and those implementations are not all the same ad do
> not include the same specific steps which is why that isn't included in
> the definition. But they all analyze a computation and determine what
> the result would be. Different implementations perform that analysis in
> different ways. None of them resemble a 'interpreter of TM source code'.
>
> WHY DON'T YOU ACTUALLY *LOOK* AT THE EXAMPLES IN THE PAPER I LINKED TO.
>
>
> André
>

None-the-less when a TM copies a string then the simulation of the TM by
a UTM does write data to its tape performing the functional equivalent
of an actual string copy operation.

Almost all of the "errors" the Ben has ever pointed out with my work are
when I am talking about high level abstractions these abstractions
abstract away irrelevant low level implementation details and Ben says
that such abstractions are incorrect.

This is just like Ben claiming there there is no such thing as a "for
loop" because all of these "for loops" are implemented using low level
assembly language jump code.

So the bottom line of all this is that when a UTM simulates a string
copy operation a freaking string literally is freaking copied and Ben is
simply flat out wrong to say otherwise.

--
Copyright 2021 Pete Olcott

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

On 2021-08-27 13:13, olcott wrote:
> On 8/27/2021 1:39 PM, André G. Isaak wrote:
>> On 2021-08-27 11:43, olcott wrote:
>>> On 8/27/2021 12:17 PM, André G. Isaak wrote:
>>>> On 2021-08-27 10:41, olcott wrote:
>>>>> On 8/27/2021 11:25 AM, André G. Isaak wrote:
>>>>>> On 2021-08-27 09:57, olcott wrote:
>>>>>>> On 8/27/2021 10:20 AM, Malcolm McLean wrote:
>>>>>>>> On Friday, 27 August 2021 at 16:11:45 UTC+1, olcott wrote:
>>>>>>>>>
>>>>>>>>> How can the UTM simulation of a machine that copies a string
>>>>>>>>> not perform
>>>>>>>>> the functional equivalent of copying a string and still be an
>>>>>>>>> accurate
>>>>>>>>> simulation of this TM?
>>>>>>>>>
>>>>>>>> If the machine simply copies the input string, then the UTM
>>>>>>>> simulation must
>>>>>>>> place a copy of the input on the tape before it terminates.
>>>>>>>
>>>>>>> Because Ben said this is not true Ben is wrong.
>>>>>>
>>>>>> You're misconstruing both Ben and Malcolm here. Please pay special
>>>>>> attention to the word *intermediate* in the next sentence.
>>>>>>
>>>>>> You keep talking about a UTM as a 'simulator', but that's really
>>>>>> only a metaphor, and it is one that perhaps you are taking far too
>>>>>> literally.
>>>>>>
>>>>>> A UTM is a TM which takes as its input the description of a
>>>>>> computation (i.e. the description of a TM concatenated with an
>>>>>> input string) and computes what the *result* of that computation
>>>>>> would be. There is absolutely no requirement that any intermediate
>>>>>> data which would be written to the tape by the TM described by the
>>>>>> input be duplicated. The final result is all that matters.
>>>>>>
>>>>>> It might be better for you to think of a UTM as a TM which
>>>>>> *analyzes* the description of a TM + input string and determines
>>>>>> what that TM would do rather than a TM which simulates another TM.
>>>
>>> Using the vague term *analyzes* making sure to not elaborate any of
>>> the details of the specific steps of this process is not any
>>> improvement in clarity.
>>
>> I am stressing that a UTM is defined in terms of *what* it does,
>> rather than *how* it does it.
>
> Leaving many essential details to the imagination thus making sure that
> there are huge gaps in the specification that are never fully

This is an idiotic position to take. The 'specification' and the
implementation are two different things.

To make an analogy from 'software engineering', the C standard defines
what the standard library functions *do*. The actual implementation
varies from platform to platform.

> elaborated. This only matters when these underlying details are required
> to answer specific questions such as whether or not a string copy
> operation simulated by a UTM ever results in any data actually being
> written to the tape.

You're stumbling back into your absurd interpretations once again. No
one, not Ben, not I, not anyone, ever claimed that a string copying
operation would not result in any data being written to the tape. What
was pointed out was that the data written to the tape by a UTM will
generally *not* be an actual copy of the string in question. It will be
some representation which will generally look quite different from the
original, and which will generally not even be a string insofar as it
will not consist of a sequence of contiguous symbols but rather symbols
scattered around on the tape.

You're the one who specified that your J was a UTM without ever giving a
specific implementation, so you're really just criticizing your own
claim here.

>> It takes a computation as an input and determines what the result of
>> that computation would be. You want to insist that it does this by
>> some sort of slavish emulation but that isn't actually part of the
>> definition.
>>
>
> Yes it might do it by sprinkling majick fairy dust.

Once again you come up with some absurd interpretation.

If I tell you that the specific details of a factorial function are not
required to use recursion would you respond with 'yes, it might do it by
sprinkling majick fairy dust'? Of course not because that would be a
stupid interpretation of the statement, just as it is a stupid
interpretation of the above. You've often used factorial as an example
of recursion, but it is most often implemented using a loop rather than
recursion since that's more efficient.

Look at some actual UTMs. You've been given links. They don't all work
the same way, which is what I am pointing out above. However, none of
them actually work by simulating, at least not in the way that you
appear to be imagining.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 8/27/2021 2:27 PM, André G. Isaak wrote:
> On 2021-08-27 13:13, olcott wrote:
>> On 8/27/2021 1:39 PM, André G. Isaak wrote:
>>> On 2021-08-27 11:43, olcott wrote:
>>>> On 8/27/2021 12:17 PM, André G. Isaak wrote:
>>>>> On 2021-08-27 10:41, olcott wrote:
>>>>>> On 8/27/2021 11:25 AM, André G. Isaak wrote:
>>>>>>> On 2021-08-27 09:57, olcott wrote:
>>>>>>>> On 8/27/2021 10:20 AM, Malcolm McLean wrote:
>>>>>>>>> On Friday, 27 August 2021 at 16:11:45 UTC+1, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> How can the UTM simulation of a machine that copies a string
>>>>>>>>>> not perform
>>>>>>>>>> the functional equivalent of copying a string and still be an
>>>>>>>>>> accurate
>>>>>>>>>> simulation of this TM?
>>>>>>>>>>
>>>>>>>>> If the machine simply copies the input string, then the UTM
>>>>>>>>> simulation must
>>>>>>>>> place a copy of the input on the tape before it terminates.
>>>>>>>>
>>>>>>>> Because Ben said this is not true Ben is wrong.
>>>>>>>
>>>>>>> You're misconstruing both Ben and Malcolm here. Please pay
>>>>>>> special attention to the word *intermediate* in the next sentence.
>>>>>>>
>>>>>>> You keep talking about a UTM as a 'simulator', but that's really
>>>>>>> only a metaphor, and it is one that perhaps you are taking far
>>>>>>> too literally.
>>>>>>>
>>>>>>> A UTM is a TM which takes as its input the description of a
>>>>>>> computation (i.e. the description of a TM concatenated with an
>>>>>>> input string) and computes what the *result* of that computation
>>>>>>> would be. There is absolutely no requirement that any
>>>>>>> intermediate data which would be written to the tape by the TM
>>>>>>> described by the input be duplicated. The final result is all
>>>>>>> that matters.
>>>>>>>
>>>>>>> It might be better for you to think of a UTM as a TM which
>>>>>>> *analyzes* the description of a TM + input string and determines
>>>>>>> what that TM would do rather than a TM which simulates another TM.
>>>>
>>>> Using the vague term *analyzes* making sure to not elaborate any of
>>>> the details of the specific steps of this process is not any
>>>> improvement in clarity.
>>>
>>> I am stressing that a UTM is defined in terms of *what* it does,
>>> rather than *how* it does it.
>>
>> Leaving many essential details to the imagination thus making sure
>> that there are huge gaps in the specification that are never fully
>
> This is an idiotic position to take. The 'specification' and the
> implementation are two different things.
>
> To make an analogy from 'software engineering', the C standard defines
> what the standard library functions *do*. The actual implementation
> varies from platform to platform.
>
>> elaborated. This only matters when these underlying details are
>> required to answer specific questions such as whether or not a string
>> copy operation simulated by a UTM ever results in any data actually
>> being written to the tape.
>
> You're stumbling back into your absurd interpretations once again. No
> one, not Ben, not I, not anyone, ever claimed that a string copying
> operation would not result in any data being written to the tape. What
> was pointed out was that the data written to the tape by a UTM will
> generally *not* be an actual copy of the string in question. It will be
> some representation which will generally look quite different from the
> original, and which will generally not even be a string insofar as it
> will not consist of a sequence of contiguous symbols but rather symbols
> scattered around on the tape.
>
> You're the one who specified that your J was a UTM without ever giving a
> specific implementation, so you're really just criticizing your own
> claim here.
>
>>> It takes a computation as an input and determines what the result of
>>> that computation would be. You want to insist that it does this by
>>> some sort of slavish emulation but that isn't actually part of the
>>> definition.
>>>
>>
>> Yes it might do it by sprinkling majick fairy dust.
>
> Once again you come up with some absurd interpretation.
>
> If I tell you that the specific details of a factorial function are not
> required to use recursion would you respond with 'yes, it might do it by
> sprinkling majick fairy dust'? Of course not because that would be a
> stupid interpretation of the statement, just as it is a stupid
> interpretation of the above. You've often used factorial as an example
> of recursion, but it is most often implemented using a loop rather than
> recursion since that's more efficient.
>
> Look at some actual UTMs. You've been given links. They don't all work
> the same way, which is what I am pointing out above. However, none of
> them actually work by simulating, at least not in the way that you
> appear to be imagining.
>
> André
>

Because a UTM must reproduce the functional equivalent of what the TM's
description specifies and it does not do this by sprinkling majick fairy
dust the most straight forward way to envision the essence of this is to
construe the UTM as an interpreter of the TM description as if it was
the source-code of this TM.

--
Copyright 2021 Pete Olcott

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

On 2021-08-27 13:45, olcott wrote:

> Because a UTM must reproduce the functional equivalent of what the TM's
> description specifies and it does not do this by sprinkling majick fairy
> dust the most straight forward way to envision the essence of this is to
> construe the UTM as an interpreter of the TM description as if it was
> the source-code of this TM.

And if you actually LOOK at some of the UTMs provided in the paper I
linked to you will learn how they *actually* work as opposed to what you
think is the most straightforward way to envision their "essence".

Do you want to be taken seriously? You claim that you do. Talking about
UTMs in a way that reveals you have absolutely no idea of how they work
is a good way to guarantee that you won't be.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 8/27/2021 3:00 PM, André G. Isaak wrote:
> On 2021-08-27 13:45, olcott wrote:
>
>> Because a UTM must reproduce the functional equivalent of what the
>> TM's description specifies and it does not do this by sprinkling
>> majick fairy dust the most straight forward way to envision the
>> essence of this is to construe the UTM as an interpreter of the TM
>> description as if it was the source-code of this TM.
>
> And if you actually LOOK at some of the UTMs provided in the paper I
> linked to you will learn how they *actually* work as opposed to what you
> think is the most straightforward way to envision their "essence".
>
> Do you want to be taken seriously? You claim that you do. Talking about
> UTMs in a way that reveals you have absolutely no idea of how they work
> is a good way to guarantee that you won't be.
>
> André
>

Turing machine Ĥ is defined at the bottom of page 319:

From H' we construct another Turing machine Ĥ.
This new machine takes as input WM, copies it,
and then behaves exactly like H'.

https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts.

Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then simulates this input Ĵ1 with its
input ⟨Ĵ2⟩
which copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then simulates this input Ĵ2 with
its input ⟨Ĵ3⟩
which copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then simulates this input Ĵ3 with
its input ⟨Ĵ4⟩ ...

What is actually inaccurate about the above?

--
Copyright 2021 Pete Olcott

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

On 2021-08-27 14:12, olcott wrote:
> On 8/27/2021 3:00 PM, André G. Isaak wrote:
>> On 2021-08-27 13:45, olcott wrote:
>>
>>> Because a UTM must reproduce the functional equivalent of what the
>>> TM's description specifies and it does not do this by sprinkling
>>> majick fairy dust the most straight forward way to envision the
>>> essence of this is to construe the UTM as an interpreter of the TM
>>> description as if it was the source-code of this TM.
>>
>> And if you actually LOOK at some of the UTMs provided in the paper I
>> linked to you will learn how they *actually* work as opposed to what
>> you think is the most straightforward way to envision their "essence".
>>
>> Do you want to be taken seriously? You claim that you do. Talking
>> about UTMs in a way that reveals you have absolutely no idea of how
>> they work is a good way to guarantee that you won't be.
>>
>> André
>>
>
> Turing machine Ĥ is defined at the bottom of page 319:
>
>    From H' we construct another Turing machine Ĥ.
>    This new machine takes as input WM, copies it,
>    and then behaves exactly like H'.
>
> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>
> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
> instead of a simulating halt decider then we can see that Ĵ applied to
> ⟨Ĵ⟩ never halts.
>
> Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then simulates this input Ĵ1 with its
> input ⟨Ĵ2⟩
> which copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then simulates this input Ĵ2 with
> its input ⟨Ĵ3⟩
> which copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then simulates this input Ĵ3 with
> its input ⟨Ĵ4⟩ ...
>
> What is actually inaccurate about the above?

To qote your own words, "If one is very careful to make sure that one
uses sufficiently vague language one can be certainly never sufficiently
understood."

"When we make every detail of a UTM concrete that such it actually
executes on a physical computer then all the vagueness is abolished and
the UTM is an interpreter of the source code of TMs."

The above certainly counts as 'sufficiently vague language' You give
absolutely no details about how Ĵ actually performs any of these steps.
You certainly don't give any concrete details such that it actually
executes on a physical computer to abolish that vagueness. Similarly,
you could give the actual code for your H to abolish vagueness about how
that works.

Why not actually implement your Ĵ using one of the UTMs described in the
paper I gave you? Then you can see how things actually work and if it
really works as you claim. Then actually implement your H and show the
full code.

Your determination to talk about TMs and UTMs and to assert how correct
you are without having the *slightest* idea of how they work is truly
mystifying.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 8/27/2021 12:56 PM, André G. Isaak wrote:
> On 2021-08-27 11:54, Jeff Barnett wrote:
>
>> Perhaps if he/she decided to show Beethoven's Symphony No. 5 in C
>> minor was really in C major, there would be better luck since deep
>> analysis isn't needed;
>
> But he/she would probably accomplish this by first establishing some
> 'equivalent problem'. For example, proving that Beethoven's Symphony No.
> 5 is actually Beethoven's Symphony No. 1.
Yup!
--
Jeff Barnett

On 8/27/2021 3:23 PM, André G. Isaak wrote:
> On 2021-08-27 14:12, olcott wrote:
>> On 8/27/2021 3:00 PM, André G. Isaak wrote:
>>> On 2021-08-27 13:45, olcott wrote:
>>>
>>>> Because a UTM must reproduce the functional equivalent of what the
>>>> TM's description specifies and it does not do this by sprinkling
>>>> majick fairy dust the most straight forward way to envision the
>>>> essence of this is to construe the UTM as an interpreter of the TM
>>>> description as if it was the source-code of this TM.
>>>
>>> And if you actually LOOK at some of the UTMs provided in the paper I
>>> linked to you will learn how they *actually* work as opposed to what
>>> you think is the most straightforward way to envision their "essence".
>>>
>>> Do you want to be taken seriously? You claim that you do. Talking
>>> about UTMs in a way that reveals you have absolutely no idea of how
>>> they work is a good way to guarantee that you won't be.
>>>
>>> André
>>>
>>
>> Turing machine Ĥ is defined at the bottom of page 319:
>>
>>     From H' we construct another Turing machine Ĥ.
>>     This new machine takes as input WM, copies it,
>>     and then behaves exactly like H'.
>>
>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>
>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>> instead of a simulating halt decider then we can see that Ĵ applied to
>> ⟨Ĵ⟩ never halts.
>>
>> Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then simulates this input Ĵ1 with its
>> input ⟨Ĵ2⟩
>> which copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then simulates this input Ĵ2 with
>> its input ⟨Ĵ3⟩
>> which copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then simulates this input Ĵ3 with
>> its input ⟨Ĵ4⟩ ...
>>
>> What is actually inaccurate about the above?
>
> To qote your own words, "If one is very careful to make sure that one
> uses sufficiently vague language one can be certainly never sufficiently
> understood."
>
> "When we make every detail of a UTM concrete that such it actually
> executes on a physical computer then all the vagueness is abolished and
> the UTM is an interpreter of the source code of TMs."
>
> The above certainly counts as 'sufficiently vague language' You give
> absolutely no details about how Ĵ actually performs any of these steps.

When Ĥ definitely copies its input can it possibly be wrong to say that
the simulation of ⟨Ĥ⟩ copies its input?

> You certainly don't give any concrete details such that it actually
> executes on a physical computer to abolish that vagueness. Similarly,
> you could give the actual code for your H to abolish vagueness about how
> that works.
>
> Why not actually implement your Ĵ using one of the UTMs described in the
> paper I gave you?

Because the only purpose of even mentioning Ĵ was to make the idea that
Ĵ is stuck in infinitely nested simulation clear to thickheaded fools
that are stuck in rebuttal mode.

The only purpose of this was to make the idea that Ĥ is equally stuck in
infinitely nested simulation while its simulating halt decider at Ĥ.qx
is in simulation mode clear to thickheaded fools that are stuck in
rebuttal mode.

As soon as I have made my point clear to thickheaded fools that are
stuck in rebuttal mode then I can submit my paper to actual computer
scientists in the field of the theory of computation.

These thickheaded fools that are stuck in rebuttal mode will never
acknowledge that they understand or agree, the only measure is that
there best fake rebuttals will not rise above the level of terribly lame.

> Then you can see how things actually work and if it
> really works as you claim. Then actually implement your H and show the
> full code.
>
> Your determination to talk about TMs and UTMs and to assert how correct
> you are without having the *slightest* idea of how they work is truly
> mystifying.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 8/27/21 10:09 AM, olcott wrote:
> On 8/27/2021 6:32 AM, Richard Damon wrote:
>> On 8/26/21 10:48 PM, olcott wrote:
>>> On 8/26/2021 8:05 PM, André G. Isaak wrote:
>>>> On 2021-08-26 18:55, Richard Damon wrote:
>>>>> On 8/26/21 7:19 PM, olcott wrote:
>>>>>> On 8/26/2021 6:12 PM, Richard Damon wrote:
>>>>>>> On 8/26/21 2:10 PM, olcott wrote:
>>>>>>>> On 8/26/2021 1:03 PM, André G. Isaak wrote:
>>>>>>>
>>>>>>>>> And if you don't know exactly how a UTM works, then how do you
>>>>>>>>> plan on
>>>>>>>>> establishing that a 'simulating halt decider' based on a UTM can
>>>>>>>>> recognize a given sequence of steps as being infinite?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> A UTM must simulate the code that it is presented with. If this
>>>>>>>> code
>>>>>>>> writes to its tape the it must literally write to its tape.
>>>>>>>>
>>>>>>>
>>>>>>> Right, but it write the representation of that data, not the data
>>>>>>> itself.
>>>>>>>
>>>>>>> Remember the machine that the UTM is running on, and thus that
>>>>>>> 'symbol
>>>>>>> set' of the tape may be very different than the symbol set of the
>>>>>>> machine that it is simulating, so there is an encoding issue.
>>>>>>>
>>>>>>> THere also needs to be an encoding of where the tape is, since the
>>>>>>> actual tape the UTM is using will be moving to other spots.
>>>>>>>
>>>>>>
>>>>>> All of that merely dodges Ben's mistake.
>>>>>> You really can't seem to stay focused on the pint at hand.
>>>>>>
>>>>>
>>>>> No, YOU miss the important point. If the simulate machine writes a
>>>>> given
>>>>> symbol onto its simulated tape (like a '1') that doesn't mean the
>>>>> actual
>>>>> tape got a '1' written on it, and in fact, that tape might not even
>>>>> allow the symbol '1' to be written. Instead, the UTM translates that
>>>>> writing of a '1' in the simulated machine into writting a
>>>>> representation
>>>>> of that '1' in its representation of the tape.
>>>>
>>>
>>> That is very dumb.
>>
>> No, it is how it has to work.
>
> The UTM is a TM of the same type as the TM that it emulates, assuming
> otherwise is ridiculous. Ben is flatly wrong and you are a liar for not
> acknowledging this.

No, you don't understand what *Universal* means then. A UTM can emulate
ANY Turing Machine, not just Turing Machines with the same symbol set of
tap.

In fact, if you understood how you would actually write a UTM, you would
see that if the tape had exactly the same character set as the target
machine, it would be impossible to just use that as a native
representation, as you need to somehow mark that representation for the
'current' tape head position so you can go off to read the
representation of the code, and the go back to the current location on
the tape to update it.

This means the UTM needs to be able to have codes that the simulatd
machine can't use.

On 8/27/21 10:26 AM, olcott wrote:
> On 8/26/2021 7:51 PM, Richard Damon wrote:
>> On 8/26/21 7:20 PM, olcott wrote:
>>> On 8/26/2021 6:17 PM, Richard Damon wrote:
>>>> On 8/26/21 8:58 AM, olcott wrote:
>>>>> On 8/26/2021 5:45 AM, Richard Damon wrote:
>>>>>> On 8/25/21 11:48 PM, olcott wrote:
>>>>>>> On 8/25/2021 10:17 PM, Richard Damon wrote:
>>>>>>>> On 8/25/21 11:03 PM, olcott wrote:
>>>>>>>>> On 8/25/2021 9:44 PM, Richard Damon wrote:
>>>>>>>>>> On 8/25/21 10:22 PM, olcott wrote:
>>>>>>>>>>> On 8/25/2021 9:04 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/25/21 10:01 PM, olcott wrote:
>>>>>>>>>>>>> On 8/25/2021 8:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 8/25/21 9:34 PM, olcott wrote:
>>>>>>>>>>>>>>> On 8/25/2021 8:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, becuase UTM(<H^>, <H^>) Halts, thus showing that since
>>>>>>>>>>>>>>>> H(<H^>,<H^>)
>>>>>>>>>>>>>>>> says non-halting it was wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That was your last chance.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You admit defeat?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I acknowledge that you are an incorrigible jackass.
>>>>>>>>>>>>> The review process moves to phase two.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What does that mean? You going to write the paper to submit to
>>>>>>>>>>>> get
>>>>>>>>>>>> your
>>>>>>>>>>>> rejection?
>>>>>>>>>>>>
>>>>>>>>>>>> You have yet to show anywhere whre my basic objections are
>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You know full well that your "objections" are pure drivel.
>>>>>>>>>>
>>>>>>>>>> No, I, and everyone else who is reading this will see that what
>>>>>>>>>> I say
>>>>>>>>>> makes sense.
>>>>>>>>>>
>>>>>>>>>> YOUR statements are the 'pure drivel'.
>>>>>>>>>>
>>>>>>>>>> Please note that basically no one belives your statements and
>>>>>>>>>> everyone
>>>>>>>>>> thinks you are wrong. While it is possible that you have
>>>>>>>>>> discovered
>>>>>>>>>> some
>>>>>>>>>> hidden secret, it is very unlikely. One key thing to ask
>>>>>>>>>> yourself,
>>>>>>>>>> what
>>>>>>>>>> grounds do I have to actually expect that I could come up with
>>>>>>>>>> some
>>>>>>>>>> insite like that that no one else beleives.
>>>>>>>>> Because of this my work is not getting an honest review. It is
>>>>>>>>> obvious
>>>>>>>>> that my work is not getting an honest review to anyone knowing the
>>>>>>>>> material very well that all of the "rebuttals" simply dodge
>>>>>>>>> directly
>>>>>>>>> assessing my points and change to subject to some other points.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, it HAS gotten an Honest review, and you just don't want to
>>>>>>>> accept
>>>>>>>> it, because it shows how BAD your logic is.
>>>>>>>>
>>>>>>>
>>>>>>> You cannot correctly point to any actual mistake in the essence
>>>>>>> of my
>>>>>>> proof. All you can do is talk in circles.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> You mean like the false assumption that H makes that the copy of H
>>>>>> that
>>>>>> it is simulating will NEVER abort its simulation, when it is clear
>>>>>> that,
>>>>>> at least if H is a computation, that it will as another identical
>>>>>> copy
>>>>>> of the computation does.
>>>>>>
>>>>>
>>>>> It is a verified fact that if H waits for some other H to abort the
>>>>> simulation that every H waits for some other H to abort the simulation
>>>>> and the simulation is never aborted because every H has the exact same
>>>>> code.
>>>>
>>>> Yes, if you change EVERY H
>>>
>>> H is required to be a single machine or the HP proof is not refuted.
>>>
>>>
>>
>> Yes, H is *A* machine, so it has a SPECIFIC definition, SPECIFIED BEFORE
>> YOU GET INTO THE PROOF.
>>
>
> The key detail that everyone left out that was unspecified because no
> one else ever thought it all the way through is what happens when H is a
> simulating halt decider.
>

Because it doesn't make a difference, as the definition of Halting
doesn't care about how you make the decision, only what the decision is
an what the machine actually does,

>> Thus, every time YOU talk about a change to H, you just broke the rules
>> of the proof and have to start over.
>>
>
> Bullshit is was never specified that H is not a simulating halt decider.

H is a SPECIFIED Halt Decider. Change the specifications, and everything
you have previously determined about H^ is no longer valid.

>
>> When you posit questions about if H ..., you are outside the proof. Any
>> of your if H ... must be a factual Truth Bearer (or is illogical).
>>
>> If H doesn't abort the simulation, well that statement is either TRUE,
>> or it is FALSE. IF it is True, that decision has consequences, like H
>> won't answer the question H(<H^>,<H^>). If it is false, you make an
>> error if you perform logic assuming it never does.
>>
>
> We can see that a hypothetical H that never aborts its simulation never
> halts because its input never halts, therefore H is correct to abort its
> simulation and report that its input never halts.

But if H is a Halt decider that does abort, your hypothetical H that
doesn't is non-existant at best or a logical contradiction.

The behavor of the Hn^ based on the Hn that doesn't abort tells you
NOTHING about the behavior of the Ha^ that is based on the Ha that does.

That is like your 'proof' that cats bark that you did by using a dog
instead of a cat and asked what if the dog was a cat.

>
>> Also, you statement about if H waited long enough for some other copy of
>> it to make its decision is basically a null set for your design. Since
>> the H inside will take just as long to make its decision as the H doing
>> the simulation, to figure out how long it needs to simulate is like
>> finding the answer to the problem find an X that is greater than X+1,
>> there is no such number, so their can't be a machine with your type of
>> algorithm that can simulate long enough to simulate a copy of itself
>> making the same decision.
>>
>
> This is the key part that must be beyond your intellectual capacity.
>
> Not at all. We can see that this infinite recursion criteria is met:
>
> Infinite recursion detection criteria:
> If the execution trace of function X() called by function Y() shows:
> (1) Function X() is called twice in sequence from the same machine
> address of Y().
> (2) With the same parameters to X().
> (3) With no conditional branch or indexed jump instructions in Y().
> (4) With no function call returns from X().
> then the function call from Y() to X() is infinitely recursive.

On 8/27/21 10:16 AM, olcott wrote:
> On 8/26/2021 7:38 PM, Richard Damon wrote:
>> On 8/26/21 8:53 AM, olcott wrote:
>>> On 8/26/2021 5:41 AM, Richard Damon wrote:
>>>> On 8/25/21 11:50 PM, olcott wrote:
>>>>> On 8/25/2021 10:21 PM, Richard Damon wrote:
>>>>>> On 8/25/21 11:10 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>>> Too disingenuous to continue.
>>>>>>>
>>>>>>> Excellent!  Mind you, you've said you won't talk go to me many times
>>>>>>> before and I always end up disappointed.
>>>>>>>
>>>>>>
>>>>>> Yes, me too. It is clear that when people clearly point out his
>>>>>> mistakes, his brain starts to go crazy and he finds it
>>>>>> irresistible to
>>>>>> lash out and try to muddy the air with some illogic to try and
>>>>>> hide the
>>>>>> clear rebuttal.
>>>>>>
>>>>>> I think he hopes that the thread will go off some other direction and
>>>>>> the clear rebuttal will be forgotten.
>>>>>>
>>>>>> THAT is why he calls them 'dishonest dodges', he thinks if he says
>>>>>> that
>>>>>> enough some people might beleive it and not look at them.
>>>>>>
>>>>>
>>>>> This is the crux of my whole proof try and refute it without changing
>>>>> the subject or talking in circles:
>>>>>
>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>> A simulating halt decider correctly decides that any input that never
>>>>> halts unless the simulating halt decider aborts its simulation of this
>>>>> input is an input that never halts.
>>>>>
>>>>
>>>> Easy, Fundamental Definitions (do you disagree with any of these):
>>>>
>>>> The Definition of a Computation: The act of performing a Step by Step
>>>> Algorithm on an input data to get an answer. The Algorithm needs to
>>>> precisely state exactly what operations to perform and the input needs
>>>> to specify all the variable data for the caluclation.
>>>>
>>>> Since a Computation fully specifies what is done and what it is done
>>>> on,
>>>> every time you run a given computation on the same data you will get
>>>> the
>>>> same answer.
>>>>
>>>> The Definition of A Halting Computation is CDomputatiion that reaches a
>>>> halting state in a finite numb4r of steps. A Non-Halting one is one
>>>> that
>>>> never reaches a Halting state for ANY finite number of Steps.
>>>>
>>>> The Definition of a Halt Decider: A Computation that, when given as an
>>>> input the representation of a Computation, is able to correctly
>>>> indicate
>>>> if that Computation is Halting or Non-Halting.
>>>>
>>>> Thus the right answer isn't based on a partial simulation performed by
>>>> the decider, but on what the actual machine does.
>>>>
>>>
>>> // Simplified Linz Ĥ (Linz:1990:319)
>>> // Strachey(1965) CPL translated to C
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H1((u32)P, (u32)P));
>>> }
>>>
>>> H1 determines that its input halts on its input on the basis that H
>>> determines that its input never halts.
>>
>> Yes H THINKS its input never halts, but since the input to H is the
>> exact same input as to H1, the machine it represents is the same, so its
>> behavior MUST be the same.
>>
>> Think about what you are trying to claim.
>>
>
> I don't have to think about it. H1 does correctly decide that P halts on
> the basis that H correctly decides that its input never halts.

No, you wouldn't think about it would you.
>
> H1 has identical machine code and inputs to H.
> It is the execution order that makes the difference in the results.
>
> H1 can see all of the code that it simulates, H can see all of the code
> that its simulates, H1 cannot see any of the code that H simulates.

Since H1 and H are copies of each other and H(P,P) and H1(P,P) give
different answer, you have just proved that your H is NOT a computation,
and thus can't be a valid halt decider, as it is NOT the Computational
Equvalent of a Turing Machine, because it isn't a Computation so that
concept just doesn't apply.

FAIL.

I Guess we can just keep quoting that H has been proved to not be a
Computaiton and thus can't be a Halt Decider to ALL your statements, at
least until you provide some proof that it is a computation.

André G. Isaak <agisaak@gm.invalid> writes:

> On 2021-08-27 10:18, olcott wrote:
>> On 8/27/2021 10:57 AM, André G. Isaak wrote:

>>> Ben never made any claims that it didn't perform some operation
>>> which could be construed as the functional equivalent of copying a
>>> string. He claimed that there was no *literal* copying involved
>>> except in the first instance.

Indeed. I see in my absence there's been a flurry of "Ben is wrong"
posts from PO. Thanks, to you and RD, for stepping in.

>> So in other words he said that my high level abstraction was wrong on
>> the basis that it was a high level abstraction and did not delve into
>> the tedious details of how this high level abstraction is
>> implemented.
>
> No, he was claiming that your high level abstraction was *misleading*
> and belied a lack of understanding of UTMs on your part.

At the time I was actually calling out hard errors of fact, not just
misleading abstractions. I was (dangerously) prepared to go along with
the abstract view, as I (and others) have done for some time, because,
whilst I agree it is potentially misleading, it's not actually wrong.

But PO did not think he was talking about abstractions at the time I
called him out on the mistake. He really did think that if you do the
"hat" construction on a TM that is little more that a UTM, then it --
the actual TM we'd call UTM^ -- has a cycle in its state graph allowing
it to go from what he calls qx (the UTM's q0) back (via other states of
course) to UTM^'s q0. And he thought that this loop is what wrote the
endless literal copies. He used Linz's notation for TM configurations
to show the strings right there on the tape next to each other, mid
computation, with q0 being entered again and again.

Even if he now tries to suggest that he was using the notation in some
sort of abstract way, the explicit cycle in the states gives a lie to
that. He thought it was actual, literal, symbol by symbol copying every
time, exactly as the extra states added by the hat construction do it.

--
Ben.

On 2021-08-27 17:51, Richard Damon wrote:
> On 8/27/21 10:16 AM, olcott wrote:

>> I don't have to think about it. H1 does correctly decide that P halts on
>> the basis that H correctly decides that its input never halts.
>
> No, you wouldn't think about it would you.

Thinking is dangerous. It might lead to actual learning, and that
something which is anathema to PO.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 8/27/21 8:01 PM, Ben Bacarisse wrote:
> André G. Isaak <agisaak@gm.invalid> writes:
>
>> On 2021-08-27 10:18, olcott wrote:
>>> On 8/27/2021 10:57 AM, André G. Isaak wrote:
>
>>>> Ben never made any claims that it didn't perform some operation
>>>> which could be construed as the functional equivalent of copying a
>>>> string. He claimed that there was no *literal* copying involved
>>>> except in the first instance.
>
> Indeed. I see in my absence there's been a flurry of "Ben is wrong"
> posts from PO. Thanks, to you and RD, for stepping in.
>
>>> So in other words he said that my high level abstraction was wrong on
>>> the basis that it was a high level abstraction and did not delve into
>>> the tedious details of how this high level abstraction is
>>> implemented.
>>
>> No, he was claiming that your high level abstraction was *misleading*
>> and belied a lack of understanding of UTMs on your part.
>
> At the time I was actually calling out hard errors of fact, not just
> misleading abstractions. I was (dangerously) prepared to go along with
> the abstract view, as I (and others) have done for some time, because,
> whilst I agree it is potentially misleading, it's not actually wrong.
>
> But PO did not think he was talking about abstractions at the time I
> called him out on the mistake. He really did think that if you do the
> "hat" construction on a TM that is little more that a UTM, then it --
> the actual TM we'd call UTM^ -- has a cycle in its state graph allowing
> it to go from what he calls qx (the UTM's q0) back (via other states of
> course) to UTM^'s q0. And he thought that this loop is what wrote the
> endless literal copies. He used Linz's notation for TM configurations
> to show the strings right there on the tape next to each other, mid
> computation, with q0 being entered again and again.
>
> Even if he now tries to suggest that he was using the notation in some
> sort of abstract way, the explicit cycle in the states gives a lie to
> that. He thought it was actual, literal, symbol by symbol copying every
> time, exactly as the extra states added by the hat construction do it.
>

Actually, lets help him by showing what the trace actually might look like.

Let us assume that U is a UTM, its basic flow is we start at U.q0 with
an input of the representation of the Machine P to run, and the
representation of the initial input I0.

A common simple sketch of a UTM is it starts at that q0, does some
initializeation and perhaps modifies the machine representation to mark
the initial state to be <P.q0> and then goes to the state U.qs where it
comes for every instruction with the tape being the representation
marked with the current state, and the representation of the current
emulated tape.

It then runs that instruction an either returns to U.qs with updated
state, or ends off going to U.qh if the machine Halted.

We will let our input be U^, which starts at U^.q0 with a representation
of a Machine as input, and then moves to state U^.qx with two copies of
that machine, U^.qx being were we place a copy of U, and then we modifiy
U.qh to be in infinite loop, as that is its 'halting' answer, since it
doesn't have the equivalent of qn for non-halting, we don't need to
leave that as a simple halt. We will call the U.qs state inside as U^.qs
and the state U.qh as U^.qh.

So, Running U(<U^>,<U^>) (and skipping over unlabled states)

U.q0 <U^> <U^>
U.qs <U^.q0> <U^>
U.qs <U^.qx> <U^> <U^>
U.qs <U^.qs> <U^.q0> <U^>
U.qs <U^.qs> <U^.qx> <U^> <U^>
U.qs <U^.qs> <U^.qs> <U^.q0> <U^>
U.qs <U^.qs? <U^.qs> <U^.qx> <U^> <U^>
U.qs <U^.qs> <U^.qs> <U^.qs> <U^.q0> <U^>

You should be able to see that patttern.

Note at NO level do we ever return to a .q0 state, only generate a .q0
state a level down in the simulation.

Also, for each level of .qs that is present, the actual UTM is going
through more and more states that we haven't named. If it takes N steps
to go from one U.qx to the next for a single step of the emulated
program. It will take N^2 steps to simulate a simulated step, and N^3
steps to simulate a simulated simulated step.

Now, if we modify that U to be H, and in its stepping it checks for your
'recursive pattern' somehow and aborts its simulation, and get a trace
that looks something like this: (Note, since H^ does have a qn answer,
H^ will keep that as a halting state H^.qn

H.q0 <H^> <H^>
H.qs <H^.q0> <H^>
H.qs <H^.qx> <H^> <H^>
H.qs <H^.qs> <H^.q0> <H^>
H.qs <H^.qs> <H^.qx> <H^> <H^>
H.qs <H^.qs> <H^.qs> <H^.q0> <H^>
I'll presume this is where H detects the 'infinite recursion'
H.qn

SO H says H^ <H^> is non-Halting
We can then check the answer by running H^ as the top level

H^.q0 <H^>
H^.qx <H^> <H^>
H^.qs <H^.q0> <H^>
H^.qs <H^.qx> <H^> <H^>
H^.qs <H^.qs> <H^.q0> <H^>
H^.qs <H^.qs> <H^.qx> <H^> <H^>
H^.qs <H^.qs> <H^.qs> <H^.q0> <H^>
H^.qn

So we wee that H^ ended at its halting state, so H was wrong.

On 8/27/2021 7:01 PM, Ben Bacarisse wrote:
> André G. Isaak <agisaak@gm.invalid> writes:
>
>> On 2021-08-27 10:18, olcott wrote:
>>> On 8/27/2021 10:57 AM, André G. Isaak wrote:
>
>>>> Ben never made any claims that it didn't perform some operation
>>>> which could be construed as the functional equivalent of copying a
>>>> string. He claimed that there was no *literal* copying involved
>>>> except in the first instance.
>
> Indeed. I see in my absence there's been a flurry of "Ben is wrong"
> posts from PO. Thanks, to you and RD, for stepping in.
>
>>> So in other words he said that my high level abstraction was wrong on
>>> the basis that it was a high level abstraction and did not delve into
>>> the tedious details of how this high level abstraction is
>>> implemented.
>>
>> No, he was claiming that your high level abstraction was *misleading*
>> and belied a lack of understanding of UTMs on your part.
>
> At the time I was actually calling out hard errors of fact, not just
> misleading abstractions. I was (dangerously) prepared to go along with
> the abstract view, as I (and others) have done for some time, because,
> whilst I agree it is potentially misleading, it's not actually wrong.
>
> But PO did not think he was talking about abstractions at the time I
> called him out on the mistake. He really did think that if you do the
> "hat" construction on a TM that is little more that a UTM, then it --
> the actual TM we'd call UTM^ -- has a cycle in its state graph allowing
> it to go from what he calls qx (the UTM's q0) back (via other states of
> course) to UTM^'s q0. And he thought that this loop is what wrote the
> endless literal copies. He used Linz's notation for TM configurations
> to show the strings right there on the tape next to each other, mid
> computation, with q0 being entered again and again.
>

It does have literal endless copies and no one besides you has claimed
otherwise.

> Even if he now tries to suggest that he was using the notation in some
> sort of abstract way, the explicit cycle in the states gives a lie to
> that. He thought it was actual, literal, symbol by symbol copying every
> time, exactly as the extra states added by the hat construction do it.
>

--
Copyright 2021 Pete Olcott

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

On 8/27/2021 6:51 PM, Richard Damon wrote:
> On 8/27/21 10:16 AM, olcott wrote:
>> On 8/26/2021 7:38 PM, Richard Damon wrote:
>>> On 8/26/21 8:53 AM, olcott wrote:
>>>> On 8/26/2021 5:41 AM, Richard Damon wrote:
>>>>> On 8/25/21 11:50 PM, olcott wrote:
>>>>>> On 8/25/2021 10:21 PM, Richard Damon wrote:
>>>>>>> On 8/25/21 11:10 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>>> Too disingenuous to continue.
>>>>>>>>
>>>>>>>> Excellent!  Mind you, you've said you won't talk go to me many times
>>>>>>>> before and I always end up disappointed.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, me too. It is clear that when people clearly point out his
>>>>>>> mistakes, his brain starts to go crazy and he finds it
>>>>>>> irresistible to
>>>>>>> lash out and try to muddy the air with some illogic to try and
>>>>>>> hide the
>>>>>>> clear rebuttal.
>>>>>>>
>>>>>>> I think he hopes that the thread will go off some other direction and
>>>>>>> the clear rebuttal will be forgotten.
>>>>>>>
>>>>>>> THAT is why he calls them 'dishonest dodges', he thinks if he says
>>>>>>> that
>>>>>>> enough some people might beleive it and not look at them.
>>>>>>>
>>>>>>
>>>>>> This is the crux of my whole proof try and refute it without changing
>>>>>> the subject or talking in circles:
>>>>>>
>>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>>> A simulating halt decider correctly decides that any input that never
>>>>>> halts unless the simulating halt decider aborts its simulation of this
>>>>>> input is an input that never halts.
>>>>>>
>>>>>
>>>>> Easy, Fundamental Definitions (do you disagree with any of these):
>>>>>
>>>>> The Definition of a Computation: The act of performing a Step by Step
>>>>> Algorithm on an input data to get an answer. The Algorithm needs to
>>>>> precisely state exactly what operations to perform and the input needs
>>>>> to specify all the variable data for the caluclation.
>>>>>
>>>>> Since a Computation fully specifies what is done and what it is done
>>>>> on,
>>>>> every time you run a given computation on the same data you will get
>>>>> the
>>>>> same answer.
>>>>>
>>>>> The Definition of A Halting Computation is CDomputatiion that reaches a
>>>>> halting state in a finite numb4r of steps. A Non-Halting one is one
>>>>> that
>>>>> never reaches a Halting state for ANY finite number of Steps.
>>>>>
>>>>> The Definition of a Halt Decider: A Computation that, when given as an
>>>>> input the representation of a Computation, is able to correctly
>>>>> indicate
>>>>> if that Computation is Halting or Non-Halting.
>>>>>
>>>>> Thus the right answer isn't based on a partial simulation performed by
>>>>> the decider, but on what the actual machine does.
>>>>>
>>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> // Strachey(1965) CPL translated to C
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H1((u32)P, (u32)P));
>>>> }
>>>>
>>>> H1 determines that its input halts on its input on the basis that H
>>>> determines that its input never halts.
>>>
>>> Yes H THINKS its input never halts, but since the input to H is the
>>> exact same input as to H1, the machine it represents is the same, so its
>>> behavior MUST be the same.
>>>
>>> Think about what you are trying to claim.
>>>
>>
>> I don't have to think about it. H1 does correctly decide that P halts on
>> the basis that H correctly decides that its input never halts.
>
> No, you wouldn't think about it would you.
>>
>> H1 has identical machine code and inputs to H.
>> It is the execution order that makes the difference in the results.
>>
>> H1 can see all of the code that it simulates, H can see all of the code
>> that its simulates, H1 cannot see any of the code that H simulates.
>
> Since H1 and H are copies of each other and H(P,P) and H1(P,P) give
> different answer, you have just proved that your H is NOT a computation,

H(P,P) and H1(P,P) give a different answer because of their different
placement in the execution sequence.

> and thus can't be a valid halt decider, as it is NOT the Computational
> Equvalent of a Turing Machine, because it isn't a Computation so that
> concept just doesn't apply.
>
> FAIL.
>
> I Guess we can just keep quoting that H has been proved to not be a
> Computaiton and thus can't be a Halt Decider to ALL your statements, at
> least until you provide some proof that it is a computation.
>

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/27/2021 7:01 PM, Ben Bacarisse wrote:
>> André G. Isaak <agisaak@gm.invalid> writes:
>>
>>> On 2021-08-27 10:18, olcott wrote:
>>>> On 8/27/2021 10:57 AM, André G. Isaak wrote:
>>
>>>>> Ben never made any claims that it didn't perform some operation
>>>>> which could be construed as the functional equivalent of copying a
>>>>> string. He claimed that there was no *literal* copying involved
>>>>> except in the first instance.
>> Indeed. I see in my absence there's been a flurry of "Ben is wrong"
>> posts from PO. Thanks, to you and RD, for stepping in.
>>
>>>> So in other words he said that my high level abstraction was wrong on
>>>> the basis that it was a high level abstraction and did not delve into
>>>> the tedious details of how this high level abstraction is
>>>> implemented.
>>>
>>> No, he was claiming that your high level abstraction was *misleading*
>>> and belied a lack of understanding of UTMs on your part.
>> At the time I was actually calling out hard errors of fact, not just
>> misleading abstractions. I was (dangerously) prepared to go along with
>> the abstract view, as I (and others) have done for some time, because,
>> whilst I agree it is potentially misleading, it's not actually wrong.
>> But PO did not think he was talking about abstractions at the time I
>> called him out on the mistake. He really did think that if you do the
>> "hat" construction on a TM that is little more that a UTM, then it --
>> the actual TM we'd call UTM^ -- has a cycle in its state graph allowing
>> it to go from what he calls qx (the UTM's q0) back (via other states of
>> course) to UTM^'s q0. And he thought that this loop is what wrote the
>> endless literal copies. He used Linz's notation for TM configurations
>> to show the strings right there on the tape next to each other, mid
>> computation, with q0 being entered again and again.
>
> It does have literal endless copies and no one besides you has claimed
> otherwise.

(1) Of something, yes, but of what? Not of what you claimed.

(2) Are you backing down from your claim about the loop in the state
transition graph?

(3) You have it backwards. I only see posters agreeing with me on this
topic.

>> Even if he now tries to suggest that he was using the notation in some
>> sort of abstract way, the explicit cycle in the states gives a lie to
>> that. He thought it was actual, literal, symbol by symbol copying every
>> time, exactly as the extra states added by the hat construction do it.

--
Ben.

On 8/28/21 12:46 AM, olcott wrote:
> On 8/27/2021 6:51 PM, Richard Damon wrote:
>> On 8/27/21 10:16 AM, olcott wrote:
>>> On 8/26/2021 7:38 PM, Richard Damon wrote:
>>>> On 8/26/21 8:53 AM, olcott wrote:
>>>>> On 8/26/2021 5:41 AM, Richard Damon wrote:
>>>>>> On 8/25/21 11:50 PM, olcott wrote:
>>>>>>> On 8/25/2021 10:21 PM, Richard Damon wrote:
>>>>>>>> On 8/25/21 11:10 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>> Too disingenuous to continue.
>>>>>>>>>
>>>>>>>>> Excellent!  Mind you, you've said you won't talk go to me many
>>>>>>>>> times
>>>>>>>>> before and I always end up disappointed.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, me too. It is clear that when people clearly point out his
>>>>>>>> mistakes, his brain starts to go crazy and he finds it
>>>>>>>> irresistible to
>>>>>>>> lash out and try to muddy the air with some illogic to try and
>>>>>>>> hide the
>>>>>>>> clear rebuttal.
>>>>>>>>
>>>>>>>> I think he hopes that the thread will go off some other
>>>>>>>> direction and
>>>>>>>> the clear rebuttal will be forgotten.
>>>>>>>>
>>>>>>>> THAT is why he calls them 'dishonest dodges', he thinks if he says
>>>>>>>> that
>>>>>>>> enough some people might beleive it and not look at them.
>>>>>>>>
>>>>>>>
>>>>>>> This is the crux of my whole proof try and refute it without
>>>>>>> changing
>>>>>>> the subject or talking in circles:
>>>>>>>
>>>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>>>> A simulating halt decider correctly decides that any input that
>>>>>>> never
>>>>>>> halts unless the simulating halt decider aborts its simulation of
>>>>>>> this
>>>>>>> input is an input that never halts.
>>>>>>>
>>>>>>
>>>>>> Easy, Fundamental Definitions (do you disagree with any of these):
>>>>>>
>>>>>> The Definition of a Computation: The act of performing a Step by Step
>>>>>> Algorithm on an input data to get an answer. The Algorithm needs to
>>>>>> precisely state exactly what operations to perform and the input
>>>>>> needs
>>>>>> to specify all the variable data for the caluclation.
>>>>>>
>>>>>> Since a Computation fully specifies what is done and what it is done
>>>>>> on,
>>>>>> every time you run a given computation on the same data you will get
>>>>>> the
>>>>>> same answer.
>>>>>>
>>>>>> The Definition of A Halting Computation is CDomputatiion that
>>>>>> reaches a
>>>>>> halting state in a finite numb4r of steps. A Non-Halting one is one
>>>>>> that
>>>>>> never reaches a Halting state for ANY finite number of Steps.
>>>>>>
>>>>>> The Definition of a Halt Decider: A Computation that, when given
>>>>>> as an
>>>>>> input the representation of a Computation, is able to correctly
>>>>>> indicate
>>>>>> if that Computation is Halting or Non-Halting.
>>>>>>
>>>>>> Thus the right answer isn't based on a partial simulation
>>>>>> performed by
>>>>>> the decider, but on what the actual machine does.
>>>>>>
>>>>>
>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>> // Strachey(1965) CPL translated to C
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H1((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> H1 determines that its input halts on its input on the basis that H
>>>>> determines that its input never halts.
>>>>
>>>> Yes H THINKS its input never halts, but since the input to H is the
>>>> exact same input as to H1, the machine it represents is the same, so
>>>> its
>>>> behavior MUST be the same.
>>>>
>>>> Think about what you are trying to claim.
>>>>
>>>
>>> I don't have to think about it. H1 does correctly decide that P halts on
>>> the basis that H correctly decides that its input never halts.
>>
>> No, you wouldn't think about it would you.
>>>
>>> H1 has identical machine code and inputs to H.
>>> It is the execution order that makes the difference in the results.
>>>
>>> H1 can see all of the code that it simulates, H can see all of the code
>>> that its simulates, H1 cannot see any of the code that H simulates.
>>
>> Since H1 and H are copies of each other and H(P,P) and H1(P,P) give
>> different answer, you have just proved that your H is NOT a computation,
>
> H(P,P) and H1(P,P) give a different answer because of their different
> placement in the execution sequence.

Thus, they aren't computations, as 'placement in the execution sequence'
isn't one of their inputs, and thus not ALLOWED to change their answer.

Since they aren't computations, they are NOT the Computational
Equivalent of a Turing Machine, and thus are not even eligible to be
entered as a possible Halt Decider.

Maybe you should study what a Computation actually means.

Remember, the word doesn't just mean the result of a modern electronic
computer, as it predates their existence, going back to the days when a
'Computer' was the name for a person with an adding machine.

>
>> and thus can't be a valid halt decider, as it is NOT the Computational
>> Equvalent of a Turing Machine, because it isn't a Computation so that
>> concept just doesn't apply.
>>
>> FAIL.
>>
>> I Guess we can just keep quoting that H has been proved to not be a
>> Computaiton and thus can't be a Halt Decider to ALL your statements, at
>> least until you provide some proof that it is a computation.
>>
>
>