On Wednesday, April 12, 2023 at 1:05:14 PM UTC+10, Richard Damon wrote:
> > but LINZ still BREAKS THE SPEFICATION OF HALT
> >
> >>>>> 1/ input program ID and input
> >>>>> 2/ write 1 or 0 if program(input) halts or loops
> >>>>> 3/ TERMINATE
> >
> >
> > Whether he CHANGES the FINAL STATE
> > or CONTINUTES after halt in some way
> Which are allowed modifications for composing algorithms from other
> algorithms.

you can use halt OUT OF SCOPE
but you cant call it halt

> >>
> >> If you try to make that part of the tape "Write Only" then you break
> >> your model of computation being Turing Complete (or it is trivial to
> >> just modifiy at the point of the write 1 or write 0)
> >
> >
> > There are models of computation that have READ ONLY
> >
> > including a SUBSET of TMs
> Which is thus not Turing Complete.
> >
> > I agree the FULL SET OF TM's is not halt decidable
> > but that could be considered a weaker model than a COMPUTATIONALLY COMPLETE subset of TMs
> > (that double move the tape pointer LL or RR) and are forced to skip intermediate tape values
> > so they CANNOT write to them
> And it is well known that weaker models are decidable, and many such
> deciders are well known for many such classes, so unless you are
> actually PROVING a new method does succeed for a new class of
> computation that hasn't been known before, an not just showing you can
> defeat the simple proof program that shows that you can't decide for
> Turing Complete system, it isn't very interesting.

you ignore all points counter to your argument

you can prove/disprove halt in ANY model of computation you choose

since computer languages exist with READ ONLY
computation models exist with READ ONLY

d(D)
if halt(D D) then
L: GOTO L

halt( PROG INP )
if STACK>0 then
L: GOTO L
else
....
.... REST OF HALT FUNCTION
....

This correctly fullfills the specification of HALT
There is no requirement for other functions to call halt
They CAN but they FAIL

On 4/8/2023 7:53 PM, André G. Isaak wrote:
> On 2023-04-08 17:47, olcott wrote:
>> On 4/8/2023 6:37 PM, André G. Isaak wrote:
>>> On 2023-04-08 17:26, olcott wrote:
>>>> On 4/8/2023 6:09 PM, André G. Isaak wrote:
>>>>> On 2023-04-08 17:00, olcott wrote:
>>>>>> On 4/8/2023 4:39 PM, André G. Isaak wrote:
>>>>>>> On 2023-04-08 15:14, olcott wrote:
>>>>>>>> On 4/8/2023 3:43 PM, olcott wrote:
>>>>>>>>> On 4/8/2023 3:22 PM, André G. Isaak wrote:
>>>>>>>>>> On 2023-04-08 14:10, Ben Bacarisse wrote:
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/23 8:37 PM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> A masters degree in EE is probably not nearly as much CS as
>>>>>>>>>>>>> a BSBS in CS.
>>>>>>>>>>>>
>>>>>>>>>>>> You think so? Rmmember, my Masters was in Electrical
>>>>>>>>>>>> Engineering and
>>>>>>>>>>>> Computer Science, so I did get a lot of CS material too.
>>>>>>>>>>>
>>>>>>>>>>> Is PO saying he has a double BS degree?  You couldn't make it
>>>>>>>>>>> up!
>>>>>>>>>>
>>>>>>>>>> I think he means BS in Bullshit.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>> 02 {
>>>>>>>>> 03  int Halt_Status = H(x, x);
>>>>>>>>> 04  if (Halt_Status)
>>>>>>>>> 05    HERE: goto HERE;
>>>>>>>>> 06  return Halt_Status;
>>>>>>>>> 07 }
>>>>>>>>> 08
>>>>>>>>> 09 void main()
>>>>>>>>> 10 {
>>>>>>>>> 11  H(D,D);
>>>>>>>>> 12 }
>>>>>>>>>
>>>>>>>>> Every halt decider must report on the actual behavior of its
>>>>>>>>> actual
>>>>>>>>> input. The notion of a UTM establishes that H is correct to
>>>>>>>>> base its
>>>>>>>>> halt status decision on a finite number of steps of D correctly
>>>>>>>>> simulated by H.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The notion of a UTM guarantees that when N steps of D are correctly
>>>>>>>> simulated by H that this <is> the actual behavior that D
>>>>>>>> specifies to H.
>>>>>>>
>>>>>>> The notion of a UTM is entirely irrelevant since your H and D
>>>>>>> aren't formulated in terms of Turing Machines in the first place.
>>>>>>> No where does your code involve a TM, let alone a UTM.
>>>>>>>
>>>>>>> The notion of a UTM is simply that it is possible to construct a
>>>>>>> single TM which can mimic the behaviour of all other TMs. It says
>>>>>>> nothing whatsoever about making *decisions* about the properties
>>>>>>> of those TMs.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>>
>>>>>> It says more than that. It says that the correct simulation of a
>>>>>> machine
>>>>>> description does provide the underlying behavior specified by this
>>>>>> machine description.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> When embedded_H is a simulating halt decider and
>>>>>>
>>>>>> Ĥ is applied to ⟨Ĥ⟩
>>>>>> (q0) The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>> embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>> which simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ which begins at its own (q0) to
>>>>>> repeat the process. (never reaching the simulated ⟨Ĥ.qn⟩ and
>>>>>> halting).
>>>>>
>>>>> Since there is no mention of a UTM anywhere in the above, how can
>>>>> you claim that the 'notion of a UTM' makes any claims whatsoever
>>>>> about the above?!?
>>>>>
>>>>>> The notion of a UTM guarantees that when N steps of ⟨Ĥ⟩ are correctly
>>>>>> simulated by embedded_H that this <is> the actual behavior that ⟨Ĥ⟩
>>>>>> specifies to embedded_H.
>>>>>
>>>>> Non sequitur. embedded_H is not a UTM.
>>>>
>>>> That it is more than a UTM does not negate its UTM properties.
>>>
>>> It is not a UTM at all.
>>>
>>
>> A simulating halt decider starts with a UTM and then augments it with
>> additional features.
>
> It doesn't "augment" it. It *changes* it.

That is counter-factual. When a simulating halt decider correctly
simulates N steps of its input it derives the exact same N steps that a
pure UTM would derive because it is itself a UTM with extra features.

My reviewers cannot show that any of the extra features added to the UTM
change the behavior of the simulated input for the first N steps of
simulation.

Watching the behavior doesn't change it.
Matching non-halting behavior patterns doesn't change it.
Even aborting the simulation doesn't change the first N simulated steps.

Because of all this we can know that the first N steps of ⟨Ĥ⟩ simulated
by embedded_H are the actual behavior that ⟨Ĥ⟩ presents to embedded_H
for these same N steps.

> When given a non-halting
> computation as its input, a UTM will run forever. A simulating halt
> decider (were such a thing possible) on the other hand, would reject
> this input and then HALT. This is entirely different from what a UTM does.
>
> You can state that there is a *relationship* between your 'simulating
> halt decider' and a UTM in that the SHD uses similar methods as a UTM to
> (partially) simulate its input, but that doesn't mean you can
> legitimately say an SHD *is* a UTM -- it is not (and of course since
> your H and D are not even turing machines, it makes no sense to talk
> about UTMs at all).
>
> André
>

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

On 4/12/23 12:37 AM, olcott wrote:
> On 4/8/2023 7:53 PM, André G. Isaak wrote:
>> On 2023-04-08 17:47, olcott wrote:
>>> On 4/8/2023 6:37 PM, André G. Isaak wrote:
>>>> On 2023-04-08 17:26, olcott wrote:
>>>>> On 4/8/2023 6:09 PM, André G. Isaak wrote:
>>>>>> On 2023-04-08 17:00, olcott wrote:
>>>>>>> On 4/8/2023 4:39 PM, André G. Isaak wrote:
>>>>>>>> On 2023-04-08 15:14, olcott wrote:
>>>>>>>>> On 4/8/2023 3:43 PM, olcott wrote:
>>>>>>>>>> On 4/8/2023 3:22 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2023-04-08 14:10, Ben Bacarisse wrote:
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/23 8:37 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> A masters degree in EE is probably not nearly as much CS
>>>>>>>>>>>>>> as a BSBS in CS.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You think so? Rmmember, my Masters was in Electrical
>>>>>>>>>>>>> Engineering and
>>>>>>>>>>>>> Computer Science, so I did get a lot of CS material too.
>>>>>>>>>>>>
>>>>>>>>>>>> Is PO saying he has a double BS degree?  You couldn't make
>>>>>>>>>>>> it up!
>>>>>>>>>>>
>>>>>>>>>>> I think he means BS in Bullshit.
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>>> 02 {
>>>>>>>>>> 03  int Halt_Status = H(x, x);
>>>>>>>>>> 04  if (Halt_Status)
>>>>>>>>>> 05    HERE: goto HERE;
>>>>>>>>>> 06  return Halt_Status;
>>>>>>>>>> 07 }
>>>>>>>>>> 08
>>>>>>>>>> 09 void main()
>>>>>>>>>> 10 {
>>>>>>>>>> 11  H(D,D);
>>>>>>>>>> 12 }
>>>>>>>>>>
>>>>>>>>>> Every halt decider must report on the actual behavior of its
>>>>>>>>>> actual
>>>>>>>>>> input. The notion of a UTM establishes that H is correct to
>>>>>>>>>> base its
>>>>>>>>>> halt status decision on a finite number of steps of D correctly
>>>>>>>>>> simulated by H.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The notion of a UTM guarantees that when N steps of D are
>>>>>>>>> correctly
>>>>>>>>> simulated by H that this <is> the actual behavior that D
>>>>>>>>> specifies to H.
>>>>>>>>
>>>>>>>> The notion of a UTM is entirely irrelevant since your H and D
>>>>>>>> aren't formulated in terms of Turing Machines in the first
>>>>>>>> place. No where does your code involve a TM, let alone a UTM.
>>>>>>>>
>>>>>>>> The notion of a UTM is simply that it is possible to construct a
>>>>>>>> single TM which can mimic the behaviour of all other TMs. It
>>>>>>>> says nothing whatsoever about making *decisions* about the
>>>>>>>> properties of those TMs.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It says more than that. It says that the correct simulation of a
>>>>>>> machine
>>>>>>> description does provide the underlying behavior specified by this
>>>>>>> machine description.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> When embedded_H is a simulating halt decider and
>>>>>>>
>>>>>>> Ĥ is applied to ⟨Ĥ⟩
>>>>>>> (q0) The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>> embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>> which simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ which begins at its own (q0)
>>>>>>> to repeat the process. (never reaching the simulated ⟨Ĥ.qn⟩ and
>>>>>>> halting).
>>>>>>
>>>>>> Since there is no mention of a UTM anywhere in the above, how can
>>>>>> you claim that the 'notion of a UTM' makes any claims whatsoever
>>>>>> about the above?!?
>>>>>>
>>>>>>> The notion of a UTM guarantees that when N steps of ⟨Ĥ⟩ are
>>>>>>> correctly
>>>>>>> simulated by embedded_H that this <is> the actual behavior that ⟨Ĥ⟩
>>>>>>> specifies to embedded_H.
>>>>>>
>>>>>> Non sequitur. embedded_H is not a UTM.
>>>>>
>>>>> That it is more than a UTM does not negate its UTM properties.
>>>>
>>>> It is not a UTM at all.
>>>>
>>>
>>> A simulating halt decider starts with a UTM and then augments it with
>>> additional features.
>>
>> It doesn't "augment" it. It *changes* it.
>
> That is counter-factual. When a simulating halt decider correctly
> simulates N steps of its input it derives the exact same N steps that a
> pure UTM would derive because it is itself a UTM with extra features.

But it ISN'T a UTM, not even with extra features, at is no longer has
the essential features of a UTM.

>
> My reviewers cannot show that any of the extra features added to the UTM
> change the behavior of the simulated input for the first N steps of
> simulation.

But they don't need to, the change the validity of the logic that H uses.

H assumes that the H called by D is a UTM, but it isn't, and thus H has
just used UNSOUND logic.

>
> Watching the behavior doesn't change it.
> Matching non-halting behavior patterns doesn't change it.
> Even aborting the simulation doesn't change the first N simulated steps.

Right, but it DOES change the behavior of the rest of the machine
because that is a copy of this machine.

>
> Because of all this we can know that the first N steps of ⟨Ĥ⟩ simulated
> by embedded_H are the actual behavior that ⟨Ĥ⟩ presents to embedded_H
> for these same N steps.

Right, the first N steps, but we also know that if look at what happens
after that, something H can not do since, by your definition, it aborts
HERE, we see that embedded_H WILL transition to Qn and H^ wiil halt.

The eror isn't in the first N steps, but in the extrapolation of what
happens after that. It is in thinking that the behavior being decided
must come out of H's simulation, which CAN'T be complete (if it gives an
answer) instead of the, by definition, behavior of the actual machine,

You are just proving you are too stupid to understand what actually
matters. You seem to think that H is a UTM even though you have broken
the UTMness of it, because, you just don't know what a UTM is, in part
because you have no idea how Turing Machines actually work.

>
>> When given a non-halting computation as its input, a UTM will run
>> forever. A simulating halt decider (were such a thing possible) on the
>> other hand, would reject this input and then HALT. This is entirely
>> different from what a UTM does.
>>
>> You can state that there is a *relationship* between your 'simulating
>> halt decider' and a UTM in that the SHD uses similar methods as a UTM
>> to (partially) simulate its input, but that doesn't mean you can
>> legitimately say an SHD *is* a UTM -- it is not (and of course since
>> your H and D are not even turing machines, it makes no sense to talk
>> about UTMs at all).
>>
>> André
>>
>

On 4/12/23 12:20 AM, Graham Cooper wrote:
> On Wednesday, April 12, 2023 at 1:05:14 PM UTC+10, Richard Damon wrote:
>>> but LINZ still BREAKS THE SPEFICATION OF HALT
>>>
>>>>>>> 1/ input program ID and input
>>>>>>> 2/ write 1 or 0 if program(input) halts or loops
>>>>>>> 3/ TERMINATE
>>>
>>>
>>> Whether he CHANGES the FINAL STATE
>>> or CONTINUTES after halt in some way
>> Which are allowed modifications for composing algorithms from other
>> algorithms.
>
> you can use halt OUT OF SCOPE
> but you cant call it halt
>
>
>
>
>
>>>>
>>>> If you try to make that part of the tape "Write Only" then you break
>>>> your model of computation being Turing Complete (or it is trivial to
>>>> just modifiy at the point of the write 1 or write 0)
>>>
>>>
>>> There are models of computation that have READ ONLY
>>>
>>> including a SUBSET of TMs
>> Which is thus not Turing Complete.
>>>
>>> I agree the FULL SET OF TM's is not halt decidable
>>> but that could be considered a weaker model than a COMPUTATIONALLY COMPLETE subset of TMs
>>> (that double move the tape pointer LL or RR) and are forced to skip intermediate tape values
>>> so they CANNOT write to them
>> And it is well known that weaker models are decidable, and many such
>> deciders are well known for many such classes, so unless you are
>> actually PROVING a new method does succeed for a new class of
>> computation that hasn't been known before, an not just showing you can
>> defeat the simple proof program that shows that you can't decide for
>> Turing Complete system, it isn't very interesting.
>
>
> you ignore all points counter to your argument
>
> you can prove/disprove halt in ANY model of computation you choose

Nope, not in Turing Complete, or Turing Machines in particular.

>
> since computer languages exist with READ ONLY
> computation models exist with READ ONLY

But if it is actually "Read Only" NOTHING can set it.

>
>
> d(D)
> if halt(D D) then
> L: GOTO L
>
>
> halt( PROG INP )
> if STACK>0 then

And now halt is no longer "A Computation", so not a halt decicer.

> L: GOTO L
> else
> ...
> ... REST OF HALT FUNCTION
> ...
>

And remenber, the program D is defined not to "Call" Halt, but to be
built with a COPY of Halt, (And replacing a call with an inline copy is
ALWAYS a valid operation), you can just replace the call to halt(D,D)
with a copy of halt that omits the surperfoluos stack check.

>
> This correctly fullfills the specification of HALT
> There is no requirement for other functions to call halt
> They CAN but they FAIL
>
>

Nope, the requirment to be able to call a function is built into the
rules of what are computations.

Thus, your programming model, allowing non-callable functions isn't
Turing Complete anymore.

On Wednesday, April 12, 2023 at 9:04:32 PM UTC+10, Richard Damon wrote:
> On 4/12/23 12:20 AM, Graham Cooper wrote:
> > On Wednesday, April 12, 2023 at 1:05:14 PM UTC+10, Richard Damon wrote:
> >>> but LINZ still BREAKS THE SPEFICATION OF HALT
> >>>
> >>>>>>> 1/ input program ID and input
> >>>>>>> 2/ write 1 or 0 if program(input) halts or loops
> >>>>>>> 3/ TERMINATE
> >>>
> >>>
> >>> Whether he CHANGES the FINAL STATE
> >>> or CONTINUTES after halt in some way
> >> Which are allowed modifications for composing algorithms from other
> >> algorithms.
> >
> > you can use halt OUT OF SCOPE
> > but you cant call it halt
> >
> >
> >
> >
> >
> >>>>
> >>>> If you try to make that part of the tape "Write Only" then you break
> >>>> your model of computation being Turing Complete (or it is trivial to
> >>>> just modifiy at the point of the write 1 or write 0)
> >>>
> >>>
> >>> There are models of computation that have READ ONLY
> >>>
> >>> including a SUBSET of TMs
> >> Which is thus not Turing Complete.
> >>>
> >>> I agree the FULL SET OF TM's is not halt decidable
> >>> but that could be considered a weaker model than a COMPUTATIONALLY COMPLETE subset of TMs
> >>> (that double move the tape pointer LL or RR) and are forced to skip intermediate tape values
> >>> so they CANNOT write to them
> >> And it is well known that weaker models are decidable, and many such
> >> deciders are well known for many such classes, so unless you are
> >> actually PROVING a new method does succeed for a new class of
> >> computation that hasn't been known before, an not just showing you can
> >> defeat the simple proof program that shows that you can't decide for
> >> Turing Complete system, it isn't very interesting.
> >
> >
> > you ignore all points counter to your argument
> >
> > you can prove/disprove halt in ANY model of computation you choose
> Nope, not in Turing Complete, or Turing Machines in particular.

you dont seem to understand the point you refuted

> >
> > since computer languages exist with READ ONLY
> > computation models exist with READ ONLY
> But if it is actually "Read Only" NOTHING can set it.

it is AUTOMATICALLY set by the computing paradigm

or MAIN() can set it if just logging whether STACK=0 or STACK=1

> >
> >
> > d(D)
> > if halt(D D) then
> > L: GOTO L
> >
> >
> > halt( PROG INP )
> > if STACK>0 then
> And now halt is no longer "A Computation", so not a halt decicer.
> > L: GOTO L
> > else
> > ...
> > ... REST OF HALT FUNCTION
> > ...
> >
> And remenber, the program D is defined not to "Call" Halt, but to be
> built with a COPY of Halt, (And replacing a call with an inline copy is

only in some computation models

> ALWAYS a valid operation), you can just replace the call to halt(D,D)
> with a copy of halt that omits the surperfoluos stack check.

but HALT does the stack check

the computation model itself ensures every function call increases STACK

this is SIMPLE in most computer languages

> >
> > This correctly fullfills the specification of HALT
> > There is no requirement for other functions to call halt
> > They CAN but they FAIL
> >
> >
> Nope, the requirment to be able to call a function is built into the
> rules of what are computations.

you can call MAIN() or HALT()

but remember your using an ADJUSTED VERSION OF HALT
so HALT doesnt have to return the same value if called from the top level STACK=0

>
> Thus, your programming model, allowing non-callable functions isn't
> Turing Complete anymore.

The halt program (if / when it exists) wont be written in a TM.
It will be written in a standard computer language
which is TM compatible

It is COMPUTABLE to detect if a program is run from the top level STACK=0

On Wednesday, April 12, 2023 at 10:13:37 PM UTC+10, Graham Cooper wrote:
> On Wednesday, April 12, 2023 at 9:04:32 PM UTC+10, Richard Damon wrote:
> > > This correctly fullfills the specification of HALT
> > > There is no requirement for other functions to call halt
> > > They CAN but they FAIL
> > >
> > >
> > Nope, the requirment to be able to call a function is built into the
> > rules of what are computations.
> you can call MAIN() or HALT()
>
> but remember your using an ADJUSTED VERSION OF HALT
> so HALT doesnt have to return the same value if called from the top level STACK=0

REMEMBER the specification of HALT is to OUTPUT 1 or 0 and then TERMINATE

Because you are NOT USING THE SPECIFICATION
HALT can return a DIFFERENT VALUE
or INFINITE LOOP as Pete suggests

On 4/12/2023 6:04 AM, Richard Damon wrote:
> On 4/12/23 12:37 AM, olcott wrote:
>> On 4/8/2023 7:53 PM, André G. Isaak wrote:
>>> On 2023-04-08 17:47, olcott wrote:
>>>> On 4/8/2023 6:37 PM, André G. Isaak wrote:
>>>>> On 2023-04-08 17:26, olcott wrote:
>>>>>> On 4/8/2023 6:09 PM, André G. Isaak wrote:
>>>>>>> On 2023-04-08 17:00, olcott wrote:
>>>>>>>> On 4/8/2023 4:39 PM, André G. Isaak wrote:
>>>>>>>>> On 2023-04-08 15:14, olcott wrote:
>>>>>>>>>> On 4/8/2023 3:43 PM, olcott wrote:
>>>>>>>>>>> On 4/8/2023 3:22 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2023-04-08 14:10, Ben Bacarisse wrote:
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/7/23 8:37 PM, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A masters degree in EE is probably not nearly as much CS
>>>>>>>>>>>>>>> as a BSBS in CS.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You think so? Rmmember, my Masters was in Electrical
>>>>>>>>>>>>>> Engineering and
>>>>>>>>>>>>>> Computer Science, so I did get a lot of CS material too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is PO saying he has a double BS degree?  You couldn't make
>>>>>>>>>>>>> it up!
>>>>>>>>>>>>
>>>>>>>>>>>> I think he means BS in Bullshit.
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>>>> 02 {
>>>>>>>>>>> 03  int Halt_Status = H(x, x);
>>>>>>>>>>> 04  if (Halt_Status)
>>>>>>>>>>> 05    HERE: goto HERE;
>>>>>>>>>>> 06  return Halt_Status;
>>>>>>>>>>> 07 }
>>>>>>>>>>> 08
>>>>>>>>>>> 09 void main()
>>>>>>>>>>> 10 {
>>>>>>>>>>> 11  H(D,D);
>>>>>>>>>>> 12 }
>>>>>>>>>>>
>>>>>>>>>>> Every halt decider must report on the actual behavior of its
>>>>>>>>>>> actual
>>>>>>>>>>> input. The notion of a UTM establishes that H is correct to
>>>>>>>>>>> base its
>>>>>>>>>>> halt status decision on a finite number of steps of D correctly
>>>>>>>>>>> simulated by H.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The notion of a UTM guarantees that when N steps of D are
>>>>>>>>>> correctly
>>>>>>>>>> simulated by H that this <is> the actual behavior that D
>>>>>>>>>> specifies to H.
>>>>>>>>>
>>>>>>>>> The notion of a UTM is entirely irrelevant since your H and D
>>>>>>>>> aren't formulated in terms of Turing Machines in the first
>>>>>>>>> place. No where does your code involve a TM, let alone a UTM.
>>>>>>>>>
>>>>>>>>> The notion of a UTM is simply that it is possible to construct
>>>>>>>>> a single TM which can mimic the behaviour of all other TMs. It
>>>>>>>>> says nothing whatsoever about making *decisions* about the
>>>>>>>>> properties of those TMs.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It says more than that. It says that the correct simulation of a
>>>>>>>> machine
>>>>>>>> description does provide the underlying behavior specified by this
>>>>>>>> machine description.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> When embedded_H is a simulating halt decider and
>>>>>>>>
>>>>>>>> Ĥ is applied to ⟨Ĥ⟩
>>>>>>>> (q0) The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>>> embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>>> which simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ which begins at its own (q0)
>>>>>>>> to repeat the process. (never reaching the simulated ⟨Ĥ.qn⟩ and
>>>>>>>> halting).
>>>>>>>
>>>>>>> Since there is no mention of a UTM anywhere in the above, how can
>>>>>>> you claim that the 'notion of a UTM' makes any claims whatsoever
>>>>>>> about the above?!?
>>>>>>>
>>>>>>>> The notion of a UTM guarantees that when N steps of ⟨Ĥ⟩ are
>>>>>>>> correctly
>>>>>>>> simulated by embedded_H that this <is> the actual behavior that ⟨Ĥ⟩
>>>>>>>> specifies to embedded_H.
>>>>>>>
>>>>>>> Non sequitur. embedded_H is not a UTM.
>>>>>>
>>>>>> That it is more than a UTM does not negate its UTM properties.
>>>>>
>>>>> It is not a UTM at all.
>>>>>
>>>>
>>>> A simulating halt decider starts with a UTM and then augments it with
>>>> additional features.
>>>
>>> It doesn't "augment" it. It *changes* it.
>>
>> That is counter-factual. When a simulating halt decider correctly
>> simulates N steps of its input it derives the exact same N steps that a
>> pure UTM would derive because it is itself a UTM with extra features.
>
> But it ISN'T a UTM, not even with extra features, at is no longer has
> the essential features of a UTM.
>
>>
>> My reviewers cannot show that any of the extra features added to the UTM
>> change the behavior of the simulated input for the first N steps of
>> simulation.
>
> But they don't need to, the change the validity of the logic that H uses.
>
> H assumes that the H called by D is a UTM, but it isn't, and thus H has
> just used UNSOUND logic.
>
>>
>> Watching the behavior doesn't change it.
>> Matching non-halting behavior patterns doesn't change it.
>> Even aborting the simulation doesn't change the first N simulated steps.
>
> Right, but it DOES change the behavior of the rest of the machine
> because that is a copy of this machine.
>
>>
>> Because of all this we can know that the first N steps of ⟨Ĥ⟩ simulated
>> by embedded_H are the actual behavior that ⟨Ĥ⟩ presents to embedded_H
>> for these same N steps.
>
>
> Right, the first N steps, but we also know that if look at what happens
> after that, something H can not do since, by your definition, it aborts
> HERE, we see that embedded_H WILL transition to Qn and H^ wiil halt.
>
> The eror isn't in the first N steps, but in the extrapolation of what
> happens after that.

When N steps of ⟨Ĥ⟩ are correctly simulated by embedded_H these are the
the actual behavior that ⟨Ĥ⟩ specifies to embedded_H for these same N
steps because they are the exact same N steps that would be simulated if
embedded_H was a pure UTM.

> It is in thinking that the behavior being decided
> must come out of H's simulation, which CAN'T be complete (if it gives an
> answer) instead of the, by definition, behavior of the actual machine,
>
> You are just proving you are too stupid to understand what actually
> matters. You seem to think that H is a UTM even though you have broken
> the UTMness of it, because, you just don't know what a UTM is, in part
> because you have no idea how Turing Machines actually work.
>
>>
>>> When given a non-halting computation as its input, a UTM will run
>>> forever. A simulating halt decider (were such a thing possible) on
>>> the other hand, would reject this input and then HALT. This is
>>> entirely different from what a UTM does.
>>>
>>> You can state that there is a *relationship* between your 'simulating
>>> halt decider' and a UTM in that the SHD uses similar methods as a UTM
>>> to (partially) simulate its input, but that doesn't mean you can
>>> legitimately say an SHD *is* a UTM -- it is not (and of course since
>>> your H and D are not even turing machines, it makes no sense to talk
>>> about UTMs at all).
>>>
>>> André
>>>
>>
>

On 4/11/2023 11:37 PM, olcott wrote:
> On 4/8/2023 7:53 PM, André G. Isaak wrote:
>> On 2023-04-08 17:47, olcott wrote:
>>> On 4/8/2023 6:37 PM, André G. Isaak wrote:
>>>> On 2023-04-08 17:26, olcott wrote:
>>>>> On 4/8/2023 6:09 PM, André G. Isaak wrote:
>>>>>> On 2023-04-08 17:00, olcott wrote:
>>>>>>> On 4/8/2023 4:39 PM, André G. Isaak wrote:
>>>>>>>> On 2023-04-08 15:14, olcott wrote:
>>>>>>>>> On 4/8/2023 3:43 PM, olcott wrote:
>>>>>>>>>> On 4/8/2023 3:22 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2023-04-08 14:10, Ben Bacarisse wrote:
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/23 8:37 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> A masters degree in EE is probably not nearly as much CS
>>>>>>>>>>>>>> as a BSBS in CS.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You think so? Rmmember, my Masters was in Electrical
>>>>>>>>>>>>> Engineering and
>>>>>>>>>>>>> Computer Science, so I did get a lot of CS material too.
>>>>>>>>>>>>
>>>>>>>>>>>> Is PO saying he has a double BS degree?  You couldn't make
>>>>>>>>>>>> it up!
>>>>>>>>>>>
>>>>>>>>>>> I think he means BS in Bullshit.
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>>> 02 {
>>>>>>>>>> 03  int Halt_Status = H(x, x);
>>>>>>>>>> 04  if (Halt_Status)
>>>>>>>>>> 05    HERE: goto HERE;
>>>>>>>>>> 06  return Halt_Status;
>>>>>>>>>> 07 }
>>>>>>>>>> 08
>>>>>>>>>> 09 void main()
>>>>>>>>>> 10 {
>>>>>>>>>> 11  H(D,D);
>>>>>>>>>> 12 }
>>>>>>>>>>
>>>>>>>>>> Every halt decider must report on the actual behavior of its
>>>>>>>>>> actual
>>>>>>>>>> input. The notion of a UTM establishes that H is correct to
>>>>>>>>>> base its
>>>>>>>>>> halt status decision on a finite number of steps of D correctly
>>>>>>>>>> simulated by H.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The notion of a UTM guarantees that when N steps of D are
>>>>>>>>> correctly
>>>>>>>>> simulated by H that this <is> the actual behavior that D
>>>>>>>>> specifies to H.
>>>>>>>>
>>>>>>>> The notion of a UTM is entirely irrelevant since your H and D
>>>>>>>> aren't formulated in terms of Turing Machines in the first
>>>>>>>> place. No where does your code involve a TM, let alone a UTM.
>>>>>>>>
>>>>>>>> The notion of a UTM is simply that it is possible to construct a
>>>>>>>> single TM which can mimic the behaviour of all other TMs. It
>>>>>>>> says nothing whatsoever about making *decisions* about the
>>>>>>>> properties of those TMs.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It says more than that. It says that the correct simulation of a
>>>>>>> machine
>>>>>>> description does provide the underlying behavior specified by this
>>>>>>> machine description.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> When embedded_H is a simulating halt decider and
>>>>>>>
>>>>>>> Ĥ is applied to ⟨Ĥ⟩
>>>>>>> (q0) The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>> embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>> which simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ which begins at its own (q0)
>>>>>>> to repeat the process. (never reaching the simulated ⟨Ĥ.qn⟩ and
>>>>>>> halting).
>>>>>>
>>>>>> Since there is no mention of a UTM anywhere in the above, how can
>>>>>> you claim that the 'notion of a UTM' makes any claims whatsoever
>>>>>> about the above?!?
>>>>>>
>>>>>>> The notion of a UTM guarantees that when N steps of ⟨Ĥ⟩ are
>>>>>>> correctly
>>>>>>> simulated by embedded_H that this <is> the actual behavior that ⟨Ĥ⟩
>>>>>>> specifies to embedded_H.
>>>>>>
>>>>>> Non sequitur. embedded_H is not a UTM.
>>>>>
>>>>> That it is more than a UTM does not negate its UTM properties.
>>>>
>>>> It is not a UTM at all.
>>>>
>>>
>>> A simulating halt decider starts with a UTM and then augments it with
>>> additional features.
>>
>> It doesn't "augment" it. It *changes* it.
>
> That is counter-factual. When a simulating halt decider correctly
> simulates N steps of its input it derives the exact same N steps that a
> pure UTM would derive because it is itself a UTM with extra features.
>
> My reviewers cannot show that any of the extra features added to the UTM
> change the behavior of the simulated input for the first N steps of
> simulation.
>
> Watching the behavior doesn't change it.
> Matching non-halting behavior patterns doesn't change it.
> Even aborting the simulation doesn't change the first N simulated steps.
>
> Because of all this we can know that the first N steps of ⟨Ĥ⟩ simulated
> by embedded_H are the actual behavior that ⟨Ĥ⟩ presents to embedded_H
> for these same N steps.
>

*The above has been agreed to*
I didn't think that agreement was possible, it turns out that I simply
had not presented my case clearly enough.

*computation that halts*… “the Turing machine will halt whenever it
enters a final state” (Linz:1990:234)

When we can see that ⟨Ĥ⟩ correctly simulated by embedded_H cannot
possibly reach its simulated final state of ⟨Ĥ.qn⟩ in any finite number
of steps of correct simulation then we have conclusive proof that ⟨Ĥ⟩
presents non-halting behavior to embedded_H.

>> When given a non-halting computation as its input, a UTM will run
>> forever. A simulating halt decider (were such a thing possible) on the
>> other hand, would reject this input and then HALT. This is entirely
>> different from what a UTM does.
>>
>> You can state that there is a *relationship* between your 'simulating
>> halt decider' and a UTM in that the SHD uses similar methods as a UTM
>> to (partially) simulate its input, but that doesn't mean you can
>> legitimately say an SHD *is* a UTM -- it is not (and of course since
>> your H and D are not even turing machines, it makes no sense to talk
>> about UTMs at all).
>>
>> André
>>
>

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

On 4/12/23 8:17 AM, Graham Cooper wrote:
> On Wednesday, April 12, 2023 at 10:13:37 PM UTC+10, Graham Cooper wrote:
>> On Wednesday, April 12, 2023 at 9:04:32 PM UTC+10, Richard Damon wrote:
>>>> This correctly fullfills the specification of HALT
>>>> There is no requirement for other functions to call halt
>>>> They CAN but they FAIL
>>>>
>>>>
>>> Nope, the requirment to be able to call a function is built into the
>>> rules of what are computations.
>> you can call MAIN() or HALT()
>>
>> but remember your using an ADJUSTED VERSION OF HALT
>> so HALT doesnt have to return the same value if called from the top level STACK=0
>
>
> REMEMBER the specification of HALT is to OUTPUT 1 or 0 and then TERMINATE
>
> Because you are NOT USING THE SPECIFICATION
> HALT can return a DIFFERENT VALUE
> or INFINITE LOOP as Pete suggests
>

And the "Output" of a computation can be feed into the input of another.
BY DEFINTION.

On 4/12/23 8:13 AM, Graham Cooper wrote:
> On Wednesday, April 12, 2023 at 9:04:32 PM UTC+10, Richard Damon wrote:
>> On 4/12/23 12:20 AM, Graham Cooper wrote:
>>> On Wednesday, April 12, 2023 at 1:05:14 PM UTC+10, Richard Damon wrote:
>>>>> but LINZ still BREAKS THE SPEFICATION OF HALT
>>>>>
>>>>>>>>> 1/ input program ID and input
>>>>>>>>> 2/ write 1 or 0 if program(input) halts or loops
>>>>>>>>> 3/ TERMINATE
>>>>>
>>>>>
>>>>> Whether he CHANGES the FINAL STATE
>>>>> or CONTINUTES after halt in some way
>>>> Which are allowed modifications for composing algorithms from other
>>>> algorithms.
>>>
>>> you can use halt OUT OF SCOPE
>>> but you cant call it halt
>>>
>>>
>>>
>>>
>>>
>>>>>>
>>>>>> If you try to make that part of the tape "Write Only" then you break
>>>>>> your model of computation being Turing Complete (or it is trivial to
>>>>>> just modifiy at the point of the write 1 or write 0)
>>>>>
>>>>>
>>>>> There are models of computation that have READ ONLY
>>>>>
>>>>> including a SUBSET of TMs
>>>> Which is thus not Turing Complete.
>>>>>
>>>>> I agree the FULL SET OF TM's is not halt decidable
>>>>> but that could be considered a weaker model than a COMPUTATIONALLY COMPLETE subset of TMs
>>>>> (that double move the tape pointer LL or RR) and are forced to skip intermediate tape values
>>>>> so they CANNOT write to them
>>>> And it is well known that weaker models are decidable, and many such
>>>> deciders are well known for many such classes, so unless you are
>>>> actually PROVING a new method does succeed for a new class of
>>>> computation that hasn't been known before, an not just showing you can
>>>> defeat the simple proof program that shows that you can't decide for
>>>> Turing Complete system, it isn't very interesting.
>>>
>>>
>>> you ignore all points counter to your argument
>>>
>>> you can prove/disprove halt in ANY model of computation you choose
>> Nope, not in Turing Complete, or Turing Machines in particular.
>
> you dont seem to understand the point you refuted

Nope. You don't seem to understand the defintion of a "Computation".

A Computaiton, BY DEFINITION, is only a function of its defined inputs.

A model of computation, BY DEFINITION, to be "Turing Complete" must
allow embeding of one computation within another and have it return that
answer to the surrounding compuation.

All you have done is show that you can create lessor models of
computations that are not Turing Complete.

>
>
>
>
>>>
>>> since computer languages exist with READ ONLY
>>> computation models exist with READ ONLY
>> But if it is actually "Read Only" NOTHING can set it.
>
>
> it is AUTOMATICALLY set by the computing paradigm
>
> or MAIN() can set it if just logging whether STACK=0 or STACK=1

And genereates either "programs" that do not represent actual
computations or a computaiton model weaker than a Turing Machine.

In fact, just the requirement of "Main" tends to cause that sort of problem.

>
>
>
>
>>>
>>>
>>> d(D)
>>> if halt(D D) then
>>> L: GOTO L
>>>
>>>
>>> halt( PROG INP )
>>> if STACK>0 then
>> And now halt is no longer "A Computation", so not a halt decicer.
>>> L: GOTO L
>>> else
>>> ...
>>> ... REST OF HALT FUNCTION
>>> ...
>>>
>> And remenber, the program D is defined not to "Call" Halt, but to be
>> built with a COPY of Halt, (And replacing a call with an inline copy is
>
> only in some computation models

It is doable in ANY model that is Turing Complete.

Some don't "need" to do that, but it is always ALLOWED.

>
>
>
>
>
>> ALWAYS a valid operation), you can just replace the call to halt(D,D)
>> with a copy of halt that omits the surperfoluos stack check.
>
>
> but HALT does the stack check
>
> the computation model itself ensures every function call increases STACK
>
> this is SIMPLE in most computer languages

So you are just proving your system isn't Turing Complete, and doesn't
make actual Computations.

Fine, that makes it WORTHLESS for the Halting Problem of Computability
Theory that REQUIRES programs in a fully Turing Complete environment.
>
>
>
>
>
>>>
>>> This correctly fullfills the specification of HALT
>>> There is no requirement for other functions to call halt
>>> They CAN but they FAIL
>>>
>>>
>> Nope, the requirment to be able to call a function is built into the
>> rules of what are computations.
>
>
> you can call MAIN() or HALT()
>
> but remember your using an ADJUSTED VERSION OF HALT
> so HALT doesnt have to return the same value if called from the top level STACK=0

Yes it does, if you copies the identical algorithm.

Algorithms produced defined results for defined inputs.

>
>
>
>>
>> Thus, your programming model, allowing non-callable functions isn't
>> Turing Complete anymore.
>
>
> The halt program (if / when it exists) wont be written in a TM.
> It will be written in a standard computer language
> which is TM compatible

Which, if it is a computation, can only be a function of the description
of the machine and input, and not something extra like the "stack depth"
or it is BY DEFINITION incorrect.

>
>
> It is COMPUTABLE to detect if a program is run from the top level STACK=0
>
>
>

Nope. not if "STACK" isn't a defined input to the program.

HALT isn't defined as a function of stack depth, so if the program is,
it is BY DEFINTION incorrect.

On 4/12/23 10:04 AM, olcott wrote:
> On 4/11/2023 11:37 PM, olcott wrote:
>> On 4/8/2023 7:53 PM, André G. Isaak wrote:
>>> On 2023-04-08 17:47, olcott wrote:
>>>> On 4/8/2023 6:37 PM, André G. Isaak wrote:
>>>>> On 2023-04-08 17:26, olcott wrote:
>>>>>> On 4/8/2023 6:09 PM, André G. Isaak wrote:
>>>>>>> On 2023-04-08 17:00, olcott wrote:
>>>>>>>> On 4/8/2023 4:39 PM, André G. Isaak wrote:
>>>>>>>>> On 2023-04-08 15:14, olcott wrote:
>>>>>>>>>> On 4/8/2023 3:43 PM, olcott wrote:
>>>>>>>>>>> On 4/8/2023 3:22 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2023-04-08 14:10, Ben Bacarisse wrote:
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/7/23 8:37 PM, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A masters degree in EE is probably not nearly as much CS
>>>>>>>>>>>>>>> as a BSBS in CS.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You think so? Rmmember, my Masters was in Electrical
>>>>>>>>>>>>>> Engineering and
>>>>>>>>>>>>>> Computer Science, so I did get a lot of CS material too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is PO saying he has a double BS degree?  You couldn't make
>>>>>>>>>>>>> it up!
>>>>>>>>>>>>
>>>>>>>>>>>> I think he means BS in Bullshit.
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>>>> 02 {
>>>>>>>>>>> 03  int Halt_Status = H(x, x);
>>>>>>>>>>> 04  if (Halt_Status)
>>>>>>>>>>> 05    HERE: goto HERE;
>>>>>>>>>>> 06  return Halt_Status;
>>>>>>>>>>> 07 }
>>>>>>>>>>> 08
>>>>>>>>>>> 09 void main()
>>>>>>>>>>> 10 {
>>>>>>>>>>> 11  H(D,D);
>>>>>>>>>>> 12 }
>>>>>>>>>>>
>>>>>>>>>>> Every halt decider must report on the actual behavior of its
>>>>>>>>>>> actual
>>>>>>>>>>> input. The notion of a UTM establishes that H is correct to
>>>>>>>>>>> base its
>>>>>>>>>>> halt status decision on a finite number of steps of D correctly
>>>>>>>>>>> simulated by H.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The notion of a UTM guarantees that when N steps of D are
>>>>>>>>>> correctly
>>>>>>>>>> simulated by H that this <is> the actual behavior that D
>>>>>>>>>> specifies to H.
>>>>>>>>>
>>>>>>>>> The notion of a UTM is entirely irrelevant since your H and D
>>>>>>>>> aren't formulated in terms of Turing Machines in the first
>>>>>>>>> place. No where does your code involve a TM, let alone a UTM.
>>>>>>>>>
>>>>>>>>> The notion of a UTM is simply that it is possible to construct
>>>>>>>>> a single TM which can mimic the behaviour of all other TMs. It
>>>>>>>>> says nothing whatsoever about making *decisions* about the
>>>>>>>>> properties of those TMs.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It says more than that. It says that the correct simulation of a
>>>>>>>> machine
>>>>>>>> description does provide the underlying behavior specified by this
>>>>>>>> machine description.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> When embedded_H is a simulating halt decider and
>>>>>>>>
>>>>>>>> Ĥ is applied to ⟨Ĥ⟩
>>>>>>>> (q0) The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>>> embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>>> which simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ which begins at its own (q0)
>>>>>>>> to repeat the process. (never reaching the simulated ⟨Ĥ.qn⟩ and
>>>>>>>> halting).
>>>>>>>
>>>>>>> Since there is no mention of a UTM anywhere in the above, how can
>>>>>>> you claim that the 'notion of a UTM' makes any claims whatsoever
>>>>>>> about the above?!?
>>>>>>>
>>>>>>>> The notion of a UTM guarantees that when N steps of ⟨Ĥ⟩ are
>>>>>>>> correctly
>>>>>>>> simulated by embedded_H that this <is> the actual behavior that ⟨Ĥ⟩
>>>>>>>> specifies to embedded_H.
>>>>>>>
>>>>>>> Non sequitur. embedded_H is not a UTM.
>>>>>>
>>>>>> That it is more than a UTM does not negate its UTM properties.
>>>>>
>>>>> It is not a UTM at all.
>>>>>
>>>>
>>>> A simulating halt decider starts with a UTM and then augments it with
>>>> additional features.
>>>
>>> It doesn't "augment" it. It *changes* it.
>>
>> That is counter-factual. When a simulating halt decider correctly
>> simulates N steps of its input it derives the exact same N steps that a
>> pure UTM would derive because it is itself a UTM with extra features.
>>
>> My reviewers cannot show that any of the extra features added to the UTM
>> change the behavior of the simulated input for the first N steps of
>> simulation.
>>
>> Watching the behavior doesn't change it.
>> Matching non-halting behavior patterns doesn't change it.
>> Even aborting the simulation doesn't change the first N simulated steps.
>>
>> Because of all this we can know that the first N steps of ⟨Ĥ⟩ simulated
>> by embedded_H are the actual behavior that ⟨Ĥ⟩ presents to embedded_H
>> for these same N steps.
>>
>
> *The above has been agreed to*
> I didn't think that agreement was possible, it turns out that I simply
> had not presented my case clearly enough.

But it is irrelevent, as the answer is based on tha ACTUAL behavior of
the input, or a COMPLETE simulation of the input, not the "partial"
simualtion done by H.

>
> *computation that halts*… “the Turing machine will halt whenever it
> enters a final state” (Linz:1990:234)

And D(D) Halts, so the correct answer to H(D,D) is Halting.

PERIOD.

>
> When we can see that ⟨Ĥ⟩ correctly simulated by embedded_H cannot
> possibly reach its simulated final state of ⟨Ĥ.qn⟩ in any finite number
> of steps of correct simulation then we have conclusive proof that ⟨Ĥ⟩
> presents non-halting behavior to embedded_H.

Which doesn't matter, because the question isn't about what H can do in
its simulation but what the actual machine does.

You are just admitting you aren't working on the Halting Problem but
your POOP.

>

On Thursday, April 13, 2023 at 8:48:32 AM UTC+10, Richard Damon wrote:
>
> All you have done is show that you can create lessor models of
> computations that are not Turing Complete.
> >

Lets call d(D) a uselessTM that adds no functionality to the set of TMs

By ADDING READ-ONLY functionality to a computation model
You can only INCREASE the computing power!

Now you can put d(D) into an infinite loop - eliminating the uselessTM
and ADD MORE FUNCTIONS hence the level of computability INCREASES

************

You seem confused that if its READ/ONLY it has LESS POWER
but it REMOVES useless TMs making way for MORE POWERFUL TMs

Its not READ-ONLY its

computation model 1 - read/write
computation model 2 - read/write + read only

so computation model 2 is MORE POWERFUL

On 4/12/23 7:22 PM, Graham Cooper wrote:
> On Thursday, April 13, 2023 at 8:48:32 AM UTC+10, Richard Damon wrote:
>>
>> All you have done is show that you can create lessor models of
>> computations that are not Turing Complete.
>>>
>
> Lets call d(D) a uselessTM that adds no functionality to the set of TMs
>
> By ADDING READ-ONLY functionality to a computation model
> You can only INCREASE the computing power!

How does a resource that can't be controlled ADD power.

Note, you clearly don't understand what a COMPUTATION is (per
Computability Theory).

>
> Now you can put d(D) into an infinite loop - eliminating the uselessTM
> and ADD MORE FUNCTIONS hence the level of computability INCREASES

Nope, it might allow you to write more programs that are NOT
"Computations", but doesn't give you any more power to make an actual
COMPUTATION.

What INPUT-OUTPUT map can you compute with your added feature that
couldn't be computed before.

Remember, and program that uses your new "Read Only Stack" to affect its
behavior has that stack added to its list of input, and thus the version
that allows that parameter to be Read/Write could have set it to what
ever value was desired.
>
>
> ************
>
> You seem confused that if its READ/ONLY it has LESS POWER
> but it REMOVES useless TMs making way for MORE POWERFUL TMs
>
> Its not READ-ONLY its
>
> computation model 1 - read/write
> computation model 2 - read/write + read only

Nope, if it is an INPUT to the computation, then it is

model 1: Read/Write + Read/Write
Model 2: Read/WRite + Read Only

Why was model 1 not allowed to pass that value to its version of the
function?

>
> so computation model 2 is MORE POWERFUL
>

Nope, if the caller can't set the paramaete in model 1, your model 2
isn't a model of computtion, as it doesn't represent a definite mapping
of its inputs to its outputs.

You are just showing you are as stupid as Olcott in you lack of
understand of what is being talked about.

On Thursday, April 13, 2023 at 10:01:03 AM UTC+10, Richard Damon wrote:
> On 4/12/23 7:22 PM, Graham Cooper wrote:
> > On Thursday, April 13, 2023 at 8:48:32 AM UTC+10, Richard Damon wrote:
> >>
> >> All you have done is show that you can create lessor models of
> >> computations that are not Turing Complete.
> >>>
> >
> > Lets call d(D) a uselessTM that adds no functionality to the set of TMs
> >
> > By ADDING READ-ONLY functionality to a computation model
> > You can only INCREASE the computing power!
> How does a resource that can't be controlled ADD power.

SOME functions can write to the read-only variable and some cant

So some functions have PRIORITY over others

This is do-able in computer languages so its do-able in TMs

There are INF versions of any TM that do the same computations

eg there are INF amount of TMs that compute X+X

So you can take a SUBSET of all TMs
which has TM-equivalent computability

You dont require ALL TMs

So you can take a SUBSET with a specific property
such as adding READ-ONLY

On 4/12/23 8:51 PM, Graham Cooper wrote:
> On Thursday, April 13, 2023 at 10:01:03 AM UTC+10, Richard Damon wrote:
>> On 4/12/23 7:22 PM, Graham Cooper wrote:
>>> On Thursday, April 13, 2023 at 8:48:32 AM UTC+10, Richard Damon wrote:
>>>>
>>>> All you have done is show that you can create lessor models of
>>>> computations that are not Turing Complete.
>>>>>
>>>
>>> Lets call d(D) a uselessTM that adds no functionality to the set of TMs
>>>
>>> By ADDING READ-ONLY functionality to a computation model
>>> You can only INCREASE the computing power!
>> How does a resource that can't be controlled ADD power.
>
>
> SOME functions can write to the read-only variable and some cant

And what decides that?

Why can't P, the "impossible" program write to that variable,?

>
> So some functions have PRIORITY over others

And what decides that?

Sounds like a non-computability based model, so worthless of
computabilty theory?

>
> This is do-able in computer languages so its do-able in TMs

Nope, because programs that can do that don't represent COMPUTATIONS,
machines that are a STRCT mapping of input to output.

>
> There are INF versions of any TM that do the same computations
>
> eg there are INF amount of TMs that compute X+X

So, if it can be done by a TM, then we can build the "impossible
program" from that TM and show that it give the wrong answer.

>
> So you can take a SUBSET of all TMs
> which has TM-equivalent computability
>
> You dont require ALL TMs

Nope, the decider must be able to take in ALL TMs, or it fails to meet
the requirements.

>
> So you can take a SUBSET with a specific property
> such as adding READ-ONLY
>

Nope, that VIOLATES the requirement.

Either that subset IS Turing Complete, at which point your decider in
that subset, can be converted to a machine that doesn't need that
special property or your subset isn't Turing Complete, at which point it
doens't meet the requirements.

On 4/12/2023 5:51 PM, Richard Damon wrote:
> On 4/12/23 10:04 AM, olcott wrote:
>> On 4/11/2023 11:37 PM, olcott wrote:
>>> On 4/8/2023 7:53 PM, André G. Isaak wrote:
>>>> On 2023-04-08 17:47, olcott wrote:
>>>>> On 4/8/2023 6:37 PM, André G. Isaak wrote:
>>>>>> On 2023-04-08 17:26, olcott wrote:
>>>>>>> On 4/8/2023 6:09 PM, André G. Isaak wrote:
>>>>>>>> On 2023-04-08 17:00, olcott wrote:
>>>>>>>>> On 4/8/2023 4:39 PM, André G. Isaak wrote:
>>>>>>>>>> On 2023-04-08 15:14, olcott wrote:
>>>>>>>>>>> On 4/8/2023 3:43 PM, olcott wrote:
>>>>>>>>>>>> On 4/8/2023 3:22 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2023-04-08 14:10, Ben Bacarisse wrote:
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/7/23 8:37 PM, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A masters degree in EE is probably not nearly as much CS
>>>>>>>>>>>>>>>> as a BSBS in CS.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You think so? Rmmember, my Masters was in Electrical
>>>>>>>>>>>>>>> Engineering and
>>>>>>>>>>>>>>> Computer Science, so I did get a lot of CS material too.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is PO saying he has a double BS degree?  You couldn't make
>>>>>>>>>>>>>> it up!
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think he means BS in Bullshit.
>>>>>>>>>>>>>
>>>>>>>>>>>>> André
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>>>>> 02 {
>>>>>>>>>>>> 03  int Halt_Status = H(x, x);
>>>>>>>>>>>> 04  if (Halt_Status)
>>>>>>>>>>>> 05    HERE: goto HERE;
>>>>>>>>>>>> 06  return Halt_Status;
>>>>>>>>>>>> 07 }
>>>>>>>>>>>> 08
>>>>>>>>>>>> 09 void main()
>>>>>>>>>>>> 10 {
>>>>>>>>>>>> 11  H(D,D);
>>>>>>>>>>>> 12 }
>>>>>>>>>>>>
>>>>>>>>>>>> Every halt decider must report on the actual behavior of its
>>>>>>>>>>>> actual
>>>>>>>>>>>> input. The notion of a UTM establishes that H is correct to
>>>>>>>>>>>> base its
>>>>>>>>>>>> halt status decision on a finite number of steps of D correctly
>>>>>>>>>>>> simulated by H.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The notion of a UTM guarantees that when N steps of D are
>>>>>>>>>>> correctly
>>>>>>>>>>> simulated by H that this <is> the actual behavior that D
>>>>>>>>>>> specifies to H.
>>>>>>>>>>
>>>>>>>>>> The notion of a UTM is entirely irrelevant since your H and D
>>>>>>>>>> aren't formulated in terms of Turing Machines in the first
>>>>>>>>>> place. No where does your code involve a TM, let alone a UTM.
>>>>>>>>>>
>>>>>>>>>> The notion of a UTM is simply that it is possible to construct
>>>>>>>>>> a single TM which can mimic the behaviour of all other TMs. It
>>>>>>>>>> says nothing whatsoever about making *decisions* about the
>>>>>>>>>> properties of those TMs.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It says more than that. It says that the correct simulation of
>>>>>>>>> a machine
>>>>>>>>> description does provide the underlying behavior specified by this
>>>>>>>>> machine description.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> When embedded_H is a simulating halt decider and
>>>>>>>>>
>>>>>>>>> Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>> (q0) The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>>>> embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>>>> which simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ which begins at its own (q0)
>>>>>>>>> to repeat the process. (never reaching the simulated ⟨Ĥ.qn⟩ and
>>>>>>>>> halting).
>>>>>>>>
>>>>>>>> Since there is no mention of a UTM anywhere in the above, how
>>>>>>>> can you claim that the 'notion of a UTM' makes any claims
>>>>>>>> whatsoever about the above?!?
>>>>>>>>
>>>>>>>>> The notion of a UTM guarantees that when N steps of ⟨Ĥ⟩ are
>>>>>>>>> correctly
>>>>>>>>> simulated by embedded_H that this <is> the actual behavior that
>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>> specifies to embedded_H.
>>>>>>>>
>>>>>>>> Non sequitur. embedded_H is not a UTM.
>>>>>>>
>>>>>>> That it is more than a UTM does not negate its UTM properties.
>>>>>>
>>>>>> It is not a UTM at all.
>>>>>>
>>>>>
>>>>> A simulating halt decider starts with a UTM and then augments it with
>>>>> additional features.
>>>>
>>>> It doesn't "augment" it. It *changes* it.
>>>
>>> That is counter-factual. When a simulating halt decider correctly
>>> simulates N steps of its input it derives the exact same N steps that a
>>> pure UTM would derive because it is itself a UTM with extra features.
>>>
>>> My reviewers cannot show that any of the extra features added to the UTM
>>> change the behavior of the simulated input for the first N steps of
>>> simulation.
>>>
>>> Watching the behavior doesn't change it.
>>> Matching non-halting behavior patterns doesn't change it.
>>> Even aborting the simulation doesn't change the first N simulated steps.
>>>
>>> Because of all this we can know that the first N steps of ⟨Ĥ⟩ simulated
>>> by embedded_H are the actual behavior that ⟨Ĥ⟩ presents to embedded_H
>>> for these same N steps.
>>>
>>
>> *The above has been agreed to*
>> I didn't think that agreement was possible, it turns out that I simply
>> had not presented my case clearly enough.
>
> But it is irrelevent, as the answer is based on tha ACTUAL behavior of
> the input,

You agreed that The N steps of ⟨Ĥ⟩ that are correctly simulated by
embedded_H are the actual behavior of these N steps.

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

On 4/12/23 9:48 PM, olcott wrote:
> On 4/12/2023 5:51 PM, Richard Damon wrote:
>> On 4/12/23 10:04 AM, olcott wrote:
>>> On 4/11/2023 11:37 PM, olcott wrote:
>>>> On 4/8/2023 7:53 PM, André G. Isaak wrote:
>>>>> On 2023-04-08 17:47, olcott wrote:
>>>>>> On 4/8/2023 6:37 PM, André G. Isaak wrote:
>>>>>>> On 2023-04-08 17:26, olcott wrote:
>>>>>>>> On 4/8/2023 6:09 PM, André G. Isaak wrote:
>>>>>>>>> On 2023-04-08 17:00, olcott wrote:
>>>>>>>>>> On 4/8/2023 4:39 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2023-04-08 15:14, olcott wrote:
>>>>>>>>>>>> On 4/8/2023 3:43 PM, olcott wrote:
>>>>>>>>>>>>> On 4/8/2023 3:22 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2023-04-08 14:10, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/7/23 8:37 PM, olcott wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A masters degree in EE is probably not nearly as much
>>>>>>>>>>>>>>>>> CS as a BSBS in CS.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You think so? Rmmember, my Masters was in Electrical
>>>>>>>>>>>>>>>> Engineering and
>>>>>>>>>>>>>>>> Computer Science, so I did get a lot of CS material too.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is PO saying he has a double BS degree?  You couldn't
>>>>>>>>>>>>>>> make it up!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think he means BS in Bullshit.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>> 03  int Halt_Status = H(x, x);
>>>>>>>>>>>>> 04  if (Halt_Status)
>>>>>>>>>>>>> 05    HERE: goto HERE;
>>>>>>>>>>>>> 06  return Halt_Status;
>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>> 08
>>>>>>>>>>>>> 09 void main()
>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>> 11  H(D,D);
>>>>>>>>>>>>> 12 }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every halt decider must report on the actual behavior of
>>>>>>>>>>>>> its actual
>>>>>>>>>>>>> input. The notion of a UTM establishes that H is correct to
>>>>>>>>>>>>> base its
>>>>>>>>>>>>> halt status decision on a finite number of steps of D
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated by H.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The notion of a UTM guarantees that when N steps of D are
>>>>>>>>>>>> correctly
>>>>>>>>>>>> simulated by H that this <is> the actual behavior that D
>>>>>>>>>>>> specifies to H.
>>>>>>>>>>>
>>>>>>>>>>> The notion of a UTM is entirely irrelevant since your H and D
>>>>>>>>>>> aren't formulated in terms of Turing Machines in the first
>>>>>>>>>>> place. No where does your code involve a TM, let alone a UTM.
>>>>>>>>>>>
>>>>>>>>>>> The notion of a UTM is simply that it is possible to
>>>>>>>>>>> construct a single TM which can mimic the behaviour of all
>>>>>>>>>>> other TMs. It says nothing whatsoever about making
>>>>>>>>>>> *decisions* about the properties of those TMs.
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It says more than that. It says that the correct simulation of
>>>>>>>>>> a machine
>>>>>>>>>> description does provide the underlying behavior specified by
>>>>>>>>>> this
>>>>>>>>>> machine description.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> When embedded_H is a simulating halt decider and
>>>>>>>>>>
>>>>>>>>>> Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>> (q0) The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>>>>> embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>>>>> which simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ which begins at its own
>>>>>>>>>> (q0) to repeat the process. (never reaching the simulated
>>>>>>>>>> ⟨Ĥ.qn⟩ and halting).
>>>>>>>>>
>>>>>>>>> Since there is no mention of a UTM anywhere in the above, how
>>>>>>>>> can you claim that the 'notion of a UTM' makes any claims
>>>>>>>>> whatsoever about the above?!?
>>>>>>>>>
>>>>>>>>>> The notion of a UTM guarantees that when N steps of ⟨Ĥ⟩ are
>>>>>>>>>> correctly
>>>>>>>>>> simulated by embedded_H that this <is> the actual behavior
>>>>>>>>>> that ⟨Ĥ⟩
>>>>>>>>>> specifies to embedded_H.
>>>>>>>>>
>>>>>>>>> Non sequitur. embedded_H is not a UTM.
>>>>>>>>
>>>>>>>> That it is more than a UTM does not negate its UTM properties.
>>>>>>>
>>>>>>> It is not a UTM at all.
>>>>>>>
>>>>>>
>>>>>> A simulating halt decider starts with a UTM and then augments it with
>>>>>> additional features.
>>>>>
>>>>> It doesn't "augment" it. It *changes* it.
>>>>
>>>> That is counter-factual. When a simulating halt decider correctly
>>>> simulates N steps of its input it derives the exact same N steps that a
>>>> pure UTM would derive because it is itself a UTM with extra features.
>>>>
>>>> My reviewers cannot show that any of the extra features added to the
>>>> UTM
>>>> change the behavior of the simulated input for the first N steps of
>>>> simulation.
>>>>
>>>> Watching the behavior doesn't change it.
>>>> Matching non-halting behavior patterns doesn't change it.
>>>> Even aborting the simulation doesn't change the first N simulated
>>>> steps.
>>>>
>>>> Because of all this we can know that the first N steps of ⟨Ĥ⟩ simulated
>>>> by embedded_H are the actual behavior that ⟨Ĥ⟩ presents to
>>>> embedded_H for these same N steps.
>>>>
>>>
>>> *The above has been agreed to*
>>> I didn't think that agreement was possible, it turns out that I simply
>>> had not presented my case clearly enough.
>>
>> But it is irrelevent, as the answer is based on tha ACTUAL behavior of
>> the input,
>
> You agreed that The N steps of ⟨Ĥ⟩ that are correctly simulated by
> embedded_H are the actual behavior of these N steps.
>
>

On 4/12/2023 9:09 PM, Richard Damon wrote:
> On 4/12/23 9:48 PM, olcott wrote:
>> On 4/12/2023 5:51 PM, Richard Damon wrote:
>>> On 4/12/23 10:04 AM, olcott wrote:
>>>> On 4/11/2023 11:37 PM, olcott wrote:
>>>>> On 4/8/2023 7:53 PM, André G. Isaak wrote:
>>>>>> On 2023-04-08 17:47, olcott wrote:
>>>>>>> On 4/8/2023 6:37 PM, André G. Isaak wrote:
>>>>>>>> On 2023-04-08 17:26, olcott wrote:
>>>>>>>>> On 4/8/2023 6:09 PM, André G. Isaak wrote:
>>>>>>>>>> On 2023-04-08 17:00, olcott wrote:
>>>>>>>>>>> On 4/8/2023 4:39 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2023-04-08 15:14, olcott wrote:
>>>>>>>>>>>>> On 4/8/2023 3:43 PM, olcott wrote:
>>>>>>>>>>>>>> On 4/8/2023 3:22 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2023-04-08 14:10, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/7/23 8:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A masters degree in EE is probably not nearly as much
>>>>>>>>>>>>>>>>>> CS as a BSBS in CS.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You think so? Rmmember, my Masters was in Electrical
>>>>>>>>>>>>>>>>> Engineering and
>>>>>>>>>>>>>>>>> Computer Science, so I did get a lot of CS material too.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is PO saying he has a double BS degree?  You couldn't
>>>>>>>>>>>>>>>> make it up!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think he means BS in Bullshit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>> 03  int Halt_Status = H(x, x);
>>>>>>>>>>>>>> 04  if (Halt_Status)
>>>>>>>>>>>>>> 05    HERE: goto HERE;
>>>>>>>>>>>>>> 06  return Halt_Status;
>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>> 09 void main()
>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>> 11  H(D,D);
>>>>>>>>>>>>>> 12 }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every halt decider must report on the actual behavior of
>>>>>>>>>>>>>> its actual
>>>>>>>>>>>>>> input. The notion of a UTM establishes that H is correct
>>>>>>>>>>>>>> to base its
>>>>>>>>>>>>>> halt status decision on a finite number of steps of D
>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>> simulated by H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The notion of a UTM guarantees that when N steps of D are
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated by H that this <is> the actual behavior that D
>>>>>>>>>>>>> specifies to H.
>>>>>>>>>>>>
>>>>>>>>>>>> The notion of a UTM is entirely irrelevant since your H and
>>>>>>>>>>>> D aren't formulated in terms of Turing Machines in the first
>>>>>>>>>>>> place. No where does your code involve a TM, let alone a UTM.
>>>>>>>>>>>>
>>>>>>>>>>>> The notion of a UTM is simply that it is possible to
>>>>>>>>>>>> construct a single TM which can mimic the behaviour of all
>>>>>>>>>>>> other TMs. It says nothing whatsoever about making
>>>>>>>>>>>> *decisions* about the properties of those TMs.
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It says more than that. It says that the correct simulation
>>>>>>>>>>> of a machine
>>>>>>>>>>> description does provide the underlying behavior specified by
>>>>>>>>>>> this
>>>>>>>>>>> machine description.
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>
>>>>>>>>>>> When embedded_H is a simulating halt decider and
>>>>>>>>>>>
>>>>>>>>>>> Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>> (q0) The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>>>>>> embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>>>>>> which simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ which begins at its own
>>>>>>>>>>> (q0) to repeat the process. (never reaching the simulated
>>>>>>>>>>> ⟨Ĥ.qn⟩ and halting).
>>>>>>>>>>
>>>>>>>>>> Since there is no mention of a UTM anywhere in the above, how
>>>>>>>>>> can you claim that the 'notion of a UTM' makes any claims
>>>>>>>>>> whatsoever about the above?!?
>>>>>>>>>>
>>>>>>>>>>> The notion of a UTM guarantees that when N steps of ⟨Ĥ⟩ are
>>>>>>>>>>> correctly
>>>>>>>>>>> simulated by embedded_H that this <is> the actual behavior
>>>>>>>>>>> that ⟨Ĥ⟩
>>>>>>>>>>> specifies to embedded_H.
>>>>>>>>>>
>>>>>>>>>> Non sequitur. embedded_H is not a UTM.
>>>>>>>>>
>>>>>>>>> That it is more than a UTM does not negate its UTM properties.
>>>>>>>>
>>>>>>>> It is not a UTM at all.
>>>>>>>>
>>>>>>>
>>>>>>> A simulating halt decider starts with a UTM and then augments it
>>>>>>> with
>>>>>>> additional features.
>>>>>>
>>>>>> It doesn't "augment" it. It *changes* it.
>>>>>
>>>>> That is counter-factual. When a simulating halt decider correctly
>>>>> simulates N steps of its input it derives the exact same N steps
>>>>> that a
>>>>> pure UTM would derive because it is itself a UTM with extra features.
>>>>>
>>>>> My reviewers cannot show that any of the extra features added to
>>>>> the UTM
>>>>> change the behavior of the simulated input for the first N steps of
>>>>> simulation.
>>>>>
>>>>> Watching the behavior doesn't change it.
>>>>> Matching non-halting behavior patterns doesn't change it.
>>>>> Even aborting the simulation doesn't change the first N simulated
>>>>> steps.
>>>>>
>>>>> Because of all this we can know that the first N steps of ⟨Ĥ⟩
>>>>> simulated
>>>>> by embedded_H are the actual behavior that ⟨Ĥ⟩ presents to
>>>>> embedded_H for these same N steps.
>>>>>
>>>>
>>>> *The above has been agreed to*
>>>> I didn't think that agreement was possible, it turns out that I simply
>>>> had not presented my case clearly enough.
>>>
>>> But it is irrelevent, as the answer is based on tha ACTUAL behavior
>>> of the input,
>>
>> You agreed that The N steps of ⟨Ĥ⟩ that are correctly simulated by
>> embedded_H are the actual behavior of these N steps.
>>
>>
>
> Which is IRRELEVENT to the problem,

On 4/12/23 10:14 PM, olcott wrote:
> On 4/12/2023 9:09 PM, Richard Damon wrote:
>> On 4/12/23 9:48 PM, olcott wrote:
>>> On 4/12/2023 5:51 PM, Richard Damon wrote:
>>>> On 4/12/23 10:04 AM, olcott wrote:
>>>>> On 4/11/2023 11:37 PM, olcott wrote:
>>>>>> On 4/8/2023 7:53 PM, André G. Isaak wrote:
>>>>>>> On 2023-04-08 17:47, olcott wrote:
>>>>>>>> On 4/8/2023 6:37 PM, André G. Isaak wrote:
>>>>>>>>> On 2023-04-08 17:26, olcott wrote:
>>>>>>>>>> On 4/8/2023 6:09 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2023-04-08 17:00, olcott wrote:
>>>>>>>>>>>> On 4/8/2023 4:39 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2023-04-08 15:14, olcott wrote:
>>>>>>>>>>>>>> On 4/8/2023 3:43 PM, olcott wrote:
>>>>>>>>>>>>>>> On 4/8/2023 3:22 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2023-04-08 14:10, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 4/7/23 8:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A masters degree in EE is probably not nearly as much
>>>>>>>>>>>>>>>>>>> CS as a BSBS in CS.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You think so? Rmmember, my Masters was in Electrical
>>>>>>>>>>>>>>>>>> Engineering and
>>>>>>>>>>>>>>>>>> Computer Science, so I did get a lot of CS material too.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is PO saying he has a double BS degree?  You couldn't
>>>>>>>>>>>>>>>>> make it up!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think he means BS in Bullshit.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>> 03  int Halt_Status = H(x, x);
>>>>>>>>>>>>>>> 04  if (Halt_Status)
>>>>>>>>>>>>>>> 05    HERE: goto HERE;
>>>>>>>>>>>>>>> 06  return Halt_Status;
>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>> 09 void main()
>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>> 11  H(D,D);
>>>>>>>>>>>>>>> 12 }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every halt decider must report on the actual behavior of
>>>>>>>>>>>>>>> its actual
>>>>>>>>>>>>>>> input. The notion of a UTM establishes that H is correct
>>>>>>>>>>>>>>> to base its
>>>>>>>>>>>>>>> halt status decision on a finite number of steps of D
>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>> simulated by H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The notion of a UTM guarantees that when N steps of D are
>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>> simulated by H that this <is> the actual behavior that D
>>>>>>>>>>>>>> specifies to H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The notion of a UTM is entirely irrelevant since your H and
>>>>>>>>>>>>> D aren't formulated in terms of Turing Machines in the
>>>>>>>>>>>>> first place. No where does your code involve a TM, let
>>>>>>>>>>>>> alone a UTM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The notion of a UTM is simply that it is possible to
>>>>>>>>>>>>> construct a single TM which can mimic the behaviour of all
>>>>>>>>>>>>> other TMs. It says nothing whatsoever about making
>>>>>>>>>>>>> *decisions* about the properties of those TMs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> André
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It says more than that. It says that the correct simulation
>>>>>>>>>>>> of a machine
>>>>>>>>>>>> description does provide the underlying behavior specified
>>>>>>>>>>>> by this
>>>>>>>>>>>> machine description.
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>> When embedded_H is a simulating halt decider and
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>> (q0) The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>>>>>>> embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>>>>>>> which simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ which begins at its own
>>>>>>>>>>>> (q0) to repeat the process. (never reaching the simulated
>>>>>>>>>>>> ⟨Ĥ.qn⟩ and halting).
>>>>>>>>>>>
>>>>>>>>>>> Since there is no mention of a UTM anywhere in the above, how
>>>>>>>>>>> can you claim that the 'notion of a UTM' makes any claims
>>>>>>>>>>> whatsoever about the above?!?
>>>>>>>>>>>
>>>>>>>>>>>> The notion of a UTM guarantees that when N steps of ⟨Ĥ⟩ are
>>>>>>>>>>>> correctly
>>>>>>>>>>>> simulated by embedded_H that this <is> the actual behavior
>>>>>>>>>>>> that ⟨Ĥ⟩
>>>>>>>>>>>> specifies to embedded_H.
>>>>>>>>>>>
>>>>>>>>>>> Non sequitur. embedded_H is not a UTM.
>>>>>>>>>>
>>>>>>>>>> That it is more than a UTM does not negate its UTM properties.
>>>>>>>>>
>>>>>>>>> It is not a UTM at all.
>>>>>>>>>
>>>>>>>>
>>>>>>>> A simulating halt decider starts with a UTM and then augments it
>>>>>>>> with
>>>>>>>> additional features.
>>>>>>>
>>>>>>> It doesn't "augment" it. It *changes* it.
>>>>>>
>>>>>> That is counter-factual. When a simulating halt decider correctly
>>>>>> simulates N steps of its input it derives the exact same N steps
>>>>>> that a
>>>>>> pure UTM would derive because it is itself a UTM with extra features.
>>>>>>
>>>>>> My reviewers cannot show that any of the extra features added to
>>>>>> the UTM
>>>>>> change the behavior of the simulated input for the first N steps of
>>>>>> simulation.
>>>>>>
>>>>>> Watching the behavior doesn't change it.
>>>>>> Matching non-halting behavior patterns doesn't change it.
>>>>>> Even aborting the simulation doesn't change the first N simulated
>>>>>> steps.
>>>>>>
>>>>>> Because of all this we can know that the first N steps of ⟨Ĥ⟩
>>>>>> simulated
>>>>>> by embedded_H are the actual behavior that ⟨Ĥ⟩ presents to
>>>>>> embedded_H for these same N steps.
>>>>>>
>>>>>
>>>>> *The above has been agreed to*
>>>>> I didn't think that agreement was possible, it turns out that I simply
>>>>> had not presented my case clearly enough.
>>>>
>>>> But it is irrelevent, as the answer is based on tha ACTUAL behavior
>>>> of the input,
>>>
>>> You agreed that The N steps of ⟨Ĥ⟩ that are correctly simulated by
>>> embedded_H are the actual behavior of these N steps.
>>>
>>>
>>
>> Which is IRRELEVENT to the problem,
>
> No it is not. Every decider computes the mapping from its input to its
> own accept or reject state on the basis of a semantic or syntactic
> property of this input.
>

On Thursday, April 13, 2023 at 11:01:36 AM UTC+10, Richard Damon wrote:
> > So you can take a SUBSET of all TMs
> > which has TM-equivalent computability
> >
> > You dont require ALL TMs
> Nope, the decider must be able to take in ALL TMs, or it fails to meet
> the requirements.

Nope! Only if you specify

"IM GOING TO WRITE A HALT FUNCTION FOR ALL TMS"

The halt problem is, in any computer language (atleast as powerful as TMs) can you solve all halt values

The halt problem is NOT

In pure functions can you solve all halt values.

> >
> > So you can take a SUBSET with a specific property
> > such as adding READ-ONLY
> >
> Nope, that VIOLATES the requirement.
>
> Either that subset IS Turing Complete, at which point your decider in
> that subset, can be converted to a machine that doesn't need that
> special property or your subset isn't Turing Complete, at which point it
> doens't meet the requirements.

Nope! you cant convert individual functions back to whatever model of computation you choose

On 4/12/23 10:21 PM, Graham Cooper wrote:
> On Thursday, April 13, 2023 at 11:01:36 AM UTC+10, Richard Damon wrote:
>>> So you can take a SUBSET of all TMs
>>> which has TM-equivalent computability
>>>
>>> You dont require ALL TMs
>> Nope, the decider must be able to take in ALL TMs, or it fails to meet
>> the requirements.
>
>
> Nope! Only if you specify
>
> "IM GOING TO WRITE A HALT FUNCTION FOR ALL TMS"
>
> The halt problem is, in any computer language (atleast as powerful as TMs) can you solve all halt values
>
> The halt problem is NOT
>
> In pure functions can you solve all halt values.
>

So, you don't understand the Halt Function of the Halting Problem,
because it IS a pure function defined for ALL possible machine/input
combinations.

Pure function because ALL functions in computability theory are "pure
functions" in the sense that they are always a simple mapping of defined
inputs to outputs, so ONLY a function of their inputs, i.e. what we call
a "pure function".

This function has been proven to NOT be "Computable", because we can not
write a finite algorithm that can compute this function for all possible
machine inputs.

>
>
>
>
>
>
>
>
>>>
>>> So you can take a SUBSET with a specific property
>>> such as adding READ-ONLY
>>>
>> Nope, that VIOLATES the requirement.
>>
>> Either that subset IS Turing Complete, at which point your decider in
>> that subset, can be converted to a machine that doesn't need that
>> special property or your subset isn't Turing Complete, at which point it
>> doens't meet the requirements.
>
>
> Nope! you cant convert individual functions back to whatever model of computation you choose
>

Why not?

If it IS a computation, then it CAN be converted into a Turing Machine.
If it isn't then it doesn't qualify as a decider.

This is a fundamental property.

Unless you can actually PROVE that you can define some actual
computation, computable with your defined system that can NOT be
converted to a Turing Machine (which would likely make you famous), you
are just spouting falsehoods.

On Thursday, April 13, 2023 at 12:37:38 PM UTC+10, Richard Damon wrote:
> On 4/12/23 10:21 PM, Graham Cooper wrote:
> > On Thursday, April 13, 2023 at 11:01:36 AM UTC+10, Richard Damon wrote:
> >>> So you can take a SUBSET of all TMs
> >>> which has TM-equivalent computability
> >>>
> >>> You dont require ALL TMs
> >> Nope, the decider must be able to take in ALL TMs, or it fails to meet
> >> the requirements.
> >
> >
> > Nope! Only if you specify
> >
> > "IM GOING TO WRITE A HALT FUNCTION FOR ALL TMS"
> >
> > The halt problem is, in any computer language (atleast as powerful as TMs) can you solve all halt values
> >
> > The halt problem is NOT
> >
> > In pure functions can you solve all halt values.
> >
> So, you don't understand the Halt Function of the Halting Problem,
> because it IS a pure function defined for ALL possible machine/input
> combinations.

RUBBISH! if you can solve the halt function for non-pure functions
its SOLVED!

>
> Pure function because ALL functions in computability theory are "pure
> functions" in the sense that they are always a simple mapping of defined
> inputs to outputs, so ONLY a function of their inputs, i.e. what we call
> a "pure function".

RUBBISH! you are invoking CHURCH TURING THESIS which is unproven

>
> This function has been proven to NOT be "Computable", because we can not
> write a finite algorithm that can compute this function for all possible
> machine inputs.
> >
> >
> >
> >
> >
> >
> >
> >
> >>>
> >>> So you can take a SUBSET with a specific property
> >>> such as adding READ-ONLY
> >>>
> >> Nope, that VIOLATES the requirement.
> >>
> >> Either that subset IS Turing Complete, at which point your decider in
> >> that subset, can be converted to a machine that doesn't need that
> >> special property or your subset isn't Turing Complete, at which point it
> >> doens't meet the requirements.
> >
> >
> > Nope! you cant convert individual functions back to whatever model of computation you choose
> >
> Why not?
>
> If it IS a computation, then it CAN be converted into a Turing Machine.
> If it isn't then it doesn't qualify as a decider.
>
> This is a fundamental property.
>
> Unless you can actually PROVE that you can define some actual
> computation, computable with your defined system that can NOT be
> converted to a Turing Machine (which would likely make you famous), you
> are just spouting falsehoods.

You limit the computation model to the subset of TMs which DOUBLE MOVE the tape

IE
exclude
[s1] ->01R->[s4]

include
[s1]->01R->[s2]->00R->[s4]
[s1]->01R->[s3]->11R->[s4]

then the TM can only write to every 2nd tape cell

its an EQUIVALENT MODEL OF COMPUTATION to TMs
(actually more powerful than the standard interpretation of TMs)

On 4/12/2023 9:19 PM, Richard Damon wrote:
> On 4/12/23 10:14 PM, olcott wrote:
>> On 4/12/2023 9:09 PM, Richard Damon wrote:
>>> On 4/12/23 9:48 PM, olcott wrote:
>>>> On 4/12/2023 5:51 PM, Richard Damon wrote:
>>>>> On 4/12/23 10:04 AM, olcott wrote:
>>>>>> On 4/11/2023 11:37 PM, olcott wrote:
>>>>>>> On 4/8/2023 7:53 PM, André G. Isaak wrote:
>>>>>>>> On 2023-04-08 17:47, olcott wrote:
>>>>>>>>> On 4/8/2023 6:37 PM, André G. Isaak wrote:
>>>>>>>>>> On 2023-04-08 17:26, olcott wrote:
>>>>>>>>>>> On 4/8/2023 6:09 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2023-04-08 17:00, olcott wrote:
>>>>>>>>>>>>> On 4/8/2023 4:39 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2023-04-08 15:14, olcott wrote:
>>>>>>>>>>>>>>> On 4/8/2023 3:43 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 4/8/2023 3:22 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2023-04-08 14:10, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 4/7/23 8:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A masters degree in EE is probably not nearly as
>>>>>>>>>>>>>>>>>>>> much CS as a BSBS in CS.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You think so? Rmmember, my Masters was in Electrical
>>>>>>>>>>>>>>>>>>> Engineering and
>>>>>>>>>>>>>>>>>>> Computer Science, so I did get a lot of CS material too.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Is PO saying he has a double BS degree?  You couldn't
>>>>>>>>>>>>>>>>>> make it up!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think he means BS in Bullshit.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>>> 03  int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>> 04  if (Halt_Status)
>>>>>>>>>>>>>>>> 05    HERE: goto HERE;
>>>>>>>>>>>>>>>> 06  return Halt_Status;
>>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>>> 09 void main()
>>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>>> 11  H(D,D);
>>>>>>>>>>>>>>>> 12 }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every halt decider must report on the actual behavior of
>>>>>>>>>>>>>>>> its actual
>>>>>>>>>>>>>>>> input. The notion of a UTM establishes that H is correct
>>>>>>>>>>>>>>>> to base its
>>>>>>>>>>>>>>>> halt status decision on a finite number of steps of D
>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>> simulated by H.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The notion of a UTM guarantees that when N steps of D are
>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>> simulated by H that this <is> the actual behavior that D
>>>>>>>>>>>>>>> specifies to H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The notion of a UTM is entirely irrelevant since your H
>>>>>>>>>>>>>> and D aren't formulated in terms of Turing Machines in the
>>>>>>>>>>>>>> first place. No where does your code involve a TM, let
>>>>>>>>>>>>>> alone a UTM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The notion of a UTM is simply that it is possible to
>>>>>>>>>>>>>> construct a single TM which can mimic the behaviour of all
>>>>>>>>>>>>>> other TMs. It says nothing whatsoever about making
>>>>>>>>>>>>>> *decisions* about the properties of those TMs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It says more than that. It says that the correct simulation
>>>>>>>>>>>>> of a machine
>>>>>>>>>>>>> description does provide the underlying behavior specified
>>>>>>>>>>>>> by this
>>>>>>>>>>>>> machine description.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> When embedded_H is a simulating halt decider and
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>> (q0) The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>>>>>>>> embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>>>>>>>> which simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ which begins at its own
>>>>>>>>>>>>> (q0) to repeat the process. (never reaching the simulated
>>>>>>>>>>>>> ⟨Ĥ.qn⟩ and halting).
>>>>>>>>>>>>
>>>>>>>>>>>> Since there is no mention of a UTM anywhere in the above,
>>>>>>>>>>>> how can you claim that the 'notion of a UTM' makes any
>>>>>>>>>>>> claims whatsoever about the above?!?
>>>>>>>>>>>>
>>>>>>>>>>>>> The notion of a UTM guarantees that when N steps of ⟨Ĥ⟩ are
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated by embedded_H that this <is> the actual behavior
>>>>>>>>>>>>> that ⟨Ĥ⟩
>>>>>>>>>>>>> specifies to embedded_H.
>>>>>>>>>>>>
>>>>>>>>>>>> Non sequitur. embedded_H is not a UTM.
>>>>>>>>>>>
>>>>>>>>>>> That it is more than a UTM does not negate its UTM properties.
>>>>>>>>>>
>>>>>>>>>> It is not a UTM at all.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A simulating halt decider starts with a UTM and then augments
>>>>>>>>> it with
>>>>>>>>> additional features.
>>>>>>>>
>>>>>>>> It doesn't "augment" it. It *changes* it.
>>>>>>>
>>>>>>> That is counter-factual. When a simulating halt decider correctly
>>>>>>> simulates N steps of its input it derives the exact same N steps
>>>>>>> that a
>>>>>>> pure UTM would derive because it is itself a UTM with extra
>>>>>>> features.
>>>>>>>
>>>>>>> My reviewers cannot show that any of the extra features added to
>>>>>>> the UTM
>>>>>>> change the behavior of the simulated input for the first N steps of
>>>>>>> simulation.
>>>>>>>
>>>>>>> Watching the behavior doesn't change it.
>>>>>>> Matching non-halting behavior patterns doesn't change it.
>>>>>>> Even aborting the simulation doesn't change the first N simulated
>>>>>>> steps.
>>>>>>>
>>>>>>> Because of all this we can know that the first N steps of ⟨Ĥ⟩
>>>>>>> simulated
>>>>>>> by embedded_H are the actual behavior that ⟨Ĥ⟩ presents to
>>>>>>> embedded_H for these same N steps.
>>>>>>>
>>>>>>
>>>>>> *The above has been agreed to*
>>>>>> I didn't think that agreement was possible, it turns out that I
>>>>>> simply
>>>>>> had not presented my case clearly enough.
>>>>>
>>>>> But it is irrelevent, as the answer is based on tha ACTUAL behavior
>>>>> of the input,
>>>>
>>>> You agreed that The N steps of ⟨Ĥ⟩ that are correctly simulated by
>>>> embedded_H are the actual behavior of these N steps.
>>>>
>>>>
>>>
>>> Which is IRRELEVENT to the problem,
>>
>> No it is not. Every decider computes the mapping from its input to its
>> own accept or reject state on the basis of a semantic or syntactic
>> property of this input.
>>
>
> And the Semantic Property for a *Halt Decider* is the Halting Property
> of the machine described by its input,

On 4/12/23 11:04 PM, olcott wrote:
> On 4/12/2023 9:19 PM, Richard Damon wrote:

>> And the Semantic Property for a *Halt Decider* is the Halting Property
>> of the machine described by its input,
>
> The ultimate measure of the behavior of an input is the actual behavior
> of the actual input. N steps of ⟨Ĥ⟩ correctly simulated by embedded_H is
> the actual behavior of these N steps.
>

And we don't care about only N steps of the behavior, but the COMPLETE
behavior of this input. Does the machine represented by the input
actually eventually reach a final state.

Since D(D) Halts, as you have admitted, the ultimate answer MUST be that
it Halts, since it does.

The fact that H thinks after seeing the first N steps that THIS input
will never halt, because it starts to look at this input as if it was
something else, calling a different H than it actually calls, just shows
that it is using faulty logic.

On 4/12/23 10:51 PM, Graham Cooper wrote:
> On Thursday, April 13, 2023 at 12:37:38 PM UTC+10, Richard Damon wrote:
>> On 4/12/23 10:21 PM, Graham Cooper wrote:
>>> On Thursday, April 13, 2023 at 11:01:36 AM UTC+10, Richard Damon wrote:
>>>>> So you can take a SUBSET of all TMs
>>>>> which has TM-equivalent computability
>>>>>
>>>>> You dont require ALL TMs
>>>> Nope, the decider must be able to take in ALL TMs, or it fails to meet
>>>> the requirements.
>>>
>>>
>>> Nope! Only if you specify
>>>
>>> "IM GOING TO WRITE A HALT FUNCTION FOR ALL TMS"
>>>
>>> The halt problem is, in any computer language (atleast as powerful as TMs) can you solve all halt values
>>>
>>> The halt problem is NOT
>>>
>>> In pure functions can you solve all halt values.
>>>
>> So, you don't understand the Halt Function of the Halting Problem,
>> because it IS a pure function defined for ALL possible machine/input
>> combinations.
>
> RUBBISH! if you can solve the halt function for non-pure functions
> its SOLVED!

Your have that backwards.

It is impossible to decide on non-pure functions, as you can't possibly
figure out the behavior, as a function of just the declared inputs, if
the functioon depends on other factors than those inputs.

For instance, does the following function return?

extern bool flag;

void test() {
while(flag) continue;
}

You can't tell, becuase it depends on something you don't know,

And, the Halting Decider MUST be a pure function, and just of the
machine and its input, if its input is, as the actual mathematical
Halting Function is, so if the decider gives different answers for the
same values of those parameters based on something else, one of those
answers must be wrong.

>
>
>>
>> Pure function because ALL functions in computability theory are "pure
>> functions" in the sense that they are always a simple mapping of defined
>> inputs to outputs, so ONLY a function of their inputs, i.e. what we call
>> a "pure function".
>
>
> RUBBISH! you are invoking CHURCH TURING THESIS which is unproven
>

But accepted. If you want to claim it ISN'T true, you need a counter
example.

>
>
>
>
>
>
>
>>
>> This function has been proven to NOT be "Computable", because we can not
>> write a finite algorithm that can compute this function for all possible
>> machine inputs.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>>
>>>>> So you can take a SUBSET with a specific property
>>>>> such as adding READ-ONLY
>>>>>
>>>> Nope, that VIOLATES the requirement.
>>>>
>>>> Either that subset IS Turing Complete, at which point your decider in
>>>> that subset, can be converted to a machine that doesn't need that
>>>> special property or your subset isn't Turing Complete, at which point it
>>>> doens't meet the requirements.
>>>
>>>
>>> Nope! you cant convert individual functions back to whatever model of computation you choose
>>>
>> Why not?
>>
>> If it IS a computation, then it CAN be converted into a Turing Machine.
>> If it isn't then it doesn't qualify as a decider.
>>
>> This is a fundamental property.
>>
>> Unless you can actually PROVE that you can define some actual
>> computation, computable with your defined system that can NOT be
>> converted to a Turing Machine (which would likely make you famous), you
>> are just spouting falsehoods.
>
>
> You limit the computation model to the subset of TMs which DOUBLE MOVE the tape
>
> IE
> exclude
> [s1] ->01R->[s4]
>
> include
> [s1]->01R->[s2]->00R->[s4]
> [s1]->01R->[s3]->11R->[s4]
>
> then the TM can only write to every 2nd tape cell
>
> its an EQUIVALENT MODEL OF COMPUTATION to TMs
> (actually more powerful than the standard interpretation of TMs)
>
>

So, what computation in that system can't be done by the regular Turing
Machines? Showing you are "equivalent" doesn't make you more powerful.

Why can't I copy your "Halt Decider" into my pathological program using
that transform (and tell it it is being called "topmost") to get the
answer that your Halt Decide would give, and then just do the opposite
to make it wrong.

Either I can do this, and thus you haven't broken the pathology, and
thus still can't decide on it, or your can't do this and have just
proven that your system is weaker than a Turing Complete system.

Perhaps your issue is you don't understand what is described as the
"power" of a computation system, it relates to which actual maps can be
computed.