On 9/21/2021 1:43 PM, André G. Isaak wrote:
> On 2021-09-21 12:22, olcott wrote:
>> On 9/21/2021 12:51 PM, André G. Isaak wrote:
>>> On 2021-09-21 09:19, olcott wrote:
>>>> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>>>>
>>>>> On 9/21/21 12:55 AM, olcott wrote:
>>>>>> o in other words a C function with static local data can detect
>>>>>> that it
>>>>>> was called in infinitely nested simulation, yet a TM is not
>>>>>> allowed to
>>>>>> have static local data therefore the C function is strictly more
>>>>>> powerful than a TM.
>>>>>
>>>>> Just to clarify a bit here.
>>>>>
>>>>> A C/x86 code FRAGMENT can do more than a Turing Machine Code Fragment,
>>>>> as Turing Machine fragments are still computations. but C/x86 don't
>>>>> need
>>>>> to be.
>>>>>
>>>>> By Code fragment, I mean a piece of code that some 'Program' will
>>>>> enter
>>>>> and exit from multiple times, and the fragment is allowed to keep some
>>>>> 'internal' state that the rest of the program doesn't know about.
>>>>>
>>>>> Computation Theory doesn't care about this, as it only deals with
>>>>> Computations as a whole, not fragments.
>>>>>
>>>>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>>>>> anything that a Turng Machine can't do (the Turing Machine might do it
>>>>> differently, but can give the same results). By a Program, I mean a
>>>>> piece of code that is entered when it starts, and it stays within the
>>>>> program until it finishes, and gives up it output to what ever was
>>>>> using it.
>>>>>
>>>>
>>>> Then H(P,P) is a computation based on its initial input and final
>>>> output even though it requires static local data.
>>>>
>>>> The bottom line is that a TM must use the equivalent of static local
>>>> data to be able to keep track that it is stuck in infinitely nested
>>>> simulation:
>>>>
>>>> the simulation of the
>>>>
>>>> machine description of a UTM H that simulates
>>>> the machine description P the simulates
>>>>
>>>> machine description of a UTM H that simulates
>>>> the machine description P the simulates
>>>>
>>>> machine description of a UTM H that simulates
>>>> the machine description P the simulates ...
>>>>
>>>> Olcott H can detect when Olcott P is doing this only when Olcott H
>>>> is able to use static local data, otherwise Olcott H has its memory
>>>> of prior invocations erased upon every subsequent simulation.
>>>>
>>>> It seems ridiculous that this level of functionality is simply
>>>> disallowed. If it is simply disallowed then that makes my H strictly
>>>> more powerful than the Linz TM H can be.
>>>
>>> The problem here is that you are trying to somehow justify your use
>>> of static variables without making any effort to understand what a
>>> computation actually is.
>>>
>>> The question which the theory of computation deals with (very
>>> simplistically) is as follows:
>>>
>>> Given some set of information I, how do we construct a method M for
>>> solving some problem P using *only* the information in I.
>>>
>>
>> This becomes simply impossible when I is merely the machine address of
>> the software that must be simulated.
>
> Turing Machines don't *have* machine addresses.

Sure they do, merely no one ever references them. Each state / input
pair is a single machine code instruction at a specific machine code
address.

> In the Linz proof, the
> TM is passed a *description* of the TM and an input string.
>
> In the case of your H, if you want to think of it as a computation, the
> input would be the *entire* block of code pointed to by the function
> pointer, plus the actual string pointed to by the second parameter. It
> wouldn't simply be the pointer values themselves.
>

That merely makes it more cumbersome.

> This is what I am trying to point out to you. The parameters given in a
> C function call *don't* correspond to the input string used when
> discussing Turing Machines/computations. So just because you have a C
> function whose formal parameters resemble that of the input string to
> some TM doesn't mean you're dealing with things that are equivalent or
> which deal with the same computation.

The machine address points to a specific machine code string.

>
>>> M would be a Turing Machine. I would be the input string to that
>>> machine. P would be something like 'does this computation halt?'.
>>>
>>> The difference between Turing Machines and C isn't that C is somehow
>>> more powerful than Turing Machines, it's simply that the way C
>>> functions are expressed doesn't map directly to the theory of
>>> computation because the formal parameters to a C function don't
>>> represent all the information available to the routine; they
>>> represent only the information that is passed via the stack which may
>>> or may not be all of the information which the function has access
>>> to. Information may also be passed in global variables, static
>>> variables, etc. Thus, the input to a C function doesn't necessarily
>>> represent the same thing that the input to a TM does.
>>>
>>> If you want to analyze a C function as a computation, you need to
>>> gather all the information which the C function makes use of
>>> *including* information accessed from sources other than the formal
>>> parameters. So to discuss your H in terms of computational theory the
>>> set I would consist of the formal paramters of H *plus* the static
>>> variable which the function also makes use of as a source of
>>> information.
>>>
>>> We could then construct some Turing Machine which takes an input
>>> string representing {P, P, static_execution_trace}. So a Turing
>>> Machine is perfectly capable of implementing your H.
>>>
>>
>> This works just fine when we pass the execution trace to P, except
>> that P is free to erase the whole execution trace every time that it is
>> called.
>
> Right, because every computation starts with a tabula rasa.
>

This artificially constrains TM preventing them from having the same
power as C. A C function can correctly determine when it has been
involved in infinitely nested simulation a TM that obeys the aribitrary
rules cannot. This makes C strictly more powerful than TM's. Since it is
much more plausible that you are simply wrong that is what I conclude.

> If you want to claim what you are trying to do is equivalent to a Turing
> Machine, that machine would have to be one which takes the execution
> trace as part of its input string and which writes a new execution trace
> to the tape as part of its output which could then be fed to a new
> computation.
>

Unless it can hold the entire execution trace across nested simulations
it is strictly less powerful that the C function that can.

If the only way that it can do this requires passing the execution trace
through P where P can erase it, then again TM's are strictly less
powerful that my C function.

> But then you're not dealing with the halting problem which asks about a
> hypothetical computation whose input consists only of a description of a
> machine and its input and whose output is simply accept or reject.
>
> André
>

The full execution trace across multiple recursive invocations <is> a
pure function of the original input machine addresses. It seems that
this is the point where you err.

--
Copyright 2021 Pete Olcott

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

On 9/21/21 11:19 AM, olcott wrote:
> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>
>> On 9/21/21 12:55 AM, olcott wrote:
>>> o in other words a C function with static local data can detect that it
>>> was called in infinitely nested simulation, yet a TM is not allowed to
>>> have static local data therefore the C function is strictly more
>>> powerful than a TM.
>>
>> Just to clarify a bit here.
>>
>> A C/x86 code FRAGMENT can do more than a Turing Machine Code Fragment,
>> as Turing Machine fragments are still computations. but C/x86 don't need
>> to be.
>>
>> By Code fragment, I mean a piece of code that some 'Program' will enter
>> and exit from multiple times, and the fragment is allowed to keep some
>> 'internal' state that the rest of the program doesn't know about.
>>
>> Computation Theory doesn't care about this, as it only deals with
>> Computations as a whole, not fragments.
>>
>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>> anything that a Turng Machine can't do (the Turing Machine might do it
>> differently, but can give the same results). By a Program, I mean a
>> piece of code that is entered when it starts, and it stays within the
>> program until it finishes, and gives up it output to what ever was
>> using it.
>>
>
> Then H(P,P) is a computation based on its initial input and final output
> even though it requires static local data.

So you admit that ALL Copies of H(P,P) return non-halting?

Even the one inside the P that H is simulating (but after the time that
H has simulated it)

And thus this P is actually a Haling Computaton?

>
> The bottom line is that a TM must use the equivalent of static local
> data to be able to keep track that it is stuck in infinitely nested
> simulation:
>

No, it doesn't. IF your H isn't actually a computation because it
behavior is different between the 'Top' H and the "Slave' H, then there
is no Turing Machine Equivalent.

> the simulation of the
>
> machine description of a UTM H that simulates
> the machine description P the simulates
>
> machine description of a UTM H that simulates
> the machine description P the simulates
>
> machine description of a UTM H that simulates
> the machine description P the simulates ...
>
> Olcott H can detect when Olcott P is doing this only when Olcott H is
> able to use static local data, otherwise Olcott H has its memory of
> prior invocations erased upon every subsequent simulation.
>
> It seems ridiculous that this level of functionality is simply
> disallowed. If it is simply disallowed then that makes my H strictly
> more powerful than the Linz TM H can be.
>
>
>> Such a Program/Subprogram can always be considered some sort of
>> computation, taking as its input ALL the things that the code uses to
>> perform its operations, and it is shown that it appears that a Turing
>> Machine can perform ANY computation. Note, that while the program might
>> be A computation, if it uses inputs beyond what its problem statement
>> provides, it might not be THE Computation requested.
>>
>> This appears to be the case of your Halt Decider, the behavior of a
>> given invocation of H is dependent on some static local variables, which
>> aren't part of the defined input for a Halt Decider.
>>
>> Thus if H is 'just a C function' that doesn't meet the requirement to be
>> the computation equivalent for the Halt Decider H, then it just isn't
>> the equivalent of it and thus fails to prove what you claim.
>>
>> Your H seems to be acting like just a fragment, and NOT as a 'whole
>> program', which makes it NOT the equivalent of the Linz machine H.
>>
>
>

On 9/21/21 2:22 PM, olcott wrote:
> On 9/21/2021 12:51 PM, André G. Isaak wrote:
>> On 2021-09-21 09:19, olcott wrote:
>>> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>>>
>>>> On 9/21/21 12:55 AM, olcott wrote:
>>>>> o in other words a C function with static local data can detect
>>>>> that it
>>>>> was called in infinitely nested simulation, yet a TM is not allowed to
>>>>> have static local data therefore the C function is strictly more
>>>>> powerful than a TM.
>>>>
>>>> Just to clarify a bit here.
>>>>
>>>> A C/x86 code FRAGMENT can do more than a Turing Machine Code Fragment,
>>>> as Turing Machine fragments are still computations. but C/x86 don't
>>>> need
>>>> to be.
>>>>
>>>> By Code fragment, I mean a piece of code that some 'Program' will enter
>>>> and exit from multiple times, and the fragment is allowed to keep some
>>>> 'internal' state that the rest of the program doesn't know about.
>>>>
>>>> Computation Theory doesn't care about this, as it only deals with
>>>> Computations as a whole, not fragments.
>>>>
>>>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>>>> anything that a Turng Machine can't do (the Turing Machine might do it
>>>> differently, but can give the same results). By a Program, I mean a
>>>> piece of code that is entered when it starts, and it stays within the
>>>> program until it finishes, and gives up it output to what ever was
>>>> using it.
>>>>
>>>
>>> Then H(P,P) is a computation based on its initial input and final
>>> output even though it requires static local data.
>>>
>>> The bottom line is that a TM must use the equivalent of static local
>>> data to be able to keep track that it is stuck in infinitely nested
>>> simulation:
>>>
>>> the simulation of the
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates ...
>>>
>>> Olcott H can detect when Olcott P is doing this only when Olcott H is
>>> able to use static local data, otherwise Olcott H has its memory of
>>> prior invocations erased upon every subsequent simulation.
>>>
>>> It seems ridiculous that this level of functionality is simply
>>> disallowed. If it is simply disallowed then that makes my H strictly
>>> more powerful than the Linz TM H can be.
>>
>> The problem here is that you are trying to somehow justify your use of
>> static variables without making any effort to understand what a
>> computation actually is.
>>
>> The question which the theory of computation deals with (very
>> simplistically) is as follows:
>>
>> Given some set of information I, how do we construct a method M for
>> solving some problem P using *only* the information in I.
>>
>
> This becomes simply impossible when I is merely the machine address of
> the software that must be simulated.

Then I isn't the right representation of the input.

FAIL.

>
>> M would be a Turing Machine. I would be the input string to that
>> machine. P would be something like 'does this computation halt?'.
>>
>> The difference between Turing Machines and C isn't that C is somehow
>> more powerful than Turing Machines, it's simply that the way C
>> functions are expressed doesn't map directly to the theory of
>> computation because the formal parameters to a C function don't
>> represent all the information available to the routine; they represent
>> only the information that is passed via the stack which may or may not
>> be all of the information which the function has access to.
>> Information may also be passed in global variables, static variables,
>> etc. Thus, the input to a C function doesn't necessarily represent the
>> same thing that the input to a TM does.
>>
>> If you want to analyze a C function as a computation, you need to
>> gather all the information which the C function makes use of
>> *including* information accessed from sources other than the formal
>> parameters. So to discuss your H in terms of computational theory the
>> set I would consist of the formal paramters of H *plus* the static
>> variable which the function also makes use of as a source of information.
>>
>> We could then construct some Turing Machine which takes an input
>> string representing {P, P, static_execution_trace}. So a Turing
>> Machine is perfectly capable of implementing your H.
>>
>
> This works just fine when we pass the execution trace to P, except that
> P is free to erase the whole execution trace every time that it is
> called. With conventional static local variables in C, P is forbidden
> any access, thus P cannot erase this data.
>

P and H need to be computations, therefore they can't actually USE the
static variable to change their behavior.

It can exist, it just can't be used to change behavior,

FAIL.

>> The problem is simply that your H *doesn't* correspond to the type of
>> machine which the halting problem is concerned with since that problem
>> asks how to determine whether a given computation halts given *only* a
>> description of a Turing Machine and a description of the input to that
>> machine. If you supply the TM with an additional piece of information
>> such as static_execution_trace you are now discussing an entirely
>> different TM than the one the halting problem asks about.
>>
>> André
>>
>
> The execution trace is derived as a pure function of the input.
>
>

On 9/21/2021 6:21 PM, Richard Damon wrote:
> On 9/21/21 11:19 AM, olcott wrote:
>> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>>
>>> On 9/21/21 12:55 AM, olcott wrote:
>>>> o in other words a C function with static local data can detect that it
>>>> was called in infinitely nested simulation, yet a TM is not allowed to
>>>> have static local data therefore the C function is strictly more
>>>> powerful than a TM.
>>>
>>> Just to clarify a bit here.
>>>
>>> A C/x86 code FRAGMENT can do more than a Turing Machine Code Fragment,
>>> as Turing Machine fragments are still computations. but C/x86 don't need
>>> to be.
>>>
>>> By Code fragment, I mean a piece of code that some 'Program' will enter
>>> and exit from multiple times, and the fragment is allowed to keep some
>>> 'internal' state that the rest of the program doesn't know about.
>>>
>>> Computation Theory doesn't care about this, as it only deals with
>>> Computations as a whole, not fragments.
>>>
>>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>>> anything that a Turng Machine can't do (the Turing Machine might do it
>>> differently, but can give the same results). By a Program, I mean a
>>> piece of code that is entered when it starts, and it stays within the
>>> program until it finishes, and gives up it output to what ever was
>>> using it.
>>>
>>
>> Then H(P,P) is a computation based on its initial input and final output
>> even though it requires static local data.
>
> So you admit that ALL Copies of H(P,P) return non-halting?
>
> Even the one inside the P that H is simulating (but after the time that
> H has simulated it)
>
> And thus this P is actually a Haling Computaton?
>
>>
>> The bottom line is that a TM must use the equivalent of static local
>> data to be able to keep track that it is stuck in infinitely nested
>> simulation:
>>
>
> No, it doesn't. IF your H isn't actually a computation because it
> behavior is different between the 'Top' H and the "Slave' H, then there
> is no Turing Machine Equivalent.
>
I think that you must be incorrect about this because it means that my C
function is strictly more powerful than a TM.

My C function can determine that it has been called in infinitely nested
simulation because it has static data that is not erased between
recursive simulations.

That you some how believe that a function called in infinitely recursive
simulation must return a value to it caller seems quite nuts.

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 9/20/2021 9:50 PM, Ben Bacarisse wrote:

>> You conclude I'm stupid because I

(childish snipping)

> can't keep track of the key detail that Ĥ only refer to Linz from the
> perfecly clear conext that has been reiterated hundreds of times over
> many months.

Your contradictory statements, and your lies about not having made them,
are still contradictory and dishonest not matter what TMs the symbols
were supposed to denote.

--
Ben.

On 9/21/2021 7:44 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/20/2021 9:50 PM, Ben Bacarisse wrote:
>
>>> You conclude I'm stupid because I
>
> (childish snipping)
>
>> can't keep track of the key detail that Ĥ only refer to Linz from the
>> perfecly clear conext that has been reiterated hundreds of times over
>> many months.
>
> Your contradictory statements, and your lies about not having made them,
> are still contradictory and dishonest not matter what TMs the symbols
> were supposed to denote.
>

That I always used this symbol Ĥ in the context of the Linz proofs and
never used it in any other way and did this many hundreds of times
should have been noticed by someone that is not stupid.

Richard can't seem to keep track of this distinction when I specifically
point it out to him many dozens of times, telling him that

this Ĥ only applies to the Linz proofs.

--
Copyright 2021 Pete Olcott

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

On 9/21/21 3:25 PM, olcott wrote:
> On 9/21/2021 1:43 PM, André G. Isaak wrote:
>> On 2021-09-21 12:22, olcott wrote:
>>> On 9/21/2021 12:51 PM, André G. Isaak wrote:
>>>> On 2021-09-21 09:19, olcott wrote:
>>>>> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/21/21 12:55 AM, olcott wrote:
>>>>>>> o in other words a C function with static local data can detect
>>>>>>> that it
>>>>>>> was called in infinitely nested simulation, yet a TM is not
>>>>>>> allowed to
>>>>>>> have static local data therefore the C function is strictly more
>>>>>>> powerful than a TM.
>>>>>>
>>>>>> Just to clarify a bit here.
>>>>>>
>>>>>> A C/x86 code FRAGMENT can do more than a Turing Machine Code
>>>>>> Fragment,
>>>>>> as Turing Machine fragments are still computations. but C/x86
>>>>>> don't need
>>>>>> to be.
>>>>>>
>>>>>> By Code fragment, I mean a piece of code that some 'Program' will
>>>>>> enter
>>>>>> and exit from multiple times, and the fragment is allowed to keep
>>>>>> some
>>>>>> 'internal' state that the rest of the program doesn't know about.
>>>>>>
>>>>>> Computation Theory doesn't care about this, as it only deals with
>>>>>> Computations as a whole, not fragments.
>>>>>>
>>>>>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>>>>>> anything that a Turng Machine can't do (the Turing Machine might
>>>>>> do it
>>>>>> differently, but can give the same results). By a Program, I mean a
>>>>>> piece of code that is entered when it starts, and it stays within the
>>>>>> program until it finishes, and gives up it output to what ever was
>>>>>> using it.
>>>>>>
>>>>>
>>>>> Then H(P,P) is a computation based on its initial input and final
>>>>> output even though it requires static local data.
>>>>>
>>>>> The bottom line is that a TM must use the equivalent of static
>>>>> local data to be able to keep track that it is stuck in infinitely
>>>>> nested simulation:
>>>>>
>>>>> the simulation of the
>>>>>
>>>>> machine description of a UTM H that simulates
>>>>> the machine description P the simulates
>>>>>
>>>>> machine description of a UTM H that simulates
>>>>> the machine description P the simulates
>>>>>
>>>>> machine description of a UTM H that simulates
>>>>> the machine description P the simulates ...
>>>>>
>>>>> Olcott H can detect when Olcott P is doing this only when Olcott H
>>>>> is able to use static local data, otherwise Olcott H has its memory
>>>>> of prior invocations erased upon every subsequent simulation.
>>>>>
>>>>> It seems ridiculous that this level of functionality is simply
>>>>> disallowed. If it is simply disallowed then that makes my H
>>>>> strictly more powerful than the Linz TM H can be.
>>>>
>>>> The problem here is that you are trying to somehow justify your use
>>>> of static variables without making any effort to understand what a
>>>> computation actually is.
>>>>
>>>> The question which the theory of computation deals with (very
>>>> simplistically) is as follows:
>>>>
>>>> Given some set of information I, how do we construct a method M for
>>>> solving some problem P using *only* the information in I.
>>>>
>>>
>>> This becomes simply impossible when I is merely the machine address
>>> of the software that must be simulated.
>>
>> Turing Machines don't *have* machine addresses.
>
> Sure they do, merely no one ever references them. Each state / input
> pair is a single machine code instruction at a specific machine code
> address.
>
>
>> In the Linz proof, the TM is passed a *description* of the TM and an
>> input string.
>>
>> In the case of your H, if you want to think of it as a computation,
>> the input would be the *entire* block of code pointed to by the
>> function pointer, plus the actual string pointed to by the second
>> parameter. It wouldn't simply be the pointer values themselves.
>>
>
> That merely makes it more cumbersome.
>
>> This is what I am trying to point out to you. The parameters given in
>> a C function call *don't* correspond to the input string used when
>> discussing Turing Machines/computations. So just because you have a C
>> function whose formal parameters resemble that of the input string to
>> some TM doesn't mean you're dealing with things that are equivalent or
>> which deal with the same computation.
>
> The machine address points to a specific machine code string.
>
>>
>>>> M would be a Turing Machine. I would be the input string to that
>>>> machine. P would be something like 'does this computation halt?'.
>>>>
>>>> The difference between Turing Machines and C isn't that C is somehow
>>>> more powerful than Turing Machines, it's simply that the way C
>>>> functions are expressed doesn't map directly to the theory of
>>>> computation because the formal parameters to a C function don't
>>>> represent all the information available to the routine; they
>>>> represent only the information that is passed via the stack which
>>>> may or may not be all of the information which the function has
>>>> access to. Information may also be passed in global variables,
>>>> static variables, etc. Thus, the input to a C function doesn't
>>>> necessarily represent the same thing that the input to a TM does.
>>>>
>>>> If you want to analyze a C function as a computation, you need to
>>>> gather all the information which the C function makes use of
>>>> *including* information accessed from sources other than the formal
>>>> parameters. So to discuss your H in terms of computational theory
>>>> the set I would consist of the formal paramters of H *plus* the
>>>> static variable which the function also makes use of as a source of
>>>> information.
>>>>
>>>> We could then construct some Turing Machine which takes an input
>>>> string representing {P, P, static_execution_trace}. So a Turing
>>>> Machine is perfectly capable of implementing your H.
>>>>
>>>
>>> This works just fine when we pass the execution trace to P, except
>>> that P is free to erase the whole execution trace every time that it is
>>> called.
>>
>> Right, because every computation starts with a tabula rasa.
>>
>
> This artificially constrains TM preventing them from having the same
> power as C. A C function can correctly determine when it has been
> involved in infinitely nested simulation a TM that obeys the aribitrary
> rules cannot. This makes C strictly more powerful than TM's. Since it is
> much more plausible that you are simply wrong that is what I conclude.

No, C is not 'More Powerful' in the sense that any Computation that you
can do in C, you can also do on a Turing Machine.

PERIOD.

Yes, C code FRAGMENTS can do things that Turing Machine Fragments can't
do, but you don't actually run fragments, only programs, and in general
a program will be a computation, so C programs can be replicated by
Turing Machines (They may use different techniques to do the job, but
they give the eqivalent answer)

The one exception is if the program 'talks' to something external like
another computer or some special hardware. The basic Turing Machine has
limited I/O so that can't be copied, but that isn't important to
Computation Theory.

A cluster of Computers that talk to each other and together perform a
computation CAN be converted into a Turing Machine.

>
>> If you want to claim what you are trying to do is equivalent to a
>> Turing Machine, that machine would have to be one which takes the
>> execution trace as part of its input string and which writes a new
>> execution trace to the tape as part of its output which could then be
>> fed to a new computation.
>>
>
> Unless it can hold the entire execution trace across nested simulations
> it is strictly less powerful that the C function that can.

On 9/21/21 7:56 PM, olcott wrote:
> On 9/21/2021 6:21 PM, Richard Damon wrote:
>> On 9/21/21 11:19 AM, olcott wrote:
>>> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>>>
>>>> On 9/21/21 12:55 AM, olcott wrote:
>>>>> o in other words a C function with static local data can detect
>>>>> that it
>>>>> was called in infinitely nested simulation, yet a TM is not allowed to
>>>>> have static local data therefore the C function is strictly more
>>>>> powerful than a TM.
>>>>
>>>> Just to clarify a bit here.
>>>>
>>>> A C/x86 code FRAGMENT can do more than a Turing Machine Code Fragment,
>>>> as Turing Machine fragments are still computations. but C/x86 don't
>>>> need
>>>> to be.
>>>>
>>>> By Code fragment, I mean a piece of code that some 'Program' will enter
>>>> and exit from multiple times, and the fragment is allowed to keep some
>>>> 'internal' state that the rest of the program doesn't know about.
>>>>
>>>> Computation Theory doesn't care about this, as it only deals with
>>>> Computations as a whole, not fragments.
>>>>
>>>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>>>> anything that a Turng Machine can't do (the Turing Machine might do it
>>>> differently, but can give the same results). By a Program, I mean a
>>>> piece of code that is entered when it starts, and it stays within the
>>>> program until it finishes, and gives up it output to what ever was
>>>> using it.
>>>>
>>>
>>> Then H(P,P) is a computation based on its initial input and final output
>>> even though it requires static local data.
>>
>> So you admit that ALL Copies of H(P,P) return non-halting?
>>
>> Even the one inside the P that H is simulating (but after the time that
>> H has simulated it)
>>
>> And thus this P is actually a Haling Computaton?
>>
>>>
>>> The bottom line is that a TM must use the equivalent of static local
>>> data to be able to keep track that it is stuck in infinitely nested
>>> simulation:
>>>
>>
>> No, it doesn't. IF your H isn't actually a computation because it
>> behavior is different between the 'Top' H and the "Slave' H, then there
>> is no Turing Machine Equivalent.
>>
> I think that you must be incorrect about this because it means that my C
> function is strictly more powerful than a TM.

Not really. Yes, as a FRAGMENT, it can do things that a Turing Machine
can't do, but a FRAGMENT actually can't do anything by itself, but only
as part of a larger whole.

>
> My C function can determine that it has been called in infinitely nested
> simulation because it has static data that is not erased between
> recursive simulations.

But only if it is put into a larger whole so it can do things.

That larger whole, which will be a computation, CAN be translated into a
Turing Machine.

>
> That you some how believe that a function called in infinitely recursive
> simulation must return a value to it caller seems quite nuts.
>

No, you LIE. I have NEVER said that a function ACTUALLY in infinite
recursion must return a value to its caller.

But if the function IS a computation, and one copy of it returns a
value, then ALL copies WILL alse return a value, and thus it wasn't
actually in an infinite recursion, because there IS code that stops the
simulation and returns an answer.

YOU LIE in claiming infinite recursion that occurs within a demonstrated
finite machine (or you have LIED that your H qualifies as a decider
because it isn't actually a Computation).

On 9/21/21 11:16 AM, olcott wrote:
> On 9/20/2021 11:42 PM, Richard Damon wrote:
>> On 9/21/21 12:03 AM, olcott wrote:
>>> On 9/20/2021 10:21 PM, Richard Damon wrote:
>>>> On 9/20/21 10:25 PM, olcott wrote:
>>>>> On 9/20/2021 9:12 PM, Richard Damon wrote:
>>>>>> On 9/20/21 8:14 PM, olcott wrote:
>>>>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>>>>> It's deceptive to call your secret C functions "machines".  It
>>>>>>>>>>>> hints at
>>>>>>>>>>>> the formality a clarity of Turing machines, but a TM that is a
>>>>>>>>>>>> copy of
>>>>>>>>>>>> another will have exactly the same transfer function (i.e. it
>>>>>>>>>>>> will
>>>>>>>>>>>> never
>>>>>>>>>>>> compute a different result).
>>>>>>>>>>>
>>>>>>>>>>> Unless one of them has a pathological self-reference
>>>>>>>>>>> relationship
>>>>>>>>>>> with
>>>>>>>>>>> its input and the other one does not.
>>>>>>>>>> No.  I stated a fact (about TMs) that has no exceptions.  Your
>>>>>>>>>> secret C
>>>>>>>>>> code is another matter, of course.  It's just the deception of
>>>>>>>>>> calling
>>>>>>>>>> your code a "machine" that I was objecting to.  It gives your
>>>>>>>>>> hidden
>>>>>>>>>> code an air of formality that it lacks.
>>>>>>>>>
>>>>>>>>> This is easily proven in a way that you are incapable of
>>>>>>>>> understanding.
>>>>>>>>
>>>>>>>> You can't even write English.  Saying "This is easily proven"
>>>>>>>> following
>>>>>>>> a quote from me that you are wrong, means you can easily prove
>>>>>>>> what I
>>>>>>>> said in the quote -- that you are wrong.  That is indeed the case,
>>>>>>>> but
>>>>>>>> it is unlikely to be what you meant to say.
>>>>>>>>
>>>>>>>> Your junk functions are not "machines".  The terms suggests an
>>>>>>>> undeserved formality.
>>>>>>>>
>>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>      if (H(x, x))
>>>>>>>        HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> The actual correct x86 emulation of the input to H1(P,P) is
>>>>>>> different
>>>>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>>>>
>>>>>> Which means that your emulator is broken, or H isn't a Computation.
>>>>>>
>>>>>> PERIOD.
>>>>>>
>>>>>
>>>>> That would mean that "a computation" cannot possibly determine that it
>>>>> has been invoked in infinitely recursive simulation, whereas a C
>>>>> function with a a pair of static local variables can.
>>>>>
>>>>
>>>> Right, it can't
>>>>
>>>> Yep, a C code fragment can easily be a non-computation.
>>>>
>>>>> This means that a C function can do something that a TM cannot do thus
>>>>> making it strictly more powerful than a TM. Since this seems
>>>>> implausible
>>>>> I estimate that you are simply wrong.
>>>>
>>>> Nope.
>>>>
>>>> The Rule is that there is no COMPUTATION that the C function can do
>>>> that
>>>> a Turing Machine can not do. This is the definition of Turing
>>>> Competeness and the Turing Equivalence rule.
>>>>
>>>
>>> Yes a C function can determine that it has been called in infinitely
>>> nested simulation only because it is able to maintain static local data
>>> that is not erased between nested simulations.
>>>
>>> If a TM cannot maintain static data between nested simulations then a TM
>>> cannot detect when it is within infinitely nested simulations. This
>>> makes the C function strictly more powerful than the TM.
>>
>> Maybe, but it doesn't mean it can COMPUTE something that a Turing
>> Machine can, which is the only thing that Computation Theory is
>> concerned with.
>>
>> If it isn't a pure mapping of an input to an output, Computation Theory
>> doesn't care about it.
>>
>>>
>>>> Also, any 'complete' program (or complete fragment) that has a well
>>>> defined input, can be expressed as a Computation, and thus a Turing
>>>> Machine could do the equivalent of it. The key here is COMPLETE. You
>>>> function isn't 'Complete' as exection goes outside of it and then comes
>>>> back in.
>>>
>>> Exactly the same way that the simulation of the
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates ...
>>>
>>> Olcott H can detect when Olcott P is doing this only because Olcott H
>>> has static local data the survives nested simulations.
>>>
>>> If a TM cannot have such static local data then Olcott H is strictly
>>> more powerful than Linz H.
>>>
>>
>>
>> Right, if H IS just a UTM, then H^ is non-halting, but then H doesn't
>> give an answer to the question H(H^,H^), so it can't answer the question.
>>
>
> Although Olcott H can watch the nested simulation of itself because it
> has static local data Linz Ĥ could not do this if it is not allowed to
> have the equivalent of static local data. This would make Olcott H
> strictly more powerful that Linz Ĥ, when Linz Ĥ is arbitrarily forbidden
> from having its own static local data.

Form everything I have seen, Olcott H, BY ITSELF, is NOT an actual
computation. It seems to have different behavior under different
conditions which means it isn't a Computation.

It is also possible it is a Computation, but just totally fails at other
things it is claimed to be able to do.

In one sense, POOP-H is much more powerful than Linz-H, because Linz-H
is proved to not exist, so it actually can't do anything.

If POOP-H is fixed to actually BE a Computation, then a Turing Machine
Equivalent could be made to replicate it.

One simple way to fix it is to add to the Turing Machine the input that
POOP-H keeps as its hidden input, so H becomes H(P, I, s) where s is the
state from the outer calls. Simple.

It just means that it admits that it isn't actually a Halt Decider, as
it has the wrong set of inputs.

>
>> Once H has the code to abort the simulation loop, and is also still a
>
> We can get here because the Linz Ĥ cannot even get to the point where
> the abort criteria is matched because it is forced to erase the
> execution data that would show this.

Linz H^ is NOT a decider, so it doesn't need to do that.

Linz H^ uses a copy of Linz H inside it which is.

Now, if POOP-H is ACTUALLY a Computation by itself, with the proper
inputs, then we can form the equivalent Linz-H for it.

On 9/21/21 11:21 AM, olcott wrote:
> On 9/20/2021 10:35 PM, Richard Damon wrote:
>> On 9/20/21 11:13 PM, olcott wrote:
>>> On 9/20/2021 10:05 PM, Richard Damon wrote:
>>>> On 9/20/21 9:49 PM, olcott wrote:
>>>>>
>>>>>
>>>>> It proves that the Linz H exists nitwit !
>>>>>
>>>>> Are you too damn stupid like Richard to understand that Ĥ
>>>>> ALWAYS REFERS TO LINZ
>>>>> ALWAYS REFERS TO LINZ
>>>>> ALWAYS REFERS TO LINZ
>>>>> ALWAYS REFERS TO LINZ
>>>>
>>>> Yes, you have decided to not call your 'equivalent' of Linz-H^ H^, I
>>>> think because it points out to well that what you call 'P' actually
>>>> changes when you redefine H.
>>>>
>>> H/H1/P always refers to Olcott
>>> H/Ĥ/⟨Ĥ⟩ always refers to Linz
>>>
>>> Ĥ has never referred to Olcott
>>> H_Hat did refer to Olcott months ago before I renamed it to P.
>>>
>>
>> Right, so H is an ambiguous term, so you need to qualify ALL your uses
>> of it.
>>
>
> H/P versus H/Ĥ qualifies H
>
>

So, I will presume thta you are thus promising that No H will ever occur
without a H^ or a P in close proximity, and the other symbol will not be
anywhere near it? Not even refering to the other case without CLEAR
distinction?

PROMISE?

On 2021-09-21 13:25, olcott wrote:
> On 9/21/2021 1:43 PM, André G. Isaak wrote:
>> On 2021-09-21 12:22, olcott wrote:
>>> On 9/21/2021 12:51 PM, André G. Isaak wrote:
>>>> On 2021-09-21 09:19, olcott wrote:
>>>>> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/21/21 12:55 AM, olcott wrote:
>>>>>>> o in other words a C function with static local data can detect
>>>>>>> that it
>>>>>>> was called in infinitely nested simulation, yet a TM is not
>>>>>>> allowed to
>>>>>>> have static local data therefore the C function is strictly more
>>>>>>> powerful than a TM.
>>>>>>
>>>>>> Just to clarify a bit here.
>>>>>>
>>>>>> A C/x86 code FRAGMENT can do more than a Turing Machine Code
>>>>>> Fragment,
>>>>>> as Turing Machine fragments are still computations. but C/x86
>>>>>> don't need
>>>>>> to be.
>>>>>>
>>>>>> By Code fragment, I mean a piece of code that some 'Program' will
>>>>>> enter
>>>>>> and exit from multiple times, and the fragment is allowed to keep
>>>>>> some
>>>>>> 'internal' state that the rest of the program doesn't know about.
>>>>>>
>>>>>> Computation Theory doesn't care about this, as it only deals with
>>>>>> Computations as a whole, not fragments.
>>>>>>
>>>>>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>>>>>> anything that a Turng Machine can't do (the Turing Machine might
>>>>>> do it
>>>>>> differently, but can give the same results). By a Program, I mean a
>>>>>> piece of code that is entered when it starts, and it stays within the
>>>>>> program until it finishes, and gives up it output to what ever was
>>>>>> using it.
>>>>>>
>>>>>
>>>>> Then H(P,P) is a computation based on its initial input and final
>>>>> output even though it requires static local data.
>>>>>
>>>>> The bottom line is that a TM must use the equivalent of static
>>>>> local data to be able to keep track that it is stuck in infinitely
>>>>> nested simulation:
>>>>>
>>>>> the simulation of the
>>>>>
>>>>> machine description of a UTM H that simulates
>>>>> the machine description P the simulates
>>>>>
>>>>> machine description of a UTM H that simulates
>>>>> the machine description P the simulates
>>>>>
>>>>> machine description of a UTM H that simulates
>>>>> the machine description P the simulates ...
>>>>>
>>>>> Olcott H can detect when Olcott P is doing this only when Olcott H
>>>>> is able to use static local data, otherwise Olcott H has its memory
>>>>> of prior invocations erased upon every subsequent simulation.
>>>>>
>>>>> It seems ridiculous that this level of functionality is simply
>>>>> disallowed. If it is simply disallowed then that makes my H
>>>>> strictly more powerful than the Linz TM H can be.
>>>>
>>>> The problem here is that you are trying to somehow justify your use
>>>> of static variables without making any effort to understand what a
>>>> computation actually is.
>>>>
>>>> The question which the theory of computation deals with (very
>>>> simplistically) is as follows:
>>>>
>>>> Given some set of information I, how do we construct a method M for
>>>> solving some problem P using *only* the information in I.
>>>>
>>>
>>> This becomes simply impossible when I is merely the machine address
>>> of the software that must be simulated.
>>
>> Turing Machines don't *have* machine addresses.
>
> Sure they do, merely no one ever references them. Each state / input
> pair is a single machine code instruction at a specific machine code
> address.

No, they do not. Nor do they have machine code instructions. You can't
just make shit up and expect people to believe you.

>
>> In the Linz proof, the TM is passed a *description* of the TM and an
>> input string.
>>
>> In the case of your H, if you want to think of it as a computation,
>> the input would be the *entire* block of code pointed to by the
>> function pointer, plus the actual string pointed to by the second
>> parameter. It wouldn't simply be the pointer values themselves.
>>
>
> That merely makes it more cumbersome.

Avoiding cumbersomeness isn't a legitimate reason for doing things the
wrong way.

>> This is what I am trying to point out to you. The parameters given in
>> a C function call *don't* correspond to the input string used when
>> discussing Turing Machines/computations. So just because you have a C
>> function whose formal parameters resemble that of the input string to
>> some TM doesn't mean you're dealing with things that are equivalent or
>> which deal with the same computation.
>
> The machine address points to a specific machine code string.
>
>>
>>>> M would be a Turing Machine. I would be the input string to that
>>>> machine. P would be something like 'does this computation halt?'.
>>>>
>>>> The difference between Turing Machines and C isn't that C is somehow
>>>> more powerful than Turing Machines, it's simply that the way C
>>>> functions are expressed doesn't map directly to the theory of
>>>> computation because the formal parameters to a C function don't
>>>> represent all the information available to the routine; they
>>>> represent only the information that is passed via the stack which
>>>> may or may not be all of the information which the function has
>>>> access to. Information may also be passed in global variables,
>>>> static variables, etc. Thus, the input to a C function doesn't
>>>> necessarily represent the same thing that the input to a TM does.
>>>>
>>>> If you want to analyze a C function as a computation, you need to
>>>> gather all the information which the C function makes use of
>>>> *including* information accessed from sources other than the formal
>>>> parameters. So to discuss your H in terms of computational theory
>>>> the set I would consist of the formal paramters of H *plus* the
>>>> static variable which the function also makes use of as a source of
>>>> information.
>>>>
>>>> We could then construct some Turing Machine which takes an input
>>>> string representing {P, P, static_execution_trace}. So a Turing
>>>> Machine is perfectly capable of implementing your H.
>>>>
>>>
>>> This works just fine when we pass the execution trace to P, except
>>> that P is free to erase the whole execution trace every time that it is
>>> called.
>>
>> Right, because every computation starts with a tabula rasa.
>>
>
> This artificially constrains TM preventing them from having the same
> power as C. A C function can correctly determine when it has been

This isn't an artificial constraint, nor does it imply that C is somehow
more powerful. The problem here is that C functions don't map directly
to computations in many cases, or at least not to the computation that
the functions prototype would suggest. As I said, when talking about
computations *all* sources of information supplied to the computation
are considered part of the input.

So a C function like int

int foo(int x) {
return(x+someGlobal)
}

would have a corresponding Turing Machine whose input string consists of
*two* components, y and someGlobal. The above *is* a computation; it
just isn't a computation of a function from x to foo(x). And for any C
function, if you want to talk about it as a computation you may need to
restructure it in a similar way.

While people have claimed your H isn't really a computation, what's
really intended by that is to say that it isn't really the computation
you claim it to be. It corresponds to a Turing Machine with (minimally)
*three* components to its input string, not just the two which have been
declared as formal parameters. And one whose output consists of more
than a simple binary value but also of an update trace. Which means it
*can't* be equivalent in any sense to the computation represented by
Linz's H whose input string consists of only two components and which
simply accepts or rejects that input.

On 9/21/2021 10:45 PM, André G. Isaak wrote:
> On 2021-09-21 13:25, olcott wrote:
>> On 9/21/2021 1:43 PM, André G. Isaak wrote:
>>> On 2021-09-21 12:22, olcott wrote:
>>>> On 9/21/2021 12:51 PM, André G. Isaak wrote:
>>>>> On 2021-09-21 09:19, olcott wrote:
>>>>>> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/21/21 12:55 AM, olcott wrote:
>>>>>>>> o in other words a C function with static local data can detect
>>>>>>>> that it
>>>>>>>> was called in infinitely nested simulation, yet a TM is not
>>>>>>>> allowed to
>>>>>>>> have static local data therefore the C function is strictly more
>>>>>>>> powerful than a TM.
>>>>>>>
>>>>>>> Just to clarify a bit here.
>>>>>>>
>>>>>>> A C/x86 code FRAGMENT can do more than a Turing Machine Code
>>>>>>> Fragment,
>>>>>>> as Turing Machine fragments are still computations. but C/x86
>>>>>>> don't need
>>>>>>> to be.
>>>>>>>
>>>>>>> By Code fragment, I mean a piece of code that some 'Program' will
>>>>>>> enter
>>>>>>> and exit from multiple times, and the fragment is allowed to keep
>>>>>>> some
>>>>>>> 'internal' state that the rest of the program doesn't know about.
>>>>>>>
>>>>>>> Computation Theory doesn't care about this, as it only deals with
>>>>>>> Computations as a whole, not fragments.
>>>>>>>
>>>>>>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>>>>>>> anything that a Turng Machine can't do (the Turing Machine might
>>>>>>> do it
>>>>>>> differently, but can give the same results). By a Program, I mean a
>>>>>>> piece of code that is entered when it starts, and it stays within
>>>>>>> the
>>>>>>> program until it finishes, and gives up it output to what ever
>>>>>>> was using it.
>>>>>>>
>>>>>>
>>>>>> Then H(P,P) is a computation based on its initial input and final
>>>>>> output even though it requires static local data.
>>>>>>
>>>>>> The bottom line is that a TM must use the equivalent of static
>>>>>> local data to be able to keep track that it is stuck in infinitely
>>>>>> nested simulation:
>>>>>>
>>>>>> the simulation of the
>>>>>>
>>>>>> machine description of a UTM H that simulates
>>>>>> the machine description P the simulates
>>>>>>
>>>>>> machine description of a UTM H that simulates
>>>>>> the machine description P the simulates
>>>>>>
>>>>>> machine description of a UTM H that simulates
>>>>>> the machine description P the simulates ...
>>>>>>
>>>>>> Olcott H can detect when Olcott P is doing this only when Olcott H
>>>>>> is able to use static local data, otherwise Olcott H has its
>>>>>> memory of prior invocations erased upon every subsequent simulation.
>>>>>>
>>>>>> It seems ridiculous that this level of functionality is simply
>>>>>> disallowed. If it is simply disallowed then that makes my H
>>>>>> strictly more powerful than the Linz TM H can be.
>>>>>
>>>>> The problem here is that you are trying to somehow justify your use
>>>>> of static variables without making any effort to understand what a
>>>>> computation actually is.
>>>>>
>>>>> The question which the theory of computation deals with (very
>>>>> simplistically) is as follows:
>>>>>
>>>>> Given some set of information I, how do we construct a method M for
>>>>> solving some problem P using *only* the information in I.
>>>>>
>>>>
>>>> This becomes simply impossible when I is merely the machine address
>>>> of the software that must be simulated.
>>>
>>> Turing Machines don't *have* machine addresses.
>>
>> Sure they do, merely no one ever references them. Each state / input
>> pair is a single machine code instruction at a specific machine code
>> address.
>
> No, they do not. Nor do they have machine code instructions. You can't
> just make shit up and expect people to believe you.

The only way that state transitions can actually be implemented requires
current_state / current_input pairs that map to the next state.

Whenever this is not intentionally kept vague it involves integer pairs
that map to another integer.

Whenever this is not intentionally kept vague it involves these pairs
and their mapped state to be stored in some specific location.

Whatever this specific location is can be construed as its machine address.

Typically all these things are left intentionally vague.
Just because no one ever talks about the additional details does not
mean that they are not actually required.

Vagueness merely means that some details have not been specified.
It does not mean that these details do not exist.

>
>>
>>> In the Linz proof, the TM is passed a *description* of the TM and an
>>> input string.
>>>
>>> In the case of your H, if you want to think of it as a computation,
>>> the input would be the *entire* block of code pointed to by the
>>> function pointer, plus the actual string pointed to by the second
>>> parameter. It wouldn't simply be the pointer values themselves.
>>>
>>
>> That merely makes it more cumbersome.
>
> Avoiding cumbersomeness isn't a legitimate reason for doing things the
> wrong way.
>
>>> This is what I am trying to point out to you. The parameters given in
>>> a C function call *don't* correspond to the input string used when
>>> discussing Turing Machines/computations. So just because you have a C
>>> function whose formal parameters resemble that of the input string to
>>> some TM doesn't mean you're dealing with things that are equivalent
>>> or which deal with the same computation.
>>
>> The machine address points to a specific machine code string.
>>
>>>
>>>>> M would be a Turing Machine. I would be the input string to that
>>>>> machine. P would be something like 'does this computation halt?'.
>>>>>
>>>>> The difference between Turing Machines and C isn't that C is
>>>>> somehow more powerful than Turing Machines, it's simply that the
>>>>> way C functions are expressed doesn't map directly to the theory of
>>>>> computation because the formal parameters to a C function don't
>>>>> represent all the information available to the routine; they
>>>>> represent only the information that is passed via the stack which
>>>>> may or may not be all of the information which the function has
>>>>> access to. Information may also be passed in global variables,
>>>>> static variables, etc. Thus, the input to a C function doesn't
>>>>> necessarily represent the same thing that the input to a TM does.
>>>>>
>>>>> If you want to analyze a C function as a computation, you need to
>>>>> gather all the information which the C function makes use of
>>>>> *including* information accessed from sources other than the formal
>>>>> parameters. So to discuss your H in terms of computational theory
>>>>> the set I would consist of the formal paramters of H *plus* the
>>>>> static variable which the function also makes use of as a source of
>>>>> information.
>>>>>
>>>>> We could then construct some Turing Machine which takes an input
>>>>> string representing {P, P, static_execution_trace}. So a Turing
>>>>> Machine is perfectly capable of implementing your H.
>>>>>
>>>>
>>>> This works just fine when we pass the execution trace to P, except
>>>> that P is free to erase the whole execution trace every time that it is
>>>> called.
>>>
>>> Right, because every computation starts with a tabula rasa.
>>>
>>
>> This artificially constrains TM preventing them from having the same
>> power as C. A C function can correctly determine when it has been
>
> This isn't an artificial constraint, nor does it imply that C is somehow
> more powerful. The problem here is that C functions don't map directly
> to computations in many cases, or at least not to the computation that
> the functions prototype would suggest. As I said, when talking about
> computations *all* sources of information supplied to the computation
> are considered part of the input.
>
> So a C function like int
>
> int foo(int x) {
>     return(x+someGlobal)
> }
>
> would have a corresponding Turing Machine whose input string consists of
> *two* components, y and someGlobal. The above *is* a computation; it
> just isn't a computation of a function from x to foo(x). And for any C
> function, if you want to talk about it as a computation you may need to
> restructure it in a similar way.
>
> While people have claimed your H isn't really a computation, what's
> really intended by that is to say that it isn't really the computation
> you claim it to be. It corresponds to a Turing Machine with (minimally)
> *three* components to its input string, not just the two which have been
> declared as formal parameters. And one whose output consists of more
> than a simple binary value but also of an update trace. Which means it
> *can't* be equivalent in any sense to the computation represented by
> Linz's H whose input string consists of only two components and which
> simply accepts or rejects that input.
>
> The C language simply isn't designed with representing or discussing
> computations in mind. Its designed for writing computer programs. Turing
> Machines, on the other hand, were specifically designed with the goal of
> representing and discussing computations. So basically, you're using the
> wrong tool.
>
> It's like deciding you want to come up with a theory of the real numbers
> and then opting to use Roman numerals. Yes, you might be able to do it
> but it would be an incredibly stupid choice.
>
>> involved in infinitely nested simulation a TM that obeys the
>> aribitrary rules cannot. This makes C strictly more powerful than
>> TM's. Since it is much more plausible that you are simply wrong that
>> is what I conclude.
>>
>>> If you want to claim what you are trying to do is equivalent to a
>>> Turing Machine, that machine would have to be one which takes the
>>> execution trace as part of its input string and which writes a new
>>> execution trace to the tape as part of its output which could then be
>>> fed to a new computation.
>>>
>>
>> Unless it can hold the entire execution trace across nested
>> simulations it is strictly less powerful that the C function that can.
>
> TMs can do this, but it would require that said trace (or whatever you
> view the TM equivalent to be since TMs don't really have traces) be
> passed as a formal input to each invocation and that any changes be
> written to the tape as part of each invocations output. TMs are no less
> capable of doing it than C functions, but with C you can obscure *which*
> computation is actually being performed so that you can make a function
> which has a prototype which *looks* like Linz's H but which really an
> entirely different type of computation. With TMs you are forced to more
> clearly express what is going on.
>
> André
>

On 9/22/21 12:05 AM, olcott wrote:
> On 9/21/2021 10:45 PM, André G. Isaak wrote:

>> No, they do not. Nor do they have machine code instructions. You can't
>> just make shit up and expect people to believe you.
>
> The only way that state transitions can actually be implemented requires
> current_state / current_input pairs that map to the next state.
>
> Whenever this is not intentionally kept vague it involves integer pairs
> that map to another integer.
>
> Whenever this is not intentionally kept vague it involves these pairs
> and their mapped state to be stored in some specific location.
>
> Whatever this specific location is can be construed as its machine address.
>
> Typically all these things are left intentionally vague.
> Just because no one ever talks about the additional details does not
> mean that they are not actually required.
>
> Vagueness merely means that some details have not been specified.
> It does not mean that these details do not exist.
>

You just don't understand how it works, do you.

You mind can only think in terms of a 'classical' Von Neumann machine.

States do not need to be 'addresses', but perhaps you could map the
states to some 'address' but such a mapping is not a unique mapping, as
there are many ways to map N states to N numeric addresses.

A Turing Machine at any given instance is in 'A State'.

Turing Machine are mathematical constructions so it doesn't really
matter HOW that state is constructed.

Do YOU care for you x86 machine how it actually DOES what it does? Do
you care about the fact that you have an array of transistors on a
Silicon substrate. Would it make a difference if it was built differently.

Do you mind that the registers you think of as a programmer don't
actually exist in the hardware. There isn't a flip-flop inside the
computer that you can call bit 0 of AX, but that keeps on moving around
inside the device with other flip flops keeping track of where it is.

Turing Machines ARE Fully defined and perhaps even less vague than your
x86 computation model.

Maybe your problem is that you don't understand mathematical concepts,
but only things that are very concrete, but you don't know how abstract
your view of the typical CPU is.

On 9/21/21 7:56 PM, olcott wrote:
>>
> I think that you must be incorrect about this because it means that my C
> function is strictly more powerful than a TM.
>
> My C function can determine that it has been called in infinitely nested
> simulation because it has static data that is not erased between
> recursive simulations.
>
> That you some how believe that a function called in infinitely recursive
> simulation must return a value to it caller seems quite nuts.
>

I will point out that you mis-characterize what you H is able to do.

H can't tell if it is infinitely nested, only that it is nested with no
condition outside of the function H.

This is a SYNTACTIC property, not a SEMANTIC property.

This doesn't actually let you C function do anything that a Turing
Machine can't do, as FRAGMENTS don't actually have the ability to do
anything, they are only building blocks to make a total program (which
is what Computation Theory looks at).

Once you connect your POOP-H to your POOP-P to make a 'program' that is
actually a computation, that exact same results can be converted into a
Turing Machine becuase it NOW is a simple recursion that POOP-H_P uses
itself, so this recursion can be unrolled into an iteration, which
Turing Machine can easily handle.

Part of the issue is that your H doesn't seem to ACTUALLY simulate its
input, but does a form of running it within itself, as the simulated
copies of H aren't simulated but are effectively called.

If that 'simulated' H was actually simulated, then it couldn't actually
access that static local variable in the simulating H, as the simulation
is a different 'address space'. Since it does, you must not be actually
having H simulating its input.

Somewhat makes me wonder what all the purpose of the simulator that you
borrowed is for, unless all you are doing is making a 'virtual' x86
machine for all you code to run on so x86utm can be compiled a run on
any CPU and the assembly code for H can thus assume it is an x86
processor so you can use the debug instructions.

That says that H itself isn't simulating, but actually just debug
stepping its input, which puts you in a very different light.

On 2021-09-21 22:05, olcott wrote:
> On 9/21/2021 10:45 PM, André G. Isaak wrote:
>> On 2021-09-21 13:25, olcott wrote:
>>> On 9/21/2021 1:43 PM, André G. Isaak wrote:

>>>> Turing Machines don't *have* machine addresses.
>>>
>>> Sure they do, merely no one ever references them. Each state / input
>>> pair is a single machine code instruction at a specific machine code
>>> address.
>>
>> No, they do not. Nor do they have machine code instructions. You can't
>> just make shit up and expect people to believe you.
>
> The only way that state transitions can actually be implemented requires
> current_state / current_input pairs that map to the next state.

Implemented? Turing machines are mathematical abstractions. They are not
computers containing addressable RAM or computer programs. A state
transition doesn't have a machine address anymore than an element of a
set or a node on directed graph or a specific term of a polynomial has a
machine address.

Sure, if you implement a Turing Machine interpreter on a computer, then
the description of each state transition will be stored somewhere in
memory and that location will have an address, but that doesn't mean the
actual Turing Machine has machine addresses.

It is meaningful to talk about x86 instructions as having machine
addresses because an actual x86 program can refer to those addresses,
i.e. through a function pointer or whatever. But a Turing Machine lacks
that ability. Even if you assign 'addresses' to each state transition,
the TM has absolutely no way of referring to those addresses.

Did you bother to read the remainder of this post?

<snip>

>>> This artificially constrains TM preventing them from having the same
>>> power as C. A C function can correctly determine when it has been
>>
>> This isn't an artificial constraint, nor does it imply that C is
>> somehow more powerful. The problem here is that C functions don't map
>> directly to computations in many cases, or at least not to the
>> computation that the functions prototype would suggest. As I said,
>> when talking about computations *all* sources of information supplied
>> to the computation are considered part of the input.
>>
>> So a C function like int
>>
>> int foo(int x) {
>>      return(x+someGlobal)
>> }
>>
>> would have a corresponding Turing Machine whose input string consists
>> of *two* components, y and someGlobal. The above *is* a computation;
>> it just isn't a computation of a function from x to foo(x). And for
>> any C function, if you want to talk about it as a computation you may
>> need to restructure it in a similar way.
>>
>> While people have claimed your H isn't really a computation, what's
>> really intended by that is to say that it isn't really the computation
>> you claim it to be. It corresponds to a Turing Machine with
>> (minimally) *three* components to its input string, not just the two
>> which have been declared as formal parameters. And one whose output
>> consists of more than a simple binary value but also of an update
>> trace. Which means it *can't* be equivalent in any sense to the
>> computation represented by Linz's H whose input string consists of
>> only two components and which simply accepts or rejects that input.
>>
>> The C language simply isn't designed with representing or discussing
>> computations in mind. Its designed for writing computer programs.
>> Turing Machines, on the other hand, were specifically designed with
>> the goal of representing and discussing computations. So basically,
>> you're using the wrong tool.
>>
>> It's like deciding you want to come up with a theory of the real
>> numbers and then opting to use Roman numerals. Yes, you might be able
>> to do it but it would be an incredibly stupid choice.
>>
>>> involved in infinitely nested simulation a TM that obeys the
>>> aribitrary rules cannot. This makes C strictly more powerful than
>>> TM's. Since it is much more plausible that you are simply wrong that
>>> is what I conclude.
>>>
>>>> If you want to claim what you are trying to do is equivalent to a
>>>> Turing Machine, that machine would have to be one which takes the
>>>> execution trace as part of its input string and which writes a new
>>>> execution trace to the tape as part of its output which could then
>>>> be fed to a new computation.
>>>>
>>>
>>> Unless it can hold the entire execution trace across nested
>>> simulations it is strictly less powerful that the C function that can.
>>
>> TMs can do this, but it would require that said trace (or whatever you
>> view the TM equivalent to be since TMs don't really have traces) be
>> passed as a formal input to each invocation and that any changes be
>> written to the tape as part of each invocations output. TMs are no
>> less capable of doing it than C functions, but with C you can obscure
>> *which* computation is actually being performed so that you can make a
>> function which has a prototype which *looks* like Linz's H but which
>> really an entirely different type of computation. With TMs you are
>> forced to more clearly express what is going on.
>>
>> André
>>
>
>

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

On 9/22/2021 3:46 PM, André G. Isaak wrote:
> On 2021-09-21 22:05, olcott wrote:
>> On 9/21/2021 10:45 PM, André G. Isaak wrote:
>>> On 2021-09-21 13:25, olcott wrote:
>>>> On 9/21/2021 1:43 PM, André G. Isaak wrote:
>
>>>>> Turing Machines don't *have* machine addresses.
>>>>
>>>> Sure they do, merely no one ever references them. Each state / input
>>>> pair is a single machine code instruction at a specific machine code
>>>> address.
>>>
>>> No, they do not. Nor do they have machine code instructions. You
>>> can't just make shit up and expect people to believe you.
>>
>> The only way that state transitions can actually be implemented
>> requires current_state / current_input pairs that map to the next state.
>
> Implemented? Turing machines are mathematical abstractions. They are not
> computers containing addressable RAM or computer programs. A state
> transition doesn't have a machine address anymore than an element of a
> set or a node on directed graph or a specific term of a polynomial has a
> machine address.
>
> Sure, if you implement a Turing Machine interpreter on a computer, then
> the description of each state transition will be stored somewhere in
> memory and that location will have an address, but that doesn't mean the
> actual Turing Machine has machine addresses.
>

In order for the machine to actually function the vagueness must be made
specific. Even an imaginary Turing machine must have an imaginary
specific location to store its states. That imaginary location is the
machine address of this state. Not bothering to specify these details
BY-NO-MEANS eliminates the logical necessity of these details.

> It is meaningful to talk about x86 instructions as having machine
> addresses because an actual x86 program can refer to those addresses,
> i.e. through a function pointer or whatever. But a Turing Machine lacks
> that ability. Even if you assign 'addresses' to each state transition,
> the TM has absolutely no way of referring to those addresses.
>
> Did you bother to read the remainder of this post?
>
> <snip>
>
>>>> This artificially constrains TM preventing them from having the same
>>>> power as C. A C function can correctly determine when it has been
>>>
>>> This isn't an artificial constraint, nor does it imply that C is
>>> somehow more powerful. The problem here is that C functions don't map
>>> directly to computations in many cases, or at least not to the
>>> computation that the functions prototype would suggest. As I said,
>>> when talking about computations *all* sources of information supplied
>>> to the computation are considered part of the input.
>>>
>>> So a C function like int
>>>
>>> int foo(int x) {
>>>      return(x+someGlobal)
>>> }
>>>
>>> would have a corresponding Turing Machine whose input string consists
>>> of *two* components, y and someGlobal. The above *is* a computation;
>>> it just isn't a computation of a function from x to foo(x). And for
>>> any C function, if you want to talk about it as a computation you may
>>> need to restructure it in a similar way.
>>>
>>> While people have claimed your H isn't really a computation, what's
>>> really intended by that is to say that it isn't really the
>>> computation you claim it to be. It corresponds to a Turing Machine
>>> with (minimally) *three* components to its input string, not just the
>>> two which have been declared as formal parameters. And one whose
>>> output consists of more than a simple binary value but also of an
>>> update trace. Which means it *can't* be equivalent in any sense to
>>> the computation represented by Linz's H whose input string consists
>>> of only two components and which simply accepts or rejects that input.
>>>
>>> The C language simply isn't designed with representing or discussing
>>> computations in mind. Its designed for writing computer programs.
>>> Turing Machines, on the other hand, were specifically designed with
>>> the goal of representing and discussing computations. So basically,
>>> you're using the wrong tool.
>>>
>>> It's like deciding you want to come up with a theory of the real
>>> numbers and then opting to use Roman numerals. Yes, you might be able
>>> to do it but it would be an incredibly stupid choice.
>>>
>>>> involved in infinitely nested simulation a TM that obeys the
>>>> aribitrary rules cannot. This makes C strictly more powerful than
>>>> TM's. Since it is much more plausible that you are simply wrong that
>>>> is what I conclude.
>>>>
>>>>> If you want to claim what you are trying to do is equivalent to a
>>>>> Turing Machine, that machine would have to be one which takes the
>>>>> execution trace as part of its input string and which writes a new
>>>>> execution trace to the tape as part of its output which could then
>>>>> be fed to a new computation.
>>>>>
>>>>
>>>> Unless it can hold the entire execution trace across nested
>>>> simulations it is strictly less powerful that the C function that can.
>>>
>>> TMs can do this, but it would require that said trace (or whatever
>>> you view the TM equivalent to be since TMs don't really have traces)
>>> be passed as a formal input to each invocation and that any changes
>>> be written to the tape as part of each invocations output. TMs are no
>>> less capable of doing it than C functions, but with C you can obscure
>>> *which* computation is actually being performed so that you can make
>>> a function which has a prototype which *looks* like Linz's H but
>>> which really an entirely different type of computation. With TMs you
>>> are forced to more clearly express what is going on.
>>>
>>> André
>>>
>>
>>
>
>

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 9/21/2021 7:44 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/20/2021 9:50 PM, Ben Bacarisse wrote:
>>
>>>> You conclude I'm stupid because I
>> (childish snipping)
>>
>>> can't keep track of the key detail that Ĥ only refer to Linz from the
>>> perfecly clear conext that has been reiterated hundreds of times over
>>> many months.
>>
>> Your contradictory statements, and your lies about not having made them,
>> are still contradictory and dishonest not matter what TMs the symbols
>> were supposed to denote.
>
> That I always used this symbol Ĥ in the context of the Linz proofs and
> never used it in any other way and did this many hundreds of times
> should have been noticed by someone that is not stupid.

More deflection from the rather obvious lie you've been caught telling.
You lied about never having agreed to something you had agreed to less
than two weeks earlier. In the mean time you went ahead and said the
opposite because it suited you are the time. Truth is of no interest to
you. Just boasting.

--
Ben.

On 9/22/21 4:52 PM, olcott wrote:
> On 9/22/2021 3:46 PM, André G. Isaak wrote:
>> On 2021-09-21 22:05, olcott wrote:
>>> On 9/21/2021 10:45 PM, André G. Isaak wrote:
>>>> On 2021-09-21 13:25, olcott wrote:
>>>>> On 9/21/2021 1:43 PM, André G. Isaak wrote:
>>
>>>>>> Turing Machines don't *have* machine addresses.
>>>>>
>>>>> Sure they do, merely no one ever references them. Each state /
>>>>> input pair is a single machine code instruction at a specific
>>>>> machine code address.
>>>>
>>>> No, they do not. Nor do they have machine code instructions. You
>>>> can't just make shit up and expect people to believe you.
>>>
>>> The only way that state transitions can actually be implemented
>>> requires current_state / current_input pairs that map to the next state.
>>
>> Implemented? Turing machines are mathematical abstractions. They are
>> not computers containing addressable RAM or computer programs. A state
>> transition doesn't have a machine address anymore than an element of a
>> set or a node on directed graph or a specific term of a polynomial has
>> a machine address.
>>
>> Sure, if you implement a Turing Machine interpreter on a computer,
>> then the description of each state transition will be stored somewhere
>> in memory and that location will have an address, but that doesn't
>> mean the actual Turing Machine has machine addresses.
>>
>
> In order for the machine to actually function the vagueness must be made
> specific. Even an imaginary Turing machine must have an imaginary
> specific location to store its states. That imaginary location is the
> machine address of this state. Not bothering to specify these details
> BY-NO-MEANS eliminates the logical necessity of these details.
>

Nope, you don't seem to understand how this works. Turing Machines have
states. States are NOT just an address in some memory. Yes, you could
assign a given state to some numerical address, but that address isn't
somehow tied to the machine.

The key thing to note is that a Turing Machine description is a SET, not
a list. It is a set of tuples of Current State, Input Symbol, Next
State, and 'Tape Operation' (various variations use different sets of
Tape Operations but that isn't important here).

One key feature of Sets, is that the order of their elements isn't
important, THEY DON'T HAVE ADDRESSES.

Yes, perhaps if you want to build a x86 computer program to try to
process the machine, you need to assign 'numbers' to each of the states
and input symbols so the dumb computer can find the entry because of the
limitations of these computers. But this does NOT say those states
actually have an address that you can look at to see if it matches,
because each for each copy of the machine you might map those states
differently to the numbers you build the addresses from.

This means that your concept of 'matching addresses' just doesn't work.