On 5/4/22 12:24 PM, olcott wrote:
> On 5/4/2022 6:15 AM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> Even infinitely recursive math expressions are semantically incorrect
>>> in that they can never be evaluated.
>>
>> Someone with no education in mathematics makes a bold claim about
>> mathematical concepts without defining any of then, and for some reason
>> a discussion ensues on Usenet.  Let me get snacks...
>>
>
> I have spent thousands of hours on this point.
> When the evaluation directed graph of an expression has an infinite
> cycle. See page 4.
>
> https://www.researchgate.net/publication/350789898_Prolog_detects_and_rejects_pathological_self_reference_in_the_Godel_sentence
>
>

Which shows that Prolog's limited logic capability can't handle (with
that method) this form of logic.

I don't think Prolog can handle the properties of mathematics, so I
suspect that you are just showing that you logic syste is to primative
to handle the complexity needed to handle the incompleteness proof
(which states the minimum capability of the logic system to apply) or
Computation theory.

So, baseing your rejection on the limitations of Prolog just show your
lack of understand of what you are claiming.

On 5/4/22 1:57 PM, olcott wrote:
> 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.
>
>

And Prolog implements a logic system simpler than needed to handle the
proof you are talking about.

Prolog can't handle the needed logic to express the needed properties of
mathematics, so you "proof" just fails.

>>> It is generally the case that every expression of any natural of
>>> formal language that cannot be derived by applying truth preserving
>>> operations (such as Prolog rules) to expressions known to be true
>>> (such as Prolog facts) cannot possibly be correctly construed as true.
>>>
>>> Dogs are animals (purely analytic)
>>> There is a small dog in my living room right now (Empirical).
>>>
>>> This is true for the entire body of analytic knowledge which only
>>> excludes expressions of language that rely on sense data from the
>>> sense organs to verify truth.
>>>
>>> The proof that this is correct is that no counter-examples exist.
>>> When G is considered true and unprovable there is some way the "true"
>>> is derived, it is not merely a wild guess.
>>>
>>> Just like Prolog databases True is limited to a specific formal
>>> system, one formal system is the entire body of analytic knowledge:
>>> EBAK. This is an entirely different formal system than PA.
>>>
>>> unprovable in PA and true in EBAC is not the same thing as true and
>>> unprovable. unprovable in PA means not true in PA, and true in EBAC
>>> means provable in EBAC.
>>
>> Nothing in this response is relevant to the responded message.
>> In particular, none of the simple questions were answered.
>>
>> Mikko
>>
>
>

On 5/4/22 12:40 PM, Mr Flibble wrote:
> On Tue, 3 May 2022 21:54:42 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 5/3/22 3:06 PM, Mr Flibble wrote:
>>> On Mon, 2 May 2022 20:40:13 -0400
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 5/2/22 7:30 PM, Mr Flibble wrote:
>>>>> On Mon, 2 May 2022 19:16:03 -0400
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 5/2/22 6:47 PM, Mr Flibble wrote:
>>>>>>> On Mon, 2 May 2022 18:46:00 -0400
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 5/2/22 6:38 PM, Mr Flibble wrote:
>>>>>>>>> On Mon, 2 May 2022 18:32:16 -0400
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 5/2/22 11:47 AM, Mr Flibble wrote:
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Except that the "impossible program" isn't part of the
>>>>>>>>>> definition of the Halting Problem.
>>>>>>>>>
>>>>>>>>> It is according to [Wikipedia, 2022].
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope, you comprehend worse that PO.
>>>>>>>>
>>>>>>>> Note, and Encyclopedic entery, like Wikipedia, is NOT just a
>>>>>>>> definition but a full article explaining the subject.
>>>>>>>>
>>>>>>>> Maybe if you look for a FORMAL source, that states what is the
>>>>>>>> ACTUAL definition, you would learn something.
>>>>>>>
>>>>>>> If Wikipedia is wrong then correct it and have your corrections
>>>>>>> reviewed; until then please shut the fuck up.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> It isn't that the article is "Wrong", it is a fairly good
>>>>>> Encyclpedic article. It just is that the first two paragraphs
>>>>>> aren't all a definition, and it doesn't say they are.
>>>>>
>>>>> The first two paragraphs define the halting problem as that is
>>>>> what the currently extant halting problem "proofs" are predicated
>>>>> on (and why they are invalid).
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> No, lets actually look at what is says, and parse it:
>>>>
>>>> In computability theory, the halting problem is the problem of
>>>> determining, from a description of an arbitrary computer program
>>>> and an input, whether the program will finish running, or continue
>>>> to run forever. Alan Turing proved in 1936 that a general
>>>> algorithm to solve the halting problem for all possible
>>>> program-input pairs cannot exist.
>>>>
>>>> For any program f that might determine if programs halt, a
>>>> "pathological" program g, called with some input, can pass its own
>>>> source and its input to f and then specifically do the opposite of
>>>> what f predicts g will do. No f can exist that handles this case. A
>>>> key part of the proof is a mathematical definition of a computer
>>>> and program, which is known as a Turing machine; the halting
>>>> problem is undecidable over Turing machines. It is one of the
>>>> first cases of decision problems proven to be unsolvable. This
>>>> proof is significant to practical computing efforts, defining a
>>>> class of applications which no programming invention can possibly
>>>> perform perfectly.
>>>>
>>>> Jack Copeland attributes the introduction of the term halting
>>>> problem to the work of Martin Davis in the 1950s.[1]
>>>>
>>>>
>>>>
>>>> The FIRST SENTENCE is the definition of the Problem.
>>>>
>>>> The Second Sentence is the Theorem about it that says that no
>>>> solution exists.
>>>>
>>>> That ends the first paragraph.
>>>>
>>>> The Second Paragraph, is a continuation of the idea of the Second
>>>> Sentence, giving a summary of the proof that no solution exist.
>>>>
>>>> It is a category error to confuse the Statement of the Problem with
>>>> the Proof of the Theorem that not answer to the Problem exists.
>>>>
>>>> A Proof is NOT a Problem.
>>>
>>> Wrong; the wording in the third paragraph suggests the prior
>>> paragraphs refer to the halting problem itself, i.e. its definition.
>>>
>>> Stop playing word games. The halting problem as defined in
>>> [Wikipedia, 2022] is erroneous as it contains a category error in
>>> the form of an erroneous infinite recursion. The fact that
>>> currently extant halting problem proofs are predicated on this
>>> erroneous infinite recursion tells us that the second paragraph
>>> *is* part of the halting problem definition and thus are invalid.
>>>
>>> /Flibble
>>>
>>
>> So the second sentence of the first paragraph is part of the
>> definition, so BY DEFINITON, no answer exists to the Halting Problem?
>>
>> You can't say that paragraph 2 is part of the definiton and exclude
>> the end of paragraph 1.
>>
>> The only reasonable parsing is:
>>
>> Sentence 1: the Defintion of the Problem
>> Sentence 2: The Theorem about the Problem
>> Paragraph 2: A sketch of the proof of the Theorem
>> Paragraph 3: History of how it got its common name.
>>
>> You confuse the "Halting Problem" with the Theorem about the Halting
>> Problem that states that no machine can exist to compute the answer
>> to the problem (and its proof).
>
> Sentence 2 merely states that Turing provided a proof: a proof is not a
> theory, a proof proves a theory.
>
> I see you wish to continue to play word games; I can play word games
> too, and win.
>
> If I accept your assertion as true (which is reasonable) then the facts
> on the ground haven't actually changed: I merely have to make minor
> modifications to my original assertion. See my "reprise #2" post which I
> will post shortly.
>
> /Flibble
>

It seems that you are making the eror of confusing the Halting Problem,
with the Halting Problem Theorem, with the proof of the Theorem.

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.

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

But neither can tell us what we want. Your H does not meet D's
specification, but you are not brave enough to admit that you now know
that D can't exist because denying that is what got you started down
this rabbit hole 18 years ago.

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

You have been able to write dozens of posts, so why not the few words
needed to specify P, or the few states needed for E? And even now
you've taken on a task that seems too much for you rather than get down
to writing and specifying a TM. It looks like avoidance.

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

The firsts step is to be able to specify a TM. You can't have anything
to execute of you can't specify it. It's just avoidance.

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

You decided to start weeks ago. Then you gave up.

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

What? I thought you knew C++ and could write code.

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

I hate it, but you chose it /five years ago/. Five years ago I
suggested a simple exercise and you bailed them. I'd forgotten that. I
should learn, shouldn't I?

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

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

>> Both deciders correctly report on the actual behavior of their actual
>> input. This can be verified by carefully studying their execution
>> trace.
>
> But neither can tell us what we want.

H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).

> Your H does not meet D's
> specification, but you are not brave enough to admit that you now know
> that D can't exist because denying that is what got you started down
> this rabbit hole 18 years ago.
>
>
>>
>>>>> 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.
>
> You have been able to write dozens of posts, so why not the few words
> needed to specify P, or the few states needed for E? And even now
> you've taken on a task that seems too much for you rather than get down
> to writing and specifying a TM. It looks like avoidance.
>
>>> 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.
>
> The firsts step is to be able to specify a TM. You can't have anything
> to execute of you can't specify it. It's just avoidance.
>

I am a concrete thinker, abstractions are always far too vague.

>> (a) Deciding to get around to start this project took weeks when
>> dealing with my other issues.
>
> You decided to start weeks ago. Then you gave up.
I am dead set on finishing it now.

>
>> (b) No setting up the tedious syntax of reading a file of text lines
>> took much longer than usual, I usually cut-and-paste.
>
> What? I thought you knew C++ and could write code.
>

On this tedious syntax details I always cut-and-paste from working code.
I hate tedious syntax details. Engineering algorithms is what I enjoy.

>> (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.
>
> I hate it, but you chose it /five years ago/. Five years ago I
> suggested a simple exercise and you bailed them. I'd forgotten that. I
> should learn, shouldn't I?
>

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.

>>> Both deciders correctly report on the actual behavior of their actual
>>> input. This can be verified by carefully studying their execution
>>> trace.
>> But neither can tell us what we want.
>
> H1(P,P)==true reports on the behavior of P(P).

So what? That some functions gets the right answer for P is irrelevant.
H1 is just as wrong about it's "P" as H is. You know all this. We went
through it years ago.

Your H does not tell us about H_hat(H_hat), and your new mantra about
what it does tell us about is just an admission that fails to do what
the world correctly claims is impossible.

>> Your H does not meet D's
>> specification, but you are not brave enough to admit that you now know
>> that D can't exist because denying that is what got you started down
>> this rabbit hole 18 years ago.

Still nothing about this. You need to come clean and admit that your
mantra has nothing to do with what other people care about: a D such
that D(X,Y) == true if and only if X(Y) halts and false otherwise.

This is why you are wrong. You have nothing to say anymore about the
function the rest of the world is talking about.

>>> (a) Deciding to get around to start this project took weeks when
>>> dealing with my other issues.
>>
>> You decided to start weeks ago. Then you gave up.
>
> I am dead set on finishing it now.

But not yet. First, pointlessly re-implement an TM interpreter by
cutting and pasting code:

>>> (b) No setting up the tedious syntax of reading a file of text lines
>>> took much longer than usual, I usually cut-and-paste.
>>
>> What? I thought you knew C++ and could write code.
>
> On this tedious syntax details I always cut-and-paste from working
> code. I hate tedious syntax details. Engineering algorithms is what I
> enjoy.

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

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

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

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

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?

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

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

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

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 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. Since H and H1 perform different mappings they can't possibly both map the halting function.

So which one doesn't?

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.

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

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

Mikko

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