On 5/4/22 11:09 PM, olcott wrote:
> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>> On 5/4/2022 9:28 PM, Ben wrote:
>>>> olcott <polc...@gmail.com> writes:
>>>>
>>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>
>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely
>>>>>>>>>>>>> nested
>>>>>>>>>>>>> simulation to H.
>>>>>>>>>>>> What two pointers must be passed to H for H to tell up about
>>>>>>>>>>>> the halting
>>>>>>>>>>>> of P(P)? If H can't report on the halting of the computation
>>>>>>>>>>>> P(P) it is
>>>>>>>>>>>> not a halt decider, and you have already told use that
>>>>>>>>>>>> H(P,P) == false
>>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>>
>>>>>>>>>>> If H can report on the halting of non-input P(P) then it is
>>>>>>>>>>> not a
>>>>>>>>>>> decider because deciders only compute the mapping from inputs
>>>>>>>>>>> to final
>>>>>>>>>>> states.
>>>>>>>>>> TM deciders compute mappings from inputs to final states
>>>>>>>>>> /according to
>>>>>>>>>> some property of the inputs/
>>>>>>>>>
>>>>>>>>> That par is exactly correct.
>>>>>>>>>
>>>>>>>>>> -- whether the input represents, for
>>>>>>>>>
>>>>>>>>> That part has been the key error of everyone in that they all
>>>>>>>>> believe
>>>>>>>>> that is can represent something other than what it actually
>>>>>>>>> specifies.
>>>>>>>>
>>>>>>>> So now, after thinking otherwise for years, you claim that there
>>>>>>>> is no
>>>>>>>> way to even specify the computation P(P) for you pseudo-C halt
>>>>>>>> decider
>>>>>>>> H. At least that is a clear admission that the halting of function
>>>>>>>> calls like P(P) can not be decided because, apparently, passing
>>>>>>>> P and P
>>>>>>>> to H does not specify that computation, and you can't say what two
>>>>>>>> arguments /would/ specify it.
>>>>>>>>
>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y) ==
>>>>>>>> true if
>>>>>>>> and only if X(Y) halts and false otherwise is possible would be the
>>>>>>>> honest way to move things on. If you were clear about this, maybe
>>>>>>>> someone will talk to you about [whatever] it is that your H is
>>>>>>>> deciding.
>>>>>> So you won't admit that no algorithm can do what D is specified to
>>>>>> do?
>>>>>> You are just going to pretend that no one cares about actual halting.
>>>>>> I hope you see that by ignoring this point you are confirming that
>>>>>> you
>>>>>> know D can't exist. If you thought such a D was possible, you'd be
>>>>>> shouting that from the roof tops since it's what everyone else
>>>>>> says is
>>>>>> impossible.
>>>>>>
>>>>>>> I adapted my system so that I could empirically test this:
>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>
>>>>>> But neither can tell us squat about the halting of P(P) -- the thing
>>>>>> that H was originally supposed to decide.
>>>>>
>>>>> Are you simply wired to ignore my words so that you can disagree with
>>>>> everything that I say?
>>>>>
>>>>> H1(P,P)==true reports on the behavior of P(P).
>>>>
>>>> I try to ignore that bits that are irrelevant. These two deciders
>>>> decide all halting instances between them:
>>>>
>>>> bool H1(X, Y) { return true; }
>>>> bool H2(X, Y) { return false; }
>>>>
>>>> Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
>>>> maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
>>>
>>> H1(P,P)==true is empirically proven to be correct
>>> H(P,P)==false is empirically proven to be correct
>>
>> If that is so then H and H1 don't perform the same mapping.  This
>> means that one (or both) do not compute the halting function.
>>
>> So which one doesn't compute the halting function?
>
> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> Both take the machine code of P as input parameters and are provably
> correct simulations of this same input yet one correctly determines that
> its input halts and the other correctly determines that its input does
> not halt.

But (P,P) can't map to two different answers, so you must have a flaw in
your logic.

Just shows you don't understand what the Question is in the first place,
and thus you have WASTED the last decades of your life.

The answer a decider needs to compute isn't a function of the code of
the decider, but of the mapping it is computing.

Thus H(P,P) and H1(P,P), if they are supposed to be deciders of the same
function, must agree in their answers or they PROVE that one of them is
incorrect.

>
>>> Both take the machine code of P as input parameters and are provably
>>> correct simulations of this same input yet one correctly determines that
>>> its input halts and the other correctly determines that its input does
>>> not halt. ALL THESE THINGS ARE VERIFIED FACTS !
>>>
>>> I know that you can't verify that these are facts yet imagine they are
>>> the facts. In that case I have totally proved that I am correct.
>>>
>>> Other people can look at in this in my paper:
>>>
>>> Halting problem undecidability and infinitely nested simulation
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>>
>>> There is enough material in my first paper to verify that everything in
>>> the first paragraph is a fact for people having sufficient expertise in
>>> the x86 language and good familiarity with the halting problem.
>>> --
>>> 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 5/4/22 11:42 PM, olcott wrote:
> On 5/4/2022 10:38 PM, André G. Isaak wrote:
>> On 2022-05-04 21:35, olcott wrote:
>>> On 5/4/2022 10:17 PM, André G. Isaak wrote:
>>>> On 2022-05-04 21:09, olcott wrote:
>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>
>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>
>>>>>> If that is so then H and H1 don't perform the same mapping.  This
>>>>>> means that one (or both) do not compute the halting function.
>>>>>>
>>>>>> So which one doesn't compute the halting function?
>>>>
>>>> You didn't actually answer this question.
>>>>
>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>> Both take the machine code of P as input parameters and are
>>>>> provably correct simulations of this same input yet one correctly
>>>>> determines that its input halts and the other correctly determines
>>>>> that its input does not halt.
>>>>
>>>> Please define your use of the term "correct simulation".
>>>>
>>>> André
>>>>
>>>>
>>>
>>> Good question.
>>> The behavior of the simulated input exactly matches the correct
>>> execution trace of the behavior in a real hardware machine.
>>
>> So if P(P), when executed directly, halts, how can a 'correct
>> simulation' possibly not halt?
>>
>> André
>>
>
> As soon as you very carefully study every single detail of the above
> paragraph you will realize that it proves that I am correct as soon as
> the paragraph itself is proved to be factually correct.
>

No, it proves that you don't know what you are saying. The only machine
to use to "Correctly simulate the input (P,P) is P(P), sp that is what
must define the correct answer.

If it looks at H, then by your definition ALL simulating decider are
"correct", as it is there simulation, no matter how awful, that defines
the answer.

On 5/5/22 12:48 AM, olcott wrote:
> On 5/4/2022 11:07 PM, Dennis Bush wrote:
>> On Wednesday, May 4, 2022 at 11:58:50 PM UTC-4, olcott wrote:
>>> On 5/4/2022 10:50 PM, Dennis Bush wrote:
>>>> On Wednesday, May 4, 2022 at 11:42:53 PM UTC-4, olcott wrote:
>>>>> On 5/4/2022 10:38 PM, André G. Isaak wrote:
>>>>>> On 2022-05-04 21:35, olcott wrote:
>>>>>>> On 5/4/2022 10:17 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-04 21:09, olcott wrote:
>>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>>>>>
>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>
>>>>>>>>>> If that is so then H and H1 don't perform the same mapping. This
>>>>>>>>>> means that one (or both) do not compute the halting function.
>>>>>>>>>>
>>>>>>>>>> So which one doesn't compute the halting function?
>>>>>>>>
>>>>>>>> You didn't actually answer this question.
>>>>>>>>
>>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>>>>>> Both take the machine code of P as input parameters and are
>>>>>>>>> provably
>>>>>>>>> correct simulations of this same input yet one correctly
>>>>>>>>> determines
>>>>>>>>> that its input halts and the other correctly determines that its
>>>>>>>>> input does not halt.
>>>>>>>>
>>>>>>>> Please define your use of the term "correct simulation".
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Good question.
>>>>>>> The behavior of the simulated input exactly matches the correct
>>>>>>> execution trace of the behavior in a real hardware machine.
>>>>>>
>>>>>> So if P(P), when executed directly, halts, how can a 'correct
>>>>>> simulation' possibly not halt?
>>>>>>
>>>>>> André
>>>>>>
>>>>> As soon as you very carefully study every single detail of the above
>>>>> paragraph you will realize that it proves that I am correct as soon as
>>>>> the paragraph itself is proved to be factually correct.
>>>>
>>>> Would you then also agree that Ha3(N,5) == false and Ha7(N,5) ==
>>>> true are both correct because both perform a provably correct
>>>> simulation their input, so that Ha3 correctly determines that its
>>>> input does not halt while Ha7 correctly determines that its input
>>>> halts?
>>>>
>>>> If not, then clarify your correctness criteria so that it can apply
>>>> to *any* input and *any* decider such that it shows that Ha3(N,5)
>>>> does not perform a correct simulation but H(P,P) does.
>>> I am not going to go through any of your extraneous nonsense.
>>
>> If you can't explain why Ha3(N,5) == false is incorrect then you can't
>> explain why H(P,P) == false is correct.
>>
>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>> Both take the machine code of P as input parameters and are provably
>>> correct simulations of this same input yet one correctly determines
>>> that its input halts and the other correctly determines that its
>>> input does not halt.
>>> If the above paragraph is proven to be a fact then this proves that both
>>> H and H1 compute the halting function correctly.
>>> Try to point to any gaps in this reasoning.
>>
>>
>> You defined "correct simulation" as:
>>
>> The behavior of the simulated input exactly matches the correct
>> execution trace of the behavior in a real hardware machine
>>
>> The correct execution trace of the behavior of P(P) in a real hardware
>> machine is halting.
>
> Both H(P,P) and H1(P,P) are provably correct.

Only in your broken, and inconsistent logic system.

H is incorrect in a real logic system with the actual definition of the
Halting Problem. since P(P) Halts and H(P,P) says it is non-halting.

>
>> The behavior of the simulated input H(P,P) is non-halting.
>>
>> Therefore your claim that H(P,P) performs a "provably correct
>> simulation" is FALSE.
>>
>
>

On Thursday, May 5, 2022 at 12:49:27 AM UTC-4, olcott wrote:
> On 5/4/2022 11:12 PM, Dennis Bush wrote:
> > On Wednesday, May 4, 2022 at 11:54:14 PM UTC-4, olcott wrote:
> >> On 5/4/2022 10:43 PM, Dennis Bush wrote:
> >>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
> >>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
> >>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
> >>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
> >>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
> >>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
> >>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>
> >>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
> >>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
> >>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
> >>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
> >>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested
> >>>>>>>>>>>>>>>>>> simulation to H.
> >>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up about the halting
> >>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
> >>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that H(P,P) == false
> >>>>>>>>>>>>>>>>> and that P(P) halts.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it is not a
> >>>>>>>>>>>>>>>> decider because deciders only compute the mapping from inputs to final
> >>>>>>>>>>>>>>>> states.
> >>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states /according to
> >>>>>>>>>>>>>>> some property of the inputs/
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> That par is exactly correct.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -- whether the input represents, for
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> That part has been the key error of everyone in that they all believe
> >>>>>>>>>>>>>> that is can represent something other than what it actually specifies.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that there is no
> >>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C halt decider
> >>>>>>>>>>>>> H. At least that is a clear admission that the halting of function
> >>>>>>>>>>>>> calls like P(P) can not be decided because, apparently, passing P and P
> >>>>>>>>>>>>> to H does not specify that computation, and you can't say what two
> >>>>>>>>>>>>> arguments /would/ specify it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y) == true if
> >>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would be the
> >>>>>>>>>>>>> honest way to move things on. If you were clear about this, maybe
> >>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
> >>>>>>>>>>>>> deciding.
> >>>>>>>>>>> So you won't admit that no algorithm can do what D is specified to do?
> >>>>>>>>>>> You are just going to pretend that no one cares about actual halting.
> >>>>>>>>>>> I hope you see that by ignoring this point you are confirming that you
> >>>>>>>>>>> know D can't exist. If you thought such a D was possible, you'd be
> >>>>>>>>>>> shouting that from the roof tops since it's what everyone else says is
> >>>>>>>>>>> impossible.
> >>>>>>>>>>>
> >>>>>>>>>>>> I adapted my system so that I could empirically test this:
> >>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>>>>
> >>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the thing
> >>>>>>>>>>> that H was originally supposed to decide.
> >>>>>>>>>>
> >>>>>>>>>> Are you simply wired to ignore my words so that you can disagree with
> >>>>>>>>>> everything that I say?
> >>>>>>>>>>
> >>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
> >>>>>>>>>
> >>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
> >>>>>>>>> decide all halting instances between them:
> >>>>>>>>>
> >>>>>>>>> bool H1(X, Y) { return true; }
> >>>>>>>>> bool H2(X, Y) { return false; }
> >>>>>>>>>
> >>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
> >>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
> >>>>>>>>
> >>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>
> >>>>>>> If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
> >>>>>>>
> >>>>>>> So which one doesn't compute the halting function?
> >>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> >>>>>> Both take the machine code of P as input parameters and are provably
> >>>>>> correct simulations of this same input yet one correctly determines that
> >>>>>> its input halts and the other correctly determines that its input does
> >>>>>> not halt.
> >>>>>
> >>>>> Which means at least one is not computing the halting function. So which one is it?
> >>>>>
> >>>> The above paragraph means that it makes no mistakes in computing the
> >>>> halting function. This is a verifiable fact, not any mere opinion. The
> >>>> reason that I did the HP in C/x86 was so that every detail can be shown
> >>>> thus gaps in reasoning revealed.
> >
> > Just because a simulating halt decider aborts doesn't necessarily mean it was correct to do so. On the other hand, a simulating halt decider that simulates to a final state is always correct and proves that any mapping of the same input to non-halting is necessarily incorrect.
> >
> >>>
> >>> Any decider that maps the halting function performs the *same* mapping of inputs to outputs.
> >> That is now proven to be factually incorrect.
> >
> > FALSE. The mapping of the halting function is DEFINED (i.e. is immutable and fixed) as:
> >
> > M w maps to true if and only if M(w) halts, and
> > M w maps to false if and only if M(w) does not halt
> >
> > So any halt decider that does not compute this *exact* mapping is not computing the halting function.
> >
> Both H(P,P) and H1(P,P) are provably correct.

On 5/4/22 11:54 PM, olcott wrote:
> On 5/4/2022 10:43 PM, Dennis Bush wrote:
>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies
>>>>>>>>>>>>>>>>> infinitely nested
>>>>>>>>>>>>>>>>> simulation to H.
>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up
>>>>>>>>>>>>>>>> about the halting
>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
>>>>>>>>>>>>>>>> computation P(P) it is
>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
>>>>>>>>>>>>>>>> H(P,P) == false
>>>>>>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it
>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>> decider because deciders only compute the mapping from
>>>>>>>>>>>>>>> inputs to final
>>>>>>>>>>>>>>> states.
>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states
>>>>>>>>>>>>>> /according to
>>>>>>>>>>>>>> some property of the inputs/
>>>>>>>>>>>>>
>>>>>>>>>>>>> That par is exactly correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- whether the input represents, for
>>>>>>>>>>>>>
>>>>>>>>>>>>> That part has been the key error of everyone in that they
>>>>>>>>>>>>> all believe
>>>>>>>>>>>>> that is can represent something other than what it actually
>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>
>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that
>>>>>>>>>>>> there is no
>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C
>>>>>>>>>>>> halt decider
>>>>>>>>>>>> H. At least that is a clear admission that the halting of
>>>>>>>>>>>> function
>>>>>>>>>>>> calls like P(P) can not be decided because, apparently,
>>>>>>>>>>>> passing P and P
>>>>>>>>>>>> to H does not specify that computation, and you can't say
>>>>>>>>>>>> what two
>>>>>>>>>>>> arguments /would/ specify it.
>>>>>>>>>>>>
>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y)
>>>>>>>>>>>> == true if
>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would
>>>>>>>>>>>> be the
>>>>>>>>>>>> honest way to move things on. If you were clear about this,
>>>>>>>>>>>> maybe
>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
>>>>>>>>>>>> deciding.
>>>>>>>>>> So you won't admit that no algorithm can do what D is
>>>>>>>>>> specified to do?
>>>>>>>>>> You are just going to pretend that no one cares about actual
>>>>>>>>>> halting.
>>>>>>>>>> I hope you see that by ignoring this point you are confirming
>>>>>>>>>> that you
>>>>>>>>>> know D can't exist. If you thought such a D was possible,
>>>>>>>>>> you'd be
>>>>>>>>>> shouting that from the roof tops since it's what everyone else
>>>>>>>>>> says is
>>>>>>>>>> impossible.
>>>>>>>>>>
>>>>>>>>>>> I adapted my system so that I could empirically test this:
>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>
>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the
>>>>>>>>>> thing
>>>>>>>>>> that H was originally supposed to decide.
>>>>>>>>>
>>>>>>>>> Are you simply wired to ignore my words so that you can
>>>>>>>>> disagree with
>>>>>>>>> everything that I say?
>>>>>>>>>
>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
>>>>>>>>
>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
>>>>>>>> decide all halting instances between them:
>>>>>>>>
>>>>>>>> bool H1(X, Y) { return true; }
>>>>>>>> bool H2(X, Y) { return false; }
>>>>>>>>
>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat,
>>>>>>>> H1_hat) or
>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call
>>>>>>>> H_hat.
>>>>>>>
>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>
>>>>>> If that is so then H and H1 don't perform the same mapping. This
>>>>>> means that one (or both) do not compute the halting function.
>>>>>>
>>>>>> So which one doesn't compute the halting function?
>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>> Both take the machine code of P as input parameters and are provably
>>>>> correct simulations of this same input yet one correctly determines
>>>>> that
>>>>> its input halts and the other correctly determines that its input does
>>>>> not halt.
>>>>
>>>> Which means at least one is not computing the halting function. So
>>>> which one is it?
>>>>
>>> The above paragraph means that it makes no mistakes in computing the
>>> halting function. This is a verifiable fact, not any mere opinion. The
>>> reason that I did the HP in C/x86 was so that every detail can be shown
>>> thus gaps in reasoning revealed.
>>
>> Any decider that maps the halting function performs the *same* mapping
>> of inputs to outputs.
>
> That is now proven to be factually incorrect.
>
> If the above paragraph is proven to be a fact then this proves that both
> H and H1 compute the halting function correctly. The above paragraph can
> be proven to be a fact.

On 5/5/22 12:49 AM, olcott wrote:
> On 5/4/2022 11:12 PM, Dennis Bush wrote:
>> On Wednesday, May 4, 2022 at 11:54:14 PM UTC-4, olcott wrote:
>>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
>>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies
>>>>>>>>>>>>>>>>>>> infinitely nested
>>>>>>>>>>>>>>>>>>> simulation to H.
>>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up
>>>>>>>>>>>>>>>>>> about the halting
>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
>>>>>>>>>>>>>>>>>> computation P(P) it is
>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
>>>>>>>>>>>>>>>>>> H(P,P) == false
>>>>>>>>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then
>>>>>>>>>>>>>>>>> it is not a
>>>>>>>>>>>>>>>>> decider because deciders only compute the mapping from
>>>>>>>>>>>>>>>>> inputs to final
>>>>>>>>>>>>>>>>> states.
>>>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states
>>>>>>>>>>>>>>>> /according to
>>>>>>>>>>>>>>>> some property of the inputs/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That par is exactly correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- whether the input represents, for
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That part has been the key error of everyone in that they
>>>>>>>>>>>>>>> all believe
>>>>>>>>>>>>>>> that is can represent something other than what it
>>>>>>>>>>>>>>> actually specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that
>>>>>>>>>>>>>> there is no
>>>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C
>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>> H. At least that is a clear admission that the halting of
>>>>>>>>>>>>>> function
>>>>>>>>>>>>>> calls like P(P) can not be decided because, apparently,
>>>>>>>>>>>>>> passing P and P
>>>>>>>>>>>>>> to H does not specify that computation, and you can't say
>>>>>>>>>>>>>> what two
>>>>>>>>>>>>>> arguments /would/ specify it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A clear and unambiguous statement that no D such that
>>>>>>>>>>>>>> D(X,Y) == true if
>>>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible
>>>>>>>>>>>>>> would be the
>>>>>>>>>>>>>> honest way to move things on. If you were clear about
>>>>>>>>>>>>>> this, maybe
>>>>>>>>>>>>>> someone will talk to you about [whatever] it is that your
>>>>>>>>>>>>>> H is
>>>>>>>>>>>>>> deciding.
>>>>>>>>>>>> So you won't admit that no algorithm can do what D is
>>>>>>>>>>>> specified to do?
>>>>>>>>>>>> You are just going to pretend that no one cares about actual
>>>>>>>>>>>> halting.
>>>>>>>>>>>> I hope you see that by ignoring this point you are
>>>>>>>>>>>> confirming that you
>>>>>>>>>>>> know D can't exist. If you thought such a D was possible,
>>>>>>>>>>>> you'd be
>>>>>>>>>>>> shouting that from the roof tops since it's what everyone
>>>>>>>>>>>> else says is
>>>>>>>>>>>> impossible.
>>>>>>>>>>>>
>>>>>>>>>>>>> I adapted my system so that I could empirically test this:
>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>>>
>>>>>>>>>>>> But neither can tell us squat about the halting of P(P) --
>>>>>>>>>>>> the thing
>>>>>>>>>>>> that H was originally supposed to decide.
>>>>>>>>>>>
>>>>>>>>>>> Are you simply wired to ignore my words so that you can
>>>>>>>>>>> disagree with
>>>>>>>>>>> everything that I say?
>>>>>>>>>>>
>>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
>>>>>>>>>>
>>>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
>>>>>>>>>> decide all halting instances between them:
>>>>>>>>>>
>>>>>>>>>> bool H1(X, Y) { return true; }
>>>>>>>>>> bool H2(X, Y) { return false; }
>>>>>>>>>>
>>>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat,
>>>>>>>>>> H1_hat) or
>>>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to
>>>>>>>>>> call H_hat.
>>>>>>>>>
>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>
>>>>>>>> If that is so then H and H1 don't perform the same mapping. This
>>>>>>>> means that one (or both) do not compute the halting function.
>>>>>>>>
>>>>>>>> So which one doesn't compute the halting function?
>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>>>> Both take the machine code of P as input parameters and are provably
>>>>>>> correct simulations of this same input yet one correctly
>>>>>>> determines that
>>>>>>> its input halts and the other correctly determines that its input
>>>>>>> does
>>>>>>> not halt.
>>>>>>
>>>>>> Which means at least one is not computing the halting function. So
>>>>>> which one is it?
>>>>>>
>>>>> The above paragraph means that it makes no mistakes in computing the
>>>>> halting function. This is a verifiable fact, not any mere opinion. The
>>>>> reason that I did the HP in C/x86 was so that every detail can be
>>>>> shown
>>>>> thus gaps in reasoning revealed.
>>
>> Just because a simulating halt decider aborts doesn't necessarily mean
>> it was correct to do so.  On the other hand, a simulating halt decider
>> that simulates to a final state is always correct and proves that any
>> mapping of the same input to non-halting is necessarily incorrect.
>>
>>>>
>>>> Any decider that maps the halting function performs the *same*
>>>> mapping of inputs to outputs.
>>> That is now proven to be factually incorrect.
>>
>> FALSE.  The mapping of the halting function is DEFINED (i.e. is
>> immutable and fixed) as:
>>
>> M w maps to true if and only if M(w) halts, and
>> M w maps to false if and only if M(w) does not halt
>>
>> So any halt decider that does not compute this *exact* mapping is not
>> computing the halting function.
>>
>
> Both H(P,P) and H1(P,P) are provably correct.
>

On Thursday, May 5, 2022 at 7:50:02 AM UTC-4, richar...@gmail.com wrote:
> On 5/4/22 11:42 PM, olcott wrote:
> > On 5/4/2022 10:38 PM, André G. Isaak wrote:
> >> On 2022-05-04 21:35, olcott wrote:
> >>> On 5/4/2022 10:17 PM, André G. Isaak wrote:
> >>>> On 2022-05-04 21:09, olcott wrote:
> >>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
> >>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
> >>>>
> >>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>
> >>>>>> If that is so then H and H1 don't perform the same mapping. This
> >>>>>> means that one (or both) do not compute the halting function.
> >>>>>>
> >>>>>> So which one doesn't compute the halting function?
> >>>>
> >>>> You didn't actually answer this question.
> >>>>
> >>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> >>>>> Both take the machine code of P as input parameters and are
> >>>>> provably correct simulations of this same input yet one correctly
> >>>>> determines that its input halts and the other correctly determines
> >>>>> that its input does not halt.
> >>>>
> >>>> Please define your use of the term "correct simulation".
> >>>>
> >>>> André
> >>>>
> >>>>
> >>>
> >>> Good question.
> >>> The behavior of the simulated input exactly matches the correct
> >>> execution trace of the behavior in a real hardware machine.
> >>
> >> So if P(P), when executed directly, halts, how can a 'correct
> >> simulation' possibly not halt?
> >>
> >> André
> >>
> >
> > As soon as you very carefully study every single detail of the above
> > paragraph you will realize that it proves that I am correct as soon as
> > the paragraph itself is proved to be factually correct.
> >
> No, it proves that you don't know what you are saying. The only machine
> to use to "Correctly simulate the input (P,P) is P(P), sp that is what
> must define the correct answer.
>
> If it looks at H, then by your definition ALL simulating decider are
> "correct", as it is there simulation, no matter how awful, that defines
> the answer.

To PO: the above is exactly where the conclusion that Ha3(N,5) == false is coming from.

On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote:
> On 5/4/22 11:54 PM, olcott wrote:
> > On 5/4/2022 10:43 PM, Dennis Bush wrote:
> >> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
> >>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
> >>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
> >>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
> >>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
> >>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
> >>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>
> >>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
> >>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>
> >>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
> >>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
> >>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
> >>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies
> >>>>>>>>>>>>>>>>> infinitely nested
> >>>>>>>>>>>>>>>>> simulation to H.
> >>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up
> >>>>>>>>>>>>>>>> about the halting
> >>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
> >>>>>>>>>>>>>>>> computation P(P) it is
> >>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
> >>>>>>>>>>>>>>>> H(P,P) == false
> >>>>>>>>>>>>>>>> and that P(P) halts.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it
> >>>>>>>>>>>>>>> is not a
> >>>>>>>>>>>>>>> decider because deciders only compute the mapping from
> >>>>>>>>>>>>>>> inputs to final
> >>>>>>>>>>>>>>> states.
> >>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states
> >>>>>>>>>>>>>> /according to
> >>>>>>>>>>>>>> some property of the inputs/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That par is exactly correct.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> -- whether the input represents, for
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That part has been the key error of everyone in that they
> >>>>>>>>>>>>> all believe
> >>>>>>>>>>>>> that is can represent something other than what it actually
> >>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>
> >>>>>>>>>>>> So now, after thinking otherwise for years, you claim that
> >>>>>>>>>>>> there is no
> >>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C
> >>>>>>>>>>>> halt decider
> >>>>>>>>>>>> H. At least that is a clear admission that the halting of
> >>>>>>>>>>>> function
> >>>>>>>>>>>> calls like P(P) can not be decided because, apparently,
> >>>>>>>>>>>> passing P and P
> >>>>>>>>>>>> to H does not specify that computation, and you can't say
> >>>>>>>>>>>> what two
> >>>>>>>>>>>> arguments /would/ specify it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y)
> >>>>>>>>>>>> == true if
> >>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would
> >>>>>>>>>>>> be the
> >>>>>>>>>>>> honest way to move things on. If you were clear about this,
> >>>>>>>>>>>> maybe
> >>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
> >>>>>>>>>>>> deciding.
> >>>>>>>>>> So you won't admit that no algorithm can do what D is
> >>>>>>>>>> specified to do?
> >>>>>>>>>> You are just going to pretend that no one cares about actual
> >>>>>>>>>> halting.
> >>>>>>>>>> I hope you see that by ignoring this point you are confirming
> >>>>>>>>>> that you
> >>>>>>>>>> know D can't exist. If you thought such a D was possible,
> >>>>>>>>>> you'd be
> >>>>>>>>>> shouting that from the roof tops since it's what everyone else
> >>>>>>>>>> says is
> >>>>>>>>>> impossible.
> >>>>>>>>>>
> >>>>>>>>>>> I adapted my system so that I could empirically test this:
> >>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>>>
> >>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the
> >>>>>>>>>> thing
> >>>>>>>>>> that H was originally supposed to decide.
> >>>>>>>>>
> >>>>>>>>> Are you simply wired to ignore my words so that you can
> >>>>>>>>> disagree with
> >>>>>>>>> everything that I say?
> >>>>>>>>>
> >>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
> >>>>>>>>
> >>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
> >>>>>>>> decide all halting instances between them:
> >>>>>>>>
> >>>>>>>> bool H1(X, Y) { return true; }
> >>>>>>>> bool H2(X, Y) { return false; }
> >>>>>>>>
> >>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat,
> >>>>>>>> H1_hat) or
> >>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call
> >>>>>>>> H_hat.
> >>>>>>>
> >>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>
> >>>>>> If that is so then H and H1 don't perform the same mapping. This
> >>>>>> means that one (or both) do not compute the halting function.
> >>>>>>
> >>>>>> So which one doesn't compute the halting function?
> >>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> >>>>> Both take the machine code of P as input parameters and are provably
> >>>>> correct simulations of this same input yet one correctly determines
> >>>>> that
> >>>>> its input halts and the other correctly determines that its input does
> >>>>> not halt.
> >>>>
> >>>> Which means at least one is not computing the halting function. So
> >>>> which one is it?
> >>>>
> >>> The above paragraph means that it makes no mistakes in computing the
> >>> halting function. This is a verifiable fact, not any mere opinion. The
> >>> reason that I did the HP in C/x86 was so that every detail can be shown
> >>> thus gaps in reasoning revealed.
> >>
> >> Any decider that maps the halting function performs the *same* mapping
> >> of inputs to outputs.
> >
> > That is now proven to be factually incorrect.
> >
> > If the above paragraph is proven to be a fact then this proves that both
> > H and H1 compute the halting function correctly. The above paragraph can
> > be proven to be a fact.
> Yes, IF you can prove that cats are dogs, you can prove that H is
> correctly computing the Halting Function.
>
> Since you can't, you can't.
>
> In fact, you have just proven that you don't know what you are talking
> about, since you just asserted a LIE.
>
> Two machines claiming to compute the same function must generate the
> same answer from the same input or one of them is incorrect.
>
> BASIC FACT.
>
In parapsychology, there's something called "the experimenter effect". The same
experiment will show a parapsychological effect or not, depending on who is
performing the experiment. This has been described as parapsychology's one finding.
If true in an interesting way, it also strikes at the heart of the scientific method.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> But he's been clear about this. He's asserting what anyone who knows
> just a tiny amount about computers must consdier to be nonsense. At
> first glance. But the idea that i^2 = j^2 = k^2 = -1 whilst ijk also =
> -1 also seems like nonsense at first glance. The difference is that
> more details were forthcoming.

Why are you talking about first glances and missing details? PO has
been saying this stuff, with slight variations, for 18 years. The
points being put to him are not made by ingenues startled by first
glances; they are being made by people who understand what PO is saying
better than he does.

Whilst he's obviously hiding some details, he's had to let slip enough
that it's clear what's going on. I take your main point, though, that a
genuine researcher would publish all the details, but you should know by
now that PO is not such a person.

--
Ben.

olcott <polcott2@gmail.com> writes:

> On 5/4/2022 9:28 PM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>>
>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>
>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested
>>>>>>>>>>> simulation to H.
>>>>>>>>>> What two pointers must be passed to H for H to tell up about the halting
>>>>>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
>>>>>>>>>> not a halt decider, and you have already told use that H(P,P) == false
>>>>>>>>>> and that P(P) halts.
>>>>>>>>>
>>>>>>>>> If H can report on the halting of non-input P(P) then it is not a
>>>>>>>>> decider because deciders only compute the mapping from inputs to final
>>>>>>>>> states.
>>>>>>>> TM deciders compute mappings from inputs to final states /according to
>>>>>>>> some property of the inputs/
>>>>>>>
>>>>>>> That par is exactly correct.
>>>>>>>
>>>>>>>> -- whether the input represents, for
>>>>>>>
>>>>>>> That part has been the key error of everyone in that they all believe
>>>>>>> that is can represent something other than what it actually specifies.
>>>>>>
>>>>>> So now, after thinking otherwise for years, you claim that there is no
>>>>>> way to even specify the computation P(P) for you pseudo-C halt decider
>>>>>> H. At least that is a clear admission that the halting of function
>>>>>> calls like P(P) can not be decided because, apparently, passing P and P
>>>>>> to H does not specify that computation, and you can't say what two
>>>>>> arguments /would/ specify it.
>>>>>>
>>>>>> A clear and unambiguous statement that no D such that D(X,Y) == true if
>>>>>> and only if X(Y) halts and false otherwise is possible would be the
>>>>>> honest way to move things on. If you were clear about this, maybe
>>>>>> someone will talk to you about [whatever] it is that your H is
>>>>>> deciding.
>>>> So you won't admit that no algorithm can do what D is specified to do?
>>>> You are just going to pretend that no one cares about actual halting.
>>>> I hope you see that by ignoring this point you are confirming that you
>>>> know D can't exist. If you thought such a D was possible, you'd be
>>>> shouting that from the roof tops since it's what everyone else says is
>>>> impossible.
>>>>
>>>>> I adapted my system so that I could empirically test this:
>>>>> H1(P,P)==true is empirically proven to be correct
>>>>> H(P,P)==false is empirically proven to be correct
>>>>
>>>> But neither can tell us squat about the halting of P(P) -- the thing
>>>> that H was originally supposed to decide.
>>>
>>> Are you simply wired to ignore my words so that you can disagree with
>>> everything that I say?
>>>
>>> H1(P,P)==true reports on the behavior of P(P).
>> I try to ignore that bits that are irrelevant. These two deciders
>> decide all halting instances between them:
>> bool H1(X, Y) { return true; }
>> bool H2(X, Y) { return false; }
>> Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
>> maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
>
> H1(P,P)==true is empirically proven to be correct
> H(P,P)==false is empirically proven to be correct

> Both take the machine code of P as input parameters and are provably
> correct simulations of this same input yet one correctly determines
> that its input halts and the other correctly determines that its input
> does not halt. ALL THESE THINGS ARE VERIFIED FACTS !

Your mantra is doing sterling work, allowing you to pretend you are
taking about the halting problem while hiding what it is that your
deciders are deciding. Whatever you are hiding behind the words
"correct simulations of this same input" it is obviously not the halting
of P(P). For one thing, there is only one correct answer to the halting
or otherwise of a computation, and for another, H(X,Y) is obviously not
telling the world what it wants to know -- the halting of the
computation X(Y).

Do you have anything at all left to say about the real halting problem?
I really think you should at least state, explicitly, that you now
accept that no function D exists such that D(X,Y) == true if an only if
X(Y) halts and false otherwise.

I am sure some people will still want to talk about the mistakes in what
you call the "correct simulations of this same input" but you should be
honest about halting problem as defined above. And if people do stop
talking to you about halting, you can always switch back to Gödel or
Tarski.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

On 5/5/2022 6:54 AM, Dennis Bush wrote:
> On Thursday, May 5, 2022 at 12:49:27 AM UTC-4, olcott wrote:
>> On 5/4/2022 11:12 PM, Dennis Bush wrote:
>>> On Wednesday, May 4, 2022 at 11:54:14 PM UTC-4, olcott wrote:
>>>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
>>>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
>>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested
>>>>>>>>>>>>>>>>>>>> simulation to H.
>>>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up about the halting
>>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
>>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that H(P,P) == false
>>>>>>>>>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it is not a
>>>>>>>>>>>>>>>>>> decider because deciders only compute the mapping from inputs to final
>>>>>>>>>>>>>>>>>> states.
>>>>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states /according to
>>>>>>>>>>>>>>>>> some property of the inputs/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That par is exactly correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -- whether the input represents, for
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That part has been the key error of everyone in that they all believe
>>>>>>>>>>>>>>>> that is can represent something other than what it actually specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that there is no
>>>>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C halt decider
>>>>>>>>>>>>>>> H. At least that is a clear admission that the halting of function
>>>>>>>>>>>>>>> calls like P(P) can not be decided because, apparently, passing P and P
>>>>>>>>>>>>>>> to H does not specify that computation, and you can't say what two
>>>>>>>>>>>>>>> arguments /would/ specify it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y) == true if
>>>>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would be the
>>>>>>>>>>>>>>> honest way to move things on. If you were clear about this, maybe
>>>>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
>>>>>>>>>>>>>>> deciding.
>>>>>>>>>>>>> So you won't admit that no algorithm can do what D is specified to do?
>>>>>>>>>>>>> You are just going to pretend that no one cares about actual halting.
>>>>>>>>>>>>> I hope you see that by ignoring this point you are confirming that you
>>>>>>>>>>>>> know D can't exist. If you thought such a D was possible, you'd be
>>>>>>>>>>>>> shouting that from the roof tops since it's what everyone else says is
>>>>>>>>>>>>> impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I adapted my system so that I could empirically test this:
>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>>>>
>>>>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the thing
>>>>>>>>>>>>> that H was originally supposed to decide.
>>>>>>>>>>>>
>>>>>>>>>>>> Are you simply wired to ignore my words so that you can disagree with
>>>>>>>>>>>> everything that I say?
>>>>>>>>>>>>
>>>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
>>>>>>>>>>>
>>>>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
>>>>>>>>>>> decide all halting instances between them:
>>>>>>>>>>>
>>>>>>>>>>> bool H1(X, Y) { return true; }
>>>>>>>>>>> bool H2(X, Y) { return false; }
>>>>>>>>>>>
>>>>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
>>>>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
>>>>>>>>>>
>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>
>>>>>>>>> If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
>>>>>>>>>
>>>>>>>>> So which one doesn't compute the halting function?
>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>>>>> Both take the machine code of P as input parameters and are provably
>>>>>>>> correct simulations of this same input yet one correctly determines that
>>>>>>>> its input halts and the other correctly determines that its input does
>>>>>>>> not halt.
>>>>>>>
>>>>>>> Which means at least one is not computing the halting function. So which one is it?
>>>>>>>
>>>>>> The above paragraph means that it makes no mistakes in computing the
>>>>>> halting function. This is a verifiable fact, not any mere opinion. The
>>>>>> reason that I did the HP in C/x86 was so that every detail can be shown
>>>>>> thus gaps in reasoning revealed.
>>>
>>> Just because a simulating halt decider aborts doesn't necessarily mean it was correct to do so. On the other hand, a simulating halt decider that simulates to a final state is always correct and proves that any mapping of the same input to non-halting is necessarily incorrect.
>>>
>>>>>
>>>>> Any decider that maps the halting function performs the *same* mapping of inputs to outputs.
>>>> That is now proven to be factually incorrect.
>>>
>>> FALSE. The mapping of the halting function is DEFINED (i.e. is immutable and fixed) as:
>>>
>>> M w maps to true if and only if M(w) halts, and
>>> M w maps to false if and only if M(w) does not halt
>>>
>>> So any halt decider that does not compute this *exact* mapping is not computing the halting function.
>>>
>> Both H(P,P) and H1(P,P) are provably correct.
>
> If both are computing the halting function, which is a mathematical function which ALWAYS maps a given input to the same output, then this PROVES that one is wrong. Specifically, H(P,P) is provably *incorrect*, and it is the result of H1(P,P) that does exactly that.
>
> The only way for both to be "provably correct" is if at least one of them is computing something else besides the halting function.

On Thursday, May 5, 2022 at 12:12:45 PM UTC-4, olcott wrote:
> On 5/5/2022 6:54 AM, Dennis Bush wrote:
> > On Thursday, May 5, 2022 at 12:49:27 AM UTC-4, olcott wrote:
> >> On 5/4/2022 11:12 PM, Dennis Bush wrote:
> >>> On Wednesday, May 4, 2022 at 11:54:14 PM UTC-4, olcott wrote:
> >>>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
> >>>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
> >>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
> >>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
> >>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
> >>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
> >>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
> >>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
> >>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
> >>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
> >>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested
> >>>>>>>>>>>>>>>>>>>> simulation to H.
> >>>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up about the halting
> >>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
> >>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that H(P,P) == false
> >>>>>>>>>>>>>>>>>>> and that P(P) halts.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it is not a
> >>>>>>>>>>>>>>>>>> decider because deciders only compute the mapping from inputs to final
> >>>>>>>>>>>>>>>>>> states.
> >>>>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states /according to
> >>>>>>>>>>>>>>>>> some property of the inputs/
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That par is exactly correct.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -- whether the input represents, for
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That part has been the key error of everyone in that they all believe
> >>>>>>>>>>>>>>>> that is can represent something other than what it actually specifies.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that there is no
> >>>>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C halt decider
> >>>>>>>>>>>>>>> H. At least that is a clear admission that the halting of function
> >>>>>>>>>>>>>>> calls like P(P) can not be decided because, apparently, passing P and P
> >>>>>>>>>>>>>>> to H does not specify that computation, and you can't say what two
> >>>>>>>>>>>>>>> arguments /would/ specify it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y) == true if
> >>>>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would be the
> >>>>>>>>>>>>>>> honest way to move things on. If you were clear about this, maybe
> >>>>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
> >>>>>>>>>>>>>>> deciding.
> >>>>>>>>>>>>> So you won't admit that no algorithm can do what D is specified to do?
> >>>>>>>>>>>>> You are just going to pretend that no one cares about actual halting.
> >>>>>>>>>>>>> I hope you see that by ignoring this point you are confirming that you
> >>>>>>>>>>>>> know D can't exist. If you thought such a D was possible, you'd be
> >>>>>>>>>>>>> shouting that from the roof tops since it's what everyone else says is
> >>>>>>>>>>>>> impossible.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> I adapted my system so that I could empirically test this:
> >>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the thing
> >>>>>>>>>>>>> that H was originally supposed to decide.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Are you simply wired to ignore my words so that you can disagree with
> >>>>>>>>>>>> everything that I say?
> >>>>>>>>>>>>
> >>>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
> >>>>>>>>>>>
> >>>>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
> >>>>>>>>>>> decide all halting instances between them:
> >>>>>>>>>>>
> >>>>>>>>>>> bool H1(X, Y) { return true; }
> >>>>>>>>>>> bool H2(X, Y) { return false; }
> >>>>>>>>>>>
> >>>>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
> >>>>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
> >>>>>>>>>>
> >>>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>>
> >>>>>>>>> If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
> >>>>>>>>>
> >>>>>>>>> So which one doesn't compute the halting function?
> >>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> >>>>>>>> Both take the machine code of P as input parameters and are provably
> >>>>>>>> correct simulations of this same input yet one correctly determines that
> >>>>>>>> its input halts and the other correctly determines that its input does
> >>>>>>>> not halt.
> >>>>>>>
> >>>>>>> Which means at least one is not computing the halting function. So which one is it?
> >>>>>>>
> >>>>>> The above paragraph means that it makes no mistakes in computing the
> >>>>>> halting function. This is a verifiable fact, not any mere opinion. The
> >>>>>> reason that I did the HP in C/x86 was so that every detail can be shown
> >>>>>> thus gaps in reasoning revealed.
> >>>
> >>> Just because a simulating halt decider aborts doesn't necessarily mean it was correct to do so. On the other hand, a simulating halt decider that simulates to a final state is always correct and proves that any mapping of the same input to non-halting is necessarily incorrect.
> >>>
> >>>>>
> >>>>> Any decider that maps the halting function performs the *same* mapping of inputs to outputs.
> >>>> That is now proven to be factually incorrect.
> >>>
> >>> FALSE. The mapping of the halting function is DEFINED (i.e. is immutable and fixed) as:
> >>>
> >>> M w maps to true if and only if M(w) halts, and
> >>> M w maps to false if and only if M(w) does not halt
> >>>
> >>> So any halt decider that does not compute this *exact* mapping is not computing the halting function.
> >>>
> >> Both H(P,P) and H1(P,P) are provably correct.
> >
> > If both are computing the halting function, which is a mathematical function which ALWAYS maps a given input to the same output, then this PROVES that one is wrong. Specifically, H(P,P) is provably *incorrect*, and it is the result of H1(P,P) that does exactly that.
> >
> > The only way for both to be "provably correct" is if at least one of them is computing something else besides the halting function.
> It is a verified fact that they both provable compute the halting
> function of their own input correctly. Anyone knowing the x86 language
> can verify this fact.

On Thu, 5 May 2022 12:19:47 +0300
Mikko <mikko.levanto@iki.fi> wrote:

> On 2022-05-02 15:47:32 +0000, Mr Flibble said:
>
> > Not all infinitely recursive definitions are invalid however
> > infinitely recursive definitions that arise out of a category error
> > (as is the case with the halting problem) are invalid.
> >
> > The halting problem (as currently defined) is invalid due to the
> > invalid "impossible program" [Strachey, 1965] that is actually
> > impossible due to the category error present in its definition and
> > *not* because of any function call-like recursion; confusion between
> > these two types of recursion are why Olcott is having difficulty
> > communicating his ideas with the rest of you shower.
> >
> > The categories involved in the category error are the decider and
> > that which is being decided. Currently extant attempts to conflate
> > the decider with that which is being decided are infinitely
> > recursive and thus invalid.
>
> There is no category error in the theorem. An infinitely recursive
> computation is still in the category of computations. Its behaviour
> is well defined and it either halts in finite time (in which case
> it isn't actually infinitely recursive) or it does not (either because
> it is infinitely recursive or because of some other cause). Therefore
> the claim that there is a category error in the theorem is invalid.

The category error is in the proof of the theorem existing as an
erroneous (invalid) infinite recursion [Wikipedia, 2022]

/Flibble

On 5/5/2022 7:27 AM, Malcolm McLean wrote:
> On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote:
>> On 5/4/22 11:54 PM, olcott wrote:
>>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
>>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies
>>>>>>>>>>>>>>>>>>> infinitely nested
>>>>>>>>>>>>>>>>>>> simulation to H.
>>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up
>>>>>>>>>>>>>>>>>> about the halting
>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
>>>>>>>>>>>>>>>>>> computation P(P) it is
>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
>>>>>>>>>>>>>>>>>> H(P,P) == false
>>>>>>>>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it
>>>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>>>> decider because deciders only compute the mapping from
>>>>>>>>>>>>>>>>> inputs to final
>>>>>>>>>>>>>>>>> states.
>>>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states
>>>>>>>>>>>>>>>> /according to
>>>>>>>>>>>>>>>> some property of the inputs/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That par is exactly correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- whether the input represents, for
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That part has been the key error of everyone in that they
>>>>>>>>>>>>>>> all believe
>>>>>>>>>>>>>>> that is can represent something other than what it actually
>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that
>>>>>>>>>>>>>> there is no
>>>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C
>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>> H. At least that is a clear admission that the halting of
>>>>>>>>>>>>>> function
>>>>>>>>>>>>>> calls like P(P) can not be decided because, apparently,
>>>>>>>>>>>>>> passing P and P
>>>>>>>>>>>>>> to H does not specify that computation, and you can't say
>>>>>>>>>>>>>> what two
>>>>>>>>>>>>>> arguments /would/ specify it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y)
>>>>>>>>>>>>>> == true if
>>>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would
>>>>>>>>>>>>>> be the
>>>>>>>>>>>>>> honest way to move things on. If you were clear about this,
>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
>>>>>>>>>>>>>> deciding.
>>>>>>>>>>>> So you won't admit that no algorithm can do what D is
>>>>>>>>>>>> specified to do?
>>>>>>>>>>>> You are just going to pretend that no one cares about actual
>>>>>>>>>>>> halting.
>>>>>>>>>>>> I hope you see that by ignoring this point you are confirming
>>>>>>>>>>>> that you
>>>>>>>>>>>> know D can't exist. If you thought such a D was possible,
>>>>>>>>>>>> you'd be
>>>>>>>>>>>> shouting that from the roof tops since it's what everyone else
>>>>>>>>>>>> says is
>>>>>>>>>>>> impossible.
>>>>>>>>>>>>
>>>>>>>>>>>>> I adapted my system so that I could empirically test this:
>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>>>
>>>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the
>>>>>>>>>>>> thing
>>>>>>>>>>>> that H was originally supposed to decide.
>>>>>>>>>>>
>>>>>>>>>>> Are you simply wired to ignore my words so that you can
>>>>>>>>>>> disagree with
>>>>>>>>>>> everything that I say?
>>>>>>>>>>>
>>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
>>>>>>>>>>
>>>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
>>>>>>>>>> decide all halting instances between them:
>>>>>>>>>>
>>>>>>>>>> bool H1(X, Y) { return true; }
>>>>>>>>>> bool H2(X, Y) { return false; }
>>>>>>>>>>
>>>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat,
>>>>>>>>>> H1_hat) or
>>>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call
>>>>>>>>>> H_hat.
>>>>>>>>>
>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>
>>>>>>>> If that is so then H and H1 don't perform the same mapping. This
>>>>>>>> means that one (or both) do not compute the halting function.
>>>>>>>>
>>>>>>>> So which one doesn't compute the halting function?
>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>>>> Both take the machine code of P as input parameters and are provably
>>>>>>> correct simulations of this same input yet one correctly determines
>>>>>>> that
>>>>>>> its input halts and the other correctly determines that its input does
>>>>>>> not halt.
>>>>>>
>>>>>> Which means at least one is not computing the halting function. So
>>>>>> which one is it?
>>>>>>
>>>>> The above paragraph means that it makes no mistakes in computing the
>>>>> halting function. This is a verifiable fact, not any mere opinion. The
>>>>> reason that I did the HP in C/x86 was so that every detail can be shown
>>>>> thus gaps in reasoning revealed.
>>>>
>>>> Any decider that maps the halting function performs the *same* mapping
>>>> of inputs to outputs.
>>>
>>> That is now proven to be factually incorrect.
>>>
>>> If the above paragraph is proven to be a fact then this proves that both
>>> H and H1 compute the halting function correctly. The above paragraph can
>>> be proven to be a fact.
>> Yes, IF you can prove that cats are dogs, you can prove that H is
>> correctly computing the Halting Function.
>>
>> Since you can't, you can't.
>>
>> In fact, you have just proven that you don't know what you are talking
>> about, since you just asserted a LIE.
>>
>> Two machines claiming to compute the same function must generate the
>> same answer from the same input or one of them is incorrect.
>>
>> BASIC FACT.
>>
> In parapsychology, there's something called "the experimenter effect". The same
> experiment will show a parapsychological effect or not, depending on who is
> performing the experiment. This has been described as parapsychology's one finding.
> If true in an interesting way, it also strikes at the heart of the scientific method.
>
> But intuitively, it's not implausible that an experiment would "work" for an experimenter
> with gypsy blood, for example. You can't simply reject the experimenter effect on the
> basis that, if it means more than that certain experimenters are more gullible than
> others, it leaves the rest of science in tatters.
>
> PO says that a machine has one behaviour when run, and another behaviour when
> "correctly simulated". That claim, if true, similarly leaves the whole of computer science
> in tatters. Which means that it's his responsibility to provide a much better explanation
> of what he means than he has done currently.
>
> But he's been clear about this. He's asserting what anyone who knows just a tiny amount
> about computers must consdier to be nonsense. At first glance. But the idea that
> i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
> difference is that more details were forthcoming.

On Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote:
> On 5/5/2022 7:27 AM, Malcolm McLean wrote:
> > On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote:
> >> On 5/4/22 11:54 PM, olcott wrote:
> >>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
> >>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
> >>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
> >>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
> >>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
> >>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
> >>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
> >>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>
> >>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
> >>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
> >>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
> >>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
> >>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies
> >>>>>>>>>>>>>>>>>>> infinitely nested
> >>>>>>>>>>>>>>>>>>> simulation to H.
> >>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up
> >>>>>>>>>>>>>>>>>> about the halting
> >>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
> >>>>>>>>>>>>>>>>>> computation P(P) it is
> >>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
> >>>>>>>>>>>>>>>>>> H(P,P) == false
> >>>>>>>>>>>>>>>>>> and that P(P) halts.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it
> >>>>>>>>>>>>>>>>> is not a
> >>>>>>>>>>>>>>>>> decider because deciders only compute the mapping from
> >>>>>>>>>>>>>>>>> inputs to final
> >>>>>>>>>>>>>>>>> states.
> >>>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states
> >>>>>>>>>>>>>>>> /according to
> >>>>>>>>>>>>>>>> some property of the inputs/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That par is exactly correct.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -- whether the input represents, for
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That part has been the key error of everyone in that they
> >>>>>>>>>>>>>>> all believe
> >>>>>>>>>>>>>>> that is can represent something other than what it actually
> >>>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that
> >>>>>>>>>>>>>> there is no
> >>>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C
> >>>>>>>>>>>>>> halt decider
> >>>>>>>>>>>>>> H. At least that is a clear admission that the halting of
> >>>>>>>>>>>>>> function
> >>>>>>>>>>>>>> calls like P(P) can not be decided because, apparently,
> >>>>>>>>>>>>>> passing P and P
> >>>>>>>>>>>>>> to H does not specify that computation, and you can't say
> >>>>>>>>>>>>>> what two
> >>>>>>>>>>>>>> arguments /would/ specify it.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y)
> >>>>>>>>>>>>>> == true if
> >>>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would
> >>>>>>>>>>>>>> be the
> >>>>>>>>>>>>>> honest way to move things on. If you were clear about this,
> >>>>>>>>>>>>>> maybe
> >>>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
> >>>>>>>>>>>>>> deciding.
> >>>>>>>>>>>> So you won't admit that no algorithm can do what D is
> >>>>>>>>>>>> specified to do?
> >>>>>>>>>>>> You are just going to pretend that no one cares about actual
> >>>>>>>>>>>> halting.
> >>>>>>>>>>>> I hope you see that by ignoring this point you are confirming
> >>>>>>>>>>>> that you
> >>>>>>>>>>>> know D can't exist. If you thought such a D was possible,
> >>>>>>>>>>>> you'd be
> >>>>>>>>>>>> shouting that from the roof tops since it's what everyone else
> >>>>>>>>>>>> says is
> >>>>>>>>>>>> impossible.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I adapted my system so that I could empirically test this:
> >>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>>>>>
> >>>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the
> >>>>>>>>>>>> thing
> >>>>>>>>>>>> that H was originally supposed to decide.
> >>>>>>>>>>>
> >>>>>>>>>>> Are you simply wired to ignore my words so that you can
> >>>>>>>>>>> disagree with
> >>>>>>>>>>> everything that I say?
> >>>>>>>>>>>
> >>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
> >>>>>>>>>>
> >>>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
> >>>>>>>>>> decide all halting instances between them:
> >>>>>>>>>>
> >>>>>>>>>> bool H1(X, Y) { return true; }
> >>>>>>>>>> bool H2(X, Y) { return false; }
> >>>>>>>>>>
> >>>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat,
> >>>>>>>>>> H1_hat) or
> >>>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call
> >>>>>>>>>> H_hat.
> >>>>>>>>>
> >>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>
> >>>>>>>> If that is so then H and H1 don't perform the same mapping. This
> >>>>>>>> means that one (or both) do not compute the halting function.
> >>>>>>>>
> >>>>>>>> So which one doesn't compute the halting function?
> >>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> >>>>>>> Both take the machine code of P as input parameters and are provably
> >>>>>>> correct simulations of this same input yet one correctly determines
> >>>>>>> that
> >>>>>>> its input halts and the other correctly determines that its input does
> >>>>>>> not halt.
> >>>>>>
> >>>>>> Which means at least one is not computing the halting function. So
> >>>>>> which one is it?
> >>>>>>
> >>>>> The above paragraph means that it makes no mistakes in computing the
> >>>>> halting function. This is a verifiable fact, not any mere opinion. The
> >>>>> reason that I did the HP in C/x86 was so that every detail can be shown
> >>>>> thus gaps in reasoning revealed.
> >>>>
> >>>> Any decider that maps the halting function performs the *same* mapping
> >>>> of inputs to outputs.
> >>>
> >>> That is now proven to be factually incorrect.
> >>>
> >>> If the above paragraph is proven to be a fact then this proves that both
> >>> H and H1 compute the halting function correctly. The above paragraph can
> >>> be proven to be a fact.
> >> Yes, IF you can prove that cats are dogs, you can prove that H is
> >> correctly computing the Halting Function.
> >>
> >> Since you can't, you can't.
> >>
> >> In fact, you have just proven that you don't know what you are talking
> >> about, since you just asserted a LIE.
> >>
> >> Two machines claiming to compute the same function must generate the
> >> same answer from the same input or one of them is incorrect.
> >>
> >> BASIC FACT.
> >>
> > In parapsychology, there's something called "the experimenter effect". The same
> > experiment will show a parapsychological effect or not, depending on who is
> > performing the experiment. This has been described as parapsychology's one finding.
> > If true in an interesting way, it also strikes at the heart of the scientific method.
> >
> > But intuitively, it's not implausible that an experiment would "work" for an experimenter
> > with gypsy blood, for example. You can't simply reject the experimenter effect on the
> > basis that, if it means more than that certain experimenters are more gullible than
> > others, it leaves the rest of science in tatters.
> >
> > PO says that a machine has one behaviour when run, and another behaviour when
> > "correctly simulated". That claim, if true, similarly leaves the whole of computer science
> > in tatters. Which means that it's his responsibility to provide a much better explanation
> > of what he means than he has done currently.
> >
> > But he's been clear about this. He's asserting what anyone who knows just a tiny amount
> > about computers must consdier to be nonsense. At first glance. But the idea that
> > i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
> > difference is that more details were forthcoming.
> Anyone knowing the x86 language can verify that H(P,P) and H1(P,P)
> compute the mapping from their input parameters to their own final state
> correctly. Arguing with verified facts is a fools folly.

On 5/5/2022 4:19 AM, Mikko wrote:
> On 2022-05-02 15:47:32 +0000, Mr Flibble said:
>
>> Not all infinitely recursive definitions are invalid however infinitely
>> recursive definitions that arise out of a category error (as is the
>> case with the halting problem) are invalid.
>>
>> The halting problem (as currently defined) is invalid due to the
>> invalid "impossible program" [Strachey, 1965] that is actually
>> impossible due to the category error present in its definition and
>> *not* because of any function call-like recursion; confusion between
>> these two types of recursion are why Olcott is having difficulty
>> communicating his ideas with the rest of you shower.
>>
>> The categories involved in the category error are the decider and that
>> which is being decided.  Currently extant attempts to conflate the
>> decider with that which is being decided are infinitely
>> recursive and thus invalid.
>
> There is no category error in the theorem. An infinitely recursive
> computation is still in the category of computations.

Not according to Linz. Linz says that all computations must halt.

> Its behaviour
> is well defined and it either halts in finite time (in which case
> it isn't actually infinitely recursive) or it does not (either because

Halting only counts when the input reaches its own final state. An
aborted simulation does not count as halting.

H(P,P)==false is provably correct in that H does correctly compute the
mapping from its input parameters to its own final reject state.

> it is infinitely recursive or because of some other cause). Therefore
> the claim that there is a category error in the theorem is invalid.
>
> Mikko
>

--
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 5/5/2022 4:37 AM, Mikko wrote:
> On 2022-05-04 17:57:32 +0000, olcott said:
>
>> On 5/4/2022 2:19 AM, Mikko wrote:
>>> On 2022-05-03 18:06:24 +0000, olcott said:
>>>
>>>> On 5/3/2022 12:17 PM, Mikko wrote:
>>>>> On 2022-05-03 14:38:57 +0000, olcott said:
>>>>>
>>>>>> On 5/3/2022 4:36 AM, Mikko wrote:
>>>>>>> On 2022-05-02 16:18:36 +0000, olcott said:
>>>>>>>
>>>>>>>> It seems to me that all infinitely recursive definitions are
>>>>>>>> invalid and I am having an excellent dialogue with some Prolog
>>>>>>>> folks about this in comp.lang.prolog.
>>>>>>>
>>>>>>> One of the rules that define Prolog language is
>>>>>>>
>>>>>>>  arguments ::= argument | argument "," arguments
>>>>>>>
>>>>>>> which is infinitely recursive. Is it invalid? Is Prolog invalid
>>>>>>> because
>>>>>>> of this and other infinitely recursive rules?
>>>>>>>
>>>>>>> Mikko
>>>>>>>
>>>>>>
>>>>>> If would have to be invalid because it can never be resolved.
>>>>>
>>>>> What would be invalid? Prolog? Definition of Prolog?
>>>>> Why "would be" and not "is"?
>>>>>
>>>>> Mikko
>>>>>
>>>>
>>>> Expressions that cannot be resolved in Prolog that fail the
>>>> unify_with_occurs_check test proves that these expressions are
>>>> semantically incorrect.
>>>
>>> No, it does not mean anything like that. It only means that no well
>>> founded
>>> data structure matches both arguments.
>>>
>>> For example, unify_with_occurs_check(1, 2) fails but there is nothing
>>> sematically incorrect in 1, 2.
>>>
>>
>>
>>
>> BEGIN:(Clocksin & Mellish 2003:254)
>> Finally, a note about how Prolog matching sometimes differs from the
>> unification used in Resolution. Most Prolog systems will allow you to
>> satisfy goals like:
>>
>>    equal(X, X).
>>    ?- equal(foo(Y), Y).
>>
>> that is, they will allow you to match a term against an uninstantiated
>> subterm of itself. In this example, foo(Y) is matched against Y, which
>> appears within it. As a result, Y will stand for foo(Y), which is
>> foo(foo(Y)) (because of what Y stands for), which is foo(foo(foo(Y))),
>> and so on. So Y ends up standing for some kind of infinite structure.
>>
>> <inserted for clarity>
>> foo(foo(foo(foo(foo(foo(foo(foo(foo(foo(foo(foo(...))))))))))))
>> </inserted for clarity>
>>
>> Note that, whereas they may allow you to construct something like
>> this, most Prolog systems will not be able to write it out at the end.
>> According to the formal definition of Unification, this kind of
>> “infinite term” should never come to exist. Thus Prolog systems that
>> allow a term to match an uninstantiated subterm of itself do not act
>> correctly as Resolution theorem provers. In order to make them do so,
>> we would have to add a check that a variable cannot be instantiated to
>> something containing itself. Such a check, an occurs check, would be
>> straightforward to implement, but would slow down the execution of
>> Prolog programs considerably. Since it would only affect very few
>> programs, most implementors have simply left it out 1.
>>
>> 1 The Prolog standard states that the result is undefined if a Prolog
>> system attempts to match a term against an uninstantiated subterm of
>> itself, which means that programs which cause this  to happen will not
>> be portable. A portable program should ensure that wherever an occurs
>> check might be applicable the built-in predicate
>> unify_with_occurs_check/2 is used explicitly instead of the normal
>> unification operation of the Prolog implementation. As its name
>> suggests, this predicate acts like =/2 except that it fails if an
>> occurs check detects an illegal attempt to instantiate a variable.
>> END:(Clocksin & Mellish 2003:254)
>>
>> Clocksin, W.F. and Mellish, C.S. 2003. Programming in Prolog Using the
>> ISO Standard Fifth Edition, 254. Berlin Heidelberg: Springer-Verlag.
>
> Nice that you now agree and retract your earlier statement.
>
> Mikko
>

I never retracted anything.

--
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 5/5/2022 6:57 AM, Dennis Bush wrote:
> On Thursday, May 5, 2022 at 7:50:02 AM UTC-4, richar...@gmail.com wrote:
>> On 5/4/22 11:42 PM, olcott wrote:
>>> On 5/4/2022 10:38 PM, André G. Isaak wrote:
>>>> On 2022-05-04 21:35, olcott wrote:
>>>>> On 5/4/2022 10:17 PM, André G. Isaak wrote:
>>>>>> On 2022-05-04 21:09, olcott wrote:
>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>>>
>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>
>>>>>>>> If that is so then H and H1 don't perform the same mapping. This
>>>>>>>> means that one (or both) do not compute the halting function.
>>>>>>>>
>>>>>>>> So which one doesn't compute the halting function?
>>>>>>
>>>>>> You didn't actually answer this question.
>>>>>>
>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>>>> Both take the machine code of P as input parameters and are
>>>>>>> provably correct simulations of this same input yet one correctly
>>>>>>> determines that its input halts and the other correctly determines
>>>>>>> that its input does not halt.
>>>>>>
>>>>>> Please define your use of the term "correct simulation".
>>>>>>
>>>>>> André
>>>>>>
>>>>>>
>>>>>
>>>>> Good question.
>>>>> The behavior of the simulated input exactly matches the correct
>>>>> execution trace of the behavior in a real hardware machine.
>>>>
>>>> So if P(P), when executed directly, halts, how can a 'correct
>>>> simulation' possibly not halt?
>>>>
>>>> André
>>>>
>>>
>>> As soon as you very carefully study every single detail of the above
>>> paragraph you will realize that it proves that I am correct as soon as
>>> the paragraph itself is proved to be factually correct.
>>>
>> No, it proves that you don't know what you are saying. The only machine
>> to use to "Correctly simulate the input (P,P) is P(P), sp that is what
>> must define the correct answer.
>>
>> If it looks at H, then by your definition ALL simulating decider are
>> "correct", as it is there simulation, no matter how awful, that defines
>> the answer.
>
> To PO: the above is exactly where the conclusion that Ha3(N,5) == false is coming from.

Ha3() is merely a decider that was intentionally designed to get the
wrong answer thus no evidence what-so-ever that a decider that gets the
right answer does not exist.

--
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 Thursday, May 5, 2022 at 2:01:28 PM UTC-4, olcott wrote:
> On 5/5/2022 6:57 AM, Dennis Bush wrote:
> > On Thursday, May 5, 2022 at 7:50:02 AM UTC-4, richar...@gmail.com wrote:
> >> On 5/4/22 11:42 PM, olcott wrote:
> >>> On 5/4/2022 10:38 PM, André G. Isaak wrote:
> >>>> On 2022-05-04 21:35, olcott wrote:
> >>>>> On 5/4/2022 10:17 PM, André G. Isaak wrote:
> >>>>>> On 2022-05-04 21:09, olcott wrote:
> >>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
> >>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
> >>>>>>
> >>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>
> >>>>>>>> If that is so then H and H1 don't perform the same mapping. This
> >>>>>>>> means that one (or both) do not compute the halting function.
> >>>>>>>>
> >>>>>>>> So which one doesn't compute the halting function?
> >>>>>>
> >>>>>> You didn't actually answer this question.
> >>>>>>
> >>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> >>>>>>> Both take the machine code of P as input parameters and are
> >>>>>>> provably correct simulations of this same input yet one correctly
> >>>>>>> determines that its input halts and the other correctly determines
> >>>>>>> that its input does not halt.
> >>>>>>
> >>>>>> Please define your use of the term "correct simulation".
> >>>>>>
> >>>>>> André
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> Good question.
> >>>>> The behavior of the simulated input exactly matches the correct
> >>>>> execution trace of the behavior in a real hardware machine.
> >>>>
> >>>> So if P(P), when executed directly, halts, how can a 'correct
> >>>> simulation' possibly not halt?
> >>>>
> >>>> André
> >>>>
> >>>
> >>> As soon as you very carefully study every single detail of the above
> >>> paragraph you will realize that it proves that I am correct as soon as
> >>> the paragraph itself is proved to be factually correct.
> >>>
> >> No, it proves that you don't know what you are saying. The only machine
> >> to use to "Correctly simulate the input (P,P) is P(P), sp that is what
> >> must define the correct answer.
> >>
> >> If it looks at H, then by your definition ALL simulating decider are
> >> "correct", as it is there simulation, no matter how awful, that defines
> >> the answer.
> >
> > To PO: the above is exactly where the conclusion that Ha3(N,5) == false is coming from.
> Ha3() is merely a decider that was intentionally designed to get the
> wrong answer thus no evidence what-so-ever that a decider that gets the
> right answer does not exist.

Then you should have no problem specifying *exactly* how Ha3 gets the wrong answer in a generalized way that also describes how H(P,P) gets the right answer.

On 5/5/2022 11:20 AM, Dennis Bush wrote:
> On Thursday, May 5, 2022 at 12:12:45 PM UTC-4, olcott wrote:
>> On 5/5/2022 6:54 AM, Dennis Bush wrote:
>>> On Thursday, May 5, 2022 at 12:49:27 AM UTC-4, olcott wrote:
>>>> On 5/4/2022 11:12 PM, Dennis Bush wrote:
>>>>> On Wednesday, May 4, 2022 at 11:54:14 PM UTC-4, olcott wrote:
>>>>>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
>>>>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested
>>>>>>>>>>>>>>>>>>>>>> simulation to H.
>>>>>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up about the halting
>>>>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
>>>>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that H(P,P) == false
>>>>>>>>>>>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it is not a
>>>>>>>>>>>>>>>>>>>> decider because deciders only compute the mapping from inputs to final
>>>>>>>>>>>>>>>>>>>> states.
>>>>>>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states /according to
>>>>>>>>>>>>>>>>>>> some property of the inputs/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That par is exactly correct.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -- whether the input represents, for
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That part has been the key error of everyone in that they all believe
>>>>>>>>>>>>>>>>>> that is can represent something other than what it actually specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that there is no
>>>>>>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C halt decider
>>>>>>>>>>>>>>>>> H. At least that is a clear admission that the halting of function
>>>>>>>>>>>>>>>>> calls like P(P) can not be decided because, apparently, passing P and P
>>>>>>>>>>>>>>>>> to H does not specify that computation, and you can't say what two
>>>>>>>>>>>>>>>>> arguments /would/ specify it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y) == true if
>>>>>>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would be the
>>>>>>>>>>>>>>>>> honest way to move things on. If you were clear about this, maybe
>>>>>>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
>>>>>>>>>>>>>>>>> deciding.
>>>>>>>>>>>>>>> So you won't admit that no algorithm can do what D is specified to do?
>>>>>>>>>>>>>>> You are just going to pretend that no one cares about actual halting.
>>>>>>>>>>>>>>> I hope you see that by ignoring this point you are confirming that you
>>>>>>>>>>>>>>> know D can't exist. If you thought such a D was possible, you'd be
>>>>>>>>>>>>>>> shouting that from the roof tops since it's what everyone else says is
>>>>>>>>>>>>>>> impossible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I adapted my system so that I could empirically test this:
>>>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the thing
>>>>>>>>>>>>>>> that H was originally supposed to decide.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you simply wired to ignore my words so that you can disagree with
>>>>>>>>>>>>>> everything that I say?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
>>>>>>>>>>>>> decide all halting instances between them:
>>>>>>>>>>>>>
>>>>>>>>>>>>> bool H1(X, Y) { return true; }
>>>>>>>>>>>>> bool H2(X, Y) { return false; }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
>>>>>>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
>>>>>>>>>>>>
>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>>
>>>>>>>>>>> If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
>>>>>>>>>>>
>>>>>>>>>>> So which one doesn't compute the halting function?
>>>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>>>>>>> Both take the machine code of P as input parameters and are provably
>>>>>>>>>> correct simulations of this same input yet one correctly determines that
>>>>>>>>>> its input halts and the other correctly determines that its input does
>>>>>>>>>> not halt.
>>>>>>>>>
>>>>>>>>> Which means at least one is not computing the halting function. So which one is it?
>>>>>>>>>
>>>>>>>> The above paragraph means that it makes no mistakes in computing the
>>>>>>>> halting function. This is a verifiable fact, not any mere opinion. The
>>>>>>>> reason that I did the HP in C/x86 was so that every detail can be shown
>>>>>>>> thus gaps in reasoning revealed.
>>>>>
>>>>> Just because a simulating halt decider aborts doesn't necessarily mean it was correct to do so. On the other hand, a simulating halt decider that simulates to a final state is always correct and proves that any mapping of the same input to non-halting is necessarily incorrect.
>>>>>
>>>>>>>
>>>>>>> Any decider that maps the halting function performs the *same* mapping of inputs to outputs.
>>>>>> That is now proven to be factually incorrect.
>>>>>
>>>>> FALSE. The mapping of the halting function is DEFINED (i.e. is immutable and fixed) as:
>>>>>
>>>>> M w maps to true if and only if M(w) halts, and
>>>>> M w maps to false if and only if M(w) does not halt
>>>>>
>>>>> So any halt decider that does not compute this *exact* mapping is not computing the halting function.
>>>>>
>>>> Both H(P,P) and H1(P,P) are provably correct.
>>>
>>> If both are computing the halting function, which is a mathematical function which ALWAYS maps a given input to the same output, then this PROVES that one is wrong. Specifically, H(P,P) is provably *incorrect*, and it is the result of H1(P,P) that does exactly that.
>>>
>>> The only way for both to be "provably correct" is if at least one of them is computing something else besides the halting function.
>> It is a verified fact that they both provable compute the halting
>> function of their own input correctly. Anyone knowing the x86 language
>> can verify this fact.
>
> If they compute different outputs for the same input then BY DEFINITION they are not computing the same function.
>

On 5/5/2022 12:28 PM, Dennis Bush wrote:
> On Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote:
>> On 5/5/2022 7:27 AM, Malcolm McLean wrote:
>>> On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote:
>>>> On 5/4/22 11:54 PM, olcott wrote:
>>>>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
>>>>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
>>>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
>>>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies
>>>>>>>>>>>>>>>>>>>>> infinitely nested
>>>>>>>>>>>>>>>>>>>>> simulation to H.
>>>>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up
>>>>>>>>>>>>>>>>>>>> about the halting
>>>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
>>>>>>>>>>>>>>>>>>>> computation P(P) it is
>>>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
>>>>>>>>>>>>>>>>>>>> H(P,P) == false
>>>>>>>>>>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it
>>>>>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>>>>>> decider because deciders only compute the mapping from
>>>>>>>>>>>>>>>>>>> inputs to final
>>>>>>>>>>>>>>>>>>> states.
>>>>>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states
>>>>>>>>>>>>>>>>>> /according to
>>>>>>>>>>>>>>>>>> some property of the inputs/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That par is exactly correct.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -- whether the input represents, for
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That part has been the key error of everyone in that they
>>>>>>>>>>>>>>>>> all believe
>>>>>>>>>>>>>>>>> that is can represent something other than what it actually
>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that
>>>>>>>>>>>>>>>> there is no
>>>>>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C
>>>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>>>> H. At least that is a clear admission that the halting of
>>>>>>>>>>>>>>>> function
>>>>>>>>>>>>>>>> calls like P(P) can not be decided because, apparently,
>>>>>>>>>>>>>>>> passing P and P
>>>>>>>>>>>>>>>> to H does not specify that computation, and you can't say
>>>>>>>>>>>>>>>> what two
>>>>>>>>>>>>>>>> arguments /would/ specify it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y)
>>>>>>>>>>>>>>>> == true if
>>>>>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would
>>>>>>>>>>>>>>>> be the
>>>>>>>>>>>>>>>> honest way to move things on. If you were clear about this,
>>>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
>>>>>>>>>>>>>>>> deciding.
>>>>>>>>>>>>>> So you won't admit that no algorithm can do what D is
>>>>>>>>>>>>>> specified to do?
>>>>>>>>>>>>>> You are just going to pretend that no one cares about actual
>>>>>>>>>>>>>> halting.
>>>>>>>>>>>>>> I hope you see that by ignoring this point you are confirming
>>>>>>>>>>>>>> that you
>>>>>>>>>>>>>> know D can't exist. If you thought such a D was possible,
>>>>>>>>>>>>>> you'd be
>>>>>>>>>>>>>> shouting that from the roof tops since it's what everyone else
>>>>>>>>>>>>>> says is
>>>>>>>>>>>>>> impossible.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I adapted my system so that I could empirically test this:
>>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the
>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>> that H was originally supposed to decide.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are you simply wired to ignore my words so that you can
>>>>>>>>>>>>> disagree with
>>>>>>>>>>>>> everything that I say?
>>>>>>>>>>>>>
>>>>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
>>>>>>>>>>>>
>>>>>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
>>>>>>>>>>>> decide all halting instances between them:
>>>>>>>>>>>>
>>>>>>>>>>>> bool H1(X, Y) { return true; }
>>>>>>>>>>>> bool H2(X, Y) { return false; }
>>>>>>>>>>>>
>>>>>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat,
>>>>>>>>>>>> H1_hat) or
>>>>>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call
>>>>>>>>>>>> H_hat.
>>>>>>>>>>>
>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>
>>>>>>>>>> If that is so then H and H1 don't perform the same mapping. This
>>>>>>>>>> means that one (or both) do not compute the halting function.
>>>>>>>>>>
>>>>>>>>>> So which one doesn't compute the halting function?
>>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>>>>>> Both take the machine code of P as input parameters and are provably
>>>>>>>>> correct simulations of this same input yet one correctly determines
>>>>>>>>> that
>>>>>>>>> its input halts and the other correctly determines that its input does
>>>>>>>>> not halt.
>>>>>>>>
>>>>>>>> Which means at least one is not computing the halting function. So
>>>>>>>> which one is it?
>>>>>>>>
>>>>>>> The above paragraph means that it makes no mistakes in computing the
>>>>>>> halting function. This is a verifiable fact, not any mere opinion. The
>>>>>>> reason that I did the HP in C/x86 was so that every detail can be shown
>>>>>>> thus gaps in reasoning revealed.
>>>>>>
>>>>>> Any decider that maps the halting function performs the *same* mapping
>>>>>> of inputs to outputs.
>>>>>
>>>>> That is now proven to be factually incorrect.
>>>>>
>>>>> If the above paragraph is proven to be a fact then this proves that both
>>>>> H and H1 compute the halting function correctly. The above paragraph can
>>>>> be proven to be a fact.
>>>> Yes, IF you can prove that cats are dogs, you can prove that H is
>>>> correctly computing the Halting Function.
>>>>
>>>> Since you can't, you can't.
>>>>
>>>> In fact, you have just proven that you don't know what you are talking
>>>> about, since you just asserted a LIE.
>>>>
>>>> Two machines claiming to compute the same function must generate the
>>>> same answer from the same input or one of them is incorrect.
>>>>
>>>> BASIC FACT.
>>>>
>>> In parapsychology, there's something called "the experimenter effect". The same
>>> experiment will show a parapsychological effect or not, depending on who is
>>> performing the experiment. This has been described as parapsychology's one finding.
>>> If true in an interesting way, it also strikes at the heart of the scientific method.
>>>
>>> But intuitively, it's not implausible that an experiment would "work" for an experimenter
>>> with gypsy blood, for example. You can't simply reject the experimenter effect on the
>>> basis that, if it means more than that certain experimenters are more gullible than
>>> others, it leaves the rest of science in tatters.
>>>
>>> PO says that a machine has one behaviour when run, and another behaviour when
>>> "correctly simulated". That claim, if true, similarly leaves the whole of computer science
>>> in tatters. Which means that it's his responsibility to provide a much better explanation
>>> of what he means than he has done currently.
>>>
>>> But he's been clear about this. He's asserting what anyone who knows just a tiny amount
>>> about computers must consdier to be nonsense. At first glance. But the idea that
>>> i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
>>> difference is that more details were forthcoming.
>> Anyone knowing the x86 language can verify that H(P,P) and H1(P,P)
>> compute the mapping from their input parameters to their own final state
>> correctly. Arguing with verified facts is a fools folly.
>
> So in other words, a decider is always correct about what it's own input does.
>

On 5/5/2022 1:03 PM, Dennis Bush wrote:
> On Thursday, May 5, 2022 at 2:01:28 PM UTC-4, olcott wrote:
>> On 5/5/2022 6:57 AM, Dennis Bush wrote:
>>> On Thursday, May 5, 2022 at 7:50:02 AM UTC-4, richar...@gmail.com wrote:
>>>> On 5/4/22 11:42 PM, olcott wrote:
>>>>> On 5/4/2022 10:38 PM, André G. Isaak wrote:
>>>>>> On 2022-05-04 21:35, olcott wrote:
>>>>>>> On 5/4/2022 10:17 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-04 21:09, olcott wrote:
>>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>>>>>
>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>
>>>>>>>>>> If that is so then H and H1 don't perform the same mapping. This
>>>>>>>>>> means that one (or both) do not compute the halting function.
>>>>>>>>>>
>>>>>>>>>> So which one doesn't compute the halting function?
>>>>>>>>
>>>>>>>> You didn't actually answer this question.
>>>>>>>>
>>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>>>>>> Both take the machine code of P as input parameters and are
>>>>>>>>> provably correct simulations of this same input yet one correctly
>>>>>>>>> determines that its input halts and the other correctly determines
>>>>>>>>> that its input does not halt.
>>>>>>>>
>>>>>>>> Please define your use of the term "correct simulation".
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Good question.
>>>>>>> The behavior of the simulated input exactly matches the correct
>>>>>>> execution trace of the behavior in a real hardware machine.
>>>>>>
>>>>>> So if P(P), when executed directly, halts, how can a 'correct
>>>>>> simulation' possibly not halt?
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> As soon as you very carefully study every single detail of the above
>>>>> paragraph you will realize that it proves that I am correct as soon as
>>>>> the paragraph itself is proved to be factually correct.
>>>>>
>>>> No, it proves that you don't know what you are saying. The only machine
>>>> to use to "Correctly simulate the input (P,P) is P(P), sp that is what
>>>> must define the correct answer.
>>>>
>>>> If it looks at H, then by your definition ALL simulating decider are
>>>> "correct", as it is there simulation, no matter how awful, that defines
>>>> the answer.
>>>
>>> To PO: the above is exactly where the conclusion that Ha3(N,5) == false is coming from.
>> Ha3() is merely a decider that was intentionally designed to get the
>> wrong answer thus no evidence what-so-ever that a decider that gets the
>> right answer does not exist.
>
> Then you should have no problem specifying *exactly* how Ha3 gets the wrong answer in a generalized way that also describes how H(P,P) gets the right answer.

You know how it gets the wrong answer, you designed it that way.
TM's that are intentionally defined to get the wrong answer are off
topic please STFU about them.

--
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 Thursday, May 5, 2022 at 2:45:46 PM UTC-4, olcott wrote:
> On 5/5/2022 1:03 PM, Dennis Bush wrote:
> > On Thursday, May 5, 2022 at 2:01:28 PM UTC-4, olcott wrote:
> >> On 5/5/2022 6:57 AM, Dennis Bush wrote:
> >>> On Thursday, May 5, 2022 at 7:50:02 AM UTC-4, richar...@gmail.com wrote:
> >>>> On 5/4/22 11:42 PM, olcott wrote:
> >>>>> On 5/4/2022 10:38 PM, André G. Isaak wrote:
> >>>>>> On 2022-05-04 21:35, olcott wrote:
> >>>>>>> On 5/4/2022 10:17 PM, André G. Isaak wrote:
> >>>>>>>> On 2022-05-04 21:09, olcott wrote:
> >>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
> >>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
> >>>>>>>>
> >>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>>>
> >>>>>>>>>> If that is so then H and H1 don't perform the same mapping. This
> >>>>>>>>>> means that one (or both) do not compute the halting function.
> >>>>>>>>>>
> >>>>>>>>>> So which one doesn't compute the halting function?
> >>>>>>>>
> >>>>>>>> You didn't actually answer this question.
> >>>>>>>>
> >>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> >>>>>>>>> Both take the machine code of P as input parameters and are
> >>>>>>>>> provably correct simulations of this same input yet one correctly
> >>>>>>>>> determines that its input halts and the other correctly determines
> >>>>>>>>> that its input does not halt.
> >>>>>>>>
> >>>>>>>> Please define your use of the term "correct simulation".
> >>>>>>>>
> >>>>>>>> André
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> Good question.
> >>>>>>> The behavior of the simulated input exactly matches the correct
> >>>>>>> execution trace of the behavior in a real hardware machine.
> >>>>>>
> >>>>>> So if P(P), when executed directly, halts, how can a 'correct
> >>>>>> simulation' possibly not halt?
> >>>>>>
> >>>>>> André
> >>>>>>
> >>>>>
> >>>>> As soon as you very carefully study every single detail of the above
> >>>>> paragraph you will realize that it proves that I am correct as soon as
> >>>>> the paragraph itself is proved to be factually correct.
> >>>>>
> >>>> No, it proves that you don't know what you are saying. The only machine
> >>>> to use to "Correctly simulate the input (P,P) is P(P), sp that is what
> >>>> must define the correct answer.
> >>>>
> >>>> If it looks at H, then by your definition ALL simulating decider are
> >>>> "correct", as it is there simulation, no matter how awful, that defines
> >>>> the answer.
> >>>
> >>> To PO: the above is exactly where the conclusion that Ha3(N,5) == false is coming from.
> >> Ha3() is merely a decider that was intentionally designed to get the
> >> wrong answer thus no evidence what-so-ever that a decider that gets the
> >> right answer does not exist.
> >
> > Then you should have no problem specifying *exactly* how Ha3 gets the wrong answer in a generalized way that also describes how H(P,P) gets the right answer.
> You know how it gets the wrong answer, you designed it that way.
> TM's that are intentionally defined to get the wrong answer are off
> topic please STFU about them.

Ha3 was designed to follow the correctness criteria that you gave.

So why does Ha3(N,5) not perform a correct simulation but H(P,P) does?

On Thursday, May 5, 2022 at 2:39:16 PM UTC-4, olcott wrote:
> On 5/5/2022 12:28 PM, Dennis Bush wrote:
> > On Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote:
> >> On 5/5/2022 7:27 AM, Malcolm McLean wrote:
> >>> On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote:
> >>>> On 5/4/22 11:54 PM, olcott wrote:
> >>>>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
> >>>>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
> >>>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
> >>>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
> >>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
> >>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
> >>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
> >>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
> >>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
> >>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
> >>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
> >>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies
> >>>>>>>>>>>>>>>>>>>>> infinitely nested
> >>>>>>>>>>>>>>>>>>>>> simulation to H.
> >>>>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up
> >>>>>>>>>>>>>>>>>>>> about the halting
> >>>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
> >>>>>>>>>>>>>>>>>>>> computation P(P) it is
> >>>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
> >>>>>>>>>>>>>>>>>>>> H(P,P) == false
> >>>>>>>>>>>>>>>>>>>> and that P(P) halts.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it
> >>>>>>>>>>>>>>>>>>> is not a
> >>>>>>>>>>>>>>>>>>> decider because deciders only compute the mapping from
> >>>>>>>>>>>>>>>>>>> inputs to final
> >>>>>>>>>>>>>>>>>>> states.
> >>>>>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states
> >>>>>>>>>>>>>>>>>> /according to
> >>>>>>>>>>>>>>>>>> some property of the inputs/
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> That par is exactly correct.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -- whether the input represents, for
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> That part has been the key error of everyone in that they
> >>>>>>>>>>>>>>>>> all believe
> >>>>>>>>>>>>>>>>> that is can represent something other than what it actually
> >>>>>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that
> >>>>>>>>>>>>>>>> there is no
> >>>>>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C
> >>>>>>>>>>>>>>>> halt decider
> >>>>>>>>>>>>>>>> H. At least that is a clear admission that the halting of
> >>>>>>>>>>>>>>>> function
> >>>>>>>>>>>>>>>> calls like P(P) can not be decided because, apparently,
> >>>>>>>>>>>>>>>> passing P and P
> >>>>>>>>>>>>>>>> to H does not specify that computation, and you can't say
> >>>>>>>>>>>>>>>> what two
> >>>>>>>>>>>>>>>> arguments /would/ specify it.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y)
> >>>>>>>>>>>>>>>> == true if
> >>>>>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would
> >>>>>>>>>>>>>>>> be the
> >>>>>>>>>>>>>>>> honest way to move things on. If you were clear about this,
> >>>>>>>>>>>>>>>> maybe
> >>>>>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
> >>>>>>>>>>>>>>>> deciding.
> >>>>>>>>>>>>>> So you won't admit that no algorithm can do what D is
> >>>>>>>>>>>>>> specified to do?
> >>>>>>>>>>>>>> You are just going to pretend that no one cares about actual
> >>>>>>>>>>>>>> halting.
> >>>>>>>>>>>>>> I hope you see that by ignoring this point you are confirming
> >>>>>>>>>>>>>> that you
> >>>>>>>>>>>>>> know D can't exist. If you thought such a D was possible,
> >>>>>>>>>>>>>> you'd be
> >>>>>>>>>>>>>> shouting that from the roof tops since it's what everyone else
> >>>>>>>>>>>>>> says is
> >>>>>>>>>>>>>> impossible.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I adapted my system so that I could empirically test this:
> >>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the
> >>>>>>>>>>>>>> thing
> >>>>>>>>>>>>>> that H was originally supposed to decide.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Are you simply wired to ignore my words so that you can
> >>>>>>>>>>>>> disagree with
> >>>>>>>>>>>>> everything that I say?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
> >>>>>>>>>>>>
> >>>>>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
> >>>>>>>>>>>> decide all halting instances between them:
> >>>>>>>>>>>>
> >>>>>>>>>>>> bool H1(X, Y) { return true; }
> >>>>>>>>>>>> bool H2(X, Y) { return false; }
> >>>>>>>>>>>>
> >>>>>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat,
> >>>>>>>>>>>> H1_hat) or
> >>>>>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call
> >>>>>>>>>>>> H_hat.
> >>>>>>>>>>>
> >>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>>>
> >>>>>>>>>> If that is so then H and H1 don't perform the same mapping. This
> >>>>>>>>>> means that one (or both) do not compute the halting function.
> >>>>>>>>>>
> >>>>>>>>>> So which one doesn't compute the halting function?
> >>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> >>>>>>>>> Both take the machine code of P as input parameters and are provably
> >>>>>>>>> correct simulations of this same input yet one correctly determines
> >>>>>>>>> that
> >>>>>>>>> its input halts and the other correctly determines that its input does
> >>>>>>>>> not halt.
> >>>>>>>>
> >>>>>>>> Which means at least one is not computing the halting function. So
> >>>>>>>> which one is it?
> >>>>>>>>
> >>>>>>> The above paragraph means that it makes no mistakes in computing the
> >>>>>>> halting function. This is a verifiable fact, not any mere opinion. The
> >>>>>>> reason that I did the HP in C/x86 was so that every detail can be shown
> >>>>>>> thus gaps in reasoning revealed.
> >>>>>>
> >>>>>> Any decider that maps the halting function performs the *same* mapping
> >>>>>> of inputs to outputs.
> >>>>>
> >>>>> That is now proven to be factually incorrect.
> >>>>>
> >>>>> If the above paragraph is proven to be a fact then this proves that both
> >>>>> H and H1 compute the halting function correctly. The above paragraph can
> >>>>> be proven to be a fact.
> >>>> Yes, IF you can prove that cats are dogs, you can prove that H is
> >>>> correctly computing the Halting Function.
> >>>>
> >>>> Since you can't, you can't.
> >>>>
> >>>> In fact, you have just proven that you don't know what you are talking
> >>>> about, since you just asserted a LIE.
> >>>>
> >>>> Two machines claiming to compute the same function must generate the
> >>>> same answer from the same input or one of them is incorrect.
> >>>>
> >>>> BASIC FACT.
> >>>>
> >>> In parapsychology, there's something called "the experimenter effect". The same
> >>> experiment will show a parapsychological effect or not, depending on who is
> >>> performing the experiment. This has been described as parapsychology's one finding.
> >>> If true in an interesting way, it also strikes at the heart of the scientific method.
> >>>
> >>> But intuitively, it's not implausible that an experiment would "work" for an experimenter
> >>> with gypsy blood, for example. You can't simply reject the experimenter effect on the
> >>> basis that, if it means more than that certain experimenters are more gullible than
> >>> others, it leaves the rest of science in tatters.
> >>>
> >>> PO says that a machine has one behaviour when run, and another behaviour when
> >>> "correctly simulated". That claim, if true, similarly leaves the whole of computer science
> >>> in tatters. Which means that it's his responsibility to provide a much better explanation
> >>> of what he means than he has done currently.
> >>>
> >>> But he's been clear about this. He's asserting what anyone who knows just a tiny amount
> >>> about computers must consdier to be nonsense. At first glance. But the idea that
> >>> i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
> >>> difference is that more details were forthcoming.
> >> Anyone knowing the x86 language can verify that H(P,P) and H1(P,P)
> >> compute the mapping from their input parameters to their own final state
> >> correctly. Arguing with verified facts is a fools folly.
> >
> > So in other words, a decider is always correct about what it's own input does.
> >
> Yes this is an easily verified fact on the basis of the execution trace
> derived from the correct simulation of its input parameters.
> > If you believe that to be true, then you also believe that anyone knowing the x86 language can verify that Ha3(N,5) correctly computes the mapping from its input to a non-halting state.
> >
> H2(Ha3,N,5) would get the correct halt status for Ha3.
>
> From what I recall Ha3(N,5) is merely a computation that was defined to
> make sure it gets the wrong answer. If you disagree then remind me again
> what it means.

olcott <polcott2@gmail.com> writes:

> On 5/5/2022 4:19 AM, Mikko wrote:

>> There is no category error in the theorem. An infinitely recursive
>> computation is still in the category of computations.
>
> Not according to Linz. Linz says that all computations must halt.

That's a gem! I'm keeping that one!

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)