On 12/10/21 5:48 PM, olcott wrote:
> On 12/10/2021 4:02 PM, André G. Isaak wrote:
>> On 2021-12-10 13:47, olcott wrote:
>>> On 12/10/2021 1:55 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 12/10/2021 10:12 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 12/9/2021 9:03 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn if, and only if, UTM(⟨Ĥ⟩, ⟨Ĥ⟩)
>>>>>>>>> NEVER stops
>>>>>>>>> running without having to be aborted.
>>>>>>>>
>>>>>>>> That's the wrong criterion.  You are not describing Linz's Ĥ
>>>>>>>> anymore.
>>>>>>>> To address the proof, you need Ĥ to mean what Linz means, and
>>>>>>>> that's a
>>>>>>>> machine that does this:
>>>>>>>>
>>>>>>>>      Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>      if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>>>>      Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>      if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>
>>>>>>> This can be misinterpreted to mean that Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> transitions to Ĥ.qn if and only if Ĥ.qx does not transition to Ĥ.qn.
>>>>>> Whatever that means,
>>>>>
>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ *is not deciding whether or not itself halts*
>>>>
>>>> The sub-TM at Ĥ.qx is not a decider, so I agree with the words you have
>>>> said (but not with what you meant to say).
>>>>
>>>
>>> Ĥ.qx <is> an exact copy of H so it <is> a halt decider that has its
>>> yes state corrupted, thus causing it to no longer be a decider.
>>
>> Ĥ.qx is a single state. It isn't any kind of decider
>>
>> The set of state transitions which *starts* at Ĥ.qx is based on a halt
>> decider but with its accepting state replaced by a loop, meaning that
>> it is no longer a decider at all. So I don't see why you are arguing
>> about this.
>>
>
> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn portion is that part that is identical to H.
>
>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not
>>>> halt.
>>>>
>>>
>>> No this is false.
>>
>> The set of state transitions beginning with Ĥ.qx is, as you point out,
>> based on a halt decider, and the rejecting state of that decider
>> remains unchanged.
>>
>> So yes, the condition that
>>
>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt.
>>
>> is exactly correct since that is the condition under which a halt
>> decider is defined to reject its input.
>>
>
> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if and only if Ĥ.qx does not transition to Ĥ.qn is
> incorrect.

But it is a NATURAL consequince of the requirements, and the fact that
it is imppossible means the requirements can not be meet.

>
> A simulating halt decider does not report on its own behavior. A
> simulating halt decider reports on the behavior of the simulation its
> its own machine description.

But it DOES need to decide on its self if it is given itself to decide.

There is no exemption that H doesn't need to be able to decide on
machines that are based on a copy of H.

>
>      In computability theory, the halting problem is the problem of
>      determining, from a description of an arbitrary computer program
>      and an input, whether the program will finish running, or continue
>      to run forever. https://en.wikipedia.org/wiki/Halting_problem
>
> Common sense would tall you that these two must be identical and common
> sense is proven to be incorrect.

DEFINITIONS say they need to be identical.

If they aren't, then either YOU have defined something wrong, or you
have just ignored that you are talking about a machine that doesn't
actually exist, and non-existant machines can do all sorts of things
that seem to be impossible.

>
>> You may not like this definition. That does not make it 'false'. It is
>> the correct definition, and the one used by absolutely everyone in the
>> field of computing. If you replace it with something else, you are the
>> one using the wrong definition.
>>
>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ *is not deciding whether or not its own first state Ĥ.q0
>>>>> reaches a final state.*
>>>>
>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not deciding anything.  The sub-TM at Ĥ.qx, when given
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ on the tape, transitions to Ĥ.qn if, and only if, Ĥ applied to
>>>> ⟨Ĥ⟩ does not halt.
>>>>
>>>
>>> In other words you mean that Ĥ.qx transitions to Ĥ.qn if any only if
>>> Ĥ.qx never reaches any final state.
>>>
>>>>> Simulating halt decider Ĥ.qx *is deciding whether or not a pure
>>>>> simulation of its input ⟨Ĥ⟩ ⟨Ĥ⟩ would ever reach a final state of this
>>>>> same input.*
>>>>
>>>> The special case of things you call simulating halt deciders are
>>>> included in everything Linz has to say about halt deciders in general.
>>>> The sub-TM at Ĥ.qx, when Ĥ has been constructed from a "simulating halt
>>>> decider" called H, should, when given ⟨Ĥ⟩ ⟨Ĥ⟩ on the tape,
>>>> transition to
>>>> Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>
>>>
>>> No this is incorrect.
>>>
>>> The sub-TM at Ĥ.qx, when Ĥ has been constructed from a "simulating
>>> halt decider" called H, should, when given ⟨Ĥ⟩ ⟨Ĥ⟩ on the tape,
>>> transition to Ĥ.qn
>>>
>>> when it detects that its pure simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ never
>>> stops running unless Ĥ.qx aborts its simulation of this input.
>>
>> And if that condition is not met under *precisely* the same conditions
>> as the actual, accepted condition that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if, and
>> only if, Ĥ applied to ⟨Ĥ⟩ does not halt, then you are not justified in
>> altering the definition.
>
> A simulating halt decider does not report on its own behavior. A
> simulating halt decider reports on the behavior of the simulation its
> its own machine description.

Unless it is asked about its self.

There is NO exemption for the case that the input to the decider
references a copy of the decider.

>
> This is one level of indirection away (pointer to a pointer) from
> referring to its actual self.

If so, then it is done wrong.

H / H^.qx has as its input <H^> <H^> which is EXACTLY what means decide
on H^ applied to <H^>. PERIOD.

>
>> And while it is apparent that your condition does *not* match the
>> actual criterion, only you know what is really intended by your
>> revised criterion since you very clearly do not mean pure simulation
>> when you right 'pure simulation.'
>>
>
> 0 to ∞ steps of the simulation of P(P) by H are identical to 0 to ∞
> steps of the direct execution of P(P) by H.
>
> 0 to ∞ simulated steps of P(P) by H never stop running.

Sounds like you just changed your H. THAT isn't allowed.

FAIL.

>
>> Ĥ applied to ⟨Ĥ⟩ halts. You have acknowledged that. That means that UTM
>
> 0 to ∞ steps of the simulation ⟨Ĥ⟩ applied to ⟨Ĥ⟩ by Ĥ.qx never stop
> running.

But if H <H^> <H^> goes to qn, then ENOUGH steps of H^ applied to <H^>
will, so it is halting.

You seem to be stuck on your POOP again.

>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ will also halt and that would be the only meaning of 'pure
>> simulation' that makes any sense. So whatever meaning you intend for
>> your revised criterion will remain forever mysterious. All we know for
>> sure is that it doesn't match the actual halting criterion and
>> therefore your Ĥ has no bearing on the Linz proof.
>>
>> André
>>
>
>

On 12/10/2021 5:46 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 12/10/2021 1:55 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 12/10/2021 10:12 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 12/9/2021 9:03 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn if, and only if, UTM(⟨Ĥ⟩, ⟨Ĥ⟩) NEVER stops
>>>>>>>> running without having to be aborted.
>>>>>>>
>>>>>>> That's the wrong criterion. You are not describing Linz's Ĥ anymore.
>>>>>>> To address the proof, you need Ĥ to mean what Linz means, and that's a
>>>>>>> machine that does this:
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>
>>>>>> This can be misinterpreted to mean that Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> transitions to Ĥ.qn if and only if Ĥ.qx does not transition to Ĥ.qn.
>>>>> Whatever that means,
>>>>
>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ *is not deciding whether or not itself halts*
>>> The sub-TM at Ĥ.qx is not a decider, so I agree with the words you have
>>> said (but not with what you meant to say).
>>
>> Ĥ.qx <is> an exact copy of H...
>
> No. We've been round and round this loop before and I see that André
> has this in hand, so bye for now...
>

I agree with you on that point, see my other points.

--
Copyright 2021 Pete Olcott

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

On 12/10/21 6:47 PM, olcott wrote:
> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>> On 2021-12-10 16:32, olcott wrote:
>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>
>>>> A halt decider, regardless of whether it is simulating or otherwise,
>>>> reports on the behaviour of the computation represented by its
>>>> input. This is very clearly stated by the conditions which Linz
>>>> indicates in his proof.
>>>>
>>>
>>> This definition has confused too many people into thinking that it is
>>> reporting on something besides the precise behavior that is
>>> stipulated by the actual input.
>>
>> it hasn't confused anyone other than you. A halt decider does *not*
>> report on the behaviour of its input. It reports on the behaviour of
>> the computation represented by the input.
>>
>
> When the input to a halt decider is directly executable machine code
> then that halt status decision is based on the actual behavior of the
> actual execution of this input.

Right, what the input would do if ACTUALLY executed (and not
conditionally debug-stepped).

You AGREE that P(P) when actually run, halts if H(P,P) returns 0.

So THIS execution defines the RIGHT answer for the problem, and that
answer is HALTING, so H was wrong to say NON-Halting.

PERIOD.

>
> The only reason that the word "representation" has ever been used is the
> mere convention that TM's cannot directly execute other TM's, there must
> be an intermediate TM description (essentially source-code) inbetween.

But if you ACTUALLY implemented the requirements you would have the same
issue.

H needs to be able to take in ANY program, even programs that have other
code in them at the addresses that H occupies, This means your 'trick'
of havign H just 'call' its input doesn't work. This means that the
input can't just be normal executable code in H's memory space.

>
>>> The halt decider reports on the behavior its input as if the halt
>>> decider was performing a correct pure simulation of this input.
>>
>> No, that's not the definition of halt decider. The actual definition
>> is the one used by Linz, and that is the one that should be stuck to.
>>
>> It's trivially easy to 'prove' things when you allow your self to
>> change definitions. I can easily proof that there is a largest prime
>> number provided I get to redefine 'prime number' or 'largest', but I
>> assure you there is no Fields Medal in my future. Similarly, I can
>> prove that P = NP or that P != NP if I am just allowed to provide my
>> own definitions. But again, I won't be holding my breath for an ACM
>> Turing Award.
>>
>> Similarly, no 'proof' you offer claiming to show the halting problem
>> is computable will gain you any recognition if you don't stick to the
>> actual accepted definitions.
>>
>
>

On 12/10/21 6:32 PM, olcott wrote:
> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>> On 2021-12-10 15:48, olcott wrote:
>>> On 12/10/2021 4:02 PM, André G. Isaak wrote:
>>>> On 2021-12-10 13:47, olcott wrote:
>>>>> On 12/10/2021 1:55 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 12/10/2021 10:12 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 12/9/2021 9:03 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn if, and only if, UTM(⟨Ĥ⟩,
>>>>>>>>>>> ⟨Ĥ⟩) NEVER stops
>>>>>>>>>>> running without having to be aborted.
>>>>>>>>>>
>>>>>>>>>> That's the wrong criterion.  You are not describing Linz's Ĥ
>>>>>>>>>> anymore.
>>>>>>>>>> To address the proof, you need Ĥ to mean what Linz means, and
>>>>>>>>>> that's a
>>>>>>>>>> machine that does this:
>>>>>>>>>>
>>>>>>>>>>      Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>      if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>>>>>>      Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>      if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>
>>>>>>>>> This can be misinterpreted to mean that Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>> transitions to Ĥ.qn if and only if Ĥ.qx does not transition to
>>>>>>>>> Ĥ.qn.
>>>>>>>> Whatever that means,
>>>>>>>
>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ *is not deciding whether or not itself halts*
>>>>>>
>>>>>> The sub-TM at Ĥ.qx is not a decider, so I agree with the words you
>>>>>> have
>>>>>> said (but not with what you meant to say).
>>>>>>
>>>>>
>>>>> Ĥ.qx <is> an exact copy of H so it <is> a halt decider that has its
>>>>> yes state corrupted, thus causing it to no longer be a decider.
>>>>
>>>> Ĥ.qx is a single state. It isn't any kind of decider
>>>>
>>>> The set of state transitions which *starts* at Ĥ.qx is based on a
>>>> halt decider but with its accepting state replaced by a loop,
>>>> meaning that it is no longer a decider at all. So I don't see why
>>>> you are arguing about this.
>>>>
>>>
>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn portion is that part that is identical to H.
>>>
>>>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not
>>>>>> halt.
>>>>>>
>>>>>
>>>>> No this is false.
>>>>
>>>> The set of state transitions beginning with Ĥ.qx is, as you point
>>>> out, based on a halt decider, and the rejecting state of that
>>>> decider remains unchanged.
>>>>
>>>> So yes, the condition that
>>>>
>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>
>>>> is exactly correct since that is the condition under which a halt
>>>> decider is defined to reject its input.
>>>>
>>>
>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if and only if Ĥ.qx does not transition to Ĥ.qn
>>> is incorrect.
>>>
>>> A simulating halt decider does not report on its own behavior. A
>>> simulating halt decider reports on the behavior of the simulation its
>>> its own machine description.
>>>
>>>       In computability theory, the halting problem is the problem of
>>>       determining, from a description of an arbitrary computer program
>>>       and an input, whether the program will finish running, or continue
>>>       to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> Common sense would tall you that these two must be identical and
>>> common sense is proven to be incorrect.
>>>
>>>> You may not like this definition. That does not make it 'false'. It
>>>> is the correct definition, and the one used by absolutely everyone
>>>> in the field of computing. If you replace it with something else,
>>>> you are the one using the wrong definition.
>>>>
>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ *is not deciding whether or not its own first state
>>>>>>> Ĥ.q0
>>>>>>> reaches a final state.*
>>>>>>
>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not deciding anything.  The sub-TM at Ĥ.qx, when
>>>>>> given
>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ on the tape, transitions to Ĥ.qn if, and only if, Ĥ
>>>>>> applied to
>>>>>> ⟨Ĥ⟩ does not halt.
>>>>>>
>>>>>
>>>>> In other words you mean that Ĥ.qx transitions to Ĥ.qn if any only
>>>>> if Ĥ.qx never reaches any final state.
>>>>>
>>>>>>> Simulating halt decider Ĥ.qx *is deciding whether or not a pure
>>>>>>> simulation of its input ⟨Ĥ⟩ ⟨Ĥ⟩ would ever reach a final state of
>>>>>>> this
>>>>>>> same input.*
>>>>>>
>>>>>> The special case of things you call simulating halt deciders are
>>>>>> included in everything Linz has to say about halt deciders in
>>>>>> general.
>>>>>> The sub-TM at Ĥ.qx, when Ĥ has been constructed from a "simulating
>>>>>> halt
>>>>>> decider" called H, should, when given ⟨Ĥ⟩ ⟨Ĥ⟩ on the tape,
>>>>>> transition to
>>>>>> Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>
>>>>>
>>>>> No this is incorrect.
>>>>>
>>>>> The sub-TM at Ĥ.qx, when Ĥ has been constructed from a "simulating
>>>>> halt decider" called H, should, when given ⟨Ĥ⟩ ⟨Ĥ⟩ on the tape,
>>>>> transition to Ĥ.qn
>>>>>
>>>>> when it detects that its pure simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>> never stops running unless Ĥ.qx aborts its simulation of this input.
>>>>
>>>> And if that condition is not met under *precisely* the same
>>>> conditions as the actual, accepted condition that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢*
>>>> Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt, then you are
>>>> not justified in altering the definition.
>>>
>>> A simulating halt decider does not report on its own behavior. A
>>> simulating halt decider reports on the behavior of the simulation its
>>> its own machine description.
>>
>> A halt decider, regardless of whether it is simulating or otherwise,
>> reports on the behaviour of the computation represented by its input.
>> This is very clearly stated by the conditions which Linz indicates in
>> his proof.
>>
>
> This definition has confused too many people into thinking that it is
> reporting on something besides the precise behavior that is stipulated
> by the actual input.

The input is <H^> <H^> which represents the computation H^ applied to
<H^> which is shown to be a Halting computation if H <H^> <H^> goes to
H.qn as claimed. PERIOD.

>
> The halt decider reports on the behavior its input as if the halt
> decider was performing a correct pure simulation of this input.

And a CORRECT PURE SIMUATION is one that will NEVER be aborted, so NOT
the execution withing any H that gives an answer.

>
> The halt decider performs a correct pure simulation of N steps of its
> input until the input halts on its own or the behavior of N steps of
> this input conclusively proves that the correct simulation of this input
> never stops running unless aborted.
>

On 12/10/21 3:47 PM, olcott wrote:
> On 12/10/2021 1:55 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ *is not deciding whether or not its own first state Ĥ.q0
>>> reaches a final state.*
>>
>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not deciding anything.  The sub-TM at Ĥ.qx, when given
>> ⟨Ĥ⟩ ⟨Ĥ⟩ on the tape, transitions to Ĥ.qn if, and only if, Ĥ applied to
>> ⟨Ĥ⟩ does not halt.
>>
>
> In other words you mean that Ĥ.qx transitions to Ĥ.qn if any only if
> Ĥ.qx never reaches any final state.
>

Yes, exactly.

That is the requirement that is properly derived based on the assumption
that H is a correct halt decider on H^.

The absurd condition is the proof that this assumption doesn't
correspond to something that exists.

This is freshman level logic, if not lower. You should know it.

On 2021-12-10 16:47, olcott wrote:
> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>> On 2021-12-10 16:32, olcott wrote:
>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>
>>>> A halt decider, regardless of whether it is simulating or otherwise,
>>>> reports on the behaviour of the computation represented by its
>>>> input. This is very clearly stated by the conditions which Linz
>>>> indicates in his proof.
>>>>
>>>
>>> This definition has confused too many people into thinking that it is
>>> reporting on something besides the precise behavior that is
>>> stipulated by the actual input.
>>
>> it hasn't confused anyone other than you. A halt decider does *not*
>> report on the behaviour of its input. It reports on the behaviour of
>> the computation represented by the input.
>>
>
> When the input to a halt decider is directly executable machine code
> then that halt status decision is based on the actual behavior of the
> actual execution of this input.

The decision must describe the actual behaviour of the program described
by the input, but it cannot be based on the execution of this input. If
a putative halt decider simply executed its input it wouldn't constitute
a decider since it would not halt if its input were a non-halting
program. The input *describes* some program and input, just as the input
to a TM-based decider decribes a computation.

> The only reason that the word "representation" has ever been used is the
> mere convention that TM's cannot directly execute other TM's, there must
> be an intermediate TM description (essentially source-code) inbetween.

This is simply wrong. It doesn't matter whether a halt decider is
expressed in terms of Turing Machines or x86 programs; one must still
make a distinction between the data which a halting decider evaluates,
which is a representation of some program, and the actual executable
program. The fact that the conversion between the representation and the
executable is relatively trivial doesn't make the distinction go away.

A halt decider must be able to accept as input *any* possible program,
and that includes programs whose instructions overlap the address range
of the decider itself, so the representation is not going to be
identical to the executable code.

And earlier you'd claimed your H took a COFF file as an input, though
none of your code provides evidence of this. The contents of a COFF file
are not identical to the actual executable which is loaded into memory
from that file as anyone familiar with COFF files should know.

André

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

On 12/10/2021 10:36 PM, André G. Isaak wrote:
> On 2021-12-10 16:47, olcott wrote:
>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>> On 2021-12-10 16:32, olcott wrote:
>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>
>>>>> A halt decider, regardless of whether it is simulating or
>>>>> otherwise, reports on the behaviour of the computation represented
>>>>> by its input. This is very clearly stated by the conditions which
>>>>> Linz indicates in his proof.
>>>>>
>>>>
>>>> This definition has confused too many people into thinking that it
>>>> is reporting on something besides the precise behavior that is
>>>> stipulated by the actual input.
>>>
>>> it hasn't confused anyone other than you. A halt decider does *not*
>>> report on the behaviour of its input. It reports on the behaviour of
>>> the computation represented by the input.
>>>
>>
>> When the input to a halt decider is directly executable machine code
>> then that halt status decision is based on the actual behavior of the
>> actual execution of this input.
>
> The decision must describe the actual behaviour of the program described
> by the input, but it cannot be based on the execution of this input. If
> a putative halt decider simply executed its input it wouldn't constitute
> a decider since it would not halt if its input were a non-halting
> program. The input *describes* some program and input, just as the input
> to a TM-based decider decribes a computation.
>

It has always been the case that a halt decider has only been
accountable for the actual behavior specified by its actual input.

The actual behavior specified by its actual input H(x,y) is most
precisely defined as the pure simulation of the finite string pair input
S(x,y) from the halt decider.

H is a decider; which is a type of computable function; which is a type
of function; which only applies to its input parameters.

No function is ever accountable for anything besides inputs in its
domain. These inputs in its domain are explicitly specified as parameters.

>> The only reason that the word "representation" has ever been used is
>> the mere convention that TM's cannot directly execute other TM's,
>> there must be an intermediate TM description (essentially source-code)
>> inbetween.
>
> This is simply wrong. It doesn't matter whether a halt decider is
> expressed in terms of Turing Machines or x86 programs; one must still
> make a distinction between the data which a halting decider evaluates,
> which is a representation of some program, and the actual executable
> program.

Not if the data is x86 machine code

> The fact that the conversion between the representation and the
> executable is relatively trivial doesn't make the distinction go away.
>
> A halt decider must be able to accept as input *any* possible program,
> and that includes programs whose instructions overlap the address range
>  of the decider itself, so the representation is not going to be
> identical to the executable code.
>
> And earlier you'd claimed your H took a COFF file as an input, though
> none of your code provides evidence of this. The contents of a COFF file
> are not identical to the actual executable which is loaded into memory
> from that file as anyone familiar with COFF files should know.
>
> André
>

I transformed the COFF object file by patching relocatbale addresses to
their actual file offset so that the COFF object file is directly
excutable in my system. The link step is not allowed.

--
Copyright 2021 Pete Olcott

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

On 2021-12-10 22:13, olcott wrote:
> On 12/10/2021 10:36 PM, André G. Isaak wrote:
>> On 2021-12-10 16:47, olcott wrote:
>>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>>> On 2021-12-10 16:32, olcott wrote:
>>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>>
>>>>>> A halt decider, regardless of whether it is simulating or
>>>>>> otherwise, reports on the behaviour of the computation represented
>>>>>> by its input. This is very clearly stated by the conditions which
>>>>>> Linz indicates in his proof.
>>>>>>
>>>>>
>>>>> This definition has confused too many people into thinking that it
>>>>> is reporting on something besides the precise behavior that is
>>>>> stipulated by the actual input.
>>>>
>>>> it hasn't confused anyone other than you. A halt decider does *not*
>>>> report on the behaviour of its input. It reports on the behaviour of
>>>> the computation represented by the input.
>>>>
>>>
>>> When the input to a halt decider is directly executable machine code
>>> then that halt status decision is based on the actual behavior of the
>>> actual execution of this input.
>>
>> The decision must describe the actual behaviour of the program
>> described by the input, but it cannot be based on the execution of
>> this input. If a putative halt decider simply executed its input it
>> wouldn't constitute a decider since it would not halt if its input
>> were a non-halting program. The input *describes* some program and
>> input, just as the input to a TM-based decider decribes a computation.
>>
>
> It has always been the case that a halt decider has only been
> accountable for the actual behavior specified by its actual input.

The actual input is a string. Strings don't have actual behaviour.

> The actual behavior specified by its actual input H(x,y) is most
> precisely defined as the pure simulation of the finite string pair input
> S(x,y) from the halt decider.

By definition a halt decider describes the behaviour of the computation
*described* by its input. The input itself doesn't specify any behaviour
at all.

> H is a decider; which is a type of computable function; which is a type
> of function; which only applies to its input parameters.

Deciders are a type of Turing Machine (or Computer Program). Turing
Machines are *not* functions. They compute functions but they are not
the same as the function they compute. And the Halting Function is *not*
a computable function so referring to a halt decider as a "computable
function" is even more wrong than describing it as a "function".

You really need to stop using these terms until you learn what they
mean. You embarrass yourself with every sentence you write.

> No function is ever accountable for anything besides inputs in its
> domain. These inputs in its domain are explicitly specified as parameters.

Functions have domains. Turing Machines/Computer programs have
parameters. The parameters passed to a TM are *DESCRIPTIONS* of elements
of the domain of the function which that TM computes. The domain of the
halting function is the set of all computations. The parameters passed
to a halt decider would be *DESCRIPTIONS* of elements in that domain,
i.e. the set of computations. The answer which it is expected to return
describes the behaviour of the actual computation described by its input
parameter, not the behaviour of the input string which is a nonsensical
claim.

>
>>> The only reason that the word "representation" has ever been used is
>>> the mere convention that TM's cannot directly execute other TM's,
>>> there must be an intermediate TM description (essentially
>>> source-code) inbetween.
>>
>> This is simply wrong. It doesn't matter whether a halt decider is
>> expressed in terms of Turing Machines or x86 programs; one must still
>> make a distinction between the data which a halting decider evaluates,
>> which is a representation of some program, and the actual executable
>> program.
>
> Not if the data is x86 machine code

Yes, one still must. Did you not read the bit below?

>> The fact that the conversion between the representation and the
>> executable is relatively trivial doesn't make the distinction go away.
>>
>> A halt decider must be able to accept as input *any* possible program,
>> and that includes programs whose instructions overlap the address
>> range   of the decider itself, so the representation is not going to
>> be identical to the executable code.
>>
>> And earlier you'd claimed your H took a COFF file as an input, though
>> none of your code provides evidence of this. The contents of a COFF
>> file are not identical to the actual executable which is loaded into
>> memory from that file as anyone familiar with COFF files should know.
>>
>> André
>>
>
> I transformed the COFF object file by patching relocatbale addresses to
> their actual file offset so that the COFF object file is directly
> excutable in my system. The link step is not allowed.

So basically you never actually did this. You just thought about how you
might do it without actually testing to see if this would be workable.
It isn't.

André

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

On 12/11/21 12:13 AM, olcott wrote:
> On 12/10/2021 10:36 PM, André G. Isaak wrote:
>> On 2021-12-10 16:47, olcott wrote:
>>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>>> On 2021-12-10 16:32, olcott wrote:
>>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>>
>>>>>> A halt decider, regardless of whether it is simulating or
>>>>>> otherwise, reports on the behaviour of the computation represented
>>>>>> by its input. This is very clearly stated by the conditions which
>>>>>> Linz indicates in his proof.
>>>>>>
>>>>>
>>>>> This definition has confused too many people into thinking that it
>>>>> is reporting on something besides the precise behavior that is
>>>>> stipulated by the actual input.
>>>>
>>>> it hasn't confused anyone other than you. A halt decider does *not*
>>>> report on the behaviour of its input. It reports on the behaviour of
>>>> the computation represented by the input.
>>>>
>>>
>>> When the input to a halt decider is directly executable machine code
>>> then that halt status decision is based on the actual behavior of the
>>> actual execution of this input.
>>
>> The decision must describe the actual behaviour of the program
>> described by the input, but it cannot be based on the execution of
>> this input. If a putative halt decider simply executed its input it
>> wouldn't constitute a decider since it would not halt if its input
>> were a non-halting program. The input *describes* some program and
>> input, just as the input to a TM-based decider decribes a computation.
>>
>
> It has always been the case that a halt decider has only been
> accountable for the actual behavior specified by its actual input.

Right, and the ACTUAL behavior of H^ applied to H^, which is the input
to H, is to HALT (at least if H <H^> <H^> returns 0)

or in your program terms: if H(P,P) returns 0, we can see that P(P) will
return, and thus H gave the wrong answer.

>
> The actual behavior specified by its actual input H(x,y) is most
> precisely defined as the pure simulation of the finite string pair input
> S(x,y) from the halt decider.

Ok, and the PURE simulation UTM(<H^>,<H^>) will do exactly like H^(<H^>)
which is Halts if H(<H^>,<H^>) returns 0.

>
> H is a decider; which is a type of computable function; which is a type
> of function; which only applies to its input parameters.

As Andre has repeatedly said, H is a Algorithm, an equivalent to a
Turing Machine. These are NOT 'Functions' in the mathematical sense.
They are Algorithms which COMPUTE said function (and show that the
Function is Computatable).

>
> No function is ever accountable for anything besides inputs in its
> domain. These inputs in its domain are explicitly specified as parameters.
>

Right, H needs to decide exactly what its input specify. H also needs to
be a precise algorithm, being an exact step by step procedure and thus
will always return the same answer for the same inputs.

When we 'call' H(P,P), then the two copies of P are the input parameters
to H. the MEANING of this call, if H claims to be a Halt Decider is the
computation P(P), PERIOD. This means that for H to be a CORRECT Halt
Decider, the value it returns needs to match the behavior of a direct
call to P(P).

We can see that if H(P,P) happens to return 0 as a function of its
definied processing, then by simple examination of the code of P, we can
see that P(P) will halt in finite time. This means that H(P,P) returning
0 must be a wrong answer.

It doesn't matter what sort of 'proof' you make that it must be the
right answer, the simple matter that P(P) Halts shows that there MUST be
a flaw in the 'proof' that H was right. PERIOD.

Isn't this the method you are trying to use in the first place? So you
should understand it. You want to try to claim that by providing an
example H that gives the right answer to H appled to <H^> <H^> that the
Linz proof MUST be flawed?

If you want to deny that this sort of proof is valid, then your whole
attempt is for naught.

Your problem is that the 'logic' you try to use has more holes in it
then a block of swiss cheese, but you refuese to look at them, because
you so need to refute this VALID claim that the can not be a universal
halt decider, because that PROOF destroys your concept of Truth (which
really shows that there is a flaw in your definition of Truth).

>
>
>>> The only reason that the word "representation" has ever been used is
>>> the mere convention that TM's cannot directly execute other TM's,
>>> there must be an intermediate TM description (essentially
>>> source-code) inbetween.
>>
>> This is simply wrong. It doesn't matter whether a halt decider is
>> expressed in terms of Turing Machines or x86 programs; one must still
>> make a distinction between the data which a halting decider evaluates,
>> which is a representation of some program, and the actual executable
>> program.
>
> Not if the data is x86 machine code

You perhaps confuse yourself by your insistence on dealing only with x86
machine code. One of the properties of Von Neumann machines is that they
intermix their program and their data and thus can blur the line between
the program and the input data as a representation of the program.

(see more below).

One flaw in your model is that good practices say that an executable
segments should NOT be writable by the program, and the 'tape' segment
really does need to be writable to allow arbitrary programs to run, so
you need to take special steps to allow yourself just execute the input
tape.

Turing Machines has no problem with this sort of distinction, as the
Turing Machine, by its nature CAN'T write to its 'code', and in fact
can't even READ the code for its algorithm, so a good execution model
for a Turing Machine would have the code segment be just 'X' and the
tape segement be 'RW', and the function of a 'UTM' equivalent would be
to take the program code input and convert its access from 'RW' to 'X'
and jump to it. Again, we get back the distinction, Representation is
'RW', actual machine is 'X'.

>
>> The fact that the conversion between the representation and the
>> executable is relatively trivial doesn't make the distinction go away.
>>
>> A halt decider must be able to accept as input *any* possible program,
>> and that includes programs whose instructions overlap the address
>> range   of the decider itself, so the representation is not going to
>> be identical to the executable code.
>>
>> And earlier you'd claimed your H took a COFF file as an input, though
>> none of your code provides evidence of this. The contents of a COFF
>> file are not identical to the actual executable which is loaded into
>> memory from that file as anyone familiar with COFF files should know.
>>
>> André
>>
>
> I transformed the COFF object file by patching relocatbale addresses to
> their actual file offset so that the COFF object file is directly
> excutable in my system. The link step is not allowed.
>

This shows a fundamental LIE to your claim. You CLAIM that your decider
takes in a COFF object file, but it doesn't. If H is the decider, then H
would need to take in as its parameters, a COFF file to specify the
machine to decide on. It DOESN'T.

What DOES take the COFF file, is thus your x86utm program, so if then
the decider is actually the x86utm program, so H^ needs to be based on
invoking THAT inside it, with something like exec(), but x86utm can
handle that sort of code.

Now, perhaps H could be defined to take a pointer to the contents of the
COFF file (raw, not transformed) and then *H* does the patching of
relocatable addresses, and then 'runs' that program under its debugger
to see if it will halt.

Note, this suddenly brings back the distintion between the actual
machines (the patched code) and the representation (the raw COFF data).

This also breaks your detection mechanism of recursion as you have no
ability to detect that the input has called 'yourself' as you don't know
that the thing at your address is H, and if using non-mapped addressing,
the copy of H in the input won't end up being the same as the H that is
doing the deciding.

On 12/11/2021 12:48 AM, André G. Isaak wrote:
> On 2021-12-10 22:13, olcott wrote:
>> On 12/10/2021 10:36 PM, André G. Isaak wrote:
>>> On 2021-12-10 16:47, olcott wrote:
>>>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>>>> On 2021-12-10 16:32, olcott wrote:
>>>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>>>
>>>>>>> A halt decider, regardless of whether it is simulating or
>>>>>>> otherwise, reports on the behaviour of the computation
>>>>>>> represented by its input. This is very clearly stated by the
>>>>>>> conditions which Linz indicates in his proof.
>>>>>>>
>>>>>>
>>>>>> This definition has confused too many people into thinking that it
>>>>>> is reporting on something besides the precise behavior that is
>>>>>> stipulated by the actual input.
>>>>>
>>>>> it hasn't confused anyone other than you. A halt decider does *not*
>>>>> report on the behaviour of its input. It reports on the behaviour
>>>>> of the computation represented by the input.
>>>>>
>>>>
>>>> When the input to a halt decider is directly executable machine code
>>>> then that halt status decision is based on the actual behavior of
>>>> the actual execution of this input.
>>>
>>> The decision must describe the actual behaviour of the program
>>> described by the input, but it cannot be based on the execution of
>>> this input. If a putative halt decider simply executed its input it
>>> wouldn't constitute a decider since it would not halt if its input
>>> were a non-halting program. The input *describes* some program and
>>> input, just as the input to a TM-based decider decribes a computation.
>>>
>>
>> It has always been the case that a halt decider has only been
>> accountable for the actual behavior specified by its actual input.
>
> The actual input is a string. Strings don't have actual behaviour.
>

An x86 machine code string does have behavior.

>> The actual behavior specified by its actual input H(x,y) is most
>> precisely defined as the pure simulation of the finite string pair
>> input S(x,y) from the halt decider.
>
> By definition a halt decider describes the behaviour of the computation
> *described* by its input. The input itself doesn't specify any behaviour
> at all.

An x86 machine code string does have behavior.

>
>> H is a decider; which is a type of computable function; which is a
>> type of function; which only applies to its input parameters.
>
> Deciders are a type of Turing Machine (or Computer Program). Turing
> Machines are *not* functions.

The Church Turing thesis only applies to computable functions.

> They compute functions but they are not
> the same as the function they compute. And the Halting Function is *not*
> a computable function so referring to a halt decider as a "computable
> function" is even more wrong than describing it as a "function".
>

If halting is not a computable function on some inputs then it is
outside of the scope of computer science investigation.

Computable function
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the
corresponding output. https://en.wikipedia.org/wiki/Computable_function

> You really need to stop using these terms until you learn what they
> mean. You embarrass yourself with every sentence you write.
>
>> No function is ever accountable for anything besides inputs in its
>> domain. These inputs in its domain are explicitly specified as
>> parameters.
>
> Functions have domains. Turing Machines/Computer programs have
> parameters. The parameters passed to a TM are *DESCRIPTIONS* of elements
> of the domain of the function which that TM computes. The domain of the

int main() { P(P); } is not a to H thus has nothing to do with the
correctness of H. H is only accountable for its actual input parameters.

> halting function is the set of all computations. The parameters passed

computation
The sequence of configurations leading to a halt state will be called a
computation. (Linz:1990:238)

Not really that is far too vague. It is the set of all finite string
descriptions of sequences of configurations. Because computation must
halt when we restrict the domain to computations a correctly halt
decider only needs to return true for every input.

> to a halt decider would be *DESCRIPTIONS* of elements in that domain,
> i.e. the set of computations. The answer which it is expected to return
> describes the behaviour of the actual computation described by its input
> parameter, not the behaviour of the input string which is a nonsensical
> claim.
>

According to Linz you are totally wrong on computations because
computations always halt.

>>
>>>> The only reason that the word "representation" has ever been used is
>>>> the mere convention that TM's cannot directly execute other TM's,
>>>> there must be an intermediate TM description (essentially
>>>> source-code) inbetween.
>>>
>>> This is simply wrong. It doesn't matter whether a halt decider is
>>> expressed in terms of Turing Machines or x86 programs; one must still
>>> make a distinction between the data which a halting decider
>>> evaluates, which is a representation of some program, and the actual
>>> executable program.
>>
>> Not if the data is x86 machine code
>
> Yes, one still must. Did you not read the bit below?

#include <stdint.h>
typedef void (*ptr)();

This input to HHH is directly executed by HHH

int HHH(ptr x, ptr y)
{ x(y);
return 1;
}

void PPP(ptr x)
{ if (HHH(x, x))
HERE: goto HERE;
}

int main(void)
{ PPP(PPP);
}

>
>>> The fact that the conversion between the representation and the
>>> executable is relatively trivial doesn't make the distinction go away.
>>>
>>> A halt decider must be able to accept as input *any* possible
>>> program, and that includes programs whose instructions overlap the
>>> address range   of the decider itself, so the representation is not
>>> going to be identical to the executable code.
>>>
>>> And earlier you'd claimed your H took a COFF file as an input, though
>>> none of your code provides evidence of this. The contents of a COFF
>>> file are not identical to the actual executable which is loaded into
>>> memory from that file as anyone familiar with COFF files should know.
>>>
>>> André
>>>
>>
>> I transformed the COFF object file by patching relocatbale addresses
>> to their actual file offset so that the COFF object file is directly
>> excutable in my system. The link step is not allowed.
>
> So basically you never actually did this. You just thought about how you
> might do it without actually testing to see if this would be workable.
> It isn't.
>
> André
>

I did actually do this because it was too much of a hassle to do this
manually all the time.

//
// This function patches all of the relocatable data references
// to their file offset targets. This enables libx86emu to directly
// execute the patched object file.
//
// The object file: *.obj is patched and written to: *.bin
//
u32 COFF_Reader::PatchAddress_Targets(Section_Header& Code_Section)
{ for (int M = 0; M < Code_Section.Relocation_Count; M++)
{
Relocation_Entry Temp;
unsigned int Offset = Code_Section.Relocation_Offset +
(RELOCATION_ENTRY_SIZE * M);
memcpy(&Temp, &ObjectCode[Offset], 10);
// printf("[%02d] Code_Offset[%08x] Symbol_Index(%04x) Type(%04x)\n",
// M, (u32)Temp.Code_Offset, (u32)Temp.Symbol_Index, Temp.Type);
//Symbols[Temp.Symbol_Index].out();

unsigned int Code_Segment =
Sections[CODE_SECTION_INDEX].Data_Offset;
unsigned int Patched_Code = Code_Segment + Temp.Code_Offset;
unsigned int Target_Section =
Symbols[Temp.Symbol_Index].Section_Number;
unsigned int Patch_Target = Sections[Target_Section].Data_Offset +
Symbols[Temp.Symbol_Index].Value;

On 12/11/2021 10:57 AM, olcott wrote:
> On 12/11/2021 12:48 AM, André G. Isaak wrote:
>> On 2021-12-10 22:13, olcott wrote:
>>> On 12/10/2021 10:36 PM, André G. Isaak wrote:
>>>> On 2021-12-10 16:47, olcott wrote:
>>>>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>>>>> On 2021-12-10 16:32, olcott wrote:
>>>>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>>>>
>>>>>>>> A halt decider, regardless of whether it is simulating or
>>>>>>>> otherwise, reports on the behaviour of the computation
>>>>>>>> represented by its input. This is very clearly stated by the
>>>>>>>> conditions which Linz indicates in his proof.
>>>>>>>>
>>>>>>>
>>>>>>> This definition has confused too many people into thinking that
>>>>>>> it is reporting on something besides the precise behavior that is
>>>>>>> stipulated by the actual input.
>>>>>>
>>>>>> it hasn't confused anyone other than you. A halt decider does
>>>>>> *not* report on the behaviour of its input. It reports on the
>>>>>> behaviour of the computation represented by the input.
>>>>>>
>>>>>
>>>>> When the input to a halt decider is directly executable machine
>>>>> code then that halt status decision is based on the actual behavior
>>>>> of the actual execution of this input.
>>>>
>>>> The decision must describe the actual behaviour of the program
>>>> described by the input, but it cannot be based on the execution of
>>>> this input. If a putative halt decider simply executed its input it
>>>> wouldn't constitute a decider since it would not halt if its input
>>>> were a non-halting program. The input *describes* some program and
>>>> input, just as the input to a TM-based decider decribes a computation.
>>>>
>>>
>>> It has always been the case that a halt decider has only been
>>> accountable for the actual behavior specified by its actual input.
>>
>> The actual input is a string. Strings don't have actual behaviour.
>>
>
> An x86 machine code string does have behavior.
>
>>> The actual behavior specified by its actual input H(x,y) is most
>>> precisely defined as the pure simulation of the finite string pair
>>> input S(x,y) from the halt decider.
>>
>> By definition a halt decider describes the behaviour of the
>> computation *described* by its input. The input itself doesn't specify
>> any behaviour at all.
>
> An x86 machine code string does have behavior.
>
>>
>>> H is a decider; which is a type of computable function; which is a
>>> type of function; which only applies to its input parameters.
>>
>> Deciders are a type of Turing Machine (or Computer Program). Turing
>> Machines are *not* functions.
>
> The Church Turing thesis only applies to computable functions.
>
>> They compute functions but they are not the same as the function they
>> compute. And the Halting Function is *not* a computable function so
>> referring to a halt decider as a "computable function" is even more
>> wrong than describing it as a "function".
>>
>
> If halting is not a computable function on some inputs then it is
> outside of the scope of computer science investigation.
>
> Computable function
> Computable functions are the basic objects of study in computability
> theory. Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function is
> computable if there exists an algorithm that can do the job of the
> function, i.e. given an input of the function domain it can return the
> corresponding output. https://en.wikipedia.org/wiki/Computable_function
>
>> You really need to stop using these terms until you learn what they
>> mean. You embarrass yourself with every sentence you write.
>>
>>> No function is ever accountable for anything besides inputs in its
>>> domain. These inputs in its domain are explicitly specified as
>>> parameters.
>>
>> Functions have domains. Turing Machines/Computer programs have
>> parameters. The parameters passed to a TM are *DESCRIPTIONS* of
>> elements of the domain of the function which that TM computes. The
>> domain of the

int main() { P(P); } is not a PARAMETER to H thus has nothing to do with
the correctness of H. H is only accountable for its actual input parameters.

>> halting function is the set of all computations. The parameters passed
>
> computation
> The sequence of configurations leading to a halt state will be called a
> computation.  (Linz:1990:238)
>
> Not really that is far too vague. It is the set of all finite string
> descriptions of sequences of configurations. Because computation must
> halt when we restrict the domain to computations a correctly halt
> decider only needs to return true for every input.
>
>> to a halt decider would be *DESCRIPTIONS* of elements in that domain,
>> i.e. the set of computations. The answer which it is expected to
>> return describes the behaviour of the actual computation described by
>> its input parameter, not the behaviour of the input string which is a
>> nonsensical claim.
>>
>
> According to Linz you are totally wrong on computations because
> computations always halt.
>
>>>
>>>>> The only reason that the word "representation" has ever been used
>>>>> is the mere convention that TM's cannot directly execute other
>>>>> TM's, there must be an intermediate TM description (essentially
>>>>> source-code) inbetween.
>>>>
>>>> This is simply wrong. It doesn't matter whether a halt decider is
>>>> expressed in terms of Turing Machines or x86 programs; one must
>>>> still make a distinction between the data which a halting decider
>>>> evaluates, which is a representation of some program, and the actual
>>>> executable program.
>>>
>>> Not if the data is x86 machine code
>>
>> Yes, one still must. Did you not read the bit below?
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> This input to HHH is directly executed by HHH
>
> int HHH(ptr x, ptr y)
> {
>   x(y);
>   return 1;
> }
>
>
> void PPP(ptr x)
> {
>   if (HHH(x, x))
>     HERE: goto HERE;
> }
>
>
> int main(void)
> {
>   PPP(PPP);
> }
>
>
>>
>>>> The fact that the conversion between the representation and the
>>>> executable is relatively trivial doesn't make the distinction go away.
>>>>
>>>> A halt decider must be able to accept as input *any* possible
>>>> program, and that includes programs whose instructions overlap the
>>>> address range   of the decider itself, so the representation is not
>>>> going to be identical to the executable code.
>>>>
>>>> And earlier you'd claimed your H took a COFF file as an input,
>>>> though none of your code provides evidence of this. The contents of
>>>> a COFF file are not identical to the actual executable which is
>>>> loaded into memory from that file as anyone familiar with COFF files
>>>> should know.
>>>>
>>>> André
>>>>
>>>
>>> I transformed the COFF object file by patching relocatbale addresses
>>> to their actual file offset so that the COFF object file is directly
>>> excutable in my system. The link step is not allowed.
>>
>> So basically you never actually did this. You just thought about how
>> you might do it without actually testing to see if this would be
>> workable. It isn't.
>>
>> André
>>
>
> I did actually do this because it was too much of a hassle to do this
> manually all the time.
>
> //
> //  This function patches all of the relocatable data references
> //  to their file offset targets. This enables libx86emu to directly
> //  execute the patched object file.
> //
> //  The object file: *.obj is patched and written to: *.bin
> //
> u32 COFF_Reader::PatchAddress_Targets(Section_Header& Code_Section)
> {
>   for (int M = 0; M < Code_Section.Relocation_Count; M++)
>   {
>     Relocation_Entry Temp;
>     unsigned int Offset = Code_Section.Relocation_Offset +
> (RELOCATION_ENTRY_SIZE * M);
>     memcpy(&Temp, &ObjectCode[Offset], 10);
> //  printf("[%02d] Code_Offset[%08x] Symbol_Index(%04x) Type(%04x)\n",
> // M, (u32)Temp.Code_Offset, (u32)Temp.Symbol_Index, Temp.Type);
> //Symbols[Temp.Symbol_Index].out();
>
>     unsigned int Code_Segment   =
> Sections[CODE_SECTION_INDEX].Data_Offset;
>     unsigned int Patched_Code   = Code_Segment + Temp.Code_Offset;
>     unsigned int Target_Section =
> Symbols[Temp.Symbol_Index].Section_Number;
>     unsigned int Patch_Target   = Sections[Target_Section].Data_Offset +
>                                   Symbols[Temp.Symbol_Index].Value;
>
>     u32 Unpatched_Target        = (u32)ObjectCode[Patched_Code];
> #ifdef __linux__
>     Patch_Target += Unpatched_Target;
> #endif
>
> #ifdef DEBUG_MODE
>     if (Temp.Type == RELOC_ADDR32)
>       printf("ABSOLUTE:Patch_Target[%04x]  Patched_Code[%04x](%04x)
> Name(%s)\n",
>              Patch_Target, Patched_Code, Unpatched_Target,
>              Symbols[Temp.Symbol_Index].Name.c_str());
>     else if (Temp.Type == RELOC_REL32)
>       printf("RELATIVE:Patch_Target[%04x]  Patched_Code[%04x](%04x)
> Name(%s)\n",
>               Patch_Target, Patched_Code, Unpatched_Target,
>               Symbols[Temp.Symbol_Index].Name.c_str());
> #endif
>
>     if (Temp.Type == RELOC_REL32)
>       Patch_Target = (Patch_Target - (Patched_Code + 4));   // Make
> Relative to address of next instruction
>     else if (Temp.Type != RELOC_ADDR32 && Temp.Type != RELOC_REL32)
>     {
>       printf("FAILURE NOT PATCHED: Unknown Relocation_Entry.Type\n");
>       return 0; // Failure
>     }
>
>     unsigned int* Code2Patch = (unsigned int*) &ObjectCode[Patched_Code];
>     *Code2Patch  = (unsigned int) Patch_Target;
>   }
>   return 1;     // Success
> }
>
>
>
>

On 12/11/21 12:00 PM, olcott wrote:
> On 12/11/2021 10:57 AM, olcott wrote:
>> On 12/11/2021 12:48 AM, André G. Isaak wrote:
>>> On 2021-12-10 22:13, olcott wrote:
>>>> On 12/10/2021 10:36 PM, André G. Isaak wrote:
>>>>> On 2021-12-10 16:47, olcott wrote:
>>>>>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>>>>>> On 2021-12-10 16:32, olcott wrote:
>>>>>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>>>>>
>>>>>>>>> A halt decider, regardless of whether it is simulating or
>>>>>>>>> otherwise, reports on the behaviour of the computation
>>>>>>>>> represented by its input. This is very clearly stated by the
>>>>>>>>> conditions which Linz indicates in his proof.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This definition has confused too many people into thinking that
>>>>>>>> it is reporting on something besides the precise behavior that
>>>>>>>> is stipulated by the actual input.
>>>>>>>
>>>>>>> it hasn't confused anyone other than you. A halt decider does
>>>>>>> *not* report on the behaviour of its input. It reports on the
>>>>>>> behaviour of the computation represented by the input.
>>>>>>>
>>>>>>
>>>>>> When the input to a halt decider is directly executable machine
>>>>>> code then that halt status decision is based on the actual
>>>>>> behavior of the actual execution of this input.
>>>>>
>>>>> The decision must describe the actual behaviour of the program
>>>>> described by the input, but it cannot be based on the execution of
>>>>> this input. If a putative halt decider simply executed its input it
>>>>> wouldn't constitute a decider since it would not halt if its input
>>>>> were a non-halting program. The input *describes* some program and
>>>>> input, just as the input to a TM-based decider decribes a computation.
>>>>>
>>>>
>>>> It has always been the case that a halt decider has only been
>>>> accountable for the actual behavior specified by its actual input.
>>>
>>> The actual input is a string. Strings don't have actual behaviour.
>>>
>>
>> An x86 machine code string does have behavior.
>>
>>>> The actual behavior specified by its actual input H(x,y) is most
>>>> precisely defined as the pure simulation of the finite string pair
>>>> input S(x,y) from the halt decider.
>>>
>>> By definition a halt decider describes the behaviour of the
>>> computation *described* by its input. The input itself doesn't
>>> specify any behaviour at all.
>>
>> An x86 machine code string does have behavior.
>>
>>>
>>>> H is a decider; which is a type of computable function; which is a
>>>> type of function; which only applies to its input parameters.
>>>
>>> Deciders are a type of Turing Machine (or Computer Program). Turing
>>> Machines are *not* functions.
>>
>> The Church Turing thesis only applies to computable functions.
>>
>>> They compute functions but they are not the same as the function they
>>> compute. And the Halting Function is *not* a computable function so
>>> referring to a halt decider as a "computable function" is even more
>>> wrong than describing it as a "function".
>>>
>>
>> If halting is not a computable function on some inputs then it is
>> outside of the scope of computer science investigation.
>>
>> Computable function
>> Computable functions are the basic objects of study in computability
>> theory. Computable functions are the formalized analogue of the
>> intuitive notion of algorithms, in the sense that a function is
>> computable if there exists an algorithm that can do the job of the
>> function, i.e. given an input of the function domain it can return the
>> corresponding output. https://en.wikipedia.org/wiki/Computable_function
>>
>>> You really need to stop using these terms until you learn what they
>>> mean. You embarrass yourself with every sentence you write.
>>>
>>>> No function is ever accountable for anything besides inputs in its
>>>> domain. These inputs in its domain are explicitly specified as
>>>> parameters.
>>>
>>> Functions have domains. Turing Machines/Computer programs have
>>> parameters. The parameters passed to a TM are *DESCRIPTIONS* of
>>> elements of the domain of the function which that TM computes. The
>>> domain of the
>
>
> int main() { P(P); } is not a PARAMETER to H thus has nothing to do with
> the correctness of H. H is only accountable for its actual input
> parameters.

But P,P is its input, and the MEANING of P,P is running P(P)
unconstrained which is what that is.

Basically, it sounds like you are complaining that your system isn't
defined correctly to allow us to properly express the problem.

Question, Whst EXACTLY do you mean that H(x,y) is going to answer about.

If it isn't what

int main() { x(y); }

does, what is?

What is your systems definition of a 'computation' being run as an
independent computation?

It seems that fundamentally, you have defined a 'equavlence' system that
doesn't actually meet the requirements to be equivalent.

We need a way to define what it mean to run a given Turing Machine
equivalent, so to run x(y) or H(P,P) or P(P) we need to have a solid
definition of how to do this.

It seems that in ALL cases, this is to define the 'C' main function to
call the C function that represents the machine.

Thus the input to H(x,y) DOES mean to write an "int main() { x(y); }"

Maybe this is part of the concept of the difference between the
'representation' and the 'actual machine', your 'representation' has
stripped off the main function as to include it would create a multiple
definition error.

On 12/11/2021 11:20 AM, Richard Damon wrote:
> On 12/11/21 12:00 PM, olcott wrote:
>> On 12/11/2021 10:57 AM, olcott wrote:
>>> On 12/11/2021 12:48 AM, André G. Isaak wrote:
>>>> On 2021-12-10 22:13, olcott wrote:
>>>>> On 12/10/2021 10:36 PM, André G. Isaak wrote:
>>>>>> On 2021-12-10 16:47, olcott wrote:
>>>>>>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>>>>>>> On 2021-12-10 16:32, olcott wrote:
>>>>>>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>>>>>>
>>>>>>>>>> A halt decider, regardless of whether it is simulating or
>>>>>>>>>> otherwise, reports on the behaviour of the computation
>>>>>>>>>> represented by its input. This is very clearly stated by the
>>>>>>>>>> conditions which Linz indicates in his proof.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This definition has confused too many people into thinking that
>>>>>>>>> it is reporting on something besides the precise behavior that
>>>>>>>>> is stipulated by the actual input.
>>>>>>>>
>>>>>>>> it hasn't confused anyone other than you. A halt decider does
>>>>>>>> *not* report on the behaviour of its input. It reports on the
>>>>>>>> behaviour of the computation represented by the input.
>>>>>>>>
>>>>>>>
>>>>>>> When the input to a halt decider is directly executable machine
>>>>>>> code then that halt status decision is based on the actual
>>>>>>> behavior of the actual execution of this input.
>>>>>>
>>>>>> The decision must describe the actual behaviour of the program
>>>>>> described by the input, but it cannot be based on the execution of
>>>>>> this input. If a putative halt decider simply executed its input
>>>>>> it wouldn't constitute a decider since it would not halt if its
>>>>>> input were a non-halting program. The input *describes* some
>>>>>> program and input, just as the input to a TM-based decider
>>>>>> decribes a computation.
>>>>>>
>>>>>
>>>>> It has always been the case that a halt decider has only been
>>>>> accountable for the actual behavior specified by its actual input.
>>>>
>>>> The actual input is a string. Strings don't have actual behaviour.
>>>>
>>>
>>> An x86 machine code string does have behavior.
>>>
>>>>> The actual behavior specified by its actual input H(x,y) is most
>>>>> precisely defined as the pure simulation of the finite string pair
>>>>> input S(x,y) from the halt decider.
>>>>
>>>> By definition a halt decider describes the behaviour of the
>>>> computation *described* by its input. The input itself doesn't
>>>> specify any behaviour at all.
>>>
>>> An x86 machine code string does have behavior.
>>>
>>>>
>>>>> H is a decider; which is a type of computable function; which is a
>>>>> type of function; which only applies to its input parameters.
>>>>
>>>> Deciders are a type of Turing Machine (or Computer Program). Turing
>>>> Machines are *not* functions.
>>>
>>> The Church Turing thesis only applies to computable functions.
>>>
>>>> They compute functions but they are not the same as the function
>>>> they compute. And the Halting Function is *not* a computable
>>>> function so referring to a halt decider as a "computable function"
>>>> is even more wrong than describing it as a "function".
>>>>
>>>
>>> If halting is not a computable function on some inputs then it is
>>> outside of the scope of computer science investigation.
>>>
>>> Computable function
>>> Computable functions are the basic objects of study in computability
>>> theory. Computable functions are the formalized analogue of the
>>> intuitive notion of algorithms, in the sense that a function is
>>> computable if there exists an algorithm that can do the job of the
>>> function, i.e. given an input of the function domain it can return
>>> the corresponding output.
>>> https://en.wikipedia.org/wiki/Computable_function
>>>
>>>> You really need to stop using these terms until you learn what they
>>>> mean. You embarrass yourself with every sentence you write.
>>>>
>>>>> No function is ever accountable for anything besides inputs in its
>>>>> domain. These inputs in its domain are explicitly specified as
>>>>> parameters.
>>>>
>>>> Functions have domains. Turing Machines/Computer programs have
>>>> parameters. The parameters passed to a TM are *DESCRIPTIONS* of
>>>> elements of the domain of the function which that TM computes. The
>>>> domain of the
>>
>>
>> int main() { P(P); } is not a PARAMETER to H thus has nothing to do
>> with the correctness of H. H is only accountable for its actual input
>> parameters.
>
> But P,P is its input, and the MEANING of P,P is running P(P)
> unconstrained which is what that is.
>

When input such as P have been defined to have a dependency relationship
on a specific halt decider like H the actual behavior of P(P) can only
be correctly measured by the pure simulation of P(P) from H.

[Olcott 2021 generic halt deciding principle] Whenever the pure
simulation of the input to simulating halt decider H(x,y) never stops
running unless H aborts its simulation H correctly aborts this
simulation and returns 0 for not halting.

The above provides a correct halt status decision for all inputs.

H is a decider; which is a type of computable function; which is a type
of function; which only applies to its input parameters.

No function is ever accountable for anything besides input parameters in
its domain, thus the fact that int main() { P(P); }; has different
behavior than int main() { H(P,P); }; does not make any difference at all.

> Basically, it sounds like you are complaining that your system isn't
> defined correctly to allow us to properly express the problem.
>
> Question, Whst EXACTLY do you mean that H(x,y) is going to answer about.
>
> If it isn't what
>
> int main() { x(y); }
>
> does, what is?
>
> What is your systems definition of a 'computation' being run as an
> independent computation?
>
> It seems that fundamentally, you have defined a 'equavlence' system that
> doesn't actually meet the requirements to be equivalent.
>
> We need a way to define what it mean to run a given Turing Machine
> equivalent, so to run x(y) or H(P,P) or P(P) we need to have a solid
> definition of how to do this.
>
> It seems that in ALL cases, this is to define the 'C' main function to
> call the C function that represents the machine.
>
> Thus the input to H(x,y) DOES mean to write an "int main() { x(y); }"
>
> Maybe this is part of the concept of the difference between the
> 'representation' and the 'actual machine', your 'representation' has
> stripped off the main function as to include it would create a multiple
> definition error.

--
Copyright 2021 Pete Olcott

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

On 12/11/21 11:57 AM, olcott wrote:
> On 12/11/2021 12:48 AM, André G. Isaak wrote:
>> On 2021-12-10 22:13, olcott wrote:
>>> On 12/10/2021 10:36 PM, André G. Isaak wrote:
>>>> On 2021-12-10 16:47, olcott wrote:
>>>>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>>>>> On 2021-12-10 16:32, olcott wrote:
>>>>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>>>>
>>>>>>>> A halt decider, regardless of whether it is simulating or
>>>>>>>> otherwise, reports on the behaviour of the computation
>>>>>>>> represented by its input. This is very clearly stated by the
>>>>>>>> conditions which Linz indicates in his proof.
>>>>>>>>
>>>>>>>
>>>>>>> This definition has confused too many people into thinking that
>>>>>>> it is reporting on something besides the precise behavior that is
>>>>>>> stipulated by the actual input.
>>>>>>
>>>>>> it hasn't confused anyone other than you. A halt decider does
>>>>>> *not* report on the behaviour of its input. It reports on the
>>>>>> behaviour of the computation represented by the input.
>>>>>>
>>>>>
>>>>> When the input to a halt decider is directly executable machine
>>>>> code then that halt status decision is based on the actual behavior
>>>>> of the actual execution of this input.
>>>>
>>>> The decision must describe the actual behaviour of the program
>>>> described by the input, but it cannot be based on the execution of
>>>> this input. If a putative halt decider simply executed its input it
>>>> wouldn't constitute a decider since it would not halt if its input
>>>> were a non-halting program. The input *describes* some program and
>>>> input, just as the input to a TM-based decider decribes a computation.
>>>>
>>>
>>> It has always been the case that a halt decider has only been
>>> accountable for the actual behavior specified by its actual input.
>>
>> The actual input is a string. Strings don't have actual behaviour.
>>
>
> An x86 machine code string does have behavior.

Only when converted into an an actual prorgram with context.

Note, the code for the function P does NOT have behavior until it is
called with a parameter.

You are

>
>>> The actual behavior specified by its actual input H(x,y) is most
>>> precisely defined as the pure simulation of the finite string pair
>>> input S(x,y) from the halt decider.
>>
>> By definition a halt decider describes the behaviour of the
>> computation *described* by its input. The input itself doesn't specify
>> any behaviour at all.
>
> An x86 machine code string does have behavior.

No, see above.

>
>>
>>> H is a decider; which is a type of computable function; which is a
>>> type of function; which only applies to its input parameters.
>>
>> Deciders are a type of Turing Machine (or Computer Program). Turing
>> Machines are *not* functions.
>
> The Church Turing thesis only applies to computable functions.

No, Church Turing thesis only applies to COMPUTATIONS and ALGORITHMS.

You still don't understand that a Computable Function is just a mapping
of inputs to outputs. It is NOT the algorithm used to compute it.

Just like the mathematical sin function is defined as the apping that
corresponds to the ratio of the opposite side of the triangle divided by
the hypotenuse, and NOT some numerical method that produces the
approximate value for a given input.

The fact that Programming defines a DIFFERENT thing that is calls a
'Function' shouldn't confuse you (but seems to). You need to use the
definition that applies for the field you are in.

Computation theory is a piece of the mathematics domain, so uses the
MATHEMATICAL definition of 'Function' not the programming definition.
This ESPECIALLY appies to the term 'Computable Function' as programming
has no need for that term, as by definition, any programming function is
by definition an algorithm to compute the value of a function.

>
>> They compute functions but they are not the same as the function they
>> compute. And the Halting Function is *not* a computable function so
>> referring to a halt decider as a "computable function" is even more
>> wrong than describing it as a "function".
>>
>
> If halting is not a computable function on some inputs then it is
> outside of the scope of computer science investigation.

OK, who said it was a computer science investigation.

Halting is a COMPUTATION THEORY concept.

And yes, the fact that Computation Theory shows that the Halting
Function (as a Mathematical concept of function) is not computable
really says that Halting isn't in the domain of Programming / Computer
Science, as it is impossible to actually write a program to do it.

This is what people have been telling you for YEARS.

>
> Computable function
> Computable functions are the basic objects of study in computability
> theory. Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function is
> computable if there exists an algorithm that can do the job of the
> function, i.e. given an input of the function domain it can return the
> corresponding output. https://en.wikipedia.org/wiki/Computable_function

Right 'Function' (as in Mathematics) is a 'Comutable Function' if there
EXISTS an ALGORITHM that computes it.

The 'program' that you write is the ALGORITHM, not the FUNCTION
(Mathematical).

You don't seem to understand the definition, perhaps because you keep
using the wrong definition of FUNCTION (Mathematical).

>
>> You really need to stop using these terms until you learn what they
>> mean. You embarrass yourself with every sentence you write.
>>
>>> No function is ever accountable for anything besides inputs in its
>>> domain. These inputs in its domain are explicitly specified as
>>> parameters.
>>
>> Functions have domains. Turing Machines/Computer programs have
>> parameters. The parameters passed to a TM are *DESCRIPTIONS* of
>> elements of the domain of the function which that TM computes. The
>> domain of the
>
>
> int main() { P(P); } is not a to H thus has nothing to do with the
> correctness of H. H is only accountable for its actual input parameters.

And H(P,P) MEANS the behavior of the above program,

>
>> halting function is the set of all computations. The parameters passed
>
> computation
> The sequence of configurations leading to a halt state will be called a
> computation.  (Linz:1990:238)
>
> Not really that is far too vague. It is the set of all finite string
> descriptions of sequences of configurations. Because computation must
> halt when we restrict the domain to computations a correctly halt
> decider only needs to return true for every input.

What is vague about it?

You seem to be mixing the two variations in the field of Computing Theory.

One variation defines a 'Computation' as only those processing that DO
end in finite time, and for this version, the Halting Problem is to
detect if its input IS a Computation (because it Halts) or not. This
version has a notational difficulty of describing the applying of an
algorithm to an input, because it might not actually be a Computation.

The second version defines a Computation as ANY finite algorithm (finite
in length of description) and when processed might halt in finite time
or not, and the Halting Problem is to make a Halting Computation that
decides if the input Computation will halt or not.

For the first, the input ISN'T limited to just the representation of
Computations, but to ANY string that can represent an algorithm and its
input, and it needs to determine if it IS a Computation.

The second has a better bound on the domain of its input, as it must be
the representation of a Computation, and it needs to determine if this
Computation will Halt.

Mixing up variation specific definitions of these two variations will
lead to confusion. You really do need to understand what someone is
talking about an not just cut-and-pasting without understanding.

>
>> to a halt decider would be *DESCRIPTIONS* of elements in that domain,
>> i.e. the set of computations. The answer which it is expected to
>> return describes the behaviour of the actual computation described by
>> its input parameter, not the behaviour of the input string which is a
>> nonsensical claim.
>>
>
> According to Linz you are totally wrong on computations because
> computations always halt.

On 12/11/21 12:34 PM, olcott wrote:
> On 12/11/2021 11:20 AM, Richard Damon wrote:
>> On 12/11/21 12:00 PM, olcott wrote:
>>> On 12/11/2021 10:57 AM, olcott wrote:
>>>> On 12/11/2021 12:48 AM, André G. Isaak wrote:
>>>>> On 2021-12-10 22:13, olcott wrote:
>>>>>> On 12/10/2021 10:36 PM, André G. Isaak wrote:
>>>>>>> On 2021-12-10 16:47, olcott wrote:
>>>>>>>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-12-10 16:32, olcott wrote:
>>>>>>>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>>>> A halt decider, regardless of whether it is simulating or
>>>>>>>>>>> otherwise, reports on the behaviour of the computation
>>>>>>>>>>> represented by its input. This is very clearly stated by the
>>>>>>>>>>> conditions which Linz indicates in his proof.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This definition has confused too many people into thinking
>>>>>>>>>> that it is reporting on something besides the precise behavior
>>>>>>>>>> that is stipulated by the actual input.
>>>>>>>>>
>>>>>>>>> it hasn't confused anyone other than you. A halt decider does
>>>>>>>>> *not* report on the behaviour of its input. It reports on the
>>>>>>>>> behaviour of the computation represented by the input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> When the input to a halt decider is directly executable machine
>>>>>>>> code then that halt status decision is based on the actual
>>>>>>>> behavior of the actual execution of this input.
>>>>>>>
>>>>>>> The decision must describe the actual behaviour of the program
>>>>>>> described by the input, but it cannot be based on the execution
>>>>>>> of this input. If a putative halt decider simply executed its
>>>>>>> input it wouldn't constitute a decider since it would not halt if
>>>>>>> its input were a non-halting program. The input *describes* some
>>>>>>> program and input, just as the input to a TM-based decider
>>>>>>> decribes a computation.
>>>>>>>
>>>>>>
>>>>>> It has always been the case that a halt decider has only been
>>>>>> accountable for the actual behavior specified by its actual input.
>>>>>
>>>>> The actual input is a string. Strings don't have actual behaviour.
>>>>>
>>>>
>>>> An x86 machine code string does have behavior.
>>>>
>>>>>> The actual behavior specified by its actual input H(x,y) is most
>>>>>> precisely defined as the pure simulation of the finite string pair
>>>>>> input S(x,y) from the halt decider.
>>>>>
>>>>> By definition a halt decider describes the behaviour of the
>>>>> computation *described* by its input. The input itself doesn't
>>>>> specify any behaviour at all.
>>>>
>>>> An x86 machine code string does have behavior.
>>>>
>>>>>
>>>>>> H is a decider; which is a type of computable function; which is a
>>>>>> type of function; which only applies to its input parameters.
>>>>>
>>>>> Deciders are a type of Turing Machine (or Computer Program). Turing
>>>>> Machines are *not* functions.
>>>>
>>>> The Church Turing thesis only applies to computable functions.
>>>>
>>>>> They compute functions but they are not the same as the function
>>>>> they compute. And the Halting Function is *not* a computable
>>>>> function so referring to a halt decider as a "computable function"
>>>>> is even more wrong than describing it as a "function".
>>>>>
>>>>
>>>> If halting is not a computable function on some inputs then it is
>>>> outside of the scope of computer science investigation.
>>>>
>>>> Computable function
>>>> Computable functions are the basic objects of study in computability
>>>> theory. Computable functions are the formalized analogue of the
>>>> intuitive notion of algorithms, in the sense that a function is
>>>> computable if there exists an algorithm that can do the job of the
>>>> function, i.e. given an input of the function domain it can return
>>>> the corresponding output.
>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>
>>>>> You really need to stop using these terms until you learn what they
>>>>> mean. You embarrass yourself with every sentence you write.
>>>>>
>>>>>> No function is ever accountable for anything besides inputs in its
>>>>>> domain. These inputs in its domain are explicitly specified as
>>>>>> parameters.
>>>>>
>>>>> Functions have domains. Turing Machines/Computer programs have
>>>>> parameters. The parameters passed to a TM are *DESCRIPTIONS* of
>>>>> elements of the domain of the function which that TM computes. The
>>>>> domain of the
>>>
>>>
>>> int main() { P(P); } is not a PARAMETER to H thus has nothing to do
>>> with the correctness of H. H is only accountable for its actual input
>>> parameters.
>>
>> But P,P is its input, and the MEANING of P,P is running P(P)
>> unconstrained which is what that is.
>>
>
> When input such as P have been defined to have a dependency relationship
> on a specific halt decider like H the actual behavior of P(P) can only
> be correctly measured by the pure simulation of P(P) from H.
>

WRONG. You don't get to change definitions.

First, if H IS a pure simulation of its input, the BY DEFINITION it will
never abort its input and thus FAIL to return an answer for H(P,P).

Thus, by your definition, H just plain fails to be a decider for P(P),
and thus isn't a counter example for Linz. FAIL.

If H does abort its simulation, to return an answer, it is no longer a
Pure Simulation, and thus your definition is INCORRECT. FAIL.

The ONLY definition of Halting that actually applies is what happens
when the machine is actually run with that input, or equivalently given
as an input to a REAL Pure Simulation, and if H(P,P) returns 0, then
either of these will show that P(P) halts, and if H(P,P) doesn't return,
then H fails to be a decider.

Your H thus FAILS to be a correct decider for H(P,P).

> [Olcott 2021 generic halt deciding principle] Whenever the pure
> simulation of the input to simulating halt decider H(x,y) never stops
> running unless H aborts its simulation H correctly aborts this
> simulation and returns 0 for not halting.

FALSE. The correct answer for Non-Halting is, and only is, if the pure
simulation if the machine (that was given as an input to H) will NEVER
halt, under ANY conditions. Note, pure simulation never 'abort' their
simulations, so WILL

>
> The above provides a correct halt status decision for all inputs.

FALSE.

>
> H is a decider; which is a type of computable function; which is a type
> of function; which only applies to its input parameters.

Except the H your provide never returns an answer for H(P,P), so H is
not a decider.

If you replace H with a function that somehow aborts its simulation of
its input, then it no longer is the pure simulation needed by the
definition of Halting, so doesn't atually show the input is non-halting.

FAIL.

>
> No function is ever accountable for anything besides input parameters in
> its domain, thus the fact that int main() { P(P); }; has different
> behavior than int main() { H(P,P); }; does not make any difference at all.
>
>

But the input to H(P,P) needs to represent the program:

int main() { P(P); }

so that IS what it is responsible for, or your H isn't actually
following the requirements of a Halt Decider.

What it doesn't represent is the PARTIAL execution that H does of it.

FAIL.

On 12/11/2021 9:57 AM, olcott wrote:
> An x86 machine code string does have behavior.

That's like saying your driver's license has behaviors because it has
your name and picture on it.
--
Jeff Barnett

On 12/11/2021 1:44 PM, Jeff Barnett wrote:
> On 12/11/2021 9:57 AM, olcott wrote:
>> An x86 machine code string does have behavior.
>
> That's like saying your driver's license has behaviors because it has
> your name and picture on it.

This proves otherwise:

#include <stdint.h>
typedef void (*ptr)();

int H(ptr x, ptr y)
{ x(y);
return 1;
}

// Simplified Linz(1990) Ĥ
// and Strachey(1965) P
void P(ptr x)
{ if (H(x, x))
HERE: goto HERE;
}

int main(void)
{ P(P);
}

--
Copyright 2021 Pete Olcott

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

On 12/11/21 2:48 PM, olcott wrote:
> On 12/11/2021 1:44 PM, Jeff Barnett wrote:
>> On 12/11/2021 9:57 AM, olcott wrote:
>>> An x86 machine code string does have behavior.
>>
>> That's like saying your driver's license has behaviors because it has
>> your name and picture on it.
>
> This proves otherwise:
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y);
>   return 1;
> }
>
> // Simplified Linz(1990) Ĥ
> // and Strachey(1965) P
> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main(void)
> {
>   P(P);
> }
>
>

Right, and with Von Neuann machines, the loading of a 'data' address
into the PC becomes the conversion of a representation of the input into
a machine.

Second point, your above code is NOT the equivalent of a nested set of
machines each running its 'input', but is just a SINGLE Turing Machine
that just has a infinite loop (maybe generating an infinite tape unless
you optimize it away).

The key is that when main calls P(P), instead of a COPY of P, this says
that the 'input' P can't be on the tape, but is part of the machine
itself, similarly for H.

To really be the machine you claim you are building, main needs to load
(or have loaded) P from the COEF file, and also have a 'raw' copy of the
COEF file available to give to P.

Then each P passes to H two pointers to this COEF file data, and H
converts the first one to a FRESH copy of P, and pass it the second one.

THEN H is running its input 'from a COFF file'.

Note, the COFF file needs to include the FULL program P, including its
copy of H (no linking to the currently loaded image allowed).

Input string themselves do NOT have behavior.

Only when we interpret them as programs do the have behavior.

And that behavior requires a definition of how we convert between the
'program' and 'representation' which defines what a UTM is.

In one sense, the CPU IS the UTM for x86 code.

On 12/11/2021 12:48 PM, olcott wrote:
> On 12/11/2021 1:44 PM, Jeff Barnett wrote:
>> On 12/11/2021 9:57 AM, olcott wrote:
>>> An x86 machine code string does have behavior.
>>
>> That's like saying your driver's license has behaviors because it has
>> your name and picture on it.
>
> This proves otherwise:
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y);
>   return 1;
> }
>
> // Simplified Linz(1990) Ĥ
> // and Strachey(1965) P
> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main(void)
> {
>   P(P);
> }
You are disassociating again. Concentrate, No! No! No! Concentrate
harder. It really wont hurt that much.
--
Jeff Barnett