On 8/27/2021 10:57 AM, André G. Isaak wrote:
> On 2021-08-27 09:11, olcott wrote:
>> On 8/27/2021 9:27 AM, André G. Isaak wrote:
>>> On 2021-08-27 08:09, 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.
>>>
>>> You're really not doing yourself any favours here.
>>>
>>> Ben pointed out that the description you gave was not an accurate
>>> description of what was going on given how UTMs really work.
>>
>> A UTM is essentially a conventional programming language interpreter.
>
> It really isn't. You need to learn about TMs and to stop thinking of
> them in terms of programming languages or "software engineering". They
> are a very different model from the things you are familiar with.
>
>> This merely adds another layer of overhead on top of what would
>> otherwise be simply direct execution. If the TM is required to copy a
>> string then the interpretation of the source code of this TM must also
>> copy a string.
>
> TMs don't have "source code".

The machine description of a TM that is simulated on a UTM is for all
practical purposes source-code that is interpreted. There are no
material differences.

> We're not dealing with programming
> languages here. If a UTM is emulating a TM which makes a copy of a
> string, it must write some representation to the tape, but Ben's point
> was that this won't be a *literal* copy of that string. It may be
> something which looks entirely different.
>
>>> You've latched onto a rather absurd interpretation of what he is
>>> saying and are refusing to try to understand what he is *actually*
>>> saying which is something far more nuanced than your absurd
>>> interpretation, and this
>>
>> He is saying the the UTM and the TM cold be defined on the basis of
>> incompatible specification of the defined of a TM. One might use bits
>> as its basis data type and the other might use bytes.
>
> TMs don't use bits or bytes. Again, you need to stop thinking of TMs in
> terms of programming languages or existing computer hardware. They are
> mathematical abstractions unrelated to either of these things.
>
So when a TM writes to its tape what it is writing?
Conventionally it is writing a bit.

> The point is that a UTM is a TM which accepts a description of *any* TM
> as part of its input string.

If we narrowly define a TM to be the most conventional then this would
be true. It is not totally impossible to adapt the concept of a TM to
write 32-bit integers instead of bits.

> The set of all possible TMs includes TMs
> which use entirely different alphabets and a UTM must be able to deal
> with *all* of these. The TM being emulated may have a smaller or larger
> alphabet than the UTM makes use of.
>

Conventionally its tape alphabet is {1, SPACE}. I forgot that it does
not even conventionally have 0.

> If you read the paper to which I gave you a link, it will explain how
> this is accomplished and give examples of actual, fully specified UTMs.
> It will clear up many of your misconceptions and then you can reread
> this thread and you might actually grasp what is being said. If you
> don't understand how UTMs work (and you don't), you shouldn't be telling
> people they are wrong when they try to explain to you how UTMs actually
> work. It just makes you look foolish.
>
>>> seems to be a general pattern that you have -- when people try to
>>> correct a misconception you have or some terminological error you
>>> don't try to appreciate subtle distinctions which they are trying to
>>> draw to your attention and instead come up with some more ridiculous
>>> interpretation of what is being said and then steadfastly hold onto
>>> that interpretation.
>>>
>>> You claim that you want to learn how to express yourself correctly so
>>> people will take your work seriously and Ben is trying to draw your
>>> attention to the fact that you are not expressing yourself in a way
>>> that is strictly accurate, but you're actively resisting trying to
>>> learn from what he is saying.
>>>
>>> I gave you a link to a paper which describes how UTMs work. If you
>>> actually read through that paper and then reread this thread maybe
>>> you will realize the point that people are trying to make.
>>>
>>> If you simply keep insisting that Ben is wrong and you are right and
>>> that everyone else are liars you're never going to learn to express
>>> yourself in a way that will be taken seriously which you claim is one
>>> of your goals.
>>>
>>> André
>>>
>>
>> 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?
>
> 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.

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.

Grasping at straws to artificially contrive some rebuttal on some minor
point as if rebuttal was his sole purpose at the expense of an honest
dialogue.

With Ben's reasoning we could say that there is no such thing as a "for
loop" because it does not exist at the assembly language level after the
C source code has been compiled. None-the-less "for loops" do literally
exist so Ben is wrong to say that there is no literal copying of a string.

> You've latched onto this strange interpretation that he meant
> that nothing actually gets done in subsequent instances. That wasn't his
> claim. His claim that what was going on in subsequent instances was not
> actually as you were presenting it.
>
> André
>

--
Copyright 2021 Pete Olcott

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