On 5/25/2022 7:19 PM, Richard Damon wrote:
> On 5/25/22 10:13 AM, olcott wrote:
>> On 5/25/2022 6:01 AM, Richard Damon wrote:
>>> On 5/24/22 11:00 PM, olcott wrote:
>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software
>>>>>>>>>>>>>>>>>>>>>> engineer with a
>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates
>>>>>>>>>>>>>>>>>>>>>> its input pair of
>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function
>>>>>>>>>>>>>>>>>>>>>> P and criterion
>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would
>>>>>>>>>>>>>>>>>>>>>> never reach its "ret"
>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to
>>>>>>>>>>>>>>>>>>> be a decider or it
>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as
>>>>>>>>>>>>>>>>>>> you have introduced
>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret"
>>>>>>>>>>>>>>>>>> instruction of P in 0 to
>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this
>>>>>>>>>>>>>>>>> happening, you know this
>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator
>>>>>>>>>>>>>>>>> can.
>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of
>>>>>>>>>>>>>>>> P specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly
>>>>>>>>>>>>>>> what happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting
>>>>>>>>>>>>>>>> behavior as the
>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>> By this same despicable liar reasoning we can know that
>>>>>>>>>>>> Fluffy is not
>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>>
>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>> specifies to
>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>
>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>> You continue to be a liar.
>>>>>>>>>
>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>>> admit I'm right.
>>>>>>>>>
>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>> longer working on the halting problem?
>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>
>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>> disagreeing
>>>>>>>> with two verifiable facts higher caliber reviewers should
>>>>>>>> confirm that I
>>>>>>>> am correct.
>>>>>>>
>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>
>>>>>> Shows that they are not basing their decision on the execution
>>>>>> trace that is actually specified by the x86 source-code of P.
>>>>>>
>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
>>>>>> and H1(P,P). You can't even manage to tell the truth about the
>>>>>> names of functions.
>>>>>>
>>>>>
>>>>> The names really make that much difference?
>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
>>>> executed showing every detail of their correct simulation of their
>>>> inputs.
>>>>
>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be
>>>> pinned down to specifics. The only place that Dennis can hide his
>>>> deception is in deliberate vagnueness.
>>>>
>>>
>>> So, you don't understand what peeople are saying. For you it is just
>>> that you are right and others are wrong.
>>
>> Ha(Pa,Pa) is fully operational code named H(P,P)
>> Hb(Pa,Pa) is fully operational code named H1(P,P)
>>
>> I can prove that the actual behavior of the correct x86 emulation of
>> actual input to H(P,P) never reaches its "ret" instruction with a full
>> execution trace of P.
>>
>> I can prove that the actual behavior of the correct x86 emulation of
>> actual input to H1(P,P) reaches its "ret" instruction with a full
>> execution trace of P.
>
> And since the input is the SAME to both of these, the correct emulation
> of that input must be the same, at least if H is a computation.
So you disagree with the x86 langugae?

On 5/25/22 8:25 PM, olcott wrote:
> On 5/25/2022 7:19 PM, Richard Damon wrote:
>> On 5/25/22 10:13 AM, olcott wrote:
>>> On 5/25/2022 6:01 AM, Richard Damon wrote:
>>>> On 5/24/22 11:00 PM, olcott wrote:
>>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software
>>>>>>>>>>>>>>>>>>>>>>> engineer with a
>>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily
>>>>>>>>>>>>>>>>>>>>>>> confirm that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates
>>>>>>>>>>>>>>>>>>>>>>> its input pair of
>>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of
>>>>>>>>>>>>>>>>>>>>>>> function P and criterion
>>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would
>>>>>>>>>>>>>>>>>>>>>>> never reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that
>>>>>>>>>>>>>>>>>>>>>> does not exist in
>>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H
>>>>>>>>>>>>>>>>>>>>>> is erroneous.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the
>>>>>>>>>>>>>>>>>>>>> C function named H
>>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86
>>>>>>>>>>>>>>>>>>>>> emulation of the machine
>>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret"
>>>>>>>>>>>>>>>>>>>>> instruction of P in 0 to
>>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to
>>>>>>>>>>>>>>>>>>>> be a decider or it
>>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as
>>>>>>>>>>>>>>>>>>>> you have introduced
>>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret"
>>>>>>>>>>>>>>>>>>> instruction of P in 0 to
>>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this
>>>>>>>>>>>>>>>>>> happening, you know this
>>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT
>>>>>>>>>>>>>>>>>> simulator can.
>>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>>> instruction that H
>>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to
>>>>>>>>>>>>>>>> you, Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no
>>>>>>>>>>>>>>>> mistakes in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code
>>>>>>>>>>>>>>>>> of P specifies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly
>>>>>>>>>>>>>>>> what happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting
>>>>>>>>>>>>>>>>> behavior as the
>>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem,
>>>>>>>>>>>>>>>> does not perform a correct simulation of its input.
>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>>> By this same despicable liar reasoning we can know that
>>>>>>>>>>>>> Fluffy is not
>>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>>> specifies to
>>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>>> You continue to be a liar.
>>>>>>>>>>
>>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>>>> admit I'm right.
>>>>>>>>>>
>>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>>> longer working on the halting problem?
>>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>>
>>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>>> disagreeing
>>>>>>>>> with two verifiable facts higher caliber reviewers should
>>>>>>>>> confirm that I
>>>>>>>>> am correct.
>>>>>>>>
>>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>>
>>>>>>> Shows that they are not basing their decision on the execution
>>>>>>> trace that is actually specified by the x86 source-code of P.
>>>>>>>
>>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named
>>>>>>> H(P,P) and H1(P,P). You can't even manage to tell the truth about
>>>>>>> the names of functions.
>>>>>>>
>>>>>>
>>>>>> The names really make that much difference?
>>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
>>>>> executed showing every detail of their correct simulation of their
>>>>> inputs.
>>>>>
>>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be
>>>>> pinned down to specifics. The only place that Dennis can hide his
>>>>> deception is in deliberate vagnueness.
>>>>>
>>>>
>>>> So, you don't understand what peeople are saying. For you it is just
>>>> that you are right and others are wrong.
>>>
>>> Ha(Pa,Pa) is fully operational code named H(P,P)
>>> Hb(Pa,Pa) is fully operational code named H1(P,P)
>>>
>>> I can prove that the actual behavior of the correct x86 emulation of
>>> actual input to H(P,P) never reaches its "ret" instruction with a
>>> full execution trace of P.
>>>
>>> I can prove that the actual behavior of the correct x86 emulation of
>>> actual input to H1(P,P) reaches its "ret" instruction with a full
>>> execution trace of P.
>>
>> And since the input is the SAME to both of these, the correct
>> emulation of that input must be the same, at least if H is a computation.
> So you disagree with the x86 langugae?
>

On 5/25/2022 8:15 PM, Ben wrote:
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>
>> On 25/05/2022 19:42, Ben wrote:
>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>
>>>> It's true we don't know the details of how PO is doing this, but we
>>>> can see what's effectively going on, I'd say. It is /as though/ there
>>>> is one "master trace" of all the nested simulations maintained by the
>>>> x86utm somewhere in the address space of its virtual x86 processor.
>>> Hmm... If I had to guess I'd put some store in a few phrases he's
>>> uttered that maybe give away more than he intends. Something along the
>>> line of recursion having the same execution pattern as nested
>>> simulations (that's not verbatim -- I'm not reading so much anymore).
>>
>> Well, he certainly argued with me a couple of years back that it
>> didn't make any difference to his rule whether the trace was direct
>> call or emulation recursion. He declined to provide any proof for the
>> soundness of his rule in either scenario (of course), instead
>> suggesting it was my responsibility to provide counter-examples where
>> his rule failed! (If nobody could do that, it would mean his rule was
>> sound, so he believed...) Oh, and we know that pointing out his H as
>> an actual counterexample goes nowhere...
>>
>>> This adds wight to my idea that he has only the top level simulation and
>>> to "speed up the work" and "make the trace simpler" what's being traced
>>> by the top-level H is a different H(X, Y) that just calls X(Y). I
>>> imagine that he thought he could, in principle, eventually make both H's
>>> the same, and that just calling the computation rather than simulating
>>> was just a sort of optimisation.
>>
>> I can't say "definitely not" to that, but my thinking would be that it
>> illustrates PO not appreciating the qualitative difference between
>> recursion in call vs simulation environments, rather than PO not
>> actually using simulation. Maybe a prototype test used direct call
>> and that might have reinforced his confusions.
>
> I'm not saying there is none, just that it's not nested. I posit one
> simulation in some "top-level H" that steps through the execution of the
> specified function call (or otherwise observes it) and stops when the
> magic condition is seen. But rather than build P from this top-level H
> so he builds P from a simpler H(X, Y) that just calls X(Y).
>
> I admit it's all guesswork though. I seriously lost interest when all I
> thought it worth doing was pointing out that if H(X,Y) does not report
> on the "halting" of X(Y) then it's not doing what everyone else is
> talking about.
>

There are two key points:
(1) The the C function named H correctly determines that the correct
simulation of its x86 machine-code input would never reach its "ret"
instruction. This is a simple verified fact that lying cheating bastards
continue to deny.

That they continue to deny this is of no great concern because even
moderately competent software engineers can easily confirm that I am
correct.

(2) That H(P,P) must compute the mapping from a non-input clearly
violates the definition of a computable function that must
*given an input of the function ... return the corresponding output*
and the definition of a decider compute the mapping of its input to an
accept or reject state.

It is *not* that the computer science textbook authors disagree with
this. It is only that they simply assumed that P(P) cannot possibly
specify a different sequence of configurations than the correct
simulation of the input to H(P,P).

These two may only differ in the case of pathological self-reference
(Olcott 2004). Since no one was every able to execute an input with PSR
previously (they simply assumed it was impossibe) they never noticed
this divergence.

The actual correct x86 emulation of the input to H1(P,P) and H(P,P)
conclusive proves that P does have different halting behavior between
them. The alternative is that the x86 language itself is not telling the
truth about their behavior.

Actual computer scientists that know these things much deeper than mere
rote memorization will understand that I am correct. The alternative to
this is that computer scientists believe that textbook authors can
contradict the principles of computer science and not be wrong.

When H that simulates P calls H(P,P) this H creates a whole new process
context that simulates its input all the way through to P calling H(P,P)
again.

>> I think my description of how it /could/ be coded (using a global
>> trace area etc.) is within PO's coding ability given how long he had
>> to sort it out. Also PO has definitely talked about such a global
>> trace, I think in relation to whether this use of globals broke the
>> "pure function" requirement (as he understood it). So if I had to
>> place a bet, I'd go with it working /something/ like this, rather than
>> the blatant faking of traces otherwise required.
>
> I don't think they are faked, at least not totally faked.
>

It can be verified that they are correct thus the issue of whether they
are faked or not (they are not faked) is moot. It was very very
difficult to make H re-entrant.

It was much easier to make x86utm actually be able to execute H in
infinitely nested simulation than it was to verify that it was correct
without actual code. I had far too many false starts with imaginary
code. I had to make real code so if needed I could make adjustments to
my analysis.

>> BTW, have you noticed that PO's traces are out-of-step regarding the
>> ESP column? It's like he prints details for the "current instruction"
>> about to be executed, but the ESP column is the ESP /after/
>> instruction execution. Not how traces normally work... (that's just a
>> curiosity, but it makes me wonder about his recent "TM transition
>> function" not working posts...)
>
> No, I'd not noticed that. Curious.

Each instruction is simply shown after it has been executed thus not
out-of-sync at all.

>>>> So the purpose of all the complicated and semi-secret H code is
>>>> ultimately just to give PO some excuse to confuse himself!
>>> The original purpose was to backtrack on the claim, made I think in a
>>> manic delusion, that he had an "actual Turing machine pair", H, Ĥ, "fully
>>> encoded", "exactly and precisely as in Linz" that correctly decides the
>>> H(Ĥ, Ĥ) case.
>>> This claim was walked back step by step. It was "an algorithm", then "a
>>> pair of virtual machines" then "a few lines of C-like pseudo code"
>>> until, finally, the dump truck arrived with the "x86 language code" to
>>> make it too complicated to post. The original claim was then declared
>>> to be using "poetic licence".
>>
>> Right - that's all true! But still I imagine he actually /does/ have
>> some existing H code that he doesn't want to reveal. Right now, I
>> imagine PO's genuine reason for refusing to post H would be a
>> combination of
>>
>> 1) The H code is a total dog's dinner from a C programming
>> perspective, and he's ashamed of the quality of the code!
>>
>> 2) Architecturally it will be rather naff, having obvious breaks with
>> TM capabilities: use of global variables to communicate across
>> emulation levels; use of its own address as a hidden input to the
>> function; hacks that are designed to "just make the right decion he
>> knows he wants to make", rather than general logic that would be
>> required in anything claiming to be a more general halt decider.
>> Bottom line: it won't be at all how we'd have done it! PO thinks
>> (rightly or wrongly) that those things do not affect his claims, and
>> so he wants to avoid months of discussion/argument over whether he's
>> "doing it the right way".
>>
>> 3) If he "published everything" (x86utm and H) like he steadfastly
>> maintained he would for the first couple of years, people would be
>> able to run and post their own tests/traces, easily highlighting why
>> PO's explanations of what's going on are rubbish. PO wants to retain
>> a tight control over allowed discussion paths! Funnily enough, one of
>> PO's original selling points for developing all this was that it would
>> all be published enabling people to run it and see for themselves the
>> undisputable evidence of his claims!
>
> These are all plausible.
>
>> [I think (3) is by far the main reason why PO decided to backpedal
>> from publishing x86utm and H here. His explanation of "when I take my
>> work to a journal, the publishers will only accept if I haven't
>> revealed utmx86 + H source code elsewhere on the Internet" seems like
>> one of those retro-explanations cooked up just to excuse his breaking
>> with previous commitments. Well, you would know more about whether
>> there would be such a condition from publishers?
>
> I've never come across that. Publishers used to want a paper that was
> not largely similar to one published elsewhere (by which I mean another
> journal) for copyright reasons. But self-publishing, and making code
> public domain, pose no problems for journals as far as I know. But I
> said "used to" because it's been a while!
>
>> And yes, if PO were
>> serious about publishing he'd have acted years (decades?) ago!
>> Perhaps he can put a clause in his will and testament to publish all
>> on UseNet, just in case...]
>
> I very much doubt anyone will ever see H...
>

On 5/25/22 10:02 PM, olcott wrote:
> On 5/25/2022 8:15 PM, Ben wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>
>>> On 25/05/2022 19:42, Ben wrote:
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>
>>>>> It's true we don't know the details of how PO is doing this, but we
>>>>> can see what's effectively going on, I'd say.  It is /as though/ there
>>>>> is one "master trace" of all the nested simulations maintained by the
>>>>> x86utm somewhere in the address space of its virtual x86 processor.
>>>> Hmm... If I had to guess I'd put some store in a few phrases he's
>>>> uttered that maybe give away more than he intends.  Something along the
>>>> line of recursion having the same execution pattern as nested
>>>> simulations (that's not verbatim -- I'm not reading so much anymore).
>>>
>>> Well, he certainly argued with me a couple of years back that it
>>> didn't make any difference to his rule whether the trace was direct
>>> call or emulation recursion.  He declined to provide any proof for the
>>> soundness of his rule in either scenario (of course), instead
>>> suggesting it was my responsibility to provide counter-examples where
>>> his rule failed!  (If nobody could do that, it would mean his rule was
>>> sound, so he believed...)  Oh, and we know that pointing out his H as
>>> an actual counterexample goes nowhere...
>>>
>>>> This adds wight to my idea that he has only the top level simulation
>>>> and
>>>> to "speed up the work" and "make the trace simpler" what's being traced
>>>> by the top-level H is a different H(X, Y) that just calls X(Y).  I
>>>> imagine that he thought he could, in principle, eventually make both
>>>> H's
>>>> the same, and that just calling the computation rather than simulating
>>>> was just a sort of optimisation.
>>>
>>> I can't say "definitely not" to that, but my thinking would be that it
>>> illustrates PO not appreciating the qualitative difference between
>>> recursion in call vs simulation environments, rather than PO not
>>> actually using simulation.  Maybe a prototype test used direct call
>>> and that might have reinforced his confusions.
>>
>> I'm not saying there is none, just that it's not nested.  I posit one
>> simulation in some "top-level H" that steps through the execution of the
>> specified function call (or otherwise observes it) and stops when the
>> magic condition is seen.  But rather than build P from this top-level H
>> so he builds P from a simpler H(X, Y) that just calls X(Y).
>>
>> I admit it's all guesswork though.  I seriously lost interest when all I
>> thought it worth doing was pointing out that if H(X,Y) does not report
>> on the "halting" of X(Y) then it's not doing what everyone else is
>> talking about.
>>
>
> There are two key points:
> (1) The the C function named H correctly determines that the correct
> simulation of its x86 machine-code input would never reach its "ret"
> instruction. This is a simple verified fact that lying cheating bastards
> continue to deny.

No, it has NOT been determined that it correctly determines this, and in
fact it has been proven that it can't, because it have been proven that
a REAL CORRECT simulation of the input WILL reach that return
instruction, by the simulation of H1.

It is YOU being a lying cheating bastard that refuses to accept this proof.

What you HAVE shown is that no possible H can itself simulate to that
point, but that doesn't prove that H is a correct simulation, and you
can't stipulate that it is, because you can't stipulate correctness. (If
you try to stipulate that H will correct simulate, you first need to
actually PROVE that such an H exists, which you can't, since that is
actually the goal of the proof).

You confuse the simulation done by H with a correct simulation of its
input. BY DEFINITION, if H is a Halting Decider, the interpreation of
its input must be the reprentation of a computational program and its
input, which we know will ALWAYS behave the same, so the fact that H1
can simulate it to its return says that is *THE* correct simulation, and
thus H's can't be.

>
> That they continue to deny this is of no great concern because even
> moderately competent software engineers can easily confirm that I am
> correct.

Nope, they will confirm that you are wrong.

>
> (2) That H(P,P) must compute the mapping from a non-input clearly
> violates the definition of a computable function that must
> *given an input of the function ... return the corresponding output*
> and the definition of a decider compute the mapping of its input to an
> accept or reject state.

Yes, H must compute a mapping from its input to its output, but the
mapping that it computes is not guarenteed to be the Halting Function,
in fact, that is a required goal, to PROVE that it is. The fact that
H(P,P) doesn't match the required answer of what P(P) does, says it can
not actually be a Halting decider.

>
> It is *not* that the computer science textbook authors disagree with
> this. It is only that they simply assumed that P(P) cannot possibly
> specify a different sequence of configurations than the correct
> simulation of the input to H(P,P).
>

Because is CAN'T and have H actually be a Halt Decider, since that is
the DEFINITION of a Halting Decider.

> These two may only differ in the case of pathological self-reference
> (Olcott 2004). Since no one was every able to execute an input with PSR
> previously (they simply assumed it was impossibe) they never noticed
> this divergence.

There is no exception in the definiton of a "something" decider. To be a
"something" decider, it must compute the "something" function for ALL
inputs, even "pathological" ones. If this isn't possible, the function
is just not computable.

>
> The actual correct x86 emulation of the input to H1(P,P) and H(P,P)
> conclusive proves that P does have different halting behavior between
> them. The alternative is that the x86 language itself is not telling the
> truth about their behavior.
>

Then P is not a Computation, and due to the way P was built, that proves
that H is not a Computation, and thus can not actually a Halt Decider,
as the Halt Decider needs to be a COMPUTATION that computes the Halting
Function.

You just proved that your H isn't a Halt Decider

> Actual computer scientists that know these things much deeper than mere
> rote memorization will understand that I am correct. The alternative to
> this is that computer scientists believe that textbook authors can
> contradict the principles of computer science and not be wrong.
>

Nope.

> When H that simulates P calls H(P,P) this H creates a whole new process
> context that simulates its input all the way through to P calling H(P,P)
> again.

So, since H isn't actually a computation, it doesn't matter. Note, your
trace doesn't show that behavior, so either the trace lies or you do
about what it does.

>
>>> I think my description of how it /could/ be coded (using a global
>>> trace area etc.) is within PO's coding ability given how long he had
>>> to sort it out.  Also PO has definitely talked about such a global
>>> trace, I think in relation to whether this use of globals broke the
>>> "pure function" requirement (as he understood it).  So if I had to
>>> place a bet, I'd go with it working /something/ like this, rather than
>>> the blatant faking of traces otherwise required.
>>
>> I don't think they are faked, at least not totally faked.
>>
>
> It can be verified that they are correct thus the issue of whether they
> are faked or not (they are not faked) is moot. It was very very
> difficult to make H re-entrant.

But it appears that it isn't actually a computation since the H called
by P doesn't compute the same answer as the H that is called
independently. This disqualifies it from being a Halting Decider.

>
> It was much easier to make x86utm actually be able to execute H in
> infinitely nested simulation than it was to verify that it was correct
> without actual code. I had far too many false starts with imaginary
> code. I had to make real code so if needed I could make adjustments to
> my analysis.
>

On 5/26/2022 6:21 AM, Ben wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>
>>> I admit it's all guesswork though. I seriously lost interest when all I
>>> thought it worth doing was pointing out that if H(X,Y) does not report
>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>> talking about.
>>>
>> To me, that's what retains the interest.
>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>> wouldn't they?
>>
>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>> that they are refusing to provide the source, then really the whole
>> thing must be dismissed.
>>
>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>> reports non-halting, and they can prove that H is correct.
>
> There's no reason at all to think that H is /not/ correct. But since H
> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
> what's interesting about it being correct. Do you really think it's
> "deciding" some interesting property of the "input"?
>

The only reason that you do not see the significance of this is that the
depth of your understanding is learned-by-rote.

Someone with a deeper understanding would realize that your
interpretation that a halt decider must compute its mapping from a
non-input would understand that this would violate the definition of a
computable function and the definition of a decider.

They would understand that a halt determiner must only compute the
mapping from its input to its own final accept or reject state on the
basis of the behavior that this input actually specifies.

If we take your interpretation as correct then computer scientists we be
agreeing that it is perfectly OK for the requirements of a decision
problem to violate the principles of computer science and still be a
valid decision problem.

Then we have other undecidable decision problems such as calculating
whether or not the square root of a plate of scrambled eggs > 5.

>> Well that's something a bit new and different.
>
> Being different is key for any Usenet maths crank. No two people who
> have "refuted Cantor" or "solved halting" will agree with each other for
> long. Fortunately there are infinitely many ways to be wrong, but only
> one way to be right so it's not hard to achieve.
>

--
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/26/22 9:35 AM, olcott wrote:
> On 5/26/2022 6:21 AM, Ben wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>
>>>> I admit it's all guesswork though. I seriously lost interest when all I
>>>> thought it worth doing was pointing out that if H(X,Y) does not report
>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>> talking about.
>>>>
>>> To me, that's what retains the interest.
>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>> wouldn't they?
>>>
>>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>>> that they are refusing to provide the source, then really the whole
>>> thing must be dismissed.
>>>
>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>> reports non-halting, and they can prove that H is correct.
>>
>> There's no reason at all to think that H is /not/ correct.  But since H
>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>> what's interesting about it being correct.  Do you really think it's
>> "deciding" some interesting property of the "input"?
>>
>
> The only reason that you do not see the significance of this is that the
> depth of your understanding is learned-by-rote.
>
> Someone with a deeper understanding would realize that your
> interpretation that a halt decider must compute its mapping from a
> non-input would understand that this would violate the definition of a
> computable function and the definition of a decider.

No, it only CAN compute what can be determined by its processing of the
input, but a "something" decider MUST compute the "something" mapping
defined, and if that is not possible, the mapping just isn't computable.

You err in presuming (incorrectly) that the Halting Mapping Must be
Computable, and thus feel the ability to redefine it when you find it isn't

That just proves that you don't know what you are doing.

>
> They would understand that a halt determiner must only compute the
> mapping from its input to its own final accept or reject state on the
> basis of the behavior that this input actually specifies.
>

No, to be "Just a Decider", then that is what it CAN do, but to claim to
be a Halt Decider, then the results must match the Halting Function.

What you are saying is like claiming to be immortal, but saying that
since human bodies will die, we just need to change the definition of
immortality,

> If we take your interpretation as correct then computer scientists we be
> agreeing that it is perfectly OK for the requirements of a decision
> problem to violate the principles of computer science and still be a
> valid decision problem.

And, it this sense, it is, because there is no requirement that Halt
Deciders actually need to exist, and a perfectly fine answer is that
there is no such thing.

>
> Then we have other undecidable decision problems such as calculating
> whether or not the square root of a plate of scrambled eggs > 5.

Nope, not the same. The Halting Function is well defined, and if an H
existed, then the Halting of H^ applied to <H^> would be well defined
for the H^ built on that H.

>
>>> Well that's something a bit new and different.
>>
>> Being different is key for any Usenet maths crank.  No two people who
>> have "refuted Cantor" or "solved halting" will agree with each other for
>> long.  Fortunately there are infinitely many ways to be wrong, but only
>> one way to be right so it's not hard to achieve.
>>
>
>

On 5/26/2022 9:50 PM, Richard Damon wrote:
> On 5/26/22 9:35 AM, olcott wrote:
>> On 5/26/2022 6:21 AM, Ben wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>
>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>> all I
>>>>> thought it worth doing was pointing out that if H(X,Y) does not report
>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>> talking about.
>>>>>
>>>> To me, that's what retains the interest.
>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>> wouldn't they?
>>>>
>>>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>>>> that they are refusing to provide the source, then really the whole
>>>> thing must be dismissed.
>>>>
>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>> reports non-halting, and they can prove that H is correct.
>>>
>>> There's no reason at all to think that H is /not/ correct.  But since H
>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>> what's interesting about it being correct.  Do you really think it's
>>> "deciding" some interesting property of the "input"?
>>>
>>
>> The only reason that you do not see the significance of this is that
>> the depth of your understanding is learned-by-rote.
>>
>> Someone with a deeper understanding would realize that your
>> interpretation that a halt decider must compute its mapping from a
>> non-input would understand that this would violate the definition of a
>> computable function and the definition of a decider.
>
> No, it only CAN compute what can be determined by its processing of the
> input, but a "something" decider MUST compute the "something" mapping
> defined,
You just contradicted yourself.

The set of deciders only applies to input finite strings. It can apply
any computable criteria to these inputs. I know these things first-hand
not merely by the rote from textbooks.

--
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/26/22 11:06 PM, olcott wrote:
> On 5/26/2022 9:50 PM, Richard Damon wrote:
>> On 5/26/22 9:35 AM, olcott wrote:
>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>
>>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>>> all I
>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>> report
>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>> talking about.
>>>>>>
>>>>> To me, that's what retains the interest.
>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>> wouldn't they?
>>>>>
>>>>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>>>>> that they are refusing to provide the source, then really the whole
>>>>> thing must be dismissed.
>>>>>
>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>> reports non-halting, and they can prove that H is correct.
>>>>
>>>> There's no reason at all to think that H is /not/ correct.  But since H
>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>>> what's interesting about it being correct.  Do you really think it's
>>>> "deciding" some interesting property of the "input"?
>>>>
>>>
>>> The only reason that you do not see the significance of this is that
>>> the depth of your understanding is learned-by-rote.
>>>
>>> Someone with a deeper understanding would realize that your
>>> interpretation that a halt decider must compute its mapping from a
>>> non-input would understand that this would violate the definition of
>>> a computable function and the definition of a decider.
>>
>> No, it only CAN compute what can be determined by its processing of
>> the input, but a "something" decider MUST compute the "something"
>> mapping defined,
> You just contradicted yourself.

No, just shows you don't understand English.

I am pointing out the difference between what something is ABLE to do,
and what it is REQUIRED to do.
>
> The set of deciders only applies to input finite strings.  It can apply
> any computable criteria to these inputs. I know these things first-hand
> not merely by the rote from textbooks.
>

Right, and the finite string that descibes P is the FULL contents of the
memory including ALL the code that it executes.

This is BY DEFINITION a finite string, since there are a finite number
of bytes. Thus the behavior of that when run as a program is something
in the domain of what we MAY ask.

Then we get to your second statement, and that is the crux of the
proble, is the Halting Criteria computable? The Halting Function
Halting(M,w) is DEFINED to return True if M(w) will Halt, and False if
M(w) will never halt. Halting is clearly recognizable, as we can build a
machine that accepts (in finite time) all halting inputs, by just
simulating and accepting when the simulation halts.

This is just recognition, not deciding, as it just doesn't answer for
non-halting inputs.

The question comes can we do something to some how recognize these
non-halting and be able to REJECT them, rather than just looping on them.

The "Impossible Program" proves that this can't be done. It IS a finite
string input, at least if H is (and it must be to meet the requirements
to actually be a decider), and thus is a legal input.

It also presents a problem for the decider it is built on, as whatever
answer that decider gives, will be wrong, because of the ability to
refer to that decider inside the impossible program.

What this proves is that Halting isn't a computable function, and thus
(because it isn't computable, and what makes it non-computable) no
decider can be built to compute it.

Your logical flaw is that your start with the assumption that Halting
must be computable, when that is NOT an allowable assumption, in fact,
that is the QUESTION.

This means you don't get to redefine the meaning of the problem, to
something that is actually computable to answer the question.

That is like answering about how many Dogs you have when someone asks
about fleas, because fleas are just too hard to find to count. It just
isn't the right answer to the question.

On 5/27/2022 7:50 AM, Richard Damon wrote:
> On 5/26/22 11:06 PM, olcott wrote:
>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>> On 5/26/22 9:35 AM, olcott wrote:
>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>
>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>
>>>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>>>> all I
>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>> report
>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>> talking about.
>>>>>>>
>>>>>> To me, that's what retains the interest.
>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>> wouldn't they?
>>>>>>
>>>>>> If it turns out that H isn't a Turing machine but a C/x86 program,
>>>>>> and
>>>>>> that they are refusing to provide the source, then really the whole
>>>>>> thing must be dismissed.
>>>>>>
>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>
>>>>> There's no reason at all to think that H is /not/ correct.  But
>>>>> since H
>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>>>> what's interesting about it being correct.  Do you really think it's
>>>>> "deciding" some interesting property of the "input"?
>>>>>
>>>>
>>>> The only reason that you do not see the significance of this is that
>>>> the depth of your understanding is learned-by-rote.
>>>>
>>>> Someone with a deeper understanding would realize that your
>>>> interpretation that a halt decider must compute its mapping from a
>>>> non-input would understand that this would violate the definition of
>>>> a computable function and the definition of a decider.
>>>
>>> No, it only CAN compute what can be determined by its processing of
>>> the input, but a "something" decider MUST compute the "something"
>>> mapping defined,
>> You just contradicted yourself.
>
> No, just shows you don't understand English.
>
> I am pointing out the difference between what something is ABLE to do,
> and what it is REQUIRED to do.

You are requiring that a decider maps somethings that it does not have,
thus making your requirement incorrect. It is like I said give me the
$10 from your empty wallet.

>>
>> The set of deciders only applies to input finite strings.  It can
>> apply any computable criteria to these inputs. I know these things
>> first-hand not merely by the rote from textbooks.
>>
>
> Right, and the finite string that descibes P is the FULL contents of the
> memory including ALL the code that it executes.
>
> This is BY DEFINITION a finite string, since there are a finite number
> of bytes. Thus the behavior of that when run as a program is something
> in the domain of what we MAY ask.
>
> Then we get to your second statement, and that is the crux of the
> proble, is the Halting Criteria computable? The Halting Function
> Halting(M,w) is DEFINED to return True if M(w) will Halt, and False if
> M(w) will never halt. Halting is clearly recognizable, as we can build a
> machine that accepts (in finite time) all halting inputs, by just
> simulating and accepting when the simulation halts.
>
> This is just recognition, not deciding, as it just doesn't answer for
> non-halting inputs.
>
> The question comes can we do something to some how recognize these
> non-halting and be able to REJECT them, rather than just looping on them.
>
> The "Impossible Program" proves that this can't be done. It IS a finite
> string input, at least if H is (and it must be to meet the requirements
> to actually be a decider), and thus is a legal input.
>
> It also presents a problem for the decider it is built on, as whatever
> answer that decider gives, will be wrong, because of the ability to
> refer to that decider inside the impossible program.
>
> What this proves is that Halting isn't a computable function, and thus
> (because it isn't computable, and what makes it non-computable) no
> decider can be built to compute it.
>
> Your logical flaw is that your start with the assumption that Halting
> must be computable, when that is NOT an allowable assumption, in fact,
> that is the QUESTION.
>
> This means you don't get to redefine the meaning of the problem, to
> something that is actually computable to answer the question.
>
> That is like answering about how many Dogs you have when someone asks
> about fleas, because fleas are just too hard to find to count. It just
> isn't the right answer to the question.

--
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/27/22 11:24 AM, olcott wrote:
> On 5/27/2022 7:50 AM, Richard Damon wrote:
>> On 5/26/22 11:06 PM, olcott wrote:
>>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>>> On 5/26/22 9:35 AM, olcott wrote:
>>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>
>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>
>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>> when all I
>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>>> report
>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>>> talking about.
>>>>>>>>
>>>>>>> To me, that's what retains the interest.
>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>> wouldn't they?
>>>>>>>
>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>> program, and
>>>>>>> that they are refusing to provide the source, then really the whole
>>>>>>> thing must be dismissed.
>>>>>>>
>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>
>>>>>> There's no reason at all to think that H is /not/ correct.  But
>>>>>> since H
>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't
>>>>>> see
>>>>>> what's interesting about it being correct.  Do you really think it's
>>>>>> "deciding" some interesting property of the "input"?
>>>>>>
>>>>>
>>>>> The only reason that you do not see the significance of this is
>>>>> that the depth of your understanding is learned-by-rote.
>>>>>
>>>>> Someone with a deeper understanding would realize that your
>>>>> interpretation that a halt decider must compute its mapping from a
>>>>> non-input would understand that this would violate the definition
>>>>> of a computable function and the definition of a decider.
>>>>
>>>> No, it only CAN compute what can be determined by its processing of
>>>> the input, but a "something" decider MUST compute the "something"
>>>> mapping defined,
>>> You just contradicted yourself.
>>
>> No, just shows you don't understand English.
>>
>> I am pointing out the difference between what something is ABLE to do,
>> and what it is REQUIRED to do.
>
> You are requiring that a decider maps somethings that it does not have,
> thus making your requirement incorrect. It is like I said give me the
> $10 from your empty wallet.

But it DOES have the representation of P, so it can map it.

YOU just don't know what you are talking about.

If you are saying the Halting Problem is impossible to make as a
requirement, you have just PROVED the Theorem.

AND FAILED at its disproof.

If you disalllow the asking of a question, you make it impossible to
give a correct answer, and thus a machine that answers the question
correcctly is impossible.

Halting Theorem Proved.

YOU FAIL.

>
>
>>>
>>> The set of deciders only applies to input finite strings.  It can
>>> apply any computable criteria to these inputs. I know these things
>>> first-hand not merely by the rote from textbooks.
>>>
>>
>> Right, and the finite string that descibes P is the FULL contents of
>> the memory including ALL the code that it executes.
>>
>> This is BY DEFINITION a finite string, since there are a finite number
>> of bytes. Thus the behavior of that when run as a program is something
>> in the domain of what we MAY ask.
>>
>> Then we get to your second statement, and that is the crux of the
>> proble, is the Halting Criteria computable? The Halting Function
>> Halting(M,w) is DEFINED to return True if M(w) will Halt, and False if
>> M(w) will never halt. Halting is clearly recognizable, as we can build
>> a machine that accepts (in finite time) all halting inputs, by just
>> simulating and accepting when the simulation halts.
>>
>> This is just recognition, not deciding, as it just doesn't answer for
>> non-halting inputs.
>>
>> The question comes can we do something to some how recognize these
>> non-halting and be able to REJECT them, rather than just looping on them.
>>
>> The "Impossible Program" proves that this can't be done. It IS a
>> finite string input, at least if H is (and it must be to meet the
>> requirements to actually be a decider), and thus is a legal input.
>>
>> It also presents a problem for the decider it is built on, as whatever
>> answer that decider gives, will be wrong, because of the ability to
>> refer to that decider inside the impossible program.
>>
>> What this proves is that Halting isn't a computable function, and thus
>> (because it isn't computable, and what makes it non-computable) no
>> decider can be built to compute it.
>>
>> Your logical flaw is that your start with the assumption that Halting
>> must be computable, when that is NOT an allowable assumption, in fact,
>> that is the QUESTION.
>>
>> This means you don't get to redefine the meaning of the problem, to
>> something that is actually computable to answer the question.
>>
>> That is like answering about how many Dogs you have when someone asks
>> about fleas, because fleas are just too hard to find to count. It just
>> isn't the right answer to the question.
>
>

On 5/27/2022 10:52 AM, Malcolm McLean wrote:
> On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
>> On 5/27/22 11:21 AM, olcott wrote:
>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>
>>>>> Someone with a deeper understanding would realize that your
>>>>> interpretation that a halt decider must compute its mapping from a
>>>>> non-input would understand that this would violate the definition of
>>>>> a computable function and the definition of a decider.
>>>>
>>>> The definition of "decider" does not require much, only that it must halt
>>>> and indicate the decision. This is not violated by the definition of
>>>> "halt
>>>> decider".
>>>>
>>>
>>> a function is computable if there exists an algorithm that can do the
>>> job of the function, i.e. given an input of the function domain it can
>>> return the corresponding output.
>>> https://en.wikipedia.org/wiki/Computable_function
>>>
>>> P(P) is not in the domain of H because it is not an input to H.
>> Wrong. IF that is true the a UTM can't exist, but you are baisng your
>> argument on that.
>>
>> The representation of P, in your case the object code of it. contains
>> all the data needed to determine the behavior of that computation, and
>> thus IS in the domain of H.
>>
>> In fact, saying that the representation of P(P) is not in the domain of
>> H is, by itself, enough to prove that H can not be a correct halt decider.
>>
>> You are just digging a deeper hole for yourself.
>>
>> You are just proving your ignorance.
>>
>> If H claims to be a Halt Decider, then we need to be able to ask it
>> about any computation, how do we ask it about P(P).
>>
>> If we can't, then it isn't one.
>>
> But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
> would in fact achieve PO's broader objectives. It wouldn't "solve the
> halting problem", but it would redefine it for future workers.
>

Halt decider are required to decide the halt status of any finite
strings that specify a sequence of configurations.

Halt deciders are not required to decide that halt status of finite
strings of English poems nor are they required to compute the halt
status of anything that is not an input finite string.

For example H is not required to compute the halt status of the behavior
that a person imagines that P(P) has. H(P,P) is only required to compute
the halt state that its input actually specifies.

> However the question is how to do this in an interesting way. As Ben says,
> a lot of students, when introduced to this material, say "why not detect
> the H_Hat(H_Hat) pattern and special case it?". It's a natural reaction.
> But when you think about it a bit more deeply, you'll see that this strategy
> doesn't work.
>

It does work when H is defined to recognize the whole infinite recursion
pattern. I threw in infinite loops for good measure.

--
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/27/2022 10:53 AM, Richard Damon wrote:
> On 5/27/22 11:24 AM, olcott wrote:
>> On 5/27/2022 7:50 AM, Richard Damon wrote:
>>> On 5/26/22 11:06 PM, olcott wrote:
>>>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>>>> On 5/26/22 9:35 AM, olcott wrote:
>>>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>
>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>
>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>> when all I
>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>>>> report
>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>>>> talking about.
>>>>>>>>>
>>>>>>>> To me, that's what retains the interest.
>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>> wouldn't they?
>>>>>>>>
>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>> program, and
>>>>>>>> that they are refusing to provide the source, then really the whole
>>>>>>>> thing must be dismissed.
>>>>>>>>
>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>>
>>>>>>> There's no reason at all to think that H is /not/ correct.  But
>>>>>>> since H
>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>> don't see
>>>>>>> what's interesting about it being correct.  Do you really think it's
>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>
>>>>>>
>>>>>> The only reason that you do not see the significance of this is
>>>>>> that the depth of your understanding is learned-by-rote.
>>>>>>
>>>>>> Someone with a deeper understanding would realize that your
>>>>>> interpretation that a halt decider must compute its mapping from a
>>>>>> non-input would understand that this would violate the definition
>>>>>> of a computable function and the definition of a decider.
>>>>>
>>>>> No, it only CAN compute what can be determined by its processing of
>>>>> the input, but a "something" decider MUST compute the "something"
>>>>> mapping defined,
>>>> You just contradicted yourself.
>>>
>>> No, just shows you don't understand English.
>>>
>>> I am pointing out the difference between what something is ABLE to
>>> do, and what it is REQUIRED to do.
>>
>> You are requiring that a decider maps somethings that it does not
>> have, thus making your requirement incorrect. It is like I said give
>> me the $10 from your empty wallet.
>
> But it DOES have the representation of P, so it can map it.
>
The correctly simulated input to H(P,P)==0
The correctly simulated input to H1(P,P)==1

--
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/27/22 12:06 PM, olcott wrote:
> On 5/27/2022 10:53 AM, Richard Damon wrote:
>> On 5/27/22 11:24 AM, olcott wrote:
>>> On 5/27/2022 7:50 AM, Richard Damon wrote:
>>>> On 5/26/22 11:06 PM, olcott wrote:
>>>>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>>>>> On 5/26/22 9:35 AM, olcott wrote:
>>>>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>>
>>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>>> when all I
>>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does
>>>>>>>>>> not report
>>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone
>>>>>>>>>> else is
>>>>>>>>>> talking about.
>>>>>>>>>>
>>>>>>>>> To me, that's what retains the interest.
>>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>>> wouldn't they?
>>>>>>>>>
>>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>>> program, and
>>>>>>>>> that they are refusing to provide the source, then really the
>>>>>>>>> whole
>>>>>>>>> thing must be dismissed.
>>>>>>>>>
>>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>>>
>>>>>>>> There's no reason at all to think that H is /not/ correct.  But
>>>>>>>> since H
>>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>>> don't see
>>>>>>>> what's interesting about it being correct.  Do you really think
>>>>>>>> it's
>>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>>
>>>>>>>
>>>>>>> The only reason that you do not see the significance of this is
>>>>>>> that the depth of your understanding is learned-by-rote.
>>>>>>>
>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>> interpretation that a halt decider must compute its mapping from
>>>>>>> a non-input would understand that this would violate the
>>>>>>> definition of a computable function and the definition of a decider.
>>>>>>
>>>>>> No, it only CAN compute what can be determined by its processing
>>>>>> of the input, but a "something" decider MUST compute the
>>>>>> "something" mapping defined,
>>>>> You just contradicted yourself.
>>>>
>>>> No, just shows you don't understand English.
>>>>
>>>> I am pointing out the difference between what something is ABLE to
>>>> do, and what it is REQUIRED to do.
>>>
>>> You are requiring that a decider maps somethings that it does not
>>> have, thus making your requirement incorrect. It is like I said give
>>> me the $10 from your empty wallet.
>>
>> But it DOES have the representation of P, so it can map it.
>>
> The correctly simulated input to  H(P,P)==0
> The correctly simulated input to H1(P,P)==1
>

HOW?

It is the same input, so has the same correct simulation.

Do you really expect people to believe that that SAME program, when
simulated by two diffetent "correct" simulators have different behavior?

What definition of "correct" are you using, it must be something besides
matching the actual behavior of the code given to it.

All you have done is proven that you H isn't a computation, and thus not
eligible to be a decider.

FAIL

On 5/27/22 12:04 PM, olcott wrote:
> On 5/27/2022 10:52 AM, Malcolm McLean wrote:
>> On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
>>> On 5/27/22 11:21 AM, olcott wrote:
>>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>>
>>>>>> Someone with a deeper understanding would realize that your
>>>>>> interpretation that a halt decider must compute its mapping from a
>>>>>> non-input would understand that this would violate the definition of
>>>>>> a computable function and the definition of a decider.
>>>>>
>>>>> The definition of "decider" does not require much, only that it
>>>>> must halt
>>>>> and indicate the decision. This is not violated by the definition of
>>>>> "halt
>>>>> decider".
>>>>>
>>>>
>>>> a function is computable if there exists an algorithm that can do the
>>>> job of the function, i.e. given an input of the function domain it can
>>>> return the corresponding output.
>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>
>>>> P(P) is not in the domain of H because it is not an input to H.
>>> Wrong. IF that is true the a UTM can't exist, but you are baisng your
>>> argument on that.
>>>
>>> The representation of P, in your case the object code of it. contains
>>> all the data needed to determine the behavior of that computation, and
>>> thus IS in the domain of H.
>>>
>>> In fact, saying that the representation of P(P) is not in the domain of
>>> H is, by itself, enough to prove that H can not be a correct halt
>>> decider.
>>>
>>> You are just digging a deeper hole for yourself.
>>>
>>> You are just proving your ignorance.
>>>
>>> If H claims to be a Halt Decider, then we need to be able to ask it
>>> about any computation, how do we ask it about P(P).
>>>
>>> If we can't, then it isn't one.
>>>
>> But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
>> would in fact achieve PO's broader objectives. It wouldn't "solve the
>> halting problem", but it would redefine it for future workers.
>>
>
> Halt decider are required to decide the halt status of any finite
> strings that specify a sequence of configurations.
>
> Halt deciders are not required to decide that halt status of finite
> strings of English poems nor are they required to compute the halt
> status of anything that is not an input finite string.
>
> For example H is not required to compute the halt status of the behavior
> that a person imagines that P(P) has. H(P,P) is only required to compute
> the halt state that its input actually specifies.
>
>> However the question is how to do this in an interesting way. As Ben
>> says,
>> a lot of students, when introduced to this material, say "why not detect
>> the H_Hat(H_Hat) pattern and special case it?". It's a natural reaction.
>> But when you think about it a bit more deeply, you'll see that this
>> strategy
>> doesn't work.
>>
>
> It does work when H is defined to recognize the whole infinite recursion
> pattern. I threw in infinite loops for good measure.
>

Except there is no such universal correct pattern.

This is shown by the fact that H(P.P) says Non-Halting when P(P) Halts,
showing that H was wrong.

On 5/27/2022 12:03 PM, Richard Damon wrote:
> On 5/27/22 12:06 PM, olcott wrote:
>> On 5/27/2022 10:53 AM, Richard Damon wrote:
>>> On 5/27/22 11:24 AM, olcott wrote:
>>>> On 5/27/2022 7:50 AM, Richard Damon wrote:
>>>>> On 5/26/22 11:06 PM, olcott wrote:
>>>>>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>>>>>> On 5/26/22 9:35 AM, olcott wrote:
>>>>>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>>>
>>>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>>>> when all I
>>>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does
>>>>>>>>>>> not report
>>>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone
>>>>>>>>>>> else is
>>>>>>>>>>> talking about.
>>>>>>>>>>>
>>>>>>>>>> To me, that's what retains the interest.
>>>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H
>>>>>>>>>> such
>>>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>>>> wouldn't they?
>>>>>>>>>>
>>>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>>>> program, and
>>>>>>>>>> that they are refusing to provide the source, then really the
>>>>>>>>>> whole
>>>>>>>>>> thing must be dismissed.
>>>>>>>>>>
>>>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>>>>
>>>>>>>>> There's no reason at all to think that H is /not/ correct.  But
>>>>>>>>> since H
>>>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>>>> don't see
>>>>>>>>> what's interesting about it being correct.  Do you really think
>>>>>>>>> it's
>>>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The only reason that you do not see the significance of this is
>>>>>>>> that the depth of your understanding is learned-by-rote.
>>>>>>>>
>>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>>> interpretation that a halt decider must compute its mapping from
>>>>>>>> a non-input would understand that this would violate the
>>>>>>>> definition of a computable function and the definition of a
>>>>>>>> decider.
>>>>>>>
>>>>>>> No, it only CAN compute what can be determined by its processing
>>>>>>> of the input, but a "something" decider MUST compute the
>>>>>>> "something" mapping defined,
>>>>>> You just contradicted yourself.
>>>>>
>>>>> No, just shows you don't understand English.
>>>>>
>>>>> I am pointing out the difference between what something is ABLE to
>>>>> do, and what it is REQUIRED to do.
>>>>
>>>> You are requiring that a decider maps somethings that it does not
>>>> have, thus making your requirement incorrect. It is like I said give
>>>> me the $10 from your empty wallet.
>>>
>>> But it DOES have the representation of P, so it can map it.
>>>
>> The correctly simulated input to  H(P,P)==0
>> The correctly simulated input to H1(P,P)==1
>>
>
> HOW?
>
> It is the same input, so has the same correct simulation.
I know exactly how. When I explain exactly how my reviewers brains
short-circuit and they become utterly confused.

Instead of how we really only need to know that H(P,P)==0 and H1(P,P)==1
is easily verified as correct on the basis of the behavior of the
correct x86 emulation of these inputs.

--
Copyright 2022 Pete Olcott

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

On 5/27/2022 12:04 PM, Richard Damon wrote:
> On 5/27/22 12:04 PM, olcott wrote:
>> On 5/27/2022 10:52 AM, Malcolm McLean wrote:
>>> On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
>>>> On 5/27/22 11:21 AM, olcott wrote:
>>>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>>>
>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>> interpretation that a halt decider must compute its mapping from a
>>>>>>> non-input would understand that this would violate the definition of
>>>>>>> a computable function and the definition of a decider.
>>>>>>
>>>>>> The definition of "decider" does not require much, only that it
>>>>>> must halt
>>>>>> and indicate the decision. This is not violated by the definition of
>>>>>> "halt
>>>>>> decider".
>>>>>>
>>>>>
>>>>> a function is computable if there exists an algorithm that can do the
>>>>> job of the function, i.e. given an input of the function domain it can
>>>>> return the corresponding output.
>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>
>>>>> P(P) is not in the domain of H because it is not an input to H.
>>>> Wrong. IF that is true the a UTM can't exist, but you are baisng your
>>>> argument on that.
>>>>
>>>> The representation of P, in your case the object code of it. contains
>>>> all the data needed to determine the behavior of that computation, and
>>>> thus IS in the domain of H.
>>>>
>>>> In fact, saying that the representation of P(P) is not in the domain of
>>>> H is, by itself, enough to prove that H can not be a correct halt
>>>> decider.
>>>>
>>>> You are just digging a deeper hole for yourself.
>>>>
>>>> You are just proving your ignorance.
>>>>
>>>> If H claims to be a Halt Decider, then we need to be able to ask it
>>>> about any computation, how do we ask it about P(P).
>>>>
>>>> If we can't, then it isn't one.
>>>>
>>> But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
>>> would in fact achieve PO's broader objectives. It wouldn't "solve the
>>> halting problem", but it would redefine it for future workers.
>>>
>>
>> Halt decider are required to decide the halt status of any finite
>> strings that specify a sequence of configurations.
>>
>> Halt deciders are not required to decide that halt status of finite
>> strings of English poems nor are they required to compute the halt
>> status of anything that is not an input finite string.
>>
>> For example H is not required to compute the halt status of the
>> behavior that a person imagines that P(P) has. H(P,P) is only required
>> to compute the halt state that its input actually specifies.
>>
>>> However the question is how to do this in an interesting way. As Ben
>>> says,
>>> a lot of students, when introduced to this material, say "why not detect
>>> the H_Hat(H_Hat) pattern and special case it?". It's a natural reaction.
>>> But when you think about it a bit more deeply, you'll see that this
>>> strategy
>>> doesn't work.
>>>
>>
>> It does work when H is defined to recognize the whole infinite
>> recursion pattern. I threw in infinite loops for good measure.
>>
>
> Except there is no such universal correct pattern.
>

H correctly recognizes the only infinite recursion pattern that it needs
to recognize and that is this one:

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own x86 source and
its input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

> This is shown by the fact that H(P.P) says Non-Halting when P(P) Halts,
> showing that H was wrong.

The correct x86 emulation of the input to H(P,P) conclusively proves
that it DOES NOT HALT.

The correct x86 emulation of the input to H1(P,P) conclusively proves
that it HALTS.

When you disagree with this it is just like you are disagreeing with
arithmetic.

--
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/27/22 1:23 PM, olcott wrote:
> On 5/27/2022 12:03 PM, Richard Damon wrote:
>> On 5/27/22 12:06 PM, olcott wrote:
>>> On 5/27/2022 10:53 AM, Richard Damon wrote:
>>>> On 5/27/22 11:24 AM, olcott wrote:
>>>>> On 5/27/2022 7:50 AM, Richard Damon wrote:
>>>>>> On 5/26/22 11:06 PM, olcott wrote:
>>>>>>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>>>>>>> On 5/26/22 9:35 AM, olcott wrote:
>>>>>>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>>>>> when all I
>>>>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does
>>>>>>>>>>>> not report
>>>>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone
>>>>>>>>>>>> else is
>>>>>>>>>>>> talking about.
>>>>>>>>>>>>
>>>>>>>>>>> To me, that's what retains the interest.
>>>>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H
>>>>>>>>>>> such
>>>>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>>>>> wouldn't they?
>>>>>>>>>>>
>>>>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>>>>> program, and
>>>>>>>>>>> that they are refusing to provide the source, then really the
>>>>>>>>>>> whole
>>>>>>>>>>> thing must be dismissed.
>>>>>>>>>>>
>>>>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>>>>>
>>>>>>>>>> There's no reason at all to think that H is /not/ correct.
>>>>>>>>>> But since H
>>>>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>>>>> don't see
>>>>>>>>>> what's interesting about it being correct.  Do you really
>>>>>>>>>> think it's
>>>>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The only reason that you do not see the significance of this is
>>>>>>>>> that the depth of your understanding is learned-by-rote.
>>>>>>>>>
>>>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>>>> interpretation that a halt decider must compute its mapping
>>>>>>>>> from a non-input would understand that this would violate the
>>>>>>>>> definition of a computable function and the definition of a
>>>>>>>>> decider.
>>>>>>>>
>>>>>>>> No, it only CAN compute what can be determined by its processing
>>>>>>>> of the input, but a "something" decider MUST compute the
>>>>>>>> "something" mapping defined,
>>>>>>> You just contradicted yourself.
>>>>>>
>>>>>> No, just shows you don't understand English.
>>>>>>
>>>>>> I am pointing out the difference between what something is ABLE to
>>>>>> do, and what it is REQUIRED to do.
>>>>>
>>>>> You are requiring that a decider maps somethings that it does not
>>>>> have, thus making your requirement incorrect. It is like I said
>>>>> give me the $10 from your empty wallet.
>>>>
>>>> But it DOES have the representation of P, so it can map it.
>>>>
>>> The correctly simulated input to  H(P,P)==0
>>> The correctly simulated input to H1(P,P)==1
>>>
>>
>> HOW?
>>
>> It is the same input, so has the same correct simulation.
> I know exactly how. When I explain exactly how my reviewers brains
> short-circuit and they become utterly confused.

In other words, you can't actually explain it.

You apparently THINK you know it, by epistomolgy, you can only know
something that is actually true, and whose truth you can prove.

The fact that you can't make a reasoned argument about the truth of this
statement shows you don't actually know it.

It is a mistaken BELIEF of yours, grounded in your own ignorance of what
Truth actually requires.

>
> Instead of how we really only need to know that H(P,P)==0 and H1(P,P)==1
> is easily verified as correct on the basis of the behavior of the
> correct x86 emulation of these inputs.
>

No, you make this CLAIM, that it totally not backed up by ANY proof,
just CLAIMS, that show you don't understand the maining of the words you
are speaking.

All your arguments have shown is that there are many things you just
don't understand, beginning with most of computation theory, the theory
of how logic works, and even the meaning of Truth and Knowledge itself.

You are just a lying fool who is a legend in his own minds.

On 5/27/22 1:28 PM, olcott wrote:
> On 5/27/2022 12:04 PM, Richard Damon wrote:
>> On 5/27/22 12:04 PM, olcott wrote:
>>> On 5/27/2022 10:52 AM, Malcolm McLean wrote:
>>>> On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
>>>>> On 5/27/22 11:21 AM, olcott wrote:
>>>>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>>>>
>>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>>> interpretation that a halt decider must compute its mapping from a
>>>>>>>> non-input would understand that this would violate the
>>>>>>>> definition of
>>>>>>>> a computable function and the definition of a decider.
>>>>>>>
>>>>>>> The definition of "decider" does not require much, only that it
>>>>>>> must halt
>>>>>>> and indicate the decision. This is not violated by the definition of
>>>>>>> "halt
>>>>>>> decider".
>>>>>>>
>>>>>>
>>>>>> a function is computable if there exists an algorithm that can do the
>>>>>> job of the function, i.e. given an input of the function domain it
>>>>>> can
>>>>>> return the corresponding output.
>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>
>>>>>> P(P) is not in the domain of H because it is not an input to H.
>>>>> Wrong. IF that is true the a UTM can't exist, but you are baisng your
>>>>> argument on that.
>>>>>
>>>>> The representation of P, in your case the object code of it. contains
>>>>> all the data needed to determine the behavior of that computation, and
>>>>> thus IS in the domain of H.
>>>>>
>>>>> In fact, saying that the representation of P(P) is not in the
>>>>> domain of
>>>>> H is, by itself, enough to prove that H can not be a correct halt
>>>>> decider.
>>>>>
>>>>> You are just digging a deeper hole for yourself.
>>>>>
>>>>> You are just proving your ignorance.
>>>>>
>>>>> If H claims to be a Halt Decider, then we need to be able to ask it
>>>>> about any computation, how do we ask it about P(P).
>>>>>
>>>>> If we can't, then it isn't one.
>>>>>
>>>> But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
>>>> would in fact achieve PO's broader objectives. It wouldn't "solve the
>>>> halting problem", but it would redefine it for future workers.
>>>>
>>>
>>> Halt decider are required to decide the halt status of any finite
>>> strings that specify a sequence of configurations.
>>>
>>> Halt deciders are not required to decide that halt status of finite
>>> strings of English poems nor are they required to compute the halt
>>> status of anything that is not an input finite string.
>>>
>>> For example H is not required to compute the halt status of the
>>> behavior that a person imagines that P(P) has. H(P,P) is only
>>> required to compute the halt state that its input actually specifies.
>>>
>>>> However the question is how to do this in an interesting way. As Ben
>>>> says,
>>>> a lot of students, when introduced to this material, say "why not
>>>> detect
>>>> the H_Hat(H_Hat) pattern and special case it?". It's a natural
>>>> reaction.
>>>> But when you think about it a bit more deeply, you'll see that this
>>>> strategy
>>>> doesn't work.
>>>>
>>>
>>> It does work when H is defined to recognize the whole infinite
>>> recursion pattern. I threw in infinite loops for good measure.
>>>
>>
>> Except there is no such universal correct pattern.
>>
>
> H correctly recognizes the only infinite recursion pattern that it needs
> to recognize and that is this one:
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own x86 source and
> its input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem

Except that the pattern isn't correct, as H says P(P) is non-halting
when in fact it is haltimg.

You mind has apparently imploded as it doesn't recognize this error.

>
>
>> This is shown by the fact that H(P.P) says Non-Halting when P(P)
>> Halts, showing that H was wrong.
>
> The correct x86 emulation of the input to H(P,P) conclusively proves
> that it DOES NOT HALT.

DEFINE CORRECT, since by the normal definition of a correct simulation
of that input, one that you have even posted yourself, it shows that it
does halt.

>
> The correct x86 emulation of the input to H1(P,P) conclusively proves
> that it HALTS.

Yes, and since it is the same input, that shows that H's simulation,
which was aborted before it reached its end, was not correct.

>
> When you disagree with this it is just like you are disagreeing with
> arithmetic.
>
>

What, that counting to ten by going 1, 2, 3, 4, 5 ABORT, isn't a correct
counting to 10?

You seem to think it is.

You don't seem to have a proper definition of correct, which isn't
surprising as you don't know what Truth is, and they are tied together.

On 5/27/2022 1:45 PM, André G. Isaak wrote:
> On 2022-05-27 12:37, Andy Walker wrote:
>> On 27/05/2022 18:57, André G. Isaak wrote:
>>> The (positive) square root function you talk about maps real numbers
>>> (not scrambled eggs and not finite strings) to real numbers (again,
>>> not finite string). Unlike the prime() function, however, the
>>> positive square root function is NOT computable.
>>
>>      Um.  This is technically true, but [IMO] misleading.  The reason
>> for the failure is that most [indeed, almost all] real numbers are not
>> computable.  But non-computable reals are of [almost] no interest for
>> practical applied maths and theoretical physics, and are the sorts of
>> object that give maths a bad name in the outside world.  If "x" is a
>> computable positive real, then "sqrt(x)" is also a computable real [eg
>> by using Newton-Raphson], which is all you really have any right to
>> expect.  If you can't compute "x", then what does it even mean to talk
>> about its "sqrt"?
>
> All I was really trying to get Olcott to see was a case where it really
> *isn't* possible to encode all elements of the domain or codomain as
> finite strings, which is rather different from his strange claim that
> computations like P(P) cannot be encoded as finite strings.
>

Computations like P(P) can be encoded as finite string inputs to H1,
they cannot be encoded as finite string inputs to H simply because the
behavior specified by the correctly emulated input to H(P,P) is entirely
different behavior than the correctly emulated input to H1(P,P).

We don't even need to understand why this is the case we only need to
understand that it is a verified fact.

> (And Newton-Raphson doesn't allow you to compute square roots; it allows
> you to compute arbitrarily precise approximations of those roots).
>
> André
>

--
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-27 12:59, olcott wrote:
> On 5/27/2022 1:45 PM, André G. Isaak wrote:
>> On 2022-05-27 12:37, Andy Walker wrote:
>>> On 27/05/2022 18:57, André G. Isaak wrote:
>>>> The (positive) square root function you talk about maps real numbers
>>>> (not scrambled eggs and not finite strings) to real numbers (again,
>>>> not finite string). Unlike the prime() function, however, the
>>>> positive square root function is NOT computable.
>>>
>>>      Um.  This is technically true, but [IMO] misleading.  The reason
>>> for the failure is that most [indeed, almost all] real numbers are not
>>> computable.  But non-computable reals are of [almost] no interest for
>>> practical applied maths and theoretical physics, and are the sorts of
>>> object that give maths a bad name in the outside world.  If "x" is a
>>> computable positive real, then "sqrt(x)" is also a computable real [eg
>>> by using Newton-Raphson], which is all you really have any right to
>>> expect.  If you can't compute "x", then what does it even mean to talk
>>> about its "sqrt"?
>>
>> All I was really trying to get Olcott to see was a case where it
>> really *isn't* possible to encode all elements of the domain or
>> codomain as finite strings, which is rather different from his strange
>> claim that computations like P(P) cannot be encoded as finite strings.
>>
>
> Computations like P(P) can be encoded as finite string inputs to H1,
> they cannot be encoded as finite string inputs to H simply because the
> behavior specified by the correctly emulated input to H(P,P) is entirely
> different behavior than the correctly emulated input to H1(P,P).

Either something is encodable as a finite string or it isn't.

In much the same way, a particular integer is either encodable as a
16-bit twos complement number or it isn't. You won't find an integer
which can be encoded as as 16-bit twos complement number for one C
function but not for some other C function.

André

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

On 5/27/2022 2:18 PM, André G. Isaak wrote:
> On 2022-05-27 12:59, olcott wrote:
>> On 5/27/2022 1:45 PM, André G. Isaak wrote:
>>> On 2022-05-27 12:37, Andy Walker wrote:
>>>> On 27/05/2022 18:57, André G. Isaak wrote:
>>>>> The (positive) square root function you talk about maps real numbers
>>>>> (not scrambled eggs and not finite strings) to real numbers (again,
>>>>> not finite string). Unlike the prime() function, however, the
>>>>> positive square root function is NOT computable.
>>>>
>>>>      Um.  This is technically true, but [IMO] misleading.  The reason
>>>> for the failure is that most [indeed, almost all] real numbers are not
>>>> computable.  But non-computable reals are of [almost] no interest for
>>>> practical applied maths and theoretical physics, and are the sorts of
>>>> object that give maths a bad name in the outside world.  If "x" is a
>>>> computable positive real, then "sqrt(x)" is also a computable real [eg
>>>> by using Newton-Raphson], which is all you really have any right to
>>>> expect.  If you can't compute "x", then what does it even mean to talk
>>>> about its "sqrt"?
>>>
>>> All I was really trying to get Olcott to see was a case where it
>>> really *isn't* possible to encode all elements of the domain or
>>> codomain as finite strings, which is rather different from his
>>> strange claim that computations like P(P) cannot be encoded as finite
>>> strings.
>>>
>>
>> Computations like P(P) can be encoded as finite string inputs to H1,
>> they cannot be encoded as finite string inputs to H simply because the
>> behavior specified by the correctly emulated input to H(P,P) is
>> entirely different behavior than the correctly emulated input to H1(P,P).
>
> Either something is encodable as a finite string or it isn't.

I just proved otherwise. This is a very rare exeception and only occurs
when H/P have a pathological self-reference (Olcott 2004) relationship
and H1/P does not.

>
> In much the same way, a particular integer is either encodable as a
> 16-bit twos complement number or it isn't. You won't find an integer
> which can be encoded as as 16-bit twos complement number for one C
> function but not for some other C function.
>
> André
>

--
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/27/22 2:59 PM, olcott wrote:
> On 5/27/2022 1:45 PM, André G. Isaak wrote:
>> On 2022-05-27 12:37, Andy Walker wrote:
>>> On 27/05/2022 18:57, André G. Isaak wrote:
>>>> The (positive) square root function you talk about maps real numbers
>>>> (not scrambled eggs and not finite strings) to real numbers (again,
>>>> not finite string). Unlike the prime() function, however, the
>>>> positive square root function is NOT computable.
>>>
>>>      Um.  This is technically true, but [IMO] misleading.  The reason
>>> for the failure is that most [indeed, almost all] real numbers are not
>>> computable.  But non-computable reals are of [almost] no interest for
>>> practical applied maths and theoretical physics, and are the sorts of
>>> object that give maths a bad name in the outside world.  If "x" is a
>>> computable positive real, then "sqrt(x)" is also a computable real [eg
>>> by using Newton-Raphson], which is all you really have any right to
>>> expect.  If you can't compute "x", then what does it even mean to talk
>>> about its "sqrt"?
>>
>> All I was really trying to get Olcott to see was a case where it
>> really *isn't* possible to encode all elements of the domain or
>> codomain as finite strings, which is rather different from his strange
>> claim that computations like P(P) cannot be encoded as finite strings.
>>
>
> Computations like P(P) can be encoded as finite string inputs to H1,
> they cannot be encoded as finite string inputs to H simply because the
> behavior specified by the correctly emulated input to H(P,P) is entirely
> different behavior than the correctly emulated input to H1(P,P).
>
> We don't even need to understand why this is the case we only need to
> understand that it is a verified fact.
>
>

If P(P) can't be encoded to give to H, then H fails to be a (Universal)
Halt Decider from the begining, and can't be a counter example.

FAIL.

Just shows you still don't even understand what the problem is asking for.

>> (And Newton-Raphson doesn't allow you to compute square roots; it
>> allows you to compute arbitrarily precise approximations of those roots).
>>
>> André
>>
>
>

On 5/27/2022 2:46 PM, Richard Damon wrote:
> On 5/27/22 2:59 PM, olcott wrote:
>> On 5/27/2022 1:45 PM, André G. Isaak wrote:
>>> On 2022-05-27 12:37, Andy Walker wrote:
>>>> On 27/05/2022 18:57, André G. Isaak wrote:
>>>>> The (positive) square root function you talk about maps real numbers
>>>>> (not scrambled eggs and not finite strings) to real numbers (again,
>>>>> not finite string). Unlike the prime() function, however, the
>>>>> positive square root function is NOT computable.
>>>>
>>>>      Um.  This is technically true, but [IMO] misleading.  The reason
>>>> for the failure is that most [indeed, almost all] real numbers are not
>>>> computable.  But non-computable reals are of [almost] no interest for
>>>> practical applied maths and theoretical physics, and are the sorts of
>>>> object that give maths a bad name in the outside world.  If "x" is a
>>>> computable positive real, then "sqrt(x)" is also a computable real [eg
>>>> by using Newton-Raphson], which is all you really have any right to
>>>> expect.  If you can't compute "x", then what does it even mean to talk
>>>> about its "sqrt"?
>>>
>>> All I was really trying to get Olcott to see was a case where it
>>> really *isn't* possible to encode all elements of the domain or
>>> codomain as finite strings, which is rather different from his
>>> strange claim that computations like P(P) cannot be encoded as finite
>>> strings.
>>>
>>
>> Computations like P(P) can be encoded as finite string inputs to H1,
>> they cannot be encoded as finite string inputs to H simply because the
>> behavior specified by the correctly emulated input to H(P,P) is
>> entirely different behavior than the correctly emulated input to H1(P,P).
>>
>> We don't even need to understand why this is the case we only need to
>> understand that it is a verified fact.
>>
>>
>
> If P(P) can't be encoded to give to H, then H fails to be a (Universal)
> Halt Decider from the begining, and can't be a counter example.
>

Not at all. Halt deciders have sequences of configurations encoded as
finite strings as the domain of their computable function.

Halt deciders (like people) cannot possibly answer questions that have
not been asked. As long as they can answer every question that can be
asked then they are universal.

> FAIL.
>
> Just shows you still don't even understand what the problem is asking for.
>
>>> (And Newton-Raphson doesn't allow you to compute square roots; it
>>> allows you to compute arbitrarily precise approximations of those
>>> roots).
>>>
>>> André
>>>
>>
>>
>

--
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/27/22 3:58 PM, olcott wrote:
> On 5/27/2022 2:46 PM, Richard Damon wrote:
>> On 5/27/22 2:59 PM, olcott wrote:
>>> On 5/27/2022 1:45 PM, André G. Isaak wrote:
>>>> On 2022-05-27 12:37, Andy Walker wrote:
>>>>> On 27/05/2022 18:57, André G. Isaak wrote:
>>>>>> The (positive) square root function you talk about maps real numbers
>>>>>> (not scrambled eggs and not finite strings) to real numbers (again,
>>>>>> not finite string). Unlike the prime() function, however, the
>>>>>> positive square root function is NOT computable.
>>>>>
>>>>>      Um.  This is technically true, but [IMO] misleading.  The reason
>>>>> for the failure is that most [indeed, almost all] real numbers are not
>>>>> computable.  But non-computable reals are of [almost] no interest for
>>>>> practical applied maths and theoretical physics, and are the sorts of
>>>>> object that give maths a bad name in the outside world.  If "x" is a
>>>>> computable positive real, then "sqrt(x)" is also a computable real [eg
>>>>> by using Newton-Raphson], which is all you really have any right to
>>>>> expect.  If you can't compute "x", then what does it even mean to talk
>>>>> about its "sqrt"?
>>>>
>>>> All I was really trying to get Olcott to see was a case where it
>>>> really *isn't* possible to encode all elements of the domain or
>>>> codomain as finite strings, which is rather different from his
>>>> strange claim that computations like P(P) cannot be encoded as
>>>> finite strings.
>>>>
>>>
>>> Computations like P(P) can be encoded as finite string inputs to H1,
>>> they cannot be encoded as finite string inputs to H simply because
>>> the behavior specified by the correctly emulated input to H(P,P) is
>>> entirely different behavior than the correctly emulated input to
>>> H1(P,P).
>>>
>>> We don't even need to understand why this is the case we only need to
>>> understand that it is a verified fact.
>>>
>>>
>>
>> If P(P) can't be encoded to give to H, then H fails to be a
>> (Universal) Halt Decider from the begining, and can't be a counter
>> example.
>>
>
> Not at all. Halt deciders have sequences of configurations encoded as
> finite strings as the domain of their computable function.
>
> Halt deciders (like people) cannot possibly answer questions that have
> not been asked. As long as they can answer every question that can be
> asked then they are universal.

Nope, you don't understand what the word mean.

First, the "Question" is asked by giving the decider an
description/encoding of the machine/algorithm + the input to that.

The decider then generates the sequence of configurations, which if the
sequence of configurations the DECIDER generates isn't finite, means it
failed to be a decider and answer in finite time.

To be universal, H need to be able to be asked about ALL machines and
ALL inputs to those machines.

You definition is like the smart alec who says they know EVERY language
in the world except Greek, and when you ask them to translate something,
they just say "Thats Greek to Me".

You H just fails,, as does your argument, as do YOU.

>
>> FAIL.
>>
>> Just shows you still don't even understand what the problem is asking
>> for.
>>
>>>> (And Newton-Raphson doesn't allow you to compute square roots; it
>>>> allows you to compute arbitrarily precise approximations of those
>>>> roots).
>>>>
>>>> André
>>>>
>>>
>>>
>>
>
>

On 2022-05-27 13:58, olcott wrote:
> On 5/27/2022 2:46 PM, Richard Damon wrote:
>> On 5/27/22 2:59 PM, olcott wrote:
>>> On 5/27/2022 1:45 PM, André G. Isaak wrote:
>>>> On 2022-05-27 12:37, Andy Walker wrote:
>>>>> On 27/05/2022 18:57, André G. Isaak wrote:
>>>>>> The (positive) square root function you talk about maps real numbers
>>>>>> (not scrambled eggs and not finite strings) to real numbers (again,
>>>>>> not finite string). Unlike the prime() function, however, the
>>>>>> positive square root function is NOT computable.
>>>>>
>>>>>      Um.  This is technically true, but [IMO] misleading.  The reason
>>>>> for the failure is that most [indeed, almost all] real numbers are not
>>>>> computable.  But non-computable reals are of [almost] no interest for
>>>>> practical applied maths and theoretical physics, and are the sorts of
>>>>> object that give maths a bad name in the outside world.  If "x" is a
>>>>> computable positive real, then "sqrt(x)" is also a computable real [eg
>>>>> by using Newton-Raphson], which is all you really have any right to
>>>>> expect.  If you can't compute "x", then what does it even mean to talk
>>>>> about its "sqrt"?
>>>>
>>>> All I was really trying to get Olcott to see was a case where it
>>>> really *isn't* possible to encode all elements of the domain or
>>>> codomain as finite strings, which is rather different from his
>>>> strange claim that computations like P(P) cannot be encoded as
>>>> finite strings.
>>>>
>>>
>>> Computations like P(P) can be encoded as finite string inputs to H1,
>>> they cannot be encoded as finite string inputs to H simply because
>>> the behavior specified by the correctly emulated input to H(P,P) is
>>> entirely different behavior than the correctly emulated input to
>>> H1(P,P).
>>>
>>> We don't even need to understand why this is the case we only need to
>>> understand that it is a verified fact.
>>>
>>>
>>
>> If P(P) can't be encoded to give to H, then H fails to be a
>> (Universal) Halt Decider from the begining, and can't be a counter
>> example.
>>
>
> Not at all. Halt deciders have sequences of configurations encoded as
> finite strings as the domain of their computable function.

This is an entirely mangled sentence. You really need to go back to the
basics:

First, a Turing Machine is *NOT* a computable function.

Second, A function (computable or otherwise) is NOT a Turing Machine.

Third, the domain of a computable function is NOT the same thing as the
input (or set of possible inputs) to a Turing Machine.

Until you actually get clear in your head the difference between a
Turing Machine and a computable function and how the two are related,
you really have no business make any claims whatsoever about the halting
problem. Once you get that distinction straight we can move on to:

Fourth, the input to a halt decider is NOT a 'sequence of configurations
encoded as finite strings'

André

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