On 9/18/22 3:30 PM, olcott wrote:
> On 9/18/2022 2:21 PM, Richard Damon wrote:
>> On 9/18/22 3:12 PM, olcott wrote:
>>> On 9/18/2022 1:57 PM, Richard Damon wrote:
>>>> On 9/18/22 2:49 PM, olcott wrote:
>>>>> On 9/18/2022 1:25 PM, Richard Damon wrote:
>>>>>> On 9/18/22 2:06 PM, olcott wrote:
>>>>>>> On 9/18/2022 12:56 PM, Richard Damon wrote:
>>>>>>>> On 9/18/22 1:52 PM, olcott wrote:
>>>>>>>>> On 9/18/2022 12:49 PM, Richard Damon wrote:
>>>>>>>>>> On 9/18/22 1:44 PM, olcott wrote:
>>>>>>>>>>> On 9/18/2022 12:37 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/18/22 1:28 PM, olcott wrote:
>>>>>>>>>>>>> On 9/18/2022 12:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/18/22 1:01 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/18/2022 11:29 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/18/22 11:18 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/18/2022 6:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/18/22 12:12 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> This instance of Hx(Px,Px) correctly reports its direct
>>>>>>>>>>>>>>>>>>> execution of its input never halts:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int Hx(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>    return 0;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, it doesn't. It is only correct *IF* its input
>>>>>>>>>>>>>>>>>> wouldn't halt.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>  > If Hx DOES directly execute its input, then it will
>>>>>>>>>>>>>>>>> NEVER report
>>>>>>>>>>>>>>>>>  > non-halting, and yes, then the input Px built from
>>>>>>>>>>>>>>>>> THAT Hx will be
>>>>>>>>>>>>>>>>>  > non-halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And since Hx doesn't directly execute its input,
>>>>>>>>>>>>>>> Its basis for correctly deciding that the direct
>>>>>>>>>>>>>>> execution of this input would never halt is a wild guess.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, it guesses wrong about the actual question that is
>>>>>>>>>>>>>> being asked of it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Why do I have to tell you the same thing 500 times and you
>>>>>>>>>>>>> still don't get it?  My theory is that you are a liar only
>>>>>>>>>>>>> interested in rebuttal.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No halt decider ever directly executes its input yet must
>>>>>>>>>>>>> correctly predict the behavior of this directly executed or
>>>>>>>>>>>>> correctly simulated input.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Right, THE behavior of direct execution or correct
>>>>>>>>>>>> simulation, not by the decider, but just done.
>>>>>>>>>>>>
>>>>>>>>>>>> If you want to add the words "by the decider", you need a
>>>>>>>>>>>> source for that, which you have failed to do.
>>>>>>>>>>>
>>>>>>>>>>> First you must agree that every Hx returning 0 does correctly
>>>>>>>>>>> report the halt status of the behavior of what its direct
>>>>>>>>>>> execution of Px(Px) would be if it directly executed this input.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No. because no Hx that does a direct execution even gives an
>>>>>>>>>> answer, so your statement is ILLOGICAL.
>>>>>>>>> Halt deciders are not supposed to do a direct execution and you
>>>>>>>>> know this so what the Hell are you trying to pull here?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Right, the aren't supposed to so why do you think they need to
>>>>>>>> act like they did?
>>>>>>> Halt deciders must correctly predict what the behavior of their
>>>>>>> directly executed or correctly simulated input would be:
>>>>>>>
>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>  > If Hx DOES directly execute its input, then it
>>>>>>>  > will NEVER report non-halting, and yes, then the
>>>>>>>  > input Px built from THAT Hx will be non-halting.
>>>>>>>
>>>>>>> So you have already agreed that Hx(Px,Px)==0 is correct.
>>>>>>>
>>>>>>
>>>>>> Where?
>>>>>
>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>  > If Hx DOES directly execute its input, then it
>>>>>  > will NEVER report non-halting, and yes, then the
>>>>>  > input Px built from THAT Hx will be non-halting.
>>>>>
>>>>> The infinite set of every Hx element of the Hx/Px pairs that
>>>>> directly executes its input never halts therefore when Hx(Px,Px)==0
>>>>> means that its own direct execution of its input would never halt
>>>>> it is necessarily correct.
>>>>>
>>>> Nope. More proof of your stupidity.
>>>>
>>>> NO Hx(Px,Px) that returns 0 has a Px that is based on an Hx that
>>>> does a direct execution, by the definition of Px.
>>> Since you already know that no halt decider ever directly executes
>>> its input and instead only predicts what the behavior of this
>>> directly executed input would be *you have proven to be a liar*
>>>
>>> (1) Every element of the infinite set of Hx/Px pairs where Hx
>>> directly executes its input never halts
>>
>> Which is a subset of ONLY those Px built on an Hx that NEVER returns.
>>
>>>
>>> (2) Every Hx(Px,Px) that returns 0 correctly predicts what the
>>> behavior of its input would be if it directly executed this input
>>> because the adaptation of this Hx/Px pair is already a member of (1).
>>>
>>
>> But its input is NOT part of the subset from above, so the conclusion
>> is INVALID.
>>
>>> int Hx(ptr x, ptr y)
>>> {
>>>    return 0;
>>> }
>>>
>>> adapted so it directly executes its input becomes
>>
>> Which is an INVALID change to the input. PERIOD.
>>
>> This means your Hx is now handling a DIFFERENT input, and thus your
>> logic is INVALID.
>>
>>>
>>> int Hx(ptr x, ptr y)
>>> {
>>>    x(y);
>>>    return 0;
>>> }
>>>
>>> which is already an element of (1).
>>>
>>>
> Therefore Hx(Px,Px)==0 is necessarily correct about what the behavior of
> its the input would be if it directly executed this input.
>

On 9/18/2022 3:04 PM, Richard Damon wrote:
> On 9/18/22 3:30 PM, olcott wrote:
>> On 9/18/2022 2:21 PM, Richard Damon wrote:
>>> On 9/18/22 3:12 PM, olcott wrote:
>>>> On 9/18/2022 1:57 PM, Richard Damon wrote:
>>>>> On 9/18/22 2:49 PM, olcott wrote:
>>>>>> On 9/18/2022 1:25 PM, Richard Damon wrote:
>>>>>>> On 9/18/22 2:06 PM, olcott wrote:
>>>>>>>> On 9/18/2022 12:56 PM, Richard Damon wrote:
>>>>>>>>> On 9/18/22 1:52 PM, olcott wrote:
>>>>>>>>>> On 9/18/2022 12:49 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/18/22 1:44 PM, olcott wrote:
>>>>>>>>>>>> On 9/18/2022 12:37 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/18/22 1:28 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/18/2022 12:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/18/22 1:01 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/18/2022 11:29 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/18/22 11:18 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/18/2022 6:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/18/22 12:12 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> This instance of Hx(Px,Px) correctly reports its direct
>>>>>>>>>>>>>>>>>>>> execution of its input never halts:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> int Hx(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>    return 0;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No, it doesn't. It is only correct *IF* its input
>>>>>>>>>>>>>>>>>>> wouldn't halt.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>  > If Hx DOES directly execute its input, then it will
>>>>>>>>>>>>>>>>>> NEVER report
>>>>>>>>>>>>>>>>>>  > non-halting, and yes, then the input Px built from
>>>>>>>>>>>>>>>>>> THAT Hx will be
>>>>>>>>>>>>>>>>>>  > non-halting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And since Hx doesn't directly execute its input,
>>>>>>>>>>>>>>>> Its basis for correctly deciding that the direct
>>>>>>>>>>>>>>>> execution of this input would never halt is a wild guess.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, it guesses wrong about the actual question that is
>>>>>>>>>>>>>>> being asked of it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why do I have to tell you the same thing 500 times and you
>>>>>>>>>>>>>> still don't get it?  My theory is that you are a liar only
>>>>>>>>>>>>>> interested in rebuttal.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No halt decider ever directly executes its input yet must
>>>>>>>>>>>>>> correctly predict the behavior of this directly executed
>>>>>>>>>>>>>> or correctly simulated input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, THE behavior of direct execution or correct
>>>>>>>>>>>>> simulation, not by the decider, but just done.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you want to add the words "by the decider", you need a
>>>>>>>>>>>>> source for that, which you have failed to do.
>>>>>>>>>>>>
>>>>>>>>>>>> First you must agree that every Hx returning 0 does
>>>>>>>>>>>> correctly report the halt status of the behavior of what its
>>>>>>>>>>>> direct execution of Px(Px) would be if it directly executed
>>>>>>>>>>>> this input.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No. because no Hx that does a direct execution even gives an
>>>>>>>>>>> answer, so your statement is ILLOGICAL.
>>>>>>>>>> Halt deciders are not supposed to do a direct execution and
>>>>>>>>>> you know this so what the Hell are you trying to pull here?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right, the aren't supposed to so why do you think they need to
>>>>>>>>> act like they did?
>>>>>>>> Halt deciders must correctly predict what the behavior of their
>>>>>>>> directly executed or correctly simulated input would be:
>>>>>>>>
>>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>>  > If Hx DOES directly execute its input, then it
>>>>>>>>  > will NEVER report non-halting, and yes, then the
>>>>>>>>  > input Px built from THAT Hx will be non-halting.
>>>>>>>>
>>>>>>>> So you have already agreed that Hx(Px,Px)==0 is correct.
>>>>>>>>
>>>>>>>
>>>>>>> Where?
>>>>>>
>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>  > If Hx DOES directly execute its input, then it
>>>>>>  > will NEVER report non-halting, and yes, then the
>>>>>>  > input Px built from THAT Hx will be non-halting.
>>>>>>
>>>>>> The infinite set of every Hx element of the Hx/Px pairs that
>>>>>> directly executes its input never halts therefore when
>>>>>> Hx(Px,Px)==0 means that its own direct execution of its input
>>>>>> would never halt it is necessarily correct.
>>>>>>
>>>>> Nope. More proof of your stupidity.
>>>>>
>>>>> NO Hx(Px,Px) that returns 0 has a Px that is based on an Hx that
>>>>> does a direct execution, by the definition of Px.
>>>> Since you already know that no halt decider ever directly executes
>>>> its input and instead only predicts what the behavior of this
>>>> directly executed input would be *you have proven to be a liar*
>>>>
>>>> (1) Every element of the infinite set of Hx/Px pairs where Hx
>>>> directly executes its input never halts
>>>
>>> Which is a subset of ONLY those Px built on an Hx that NEVER returns.
>>>
>>>>
>>>> (2) Every Hx(Px,Px) that returns 0 correctly predicts what the
>>>> behavior of its input would be if it directly executed this input
>>>> because the adaptation of this Hx/Px pair is already a member of (1).
>>>>
>>>
>>> But its input is NOT part of the subset from above, so the conclusion
>>> is INVALID.
>>>
>>>> int Hx(ptr x, ptr y)
>>>> {
>>>>    return 0;
>>>> }
>>>>
>>>> adapted so it directly executes its input becomes
>>>
>>> Which is an INVALID change to the input. PERIOD.
>>>
>>> This means your Hx is now handling a DIFFERENT input, and thus your
>>> logic is INVALID.
>>>
>>>>
>>>> int Hx(ptr x, ptr y)
>>>> {
>>>>    x(y);
>>>>    return 0;
>>>> }
>>>>
>>>> which is already an element of (1).
>>>>
>>>>
>> Therefore Hx(Px,Px)==0 is necessarily correct about what the behavior
>> of its the input would be if it directly executed this input.
>>
>
> No, it is IMPOSSIBLE to be correct,
When all X are Y then then damn thing that says all X are Y is
necessarily correct.

On 9/18/22 4:19 PM, olcott wrote:
> On 9/18/2022 3:04 PM, Richard Damon wrote:
>> On 9/18/22 3:30 PM, olcott wrote:
>>> On 9/18/2022 2:21 PM, Richard Damon wrote:
>>>> On 9/18/22 3:12 PM, olcott wrote:
>>>>> On 9/18/2022 1:57 PM, Richard Damon wrote:
>>>>>> On 9/18/22 2:49 PM, olcott wrote:
>>>>>>> On 9/18/2022 1:25 PM, Richard Damon wrote:
>>>>>>>> On 9/18/22 2:06 PM, olcott wrote:
>>>>>>>>> On 9/18/2022 12:56 PM, Richard Damon wrote:
>>>>>>>>>> On 9/18/22 1:52 PM, olcott wrote:
>>>>>>>>>>> On 9/18/2022 12:49 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/18/22 1:44 PM, olcott wrote:
>>>>>>>>>>>>> On 9/18/2022 12:37 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/18/22 1:28 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/18/2022 12:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 9/18/22 1:01 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/18/2022 11:29 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/18/22 11:18 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/18/2022 6:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/18/22 12:12 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> This instance of Hx(Px,Px) correctly reports its
>>>>>>>>>>>>>>>>>>>>> direct
>>>>>>>>>>>>>>>>>>>>> execution of its input never halts:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int Hx(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>    return 0;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, it doesn't. It is only correct *IF* its input
>>>>>>>>>>>>>>>>>>>> wouldn't halt.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>  > If Hx DOES directly execute its input, then it
>>>>>>>>>>>>>>>>>>> will NEVER report
>>>>>>>>>>>>>>>>>>>  > non-halting, and yes, then the input Px built from
>>>>>>>>>>>>>>>>>>> THAT Hx will be
>>>>>>>>>>>>>>>>>>>  > non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And since Hx doesn't directly execute its input,
>>>>>>>>>>>>>>>>> Its basis for correctly deciding that the direct
>>>>>>>>>>>>>>>>> execution of this input would never halt is a wild guess.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, it guesses wrong about the actual question that is
>>>>>>>>>>>>>>>> being asked of it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why do I have to tell you the same thing 500 times and
>>>>>>>>>>>>>>> you still don't get it?  My theory is that you are a liar
>>>>>>>>>>>>>>> only interested in rebuttal.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No halt decider ever directly executes its input yet must
>>>>>>>>>>>>>>> correctly predict the behavior of this directly executed
>>>>>>>>>>>>>>> or correctly simulated input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, THE behavior of direct execution or correct
>>>>>>>>>>>>>> simulation, not by the decider, but just done.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you want to add the words "by the decider", you need a
>>>>>>>>>>>>>> source for that, which you have failed to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> First you must agree that every Hx returning 0 does
>>>>>>>>>>>>> correctly report the halt status of the behavior of what
>>>>>>>>>>>>> its direct execution of Px(Px) would be if it directly
>>>>>>>>>>>>> executed this input.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No. because no Hx that does a direct execution even gives an
>>>>>>>>>>>> answer, so your statement is ILLOGICAL.
>>>>>>>>>>> Halt deciders are not supposed to do a direct execution and
>>>>>>>>>>> you know this so what the Hell are you trying to pull here?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, the aren't supposed to so why do you think they need to
>>>>>>>>>> act like they did?
>>>>>>>>> Halt deciders must correctly predict what the behavior of their
>>>>>>>>> directly executed or correctly simulated input would be:
>>>>>>>>>
>>>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>>>  > If Hx DOES directly execute its input, then it
>>>>>>>>>  > will NEVER report non-halting, and yes, then the
>>>>>>>>>  > input Px built from THAT Hx will be non-halting.
>>>>>>>>>
>>>>>>>>> So you have already agreed that Hx(Px,Px)==0 is correct.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Where?
>>>>>>>
>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>  > If Hx DOES directly execute its input, then it
>>>>>>>  > will NEVER report non-halting, and yes, then the
>>>>>>>  > input Px built from THAT Hx will be non-halting.
>>>>>>>
>>>>>>> The infinite set of every Hx element of the Hx/Px pairs that
>>>>>>> directly executes its input never halts therefore when
>>>>>>> Hx(Px,Px)==0 means that its own direct execution of its input
>>>>>>> would never halt it is necessarily correct.
>>>>>>>
>>>>>> Nope. More proof of your stupidity.
>>>>>>
>>>>>> NO Hx(Px,Px) that returns 0 has a Px that is based on an Hx that
>>>>>> does a direct execution, by the definition of Px.
>>>>> Since you already know that no halt decider ever directly executes
>>>>> its input and instead only predicts what the behavior of this
>>>>> directly executed input would be *you have proven to be a liar*
>>>>>
>>>>> (1) Every element of the infinite set of Hx/Px pairs where Hx
>>>>> directly executes its input never halts
>>>>
>>>> Which is a subset of ONLY those Px built on an Hx that NEVER returns.
>>>>
>>>>>
>>>>> (2) Every Hx(Px,Px) that returns 0 correctly predicts what the
>>>>> behavior of its input would be if it directly executed this input
>>>>> because the adaptation of this Hx/Px pair is already a member of (1).
>>>>>
>>>>
>>>> But its input is NOT part of the subset from above, so the
>>>> conclusion is INVALID.
>>>>
>>>>> int Hx(ptr x, ptr y)
>>>>> {
>>>>>    return 0;
>>>>> }
>>>>>
>>>>> adapted so it directly executes its input becomes
>>>>
>>>> Which is an INVALID change to the input. PERIOD.
>>>>
>>>> This means your Hx is now handling a DIFFERENT input, and thus your
>>>> logic is INVALID.
>>>>
>>>>>
>>>>> int Hx(ptr x, ptr y)
>>>>> {
>>>>>    x(y);
>>>>>    return 0;
>>>>> }
>>>>>
>>>>> which is already an element of (1).
>>>>>
>>>>>
>>> Therefore Hx(Px,Px)==0 is necessarily correct about what the behavior
>>> of its the input would be if it directly executed this input.
>>>
>>
>> No, it is IMPOSSIBLE to be correct,
> When all X are Y then then damn thing that says all X are Y is
> necessarily correct.

On Saturday, September 17, 2022 at 2:55:33 PM UTC-7, olcott wrote:
> On 9/17/2022 4:31 PM, dklei...@gmail.com wrote:
> > On Friday, September 16, 2022 at 6:03:56 PM UTC-7, olcott wrote:
> >> On 9/16/2022 7:58 PM, dklei...@gmail.com wrote:
> >>> On Friday, September 16, 2022 at 12:36:09 PM UTC-7, olcott wrote:
> >>>> On 9/16/2022 2:04 PM, dklei...@gmail.com wrote:
> >>>>> On Friday, September 16, 2022 at 9:17:21 AM UTC-7, olcott wrote:
> >>>>>> void Px(ptr x)
> >>>>>> {
> >>>>>> int Halt_Status = Hx(x, x);
> >>>>>> if (Halt_Status)
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", Hx(Px, Px));
> >>>>>> }
> >>>>>>
> >>>>> This means nothing without a definition of Hx
> >>>>> Once again - what are you trying to prove?
> >>>> You have to carefully study every single word that I said and then you
> >>>> will see that Hx/Px pairs include an infinite set of definitions of Hx.
> >>>>
> >>> You're assuming something that is not written here. You haven't
> >>> defined Hx/Px pairs. What are you assuming?
> >> It is written in the part that you chopped out:
> >>
> > I don't think so. But if you are making an argument for a proposition
> > it is usually expected that all the terms you use be defined as part
> > of your argument.
> >
> >>> There are zero elements of infinite set of Hx/Px pairs such that the
> >>> correct *partial or complete* simulation of Px by Hx reaches the final
> >>> state of Px.
> >>
> > This is not easy to translate into comprehensible mathematical
> > terms. What is most missing is a clear definition of what
> > "simulation" means. Otherwise "reaches the final state of Px" has
> > no recognizable meaning.
> >
> These are common terms of the art it seems ridiculously disingenuous
> that you pretend to not know what these terms mean. I define them anyway.
> > If we achieved that much clarity then it seems that Hx is any
> > function of two variables such that Hx simulates Px.
> >
> In the key subset of the infinite set of Hx/Px pairs Hx is any compiled
> C function that correctly simulates one or more steps of the machine
> language of Px (its first argument) using an x86 emulator.
> > Then you assert the theorem that the simulation of Px by Hx
> > never reaches the final state of Px.
> This is self-evident on the basis of the source-code of Px.
> The C level "final state" of Px is its "return" instruction.
> > I think you mean that
> > this theorem is illustrated by the "if Px returns, Hx(Px, Px)
> > returns 0". But these are not equivalent statements. Which
> > do you intend?
> >
> The Hx elements of the Hx/Px pairs that return 0 correctly answer the
> question: Does any Px correctly simulated by Hx halt?
>
You still haven't explained what you mean by "simulate". I
think your notion of simulate requires the simulating
program to have "the source code" of the simulated program.
I see that the Turing Machine definition of h-hat makes
that assumption. But Turing Machines themselves are not
well-formed mathematical concepts so they can get away
with that (after proper special definitions). If you were to
argue in the world of Turing Machines you might be more
plausible but you are attempting to simulate (used here
in its ordinary language sense) Turing Machines in C.

I would use "emulate" to mean actually "run" a Turing
Machine. These ideas (Turing Machines) fit quite poorly
into mathematics and many people consider them outside
the field. That is, formal logic is not mathematics.

On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
> On Saturday, September 17, 2022 at 2:55:33 PM UTC-7, olcott wrote:
>> On 9/17/2022 4:31 PM, dklei...@gmail.com wrote:
>>> On Friday, September 16, 2022 at 6:03:56 PM UTC-7, olcott wrote:
>>>> On 9/16/2022 7:58 PM, dklei...@gmail.com wrote:
>>>>> On Friday, September 16, 2022 at 12:36:09 PM UTC-7, olcott wrote:
>>>>>> On 9/16/2022 2:04 PM, dklei...@gmail.com wrote:
>>>>>>> On Friday, September 16, 2022 at 9:17:21 AM UTC-7, olcott wrote:
>>>>>>>> void Px(ptr x)
>>>>>>>> {
>>>>>>>> int Halt_Status = Hx(x, x);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", Hx(Px, Px));
>>>>>>>> }
>>>>>>>>
>>>>>>> This means nothing without a definition of Hx
>>>>>>> Once again - what are you trying to prove?
>>>>>> You have to carefully study every single word that I said and then you
>>>>>> will see that Hx/Px pairs include an infinite set of definitions of Hx.
>>>>>>
>>>>> You're assuming something that is not written here. You haven't
>>>>> defined Hx/Px pairs. What are you assuming?
>>>> It is written in the part that you chopped out:
>>>>
>>> I don't think so. But if you are making an argument for a proposition
>>> it is usually expected that all the terms you use be defined as part
>>> of your argument.
>>>
>>>>> There are zero elements of infinite set of Hx/Px pairs such that the
>>>>> correct *partial or complete* simulation of Px by Hx reaches the final
>>>>> state of Px.
>>>>
>>> This is not easy to translate into comprehensible mathematical
>>> terms. What is most missing is a clear definition of what
>>> "simulation" means. Otherwise "reaches the final state of Px" has
>>> no recognizable meaning.
>>>
>> These are common terms of the art it seems ridiculously disingenuous
>> that you pretend to not know what these terms mean. I define them anyway.
>>> If we achieved that much clarity then it seems that Hx is any
>>> function of two variables such that Hx simulates Px.
>>>
>> In the key subset of the infinite set of Hx/Px pairs Hx is any compiled
>> C function that correctly simulates one or more steps of the machine
>> language of Px (its first argument) using an x86 emulator.
>>> Then you assert the theorem that the simulation of Px by Hx
>>> never reaches the final state of Px.
>> This is self-evident on the basis of the source-code of Px.
>> The C level "final state" of Px is its "return" instruction.
>>> I think you mean that
>>> this theorem is illustrated by the "if Px returns, Hx(Px, Px)
>>> returns 0". But these are not equivalent statements. Which
>>> do you intend?
>>>
>> The Hx elements of the Hx/Px pairs that return 0 correctly answer the
>> question: Does any Px correctly simulated by Hx halt?
>>
> You still haven't explained what you mean by "simulate". I
> think your notion of simulate requires the simulating
> program to have "the source code" of the simulated program.

There are programs called x86 emulators that can act as if they are
80386 processors. These emulators can act as if they are directly
executing 80386 machine language object code. The output of the
Microsoft C compiler is a COFF object file. This file contains the
machine language that the compiler produces when compiling a C program.
This is before the linker links the C libraries.

> I see that the Turing Machine definition of h-hat makes
> that assumption. But Turing Machines themselves are not
> well-formed mathematical concepts so they can get away
> with that (after proper special definitions). If you were to
> argue in the world of Turing Machines you might be more
> plausible but you are attempting to simulate (used here
> in its ordinary language sense) Turing Machines in C.
>
> I would use "emulate" to mean actually "run" a Turing
> Machine. These ideas (Turing Machines) fit quite poorly
> into mathematics and many people consider them outside
> the field. That is, formal logic is not mathematics.

--
Copyright 2022 Pete Olcott

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

On 9/18/22 1:58 PM, olcott wrote:
> On 9/18/2022 12:56 PM, Richard Damon wrote:
>> On 9/18/22 1:52 PM, olcott wrote:
>>> On 9/18/2022 12:49 PM, Richard Damon wrote:
>>>> On 9/18/22 1:44 PM, olcott wrote:
>>>>> On 9/18/2022 12:37 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/18/22 1:28 PM, olcott wrote:
>>>>>>> On 9/18/2022 12:23 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/18/22 1:01 PM, olcott wrote:
>>>>>>>>> On 9/18/2022 11:29 AM, Richard Damon wrote:
>>>>>>>>>> On 9/18/22 11:18 AM, olcott wrote:
>>>>>>>>>>> On 9/18/2022 6:27 AM, Richard Damon wrote:
>>>>>>>>>>>> On 9/18/22 12:12 AM, olcott wrote:
>>>>>>>>>>>>> This instance of Hx(Px,Px) correctly reports its direct
>>>>>>>>>>>>> execution of its input never halts:
>>>>>>>>>>>>>
>>>>>>>>>>>>> int Hx(ptr x, ptr y)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    return 0;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, it doesn't. It is only correct *IF* its input wouldn't
>>>>>>>>>>>> halt.
>>>>>>>>>>>>
>>>>>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>>>>>  > If Hx DOES directly execute its input, then it will NEVER
>>>>>>>>>>> report
>>>>>>>>>>>  > non-halting, and yes, then the input Px built from THAT Hx
>>>>>>>>>>> will be
>>>>>>>>>>>  > non-halting.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And since Hx doesn't directly execute its input,
>>>>>>>>> Its basis for correctly deciding that the direct execution of
>>>>>>>>> this input would never halt is a wild guess.
>>>>>>>>
>>>>>>>> So, it guesses wrong about the actual question that is being
>>>>>>>> asked of it.
>>>>>>>>
>>>>>>> Why do I have to tell you the same thing 500 times and you still
>>>>>>> don't get it?  My theory is that you are a liar only interested
>>>>>>> in rebuttal.
>>>>>>>
>>>>>>> No halt decider ever directly executes its input yet must
>>>>>>> correctly predict the behavior of this directly executed or
>>>>>>> correctly simulated input.
>>>>>>>
>>>>>>
>>>>>> Right, THE behavior of direct execution or correct simulation, not
>>>>>> by the decider, but just done.
>>>>>>
>>>>>> If you want to add the words "by the decider", you need a source
>>>>>> for that, which you have failed to do.
>>>>>
>>>>> First you must agree that every Hx returning 0 does correctly
>>>>> report the halt status of the behavior of what its direct execution
>>>>> of Px(Px) would be if it directly executed this input.
>>>>>
>>>>
>>>> No. because no Hx that does a direct execution even gives an answer,
>>>> so your statement is ILLOGICAL.
>>> Halt deciders are not supposed to do a direct execution and you know
>>> this so what the Hell are you trying to pull here?
>>>
>>
>> Right, the aren't supposed to so why do you think they need to act
>> like they did?
> Halt deciders must correctly predict what the behavior of their directly
> executed or correctly simulated input would be Hx(Px,Px)==0 does that.
>

Why do you say that?

You have already agreed that if main calls P(P), and H(P,P) returns 0
that P(P) will return in finite time, so the "directly executed input"
of H(P,P) is shown to be Halting in this case.

How is 0 the correct answer for a Halting Input.

Or, do you think that main calling P(P) will not see it return when
H(P,P) returns 0?

On 9/18/2022 9:34 PM, Richard Damon wrote:
> On 9/18/22 1:58 PM, olcott wrote:
>> On 9/18/2022 12:56 PM, Richard Damon wrote:
>>> On 9/18/22 1:52 PM, olcott wrote:
>>>> On 9/18/2022 12:49 PM, Richard Damon wrote:
>>>>> On 9/18/22 1:44 PM, olcott wrote:
>>>>>> On 9/18/2022 12:37 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/18/22 1:28 PM, olcott wrote:
>>>>>>>> On 9/18/2022 12:23 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/18/22 1:01 PM, olcott wrote:
>>>>>>>>>> On 9/18/2022 11:29 AM, Richard Damon wrote:
>>>>>>>>>>> On 9/18/22 11:18 AM, olcott wrote:
>>>>>>>>>>>> On 9/18/2022 6:27 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/18/22 12:12 AM, olcott wrote:
>>>>>>>>>>>>>> This instance of Hx(Px,Px) correctly reports its direct
>>>>>>>>>>>>>> execution of its input never halts:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int Hx(ptr x, ptr y)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>    return 0;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, it doesn't. It is only correct *IF* its input wouldn't
>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>
>>>>>>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>>>>>>  > If Hx DOES directly execute its input, then it will NEVER
>>>>>>>>>>>> report
>>>>>>>>>>>>  > non-halting, and yes, then the input Px built from THAT
>>>>>>>>>>>> Hx will be
>>>>>>>>>>>>  > non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And since Hx doesn't directly execute its input,
>>>>>>>>>> Its basis for correctly deciding that the direct execution of
>>>>>>>>>> this input would never halt is a wild guess.
>>>>>>>>>
>>>>>>>>> So, it guesses wrong about the actual question that is being
>>>>>>>>> asked of it.
>>>>>>>>>
>>>>>>>> Why do I have to tell you the same thing 500 times and you still
>>>>>>>> don't get it?  My theory is that you are a liar only interested
>>>>>>>> in rebuttal.
>>>>>>>>
>>>>>>>> No halt decider ever directly executes its input yet must
>>>>>>>> correctly predict the behavior of this directly executed or
>>>>>>>> correctly simulated input.
>>>>>>>>
>>>>>>>
>>>>>>> Right, THE behavior of direct execution or correct simulation,
>>>>>>> not by the decider, but just done.
>>>>>>>
>>>>>>> If you want to add the words "by the decider", you need a source
>>>>>>> for that, which you have failed to do.
>>>>>>
>>>>>> First you must agree that every Hx returning 0 does correctly
>>>>>> report the halt status of the behavior of what its direct
>>>>>> execution of Px(Px) would be if it directly executed this input.
>>>>>>
>>>>>
>>>>> No. because no Hx that does a direct execution even gives an
>>>>> answer, so your statement is ILLOGICAL.
>>>> Halt deciders are not supposed to do a direct execution and you know
>>>> this so what the Hell are you trying to pull here?
>>>>
>>>
>>> Right, the aren't supposed to so why do you think they need to act
>>> like they did?
>> Halt deciders must correctly predict what the behavior of their
>> directly executed or correctly simulated input would be Hx(Px,Px)==0
>> does that.
>>
>
> Why do you say that?
>
> You have already agreed that if main calls P(P), and H(P,P) returns 0
> that P(P) will return in finite time, so the "directly executed input"
> of H(P,P) is shown to be Halting in this case.

The only correct invocation of P(P) that must considered is the
invocation by H. As I have been always saying the other one is irrelevant.

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

This instance of P never halts.

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

On 9/18/22 11:18 PM, olcott wrote:
> On 9/18/2022 9:34 PM, Richard Damon wrote:
>> On 9/18/22 1:58 PM, olcott wrote:
>>> On 9/18/2022 12:56 PM, Richard Damon wrote:
>>>> On 9/18/22 1:52 PM, olcott wrote:
>>>>> On 9/18/2022 12:49 PM, Richard Damon wrote:
>>>>>> On 9/18/22 1:44 PM, olcott wrote:
>>>>>>> On 9/18/2022 12:37 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/18/22 1:28 PM, olcott wrote:
>>>>>>>>> On 9/18/2022 12:23 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/18/22 1:01 PM, olcott wrote:
>>>>>>>>>>> On 9/18/2022 11:29 AM, Richard Damon wrote:
>>>>>>>>>>>> On 9/18/22 11:18 AM, olcott wrote:
>>>>>>>>>>>>> On 9/18/2022 6:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/18/22 12:12 AM, olcott wrote:
>>>>>>>>>>>>>>> This instance of Hx(Px,Px) correctly reports its direct
>>>>>>>>>>>>>>> execution of its input never halts:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int Hx(ptr x, ptr y)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    return 0;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it doesn't. It is only correct *IF* its input wouldn't
>>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>>>>>>>  > If Hx DOES directly execute its input, then it will
>>>>>>>>>>>>> NEVER report
>>>>>>>>>>>>>  > non-halting, and yes, then the input Px built from THAT
>>>>>>>>>>>>> Hx will be
>>>>>>>>>>>>>  > non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And since Hx doesn't directly execute its input,
>>>>>>>>>>> Its basis for correctly deciding that the direct execution of
>>>>>>>>>>> this input would never halt is a wild guess.
>>>>>>>>>>
>>>>>>>>>> So, it guesses wrong about the actual question that is being
>>>>>>>>>> asked of it.
>>>>>>>>>>
>>>>>>>>> Why do I have to tell you the same thing 500 times and you
>>>>>>>>> still don't get it?  My theory is that you are a liar only
>>>>>>>>> interested in rebuttal.
>>>>>>>>>
>>>>>>>>> No halt decider ever directly executes its input yet must
>>>>>>>>> correctly predict the behavior of this directly executed or
>>>>>>>>> correctly simulated input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Right, THE behavior of direct execution or correct simulation,
>>>>>>>> not by the decider, but just done.
>>>>>>>>
>>>>>>>> If you want to add the words "by the decider", you need a source
>>>>>>>> for that, which you have failed to do.
>>>>>>>
>>>>>>> First you must agree that every Hx returning 0 does correctly
>>>>>>> report the halt status of the behavior of what its direct
>>>>>>> execution of Px(Px) would be if it directly executed this input.
>>>>>>>
>>>>>>
>>>>>> No. because no Hx that does a direct execution even gives an
>>>>>> answer, so your statement is ILLOGICAL.
>>>>> Halt deciders are not supposed to do a direct execution and you
>>>>> know this so what the Hell are you trying to pull here?
>>>>>
>>>>
>>>> Right, the aren't supposed to so why do you think they need to act
>>>> like they did?
>>> Halt deciders must correctly predict what the behavior of their
>>> directly executed or correctly simulated input would be Hx(Px,Px)==0
>>> does that.
>>>
>>
>> Why do you say that?
>>
>> You have already agreed that if main calls P(P), and H(P,P) returns 0
>> that P(P) will return in finite time, so the "directly executed input"
>> of H(P,P) is shown to be Halting in this case.
>
> The only correct invocation of P(P) that must considered is the
> invocation by H. As I have been always saying the other one is irrelevant.
>
> int H(ptr x, ptr y)
> {
>   x(y);
> }
>
>
> This instance of P never halts.
>
>

No, wrong terminology.

That VERSION of P never halts, and that version of H never gives an
answer, so is wrong.

INSTANCES are identical copies, they are the SAME computation.

Change H, you change P, and thus have a different VERSION.

You are just showing the already well known fact that the "Impossible
Program" is only designed to confound one given decider, the one that is
claimed to be correct for ALL inputs, and thus for the H^/P built on it.

It is well known that other deciders might be correct in deciding on an
H^/P built for a different decider, they just can't be correct in
deciding on the one built on them.

You are just proving your ignornance of the topic.

On Saturday, September 17, 2022 at 9:26:18 PM UTC+1, olcott wrote:
> On 9/17/2022 3:19 PM, Paul N wrote:
> > On Saturday, September 17, 2022 at 9:12:24 PM UTC+1, olcott wrote:
> >> I have fully operational code that proves my point all you have is
> >> incoherent misconceptions.
> >>
> >> *Complete halt deciding system including*
> >> *(a) x86utm operating system*
> >> *(b) complete x86 emulator*
> >> *(c) All of the various halt deciders and their inputs are contained in
> >> Halt7.c*
> >> https://liarparadox.org/2022_09_07.zip
> >
> > While you claim to have fully operational code, it's a pretty safe bet that you will not actually run it and answer the following two questions about it:
> >
> > What is the value of Hx(Px, Px)?
> > Does Px(Px) halt when you run it?
> >
> The elements of the infinite set of Hx/Px pairs contained in my project
> are named H/P and HH/PP.

That is quite clearly not the answer to the questions.

> > You will dishonestly say I've changed the subject, or some similar feeble excuse.
> When this Hx element of the set of Hx/Px pairs is directly executed it
> directly executes Px(Px) that never halts:
> Hx(ptr x, ptr y)
> {
> x(y);
> }

Not even a feeble excuse this time?

On 9/19/2022 8:37 AM, Paul N wrote:
> On Saturday, September 17, 2022 at 9:26:18 PM UTC+1, olcott wrote:
>> On 9/17/2022 3:19 PM, Paul N wrote:
>>> On Saturday, September 17, 2022 at 9:12:24 PM UTC+1, olcott wrote:
>>>> I have fully operational code that proves my point all you have is
>>>> incoherent misconceptions.
>>>>
>>>> *Complete halt deciding system including*
>>>> *(a) x86utm operating system*
>>>> *(b) complete x86 emulator*
>>>> *(c) All of the various halt deciders and their inputs are contained in
>>>> Halt7.c*
>>>> https://liarparadox.org/2022_09_07.zip
>>>
>>> While you claim to have fully operational code, it's a pretty safe bet that you will not actually run it and answer the following two questions about it:
>>>
>>> What is the value of Hx(Px, Px)?

Hx/Px is only an infinite set and none of the elements are encoded in my
system so your question is the same as: What is the value of a number?

>>> Does Px(Px) halt when you run it?

int Hx(ptr x, ptr y)
{ x(y); // is Px(Px) when Hx(Px,Px) is invoked never halts;
}

>>>
>> The elements of the infinite set of Hx/Px pairs contained in my project
>> are named H/P and HH/PP.
>
> That is quite clearly not the answer to the questions. >
>>> You will dishonestly say I've changed the subject, or some similar feeble excuse.

This is the value of Px(Px):

>> When this Hx element of the set of Hx/Px pairs is directly executed it
>> directly executes Px(Px) that never halts:
>> Hx(ptr x, ptr y)
>> {
>> x(y);
>> }
>
> Not even a feeble excuse this time?

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

On 9/19/2022 5:55 AM, Richard Damon wrote:
> On 9/18/22 11:18 PM, olcott wrote:
>> On 9/18/2022 9:34 PM, Richard Damon wrote:
>>> On 9/18/22 1:58 PM, olcott wrote:
>>>> On 9/18/2022 12:56 PM, Richard Damon wrote:
>>>>> On 9/18/22 1:52 PM, olcott wrote:
>>>>>> On 9/18/2022 12:49 PM, Richard Damon wrote:
>>>>>>> On 9/18/22 1:44 PM, olcott wrote:
>>>>>>>> On 9/18/2022 12:37 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/18/22 1:28 PM, olcott wrote:
>>>>>>>>>> On 9/18/2022 12:23 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/18/22 1:01 PM, olcott wrote:
>>>>>>>>>>>> On 9/18/2022 11:29 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/18/22 11:18 AM, olcott wrote:
>>>>>>>>>>>>>> On 9/18/2022 6:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/18/22 12:12 AM, olcott wrote:
>>>>>>>>>>>>>>>> This instance of Hx(Px,Px) correctly reports its direct
>>>>>>>>>>>>>>>> execution of its input never halts:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int Hx(ptr x, ptr y)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>    return 0;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, it doesn't. It is only correct *IF* its input
>>>>>>>>>>>>>>> wouldn't halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>>>>>>>>  > If Hx DOES directly execute its input, then it will
>>>>>>>>>>>>>> NEVER report
>>>>>>>>>>>>>>  > non-halting, and yes, then the input Px built from THAT
>>>>>>>>>>>>>> Hx will be
>>>>>>>>>>>>>>  > non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> And since Hx doesn't directly execute its input,
>>>>>>>>>>>> Its basis for correctly deciding that the direct execution
>>>>>>>>>>>> of this input would never halt is a wild guess.
>>>>>>>>>>>
>>>>>>>>>>> So, it guesses wrong about the actual question that is being
>>>>>>>>>>> asked of it.
>>>>>>>>>>>
>>>>>>>>>> Why do I have to tell you the same thing 500 times and you
>>>>>>>>>> still don't get it?  My theory is that you are a liar only
>>>>>>>>>> interested in rebuttal.
>>>>>>>>>>
>>>>>>>>>> No halt decider ever directly executes its input yet must
>>>>>>>>>> correctly predict the behavior of this directly executed or
>>>>>>>>>> correctly simulated input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right, THE behavior of direct execution or correct simulation,
>>>>>>>>> not by the decider, but just done.
>>>>>>>>>
>>>>>>>>> If you want to add the words "by the decider", you need a
>>>>>>>>> source for that, which you have failed to do.
>>>>>>>>
>>>>>>>> First you must agree that every Hx returning 0 does correctly
>>>>>>>> report the halt status of the behavior of what its direct
>>>>>>>> execution of Px(Px) would be if it directly executed this input.
>>>>>>>>
>>>>>>>
>>>>>>> No. because no Hx that does a direct execution even gives an
>>>>>>> answer, so your statement is ILLOGICAL.
>>>>>> Halt deciders are not supposed to do a direct execution and you
>>>>>> know this so what the Hell are you trying to pull here?
>>>>>>
>>>>>
>>>>> Right, the aren't supposed to so why do you think they need to act
>>>>> like they did?
>>>> Halt deciders must correctly predict what the behavior of their
>>>> directly executed or correctly simulated input would be Hx(Px,Px)==0
>>>> does that.
>>>>
>>>
>>> Why do you say that?
>>>
>>> You have already agreed that if main calls P(P), and H(P,P) returns 0
>>> that P(P) will return in finite time, so the "directly executed
>>> input" of H(P,P) is shown to be Halting in this case.
>>
>> The only correct invocation of P(P) that must considered is the
>> invocation by H. As I have been always saying the other one is
>> irrelevant.
>>
>> int H(ptr x, ptr y)
>> {
>>    x(y);
>> }
>>
>>
>> This instance of P never halts.
>>
>>
>
> No, wrong terminology.
>
> That VERSION of P never halts, and that version of H never gives an
> answer, so is wrong.

*A halt decider always only predicts the behavior of its input*, the
above behavior is what Hx must predict. By using an adapted version of
the infinite recursion behavior pattern a simulating halt decider does
correctly predict the above behavior in a finite number of steps and as
a pure function of its inputs.

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

On Monday, September 19, 2022 at 3:53:45 PM UTC+1, olcott wrote:
> On 9/19/2022 8:37 AM, Paul N wrote:
> > On Saturday, September 17, 2022 at 9:26:18 PM UTC+1, olcott wrote:
> >> On 9/17/2022 3:19 PM, Paul N wrote:
> >>> On Saturday, September 17, 2022 at 9:12:24 PM UTC+1, olcott wrote:
> >>>> I have fully operational code that proves my point all you have is
> >>>> incoherent misconceptions.
> >>>>
> >>>> *Complete halt deciding system including*
> >>>> *(a) x86utm operating system*
> >>>> *(b) complete x86 emulator*
> >>>> *(c) All of the various halt deciders and their inputs are contained in
> >>>> Halt7.c*
> >>>> https://liarparadox.org/2022_09_07.zip
> >>>
> >>> While you claim to have fully operational code, it's a pretty safe bet that you will not actually run it and answer the following two questions about it:
> >>>
> >>> What is the value of Hx(Px, Px)?
> Hx/Px is only an infinite set and none of the elements are encoded in my
> system so your question is the same as: What is the value of a number?

You claimed to have an Hx that was a simulating halt decider. You are now claiming that you don't.

> >>> Does Px(Px) halt when you run it?
> int Hx(ptr x, ptr y)
> {
> x(y); // is Px(Px) when Hx(Px,Px) is invoked never halts;
> }
>
> >>>
> >> The elements of the infinite set of Hx/Px pairs contained in my project
> >> are named H/P and HH/PP.
> >
> > That is quite clearly not the answer to the questions. >
> >>> You will dishonestly say I've changed the subject, or some similar feeble excuse.
> This is the value of Px(Px):
> >> When this Hx element of the set of Hx/Px pairs is directly executed it
> >> directly executes Px(Px) that never halts:
> >> Hx(ptr x, ptr y)
> >> {
> >> x(y);
> >> }
> >
> > Not even a feeble excuse this time?

On 9/19/2022 10:15 AM, Paul N wrote:
> On Monday, September 19, 2022 at 3:53:45 PM UTC+1, olcott wrote:
>> On 9/19/2022 8:37 AM, Paul N wrote:
>>> On Saturday, September 17, 2022 at 9:26:18 PM UTC+1, olcott wrote:
>>>> On 9/17/2022 3:19 PM, Paul N wrote:
>>>>> On Saturday, September 17, 2022 at 9:12:24 PM UTC+1, olcott wrote:
>>>>>> I have fully operational code that proves my point all you have is
>>>>>> incoherent misconceptions.
>>>>>>
>>>>>> *Complete halt deciding system including*
>>>>>> *(a) x86utm operating system*
>>>>>> *(b) complete x86 emulator*
>>>>>> *(c) All of the various halt deciders and their inputs are contained in
>>>>>> Halt7.c*
>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>
>>>>> While you claim to have fully operational code, it's a pretty safe bet that you will not actually run it and answer the following two questions about it:
>>>>>
>>>>> What is the value of Hx(Px, Px)?
>> Hx/Px is only an infinite set and none of the elements are encoded in my
>> system so your question is the same as: What is the value of a number?
>
> You claimed to have an Hx that was a simulating halt decider. You are now claiming that you don't.

Like I already said those are named H(P,P) and HH(PP,PP).

// When Px(Px) is directly invoked by Hx(Px,Px) it never halts.
int Hx(ptr x, ptr y)
{ x(y);
}

The infinite set of Hx/Px pairs contain the above element and have an
element computationally identical to H(P,P), and HH(PP,PP).

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

On Sunday, September 18, 2022 at 5:39:47 PM UTC-7, olcott wrote:
> On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
> > You still haven't explained what you mean by "simulate". I
> > think your notion of simulate requires the simulating
> > program to have "the source code" of the simulated program.
>
> There are programs called x86 emulators that can act as if they are
> 80386 processors. These emulators can act as if they are directly
> executing 80386 machine language object code. The output of the
> Microsoft C compiler is a COFF object file. This file contains the
> machine language that the compiler produces when compiling a C program.
> This is before the linker links the C libraries.
>
So the "source code" you wish to use is in assembly language.
All the fuss about C is just window dressing.

OK so far. Now how is that assembly language equivalent to a
Turing Machine?

On Mon, 19 Sep 2022 09:16:19 -0700 (PDT)
"dklei...@gmail.com" <dkleinecke@gmail.com> wrote:

> On Sunday, September 18, 2022 at 5:39:47 PM UTC-7, olcott wrote:
> > On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
> > > You still haven't explained what you mean by "simulate". I
> > > think your notion of simulate requires the simulating
> > > program to have "the source code" of the simulated program.
> >
> > There are programs called x86 emulators that can act as if they are
> > 80386 processors. These emulators can act as if they are directly
> > executing 80386 machine language object code. The output of the
> > Microsoft C compiler is a COFF object file. This file contains the
> > machine language that the compiler produces when compiling a C
> > program. This is before the linker links the C libraries.
> >
> So the "source code" you wish to use is in assembly language.
> All the fuss about C is just window dressing.
>
> OK so far. Now how is that assembly language equivalent to a
> Turing Machine?

Assembly language is Turing-complete: that is all that matters.

/Flibble

On 9/19/2022 11:16 AM, dklei...@gmail.com wrote:
> On Sunday, September 18, 2022 at 5:39:47 PM UTC-7, olcott wrote:
>> On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
>>> You still haven't explained what you mean by "simulate". I
>>> think your notion of simulate requires the simulating
>>> program to have "the source code" of the simulated program.
>>
>> There are programs called x86 emulators that can act as if they are
>> 80386 processors. These emulators can act as if they are directly
>> executing 80386 machine language object code. The output of the
>> Microsoft C compiler is a COFF object file. This file contains the
>> machine language that the compiler produces when compiling a C program.
>> This is before the linker links the C libraries.
>>
> So the "source code" you wish to use is in assembly language.
> All the fuss about C is just window dressing.
>

The source-code is the machine language bytes located in the COFF object
file after the Microsoft C compiler compiled the C source into these
machine language bytes.

> OK so far. Now how is that assembly language equivalent to a
> Turing Machine?

Apparently any C function that is a pure function is Turing computable.

In computer programming, a pure function is a function that has the
following properties:

(1) the function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams), and

(2) the function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).

https://en.wikipedia.org/wiki/Pure_function

My original H(P,P) did not meet these requirements so I spent months
redesigning it so that it does meet these requirements. The original C
function was retained and named HH(PP,PP);

This original HH(PP,PP) uses the exact same infinite recursion behavior
pattern to detect infinitely recursive simulation.

The adapted simulating halt decider H(P,P) uses an adapted version of
its infinite recursion behavior pattern to recognize infinitely
recursive simulation. This one is a pure function of its inputs.

*Complete halt deciding system including*
*(a) x86utm operating system*
*(b) complete x86 emulator*
*(c) Several halt deciders and their inputs contained within Halt7.c*
https://liarparadox.org/2022_09_07.zip

Currently compiles under:
Microsoft Visual Studio Community 2017
https://visualstudio.microsoft.com/vs/older-downloads/

--
Copyright 2022 Pete Olcott

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

On 9/19/2022 11:25 AM, Mr Flibble wrote:
> On Mon, 19 Sep 2022 09:16:19 -0700 (PDT)
> "dklei...@gmail.com" <dkleinecke@gmail.com> wrote:
>
>> On Sunday, September 18, 2022 at 5:39:47 PM UTC-7, olcott wrote:
>>> On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
>>>> You still haven't explained what you mean by "simulate". I
>>>> think your notion of simulate requires the simulating
>>>> program to have "the source code" of the simulated program.
>>>
>>> There are programs called x86 emulators that can act as if they are
>>> 80386 processors. These emulators can act as if they are directly
>>> executing 80386 machine language object code. The output of the
>>> Microsoft C compiler is a COFF object file. This file contains the
>>> machine language that the compiler produces when compiling a C
>>> program. This is before the linker links the C libraries.
>>>
>> So the "source code" you wish to use is in assembly language.
>> All the fuss about C is just window dressing.
>>
>> OK so far. Now how is that assembly language equivalent to a
>> Turing Machine?
>
> Assembly language is Turing-complete: that is all that matters.
>
> /Flibble
>

*This shocked the Hell out of me*
Unless a C function is a pure function it is not Turing computable.
https://en.wikipedia.org/wiki/Pure_function

--
Copyright 2022 Pete Olcott

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

On 18/09/2022 15:55, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
> <massive quote>
>> Except that ...
> I admire your stamina, but were all 770+ lines of quoted material
> (nested 66 levels deep!) really needed to give context for your 4-line
> reply?

Personally, I junk unread all articles over 100 lines long.
If you also discard Flibble's trollery, this group comes down to
quite readable proportions. Commended.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Chopin

On Monday, September 19, 2022 at 9:29:40 AM UTC-7, olcott wrote:
> On 9/19/2022 11:16 AM, dklei...@gmail.com wrote:
> > On Sunday, September 18, 2022 at 5:39:47 PM UTC-7, olcott wrote:
> >> On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
> >>> You still haven't explained what you mean by "simulate". I
> >>> think your notion of simulate requires the simulating
> >>> program to have "the source code" of the simulated program.
> >>
> >> There are programs called x86 emulators that can act as if they are
> >> 80386 processors. These emulators can act as if they are directly
> >> executing 80386 machine language object code. The output of the
> >> Microsoft C compiler is a COFF object file. This file contains the
> >> machine language that the compiler produces when compiling a C program.
> >> This is before the linker links the C libraries.
> >>
> > So the "source code" you wish to use is in assembly language.
> > All the fuss about C is just window dressing.
> >
> The source-code is the machine language bytes located in the COFF object
> file after the Microsoft C compiler compiled the C source into these
> machine language bytes.
>
I'm beginning to suspect you aren't sure what "assembly" means. COFF
is not the best format to collect assembly code.

This is a very strange way to write assembly code. First you write a
C source and then you, effectively, decompile it.
>
> > OK so far. Now how is that assembly language equivalent to a
> > Turing Machine?

> Apparently any C function that is a pure function is Turing computable.

That statement is very meta and close to meaningless. An
equivalence that is not explicit has very little value. You need a
reference for this "fact". It is not necessary to demonstrate
equivalence. All you need is a subset of all assembly code.

On 9/19/2022 1:54 PM, dklei...@gmail.com wrote:
> On Monday, September 19, 2022 at 9:29:40 AM UTC-7, olcott wrote:
>> On 9/19/2022 11:16 AM, dklei...@gmail.com wrote:
>>> On Sunday, September 18, 2022 at 5:39:47 PM UTC-7, olcott wrote:
>>>> On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
>>>>> You still haven't explained what you mean by "simulate". I
>>>>> think your notion of simulate requires the simulating
>>>>> program to have "the source code" of the simulated program.
>>>>
>>>> There are programs called x86 emulators that can act as if they are
>>>> 80386 processors. These emulators can act as if they are directly
>>>> executing 80386 machine language object code. The output of the
>>>> Microsoft C compiler is a COFF object file. This file contains the
>>>> machine language that the compiler produces when compiling a C program.
>>>> This is before the linker links the C libraries.
>>>>
>>> So the "source code" you wish to use is in assembly language.
>>> All the fuss about C is just window dressing.
>>>
>> The source-code is the machine language bytes located in the COFF object
>> file after the Microsoft C compiler compiled the C source into these
>> machine language bytes.
>>
> I'm beginning to suspect you aren't sure what "assembly" means. COFF
> is not the best format to collect assembly code.
>

My x86utm operating system takes a COFF object file as input and
directly executes it.

> This is a very strange way to write assembly code. First you write a
> C source and then you, effectively, decompile it.

Because machine language comes with a ready-build directed graph of all
control flow it is enormously easier for computer programs to examine
control flow on this basis.

>>
>>> OK so far. Now how is that assembly language equivalent to a
>>> Turing Machine?
>
>> Apparently any C function that is a pure function is Turing computable.
>
> That statement is very meta and close to meaningless. An

It turns out to be the best that anyone knows and hardly anyone knows as
much as this.

Every C function that is a pure function is Turing computable.
I originally took the much more difficult path of mapping a RASP machine
(known to be Turing equivalent) to the x86 language. The x86 language
itself has no memory limits. Memory that is accessed through relative
addressing could make a linked list of unlimited length.

https://www.researchgate.net/publication/343838609_The_x86_language_has_Turing_Complete_memory_access

> equivalence that is not explicit has very little value. You need a
> reference for this "fact". It is not necessary to demonstrate
> equivalence. All you need is a subset of all assembly code.

--
Copyright 2022 Pete Olcott

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

On Monday, September 19, 2022 at 12:15:34 PM UTC-7, olcott wrote:
> On 9/19/2022 1:54 PM, dklei...@gmail.com wrote:
> > On Monday, September 19, 2022 at 9:29:40 AM UTC-7, olcott wrote:
> >> On 9/19/2022 11:16 AM, dklei...@gmail.com wrote:
> >>> On Sunday, September 18, 2022 at 5:39:47 PM UTC-7, olcott wrote:
> >>>> On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
> >>>>> You still haven't explained what you mean by "simulate". I
> >>>>> think your notion of simulate requires the simulating
> >>>>> program to have "the source code" of the simulated program.
> >>>>
> >>>> There are programs called x86 emulators that can act as if they are
> >>>> 80386 processors. These emulators can act as if they are directly
> >>>> executing 80386 machine language object code. The output of the
> >>>> Microsoft C compiler is a COFF object file. This file contains the
> >>>> machine language that the compiler produces when compiling a C program.
> >>>> This is before the linker links the C libraries.
> >>>>
> >>> So the "source code" you wish to use is in assembly language.
> >>> All the fuss about C is just window dressing.
> >>>
> >> The source-code is the machine language bytes located in the COFF object
> >> file after the Microsoft C compiler compiled the C source into these
> >> machine language bytes.
> >>
> > I'm beginning to suspect you aren't sure what "assembly" means. COFF
> > is not the best format to collect assembly code.
> >
> My x86utm operating system takes a COFF object file as input and
> directly executes it.
> > This is a very strange way to write assembly code. First you write a
> > C source and then you, effectively, decompile it.

> Because machine language comes with a ready-build directed graph of all
> control flow it is enormously easier for computer programs to examine
> control flow on this basis.
>
"Machine language" normally means assembly but surely here you are
using it to me C, a higher order language. There is no obligation for a
compiler to examine control flow and the situation is simpler when it
doesn't.
>
> >>
> >>> OK so far. Now how is that assembly language equivalent to a
> >>> Turing Machine?
> >
> >> Apparently any C function that is a pure function is Turing computable.
> >
> > That statement is very meta and close to meaningless. An
>
The end of my paragraph and the start of yours are missing so I do
not understand what you are talking about.
>
> It turns out to be the best that anyone knows and hardly anyone knows as
> much as this.
>
> Every C function that is a pure function is Turing computable.
>
You need a reference to support this claim. Then you would have
to be sure your work conforms to that of your reference.

And you still haven't explained what "simulate" means to you.

On 9/19/2022 4:25 PM, dklei...@gmail.com wrote:
> On Monday, September 19, 2022 at 12:15:34 PM UTC-7, olcott wrote:
>> On 9/19/2022 1:54 PM, dklei...@gmail.com wrote:
>>> On Monday, September 19, 2022 at 9:29:40 AM UTC-7, olcott wrote:
>>>> On 9/19/2022 11:16 AM, dklei...@gmail.com wrote:
>>>>> On Sunday, September 18, 2022 at 5:39:47 PM UTC-7, olcott wrote:
>>>>>> On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
>>>>>>> You still haven't explained what you mean by "simulate". I
>>>>>>> think your notion of simulate requires the simulating
>>>>>>> program to have "the source code" of the simulated program.
>>>>>>
>>>>>> There are programs called x86 emulators that can act as if they are
>>>>>> 80386 processors. These emulators can act as if they are directly
>>>>>> executing 80386 machine language object code. The output of the
>>>>>> Microsoft C compiler is a COFF object file. This file contains the
>>>>>> machine language that the compiler produces when compiling a C program.
>>>>>> This is before the linker links the C libraries.
>>>>>>
>>>>> So the "source code" you wish to use is in assembly language.
>>>>> All the fuss about C is just window dressing.
>>>>>
>>>> The source-code is the machine language bytes located in the COFF object
>>>> file after the Microsoft C compiler compiled the C source into these
>>>> machine language bytes.
>>>>
>>> I'm beginning to suspect you aren't sure what "assembly" means. COFF
>>> is not the best format to collect assembly code.
>>>
>> My x86utm operating system takes a COFF object file as input and
>> directly executes it.
>>> This is a very strange way to write assembly code. First you write a
>>> C source and then you, effectively, decompile it.
>
>> Because machine language comes with a ready-build directed graph of all
>> control flow it is enormously easier for computer programs to examine
>> control flow on this basis.
>>
> "Machine language" normally means assembly but surely here you are

No, this is false. Assembly language mnemonics were invented to make
machine language easier for people to understand.

> using it to me C, a higher order language. There is no obligation for a
> compiler to examine control flow and the situation is simpler when it
> doesn't.
>>
>>>>
>>>>> OK so far. Now how is that assembly language equivalent to a
>>>>> Turing Machine?
>>>
>>>> Apparently any C function that is a pure function is Turing computable.
>>>
>>> That statement is very meta and close to meaningless. An
>>
> The end of my paragraph and the start of yours are missing so I do
> not understand what you are talking about.
>>
>> It turns out to be the best that anyone knows and hardly anyone knows as
>> much as this.
>>
>> Every C function that is a pure function is Turing computable.
>>
> You need a reference to support this claim. Then you would have
> to be sure your work conforms to that of your reference.
>
> And you still haven't explained what "simulate" means to you.

Yes I have, yet what I said may be too difficult for you to understand.
Also there is no "simulate to me", there is only the common term of the
art. Denotations have no subjective leeway.

--
Copyright 2022 Pete Olcott

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

On 9/19/2022 4:25 PM, dklei...@gmail.com wrote:
> On Monday, September 19, 2022 at 12:15:34 PM UTC-7, olcott wrote:
>> On 9/19/2022 1:54 PM, dklei...@gmail.com wrote:
>>> On Monday, September 19, 2022 at 9:29:40 AM UTC-7, olcott wrote:
>>>> On 9/19/2022 11:16 AM, dklei...@gmail.com wrote:
>>>>> On Sunday, September 18, 2022 at 5:39:47 PM UTC-7, olcott wrote:
>>>>>> On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
>>>>>>> You still haven't explained what you mean by "simulate". I
>>>>>>> think your notion of simulate requires the simulating
>>>>>>> program to have "the source code" of the simulated program.
>>>>>>
>>>>>> There are programs called x86 emulators that can act as if they are
>>>>>> 80386 processors. These emulators can act as if they are directly
>>>>>> executing 80386 machine language object code. The output of the
>>>>>> Microsoft C compiler is a COFF object file. This file contains the
>>>>>> machine language that the compiler produces when compiling a C program.
>>>>>> This is before the linker links the C libraries.
>>>>>>
>>>>> So the "source code" you wish to use is in assembly language.
>>>>> All the fuss about C is just window dressing.
>>>>>
>>>> The source-code is the machine language bytes located in the COFF object
>>>> file after the Microsoft C compiler compiled the C source into these
>>>> machine language bytes.
>>>>
>>> I'm beginning to suspect you aren't sure what "assembly" means. COFF
>>> is not the best format to collect assembly code.
>>>
>> My x86utm operating system takes a COFF object file as input and
>> directly executes it.
>>> This is a very strange way to write assembly code. First you write a
>>> C source and then you, effectively, decompile it.
>
>> Because machine language comes with a ready-build directed graph of all
>> control flow it is enormously easier for computer programs to examine
>> control flow on this basis.
>>
> "Machine language" normally means assembly but surely here you are

No, this is false. Assembly language mnemonics were invented to make
machine language easier for people to understand.

> using it to me C, a higher order language. There is no obligation for a
> compiler to examine control flow and the situation is simpler when it
> doesn't.
>>
>>>>
>>>>> OK so far. Now how is that assembly language equivalent to a
>>>>> Turing Machine?
>>>
>>>> Apparently any C function that is a pure function is Turing computable.
>>>
>>> That statement is very meta and close to meaningless. An
>>
> The end of my paragraph and the start of yours are missing so I do
> not understand what you are talking about.

Every C function that has certain properties is Turing computable.

>>
>> It turns out to be the best that anyone knows and hardly anyone knows as
>> much as this.
>>
>> Every C function that is a pure function is Turing computable.
>>
> You need a reference to support this claim. Then you would have
> to be sure your work conforms to that of your reference.
>
> And you still haven't explained what "simulate" means to you.

Yes I have, yet what I said may be too difficult for you to understand.
Also there is no "simulate to me", there is only the common term of the
art. Denotations have no subjective leeway.

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

On 9/19/22 11:02 AM, olcott wrote:
> On 9/19/2022 5:55 AM, Richard Damon wrote:
>> On 9/18/22 11:18 PM, olcott wrote:
>>> On 9/18/2022 9:34 PM, Richard Damon wrote:
>>>> On 9/18/22 1:58 PM, olcott wrote:
>>>>> On 9/18/2022 12:56 PM, Richard Damon wrote:
>>>>>> On 9/18/22 1:52 PM, olcott wrote:
>>>>>>> On 9/18/2022 12:49 PM, Richard Damon wrote:
>>>>>>>> On 9/18/22 1:44 PM, olcott wrote:
>>>>>>>>> On 9/18/2022 12:37 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/18/22 1:28 PM, olcott wrote:
>>>>>>>>>>> On 9/18/2022 12:23 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/18/22 1:01 PM, olcott wrote:
>>>>>>>>>>>>> On 9/18/2022 11:29 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/18/22 11:18 AM, olcott wrote:
>>>>>>>>>>>>>>> On 9/18/2022 6:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/18/22 12:12 AM, olcott wrote:
>>>>>>>>>>>>>>>>> This instance of Hx(Px,Px) correctly reports its direct
>>>>>>>>>>>>>>>>> execution of its input never halts:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int Hx(ptr x, ptr y)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>    return 0;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, it doesn't. It is only correct *IF* its input
>>>>>>>>>>>>>>>> wouldn't halt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/17/2022 9:38 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>  > If Hx DOES directly execute its input, then it will
>>>>>>>>>>>>>>> NEVER report
>>>>>>>>>>>>>>>  > non-halting, and yes, then the input Px built from
>>>>>>>>>>>>>>> THAT Hx will be
>>>>>>>>>>>>>>>  > non-halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And since Hx doesn't directly execute its input,
>>>>>>>>>>>>> Its basis for correctly deciding that the direct execution
>>>>>>>>>>>>> of this input would never halt is a wild guess.
>>>>>>>>>>>>
>>>>>>>>>>>> So, it guesses wrong about the actual question that is being
>>>>>>>>>>>> asked of it.
>>>>>>>>>>>>
>>>>>>>>>>> Why do I have to tell you the same thing 500 times and you
>>>>>>>>>>> still don't get it?  My theory is that you are a liar only
>>>>>>>>>>> interested in rebuttal.
>>>>>>>>>>>
>>>>>>>>>>> No halt decider ever directly executes its input yet must
>>>>>>>>>>> correctly predict the behavior of this directly executed or
>>>>>>>>>>> correctly simulated input.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, THE behavior of direct execution or correct simulation,
>>>>>>>>>> not by the decider, but just done.
>>>>>>>>>>
>>>>>>>>>> If you want to add the words "by the decider", you need a
>>>>>>>>>> source for that, which you have failed to do.
>>>>>>>>>
>>>>>>>>> First you must agree that every Hx returning 0 does correctly
>>>>>>>>> report the halt status of the behavior of what its direct
>>>>>>>>> execution of Px(Px) would be if it directly executed this input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No. because no Hx that does a direct execution even gives an
>>>>>>>> answer, so your statement is ILLOGICAL.
>>>>>>> Halt deciders are not supposed to do a direct execution and you
>>>>>>> know this so what the Hell are you trying to pull here?
>>>>>>>
>>>>>>
>>>>>> Right, the aren't supposed to so why do you think they need to act
>>>>>> like they did?
>>>>> Halt deciders must correctly predict what the behavior of their
>>>>> directly executed or correctly simulated input would be
>>>>> Hx(Px,Px)==0 does that.
>>>>>
>>>>
>>>> Why do you say that?
>>>>
>>>> You have already agreed that if main calls P(P), and H(P,P) returns
>>>> 0 that P(P) will return in finite time, so the "directly executed
>>>> input" of H(P,P) is shown to be Halting in this case.
>>>
>>> The only correct invocation of P(P) that must considered is the
>>> invocation by H. As I have been always saying the other one is
>>> irrelevant.
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    x(y);
>>> }
>>>
>>>
>>> This instance of P never halts.
>>>
>>>
>>
>> No, wrong terminology.
>>
>> That VERSION of P never halts, and that version of H never gives an
>> answer, so is wrong.
>
> *A halt decider always only predicts the behavior of its input*, the
> above behavior is what Hx must predict. By using an adapted version of
> the infinite recursion behavior pattern a simulating halt decider does
> correctly predict the above behavior in a finite number of steps and as
> a pure function of its inputs.
>
>

Nope, just shows you don't know what you are talking about.

The input to H(P,P) MUST represent the computation P(P) or you have lied
that you have built P by the specification.

It CAN'T use an "adapted" representation, as that is NOT what the input
is, so you are just LYING about what the input represents.

YOU HAVE FAILED to show what you want.

YOU HAVE PROVED that you are IGNORANT about what you are talking about

YOU HAVE PROVED that you are a liar.

H(P,P) is NOT correct about its input

YOu have LIED about following the requirements.

YOU HAVE FAILED.

On 9/19/22 6:28 PM, olcott wrote:
> On 9/19/2022 4:25 PM, dklei...@gmail.com wrote:
>> On Monday, September 19, 2022 at 12:15:34 PM UTC-7, olcott wrote:
>>> On 9/19/2022 1:54 PM, dklei...@gmail.com wrote:
>>>> On Monday, September 19, 2022 at 9:29:40 AM UTC-7, olcott wrote:
>>>>> On 9/19/2022 11:16 AM, dklei...@gmail.com wrote:
>>>>>> On Sunday, September 18, 2022 at 5:39:47 PM UTC-7, olcott wrote:
>>>>>>> On 9/18/2022 6:25 PM, dklei...@gmail.com wrote:
>>>>>>>> You still haven't explained what you mean by "simulate". I
>>>>>>>> think your notion of simulate requires the simulating
>>>>>>>> program to have "the source code" of the simulated program.
>>>>>>>
>>>>>>> There are programs called x86 emulators that can act as if they are
>>>>>>> 80386 processors. These emulators can act as if they are directly
>>>>>>> executing 80386 machine language object code. The output of the
>>>>>>> Microsoft C compiler is a COFF object file. This file contains the
>>>>>>> machine language that the compiler produces when compiling a C
>>>>>>> program.
>>>>>>> This is before the linker links the C libraries.
>>>>>>>
>>>>>> So the "source code" you wish to use is in assembly language.
>>>>>> All the fuss about C is just window dressing.
>>>>>>
>>>>> The source-code is the machine language bytes located in the COFF
>>>>> object
>>>>> file after the Microsoft C compiler compiled the C source into these
>>>>> machine language bytes.
>>>>>
>>>> I'm beginning to suspect you aren't sure what "assembly" means. COFF
>>>> is not the best format to collect assembly code.
>>>>
>>> My x86utm operating system takes a COFF object file as input and
>>> directly executes it.
>>>> This is a very strange way to write assembly code. First you write a
>>>> C source and then you, effectively, decompile it.
>>
>>> Because machine language comes with a ready-build directed graph of all
>>> control flow it is enormously easier for computer programs to examine
>>> control flow on this basis.
>>>
>> "Machine language" normally means assembly but surely here you are
>
> No, this is false. Assembly language mnemonics were invented to make
> machine language easier for people to understand.
>
>> using it to me C, a higher order language. There is no obligation for a
>> compiler to examine control flow and the situation is simpler when it
>> doesn't.
>>>
>>>>>
>>>>>> OK so far. Now how is that assembly language equivalent to a
>>>>>> Turing Machine?
>>>>
>>>>> Apparently any C function that is a pure function is Turing
>>>>> computable.
>>>>
>>>> That statement is very meta and close to meaningless. An
>>>
>> The end of my paragraph and the start of yours are missing so I do
>> not understand what you are talking about.
>
> Every C function that has certain properties is Turing computable.

And one of the properties is to be a leaf function, or you MUST include
all the functions it calls.

A C *PROGRAM* that has certain properties is Turing computable.

The key is the code must FULLY represent the behavior of the function,

Note, that means that P needs to INCLUDE the code of H, and everything
it calls, so you don't get to replace it by something else.

>
>>>
>>> It turns out to be the best that anyone knows and hardly anyone knows as
>>> much as this.
>>>
>>> Every C function that is a pure function is Turing computable.
>>>
>> You need a reference to support this claim. Then you would have
>> to be sure your work conforms to that of your reference.
>>
>> And you still haven't explained what "simulate" means to you.
>
> Yes I have, yet what I said may be too difficult for you to understand.
> Also there is no "simulate to me", there is only the common term of the
> art. Denotations have no subjective leeway.
>