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.
The correct simulation of the input to H(P,P) specifies non-halting
behavior.

Clueless wonders that don't know the first thing about the x86 language
assume that this simulation is incorrect even though is is nearly
trivial to determine that the simulation is correct as a verified fact.

That they contradict verified facts entirely one the basis that they are
incompetent to verify that it is a fact is the worst hubris.

> example, an even number, a prime number or a halting computation.
>
> According to you there is no "input" (in reality a pair of pointers)
> that represents the halting computation P(P). Why should anyone care
> about this H if it does not decide what we want -- the halting of the
> function call represented by the two arguments to H? Whatever H is
> actually deciding is not interesting.

(a) H does correctly decide its input
(b) H is only required to decide its input.
(c) Therefore H(P,P) is entirely correct on the "impossible" input.

> Also, I wonder why you wasted so much time justifying the fact that
> H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not
> even supposed to be deciding the halting P(P). Well, we know, of
> course. You realised you were in a hole so you started to dig sideways.
> You used to know that H(X,Y) had to decide the halting of X(Y). You're
> now pretending it never did!
>

>> That you expect a halt decider to compute the mapping from non-inputs
>> is a little nuts when you know that deciders can't possibly do this.
>
> Don't be silly. They decide properties of inputs -- parity, halting and
> so on. You'd know this if you'd done even the warm-up exercises I set.

The problem here is that you expect that the property of an input not be
the actual property of the actual input but the property of a non-input.

The halting property of the input to H(P,P) is the actual behavior of
the correct simulation of this input and thus not at all what you simply
imagine this property should be.

> How are they coming along? It looks like you have found an excuse to
> bail out again:
>

It is coming along great and it is wonderful fun.
I think that it is a great idea to move in this direction.
I may eventually convert C copy of the TM into a RASP machine.
I probably won't begin to do that until after we finish our exercises.

>> It turns out that I can create a whole TM interpreter from scratch
>> quicker than I can learn the extraneous complexity of the TM
>> Interpreter http://www.lns.mit.edu/~dsw/turing/turing.html
>
> I doubt it. But I suppose you think that's a reasonable excuse. Of
> course, some of us remember you saying writing such a thing would take
> about a week three years ago. I remember wondering how such a simple
> program could take you a week to write.

As soon as I complete the detailed design I should have an accurate
estimate of the total time. It currently looks like < 4 hours. I have
spent 15 minutes on the detailed design and it looks like it will take
45 more minutes.

One thing that is great is that I have fully recovered from what could
have been a life threatening infection. I was in the hospital getting IV
antibiotics for nearly two days. Chemotherapy patients have a few days
after chemotherapy where their immune system is very close to zero.

>
> Of course you don't need an interpreter to write E or specify P, but you
> must find some excuse for bailing out.
>

It is much better (and more fun) if I make this totally concrete.
One can not effectively debug code by desk checking.

--
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/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 whether it is that your H is deciding.
>

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

Both deciders correctly report on the actual behavior of their actual
input. This can be verified by carefully studying their execution trace.

>>> example, an even number, a prime number or a halting computation.
>>> According to you there is no "input" (in reality a pair of pointers)
>>> that represents the halting computation P(P). Why should anyone care
>>> about this H if it does not decide what we want -- the halting of the
>>> function call represented by the two arguments to H? Whatever H is
>>> actually deciding is not interesting.
>>
>> (a) H does correctly decide its input
>
> But no one cares about that as it's not what we want a decider for.
>
>> (b) H is only required to decide its input.
>
> And it seems that you agree that no D such that D(X,Y) == true if and
> only if X(Y) halts and false otherwise is possible. That's the D that
> the world cares about.
>
>> (c) Therefore H(P,P) is entirely correct on the "impossible" input.
>
> It decides some property of the pair of pointers P and P, but not the
> one people care about: the halting or otherwise of the function call
> P(P).
>
>>> Also, I wonder why you wasted so much time justifying the fact that
>>> H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not
>>> even supposed to be deciding the halting P(P). Well, we know, of
>>> course. You realised you were in a hole so you started to dig sideways.
>>> You used to know that H(X,Y) had to decide the halting of X(Y). You're
>>> now pretending it never did!
>
> Why /did/ you waste so much time trying to convince us that H(P,P) ==
> false was correct even though P(P) halted if you never intended H(P,P)
> to report on the halting of P(P)?
>
>>> You'd know this if you'd done even the warm-up exercises I set.
>
> <snip the usual waffle>
>
>>> How are they coming along? It looks like you have found an excuse to
>>> bail out again:
>>
>> It is coming along great and it is wonderful fun.
>
> It's good that it's fun, but it seems to be taking a long time. I'd
> expect students to be able to write E and specify P "live" in a tutorial
> -- i.e. it would take a couple of minutes and we could the discuss more
> interesting examples.

I have had some serious health issues that could have killed me last week.

>
> The specification of TM's is your stumbling block, so you could be doing
> that in parallel.

I like to go through all of the best steps in order. Having a machine to
execute TM's is the first step.

(a) Deciding to get around to start this project took weeks when dealing
with my other issues.

(b) No setting up the tedious syntax of reading a file of text lines
took much longer than usual, I usually cut-and-paste.

(c) I studied enough of the
http://www.lns.mit.edu/~dsw/turing/turing.html
To realize it was a superb architecture yet an overly complex
implementation.

Other people can read much faster than me, yet they lose a lot of
meaning when they read this fast. I usually read something over and over
until I have 100% complete understanding.

When I was reading the specs for how VISA changed their system so that I
could adapt the bank's system to meet these changed specs I had to read
the VISA material 17 times. I only had to read the Discover card changes
three times.

>
>> I think that it is a great idea to move in this direction.
>> I may eventually convert C copy of the TM into a RASP machine.
>
> Do ever read what you write? What is a "C copy of the TM"? I think you
> mean the TM interpreter that you've decided to write so as to delay
> actually writing even a trivial TM.
>

I am going to write a TM interpreter in C++. Sometime after I get done
with this I may adapt it to becoming an RASP machine. I will keep the
original TM interpreter and not simply overwrite it with the RASP
machine. This requires that the changes must be to a copy of the TM
interpreter.

--
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/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 !

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/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.

>> 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

--
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/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.

--
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/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.

--
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/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.

> Since H and H1 perform different mappings they can't possibly both map the halting function.
>
> So which one doesn't?

--
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/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.

*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.

--
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/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.

> 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.
>

--
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: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.