olcott <polcott2@gmail.com> writes:

> On 5/5/2022 8:21 PM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 5/5/2022 3:00 PM, Ben wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>>
>>>>> On 5/5/2022 4:19 AM, Mikko wrote:
>>>>
>>>>>> There is no category error in the theorem. An infinitely recursive
>>>>>> computation is still in the category of computations.
>>>>>
>>>>> Not according to Linz. Linz says that all computations must halt.
>>>>
>>>> That's a gem! I'm keeping that one!
>>>
>>> He does say that.
>> <sigh>
>> Something does not become a "category error" because people use terms in
>> different ways. What matters is the category not the name of the
>> category.
>
> According to Linz:
> If a sequence of configurations never halts then it is not a
> computation.

It was funny when it seemed like you were saying this in an attempt to
show that Mikko was wrong, but maybe you were just offering it up as a
random fact... The term is used differently in different contexts (you
even asked me to define it once and you claimed to like my definition).

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

On Thursday, May 5, 2022 at 10:34:02 PM UTC-4, olcott wrote:
> On 5/5/2022 9:18 PM, Dennis Bush wrote:
> > On Thursday, May 5, 2022 at 10:08:31 PM UTC-4, olcott wrote:
> >> On 5/5/2022 8:59 PM, Dennis Bush wrote:
> >>> On Thursday, May 5, 2022 at 9:36:41 PM UTC-4, olcott wrote:
> >>>> On 5/5/2022 8:17 PM, Dennis Bush wrote:
> >>>>> On Thursday, May 5, 2022 at 9:06:12 PM UTC-4, olcott wrote:
> >>>>>> On 5/5/2022 5:42 PM, Dennis Bush wrote:
> >>>>>>> On Thursday, May 5, 2022 at 6:28:10 PM UTC-4, olcott wrote:
> >>>>>>>> On 5/5/2022 5:06 PM, Dennis Bush wrote:
> >>>>>>>>> On Thursday, May 5, 2022 at 5:47:07 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 5/5/2022 1:52 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Thursday, May 5, 2022 at 2:39:16 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 5/5/2022 12:28 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 5/5/2022 7:27 AM, Malcolm McLean wrote:
> >>>>>>>>>>>>>>> On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote:
> >>>>>>>>>>>>>>>> On 5/4/22 11:54 PM, olcott wrote:
> >>>>>>>>>>>>>>>>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely nested
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation to H.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about the halting
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation P(P) it is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) == false
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and that P(P) halts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider because deciders only compute the mapping from
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inputs to final
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> states.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /according to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some property of the inputs/
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> That par is exactly correct.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- whether the input represents, for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> That part has been the key error of everyone in that they
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> all believe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that is can represent something other than what it actually
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> there is no
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> H. At least that is a clear admission that the halting of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> function
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> calls like P(P) can not be decided because, apparently,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> passing P and P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> to H does not specify that computation, and you can't say
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> what two
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> arguments /would/ specify it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> == true if
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> be the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> honest way to move things on. If you were clear about this,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> maybe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> deciding.
> >>>>>>>>>>>>>>>>>>>>>>>>>> So you won't admit that no algorithm can do what D is
> >>>>>>>>>>>>>>>>>>>>>>>>>> specified to do?
> >>>>>>>>>>>>>>>>>>>>>>>>>> You are just going to pretend that no one cares about actual
> >>>>>>>>>>>>>>>>>>>>>>>>>> halting.
> >>>>>>>>>>>>>>>>>>>>>>>>>> I hope you see that by ignoring this point you are confirming
> >>>>>>>>>>>>>>>>>>>>>>>>>> that you
> >>>>>>>>>>>>>>>>>>>>>>>>>> know D can't exist. If you thought such a D was possible,
> >>>>>>>>>>>>>>>>>>>>>>>>>> you'd be
> >>>>>>>>>>>>>>>>>>>>>>>>>> shouting that from the roof tops since it's what everyone else
> >>>>>>>>>>>>>>>>>>>>>>>>>> says is
> >>>>>>>>>>>>>>>>>>>>>>>>>> impossible.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I adapted my system so that I could empirically test this:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the
> >>>>>>>>>>>>>>>>>>>>>>>>>> thing
> >>>>>>>>>>>>>>>>>>>>>>>>>> that H was originally supposed to decide.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Are you simply wired to ignore my words so that you can
> >>>>>>>>>>>>>>>>>>>>>>>>> disagree with
> >>>>>>>>>>>>>>>>>>>>>>>>> everything that I say?
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
> >>>>>>>>>>>>>>>>>>>>>>>> decide all halting instances between them:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> bool H1(X, Y) { return true; }
> >>>>>>>>>>>>>>>>>>>>>>>> bool H2(X, Y) { return false; }
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat,
> >>>>>>>>>>>>>>>>>>>>>>>> H1_hat) or
> >>>>>>>>>>>>>>>>>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call
> >>>>>>>>>>>>>>>>>>>>>>>> H_hat.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
> >>>>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> If that is so then H and H1 don't perform the same mapping. This
> >>>>>>>>>>>>>>>>>>>>>> means that one (or both) do not compute the halting function.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> So which one doesn't compute the halting function?
> >>>>>>>>>>>>>>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> >>>>>>>>>>>>>>>>>>>>> Both take the machine code of P as input parameters and are provably
> >>>>>>>>>>>>>>>>>>>>> correct simulations of this same input yet one correctly determines
> >>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>> its input halts and the other correctly determines that its input does
> >>>>>>>>>>>>>>>>>>>>> not halt.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Which means at least one is not computing the halting function. So
> >>>>>>>>>>>>>>>>>>>> which one is it?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The above paragraph means that it makes no mistakes in computing the
> >>>>>>>>>>>>>>>>>>> halting function. This is a verifiable fact, not any mere opinion. The
> >>>>>>>>>>>>>>>>>>> reason that I did the HP in C/x86 was so that every detail can be shown
> >>>>>>>>>>>>>>>>>>> thus gaps in reasoning revealed.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Any decider that maps the halting function performs the *same* mapping
> >>>>>>>>>>>>>>>>>> of inputs to outputs.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> That is now proven to be factually incorrect.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If the above paragraph is proven to be a fact then this proves that both
> >>>>>>>>>>>>>>>>> H and H1 compute the halting function correctly. The above paragraph can
> >>>>>>>>>>>>>>>>> be proven to be a fact.
> >>>>>>>>>>>>>>>> Yes, IF you can prove that cats are dogs, you can prove that H is
> >>>>>>>>>>>>>>>> correctly computing the Halting Function.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Since you can't, you can't.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> In fact, you have just proven that you don't know what you are talking
> >>>>>>>>>>>>>>>> about, since you just asserted a LIE.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Two machines claiming to compute the same function must generate the
> >>>>>>>>>>>>>>>> same answer from the same input or one of them is incorrect.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> BASIC FACT.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In parapsychology, there's something called "the experimenter effect". The same
> >>>>>>>>>>>>>>> experiment will show a parapsychological effect or not, depending on who is
> >>>>>>>>>>>>>>> performing the experiment. This has been described as parapsychology's one finding.
> >>>>>>>>>>>>>>> If true in an interesting way, it also strikes at the heart of the scientific method.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But intuitively, it's not implausible that an experiment would "work" for an experimenter
> >>>>>>>>>>>>>>> with gypsy blood, for example. You can't simply reject the experimenter effect on the
> >>>>>>>>>>>>>>> basis that, if it means more than that certain experimenters are more gullible than
> >>>>>>>>>>>>>>> others, it leaves the rest of science in tatters.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> PO says that a machine has one behaviour when run, and another behaviour when
> >>>>>>>>>>>>>>> "correctly simulated". That claim, if true, similarly leaves the whole of computer science
> >>>>>>>>>>>>>>> in tatters. Which means that it's his responsibility to provide a much better explanation
> >>>>>>>>>>>>>>> of what he means than he has done currently.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But he's been clear about this. He's asserting what anyone who knows just a tiny amount
> >>>>>>>>>>>>>>> about computers must consdier to be nonsense. At first glance. But the idea that
> >>>>>>>>>>>>>>> i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
> >>>>>>>>>>>>>>> difference is that more details were forthcoming.
> >>>>>>>>>>>>>> Anyone knowing the x86 language can verify that H(P,P) and H1(P,P)
> >>>>>>>>>>>>>> compute the mapping from their input parameters to their own final state
> >>>>>>>>>>>>>> correctly. Arguing with verified facts is a fools folly.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So in other words, a decider is always correct about what it's own input does.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Yes this is an easily verified fact on the basis of the execution trace
> >>>>>>>>>>>> derived from the correct simulation of its input parameters.
> >>>>>>>>>>>>> If you believe that to be true, then you also believe that anyone knowing the x86 language can verify that Ha3(N,5) correctly computes the mapping from its input to a non-halting state.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> H2(Ha3,N,5) would get the correct halt status for Ha3.
> >>>>>>>>>>>>
> >>>>>>>>>>>> From what I recall Ha3(N,5) is merely a computation that was defined to
> >>>>>>>>>>>> make sure it gets the wrong answer. If you disagree then remind me again
> >>>>>>>>>>>> what it means.
> >>>>>>>>>>>
> >>>>>>>>>>> Ha3 uses as its abort criteria any computation that proceeds for more that 3 steps.
> >>>>>>>>>> WHAT ARE YOU NUTS ???
> >>>>>>>>>>
> >>>>>>>>>> Trying to push total bullshit likes this proves that you are only a
> >>>>>>>>>> troll playing head games and an honest dialogue is the last thing on
> >>>>>>>>>> your mind.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Not at all, I'm just illustrating the flaws in your logic, as you can't show that Ha3 is wrong without also showing that H is also wrong....
> >>>>>>>>>
> >>>>>>>>>> A halt decider must simulate its input until it can prove that the
> >>>>>>>>>> simulation would never end.
> >>>>>>>>>
> >>>>>>>>> ... just like this.
> >>>>>>>>>
> >>>>>>>>> What you states above is sufficient to show that Ha3(N,5) is not correct to abort, and Ha7(N,5) simulating to a final state and reporting halting proves that Ha3 didn't simulate for long enough.
> >>>>>>>> OK finally back to an honest dialogue.
> >>>>>>>
> >>>>>>> It always was. You're apparently unable to see where I was going with this.
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>> Now let's apply that to H(P,P).
> >>>>>>>>>
> >>>>>>>>> H(P,P) is not correct to abort, and H1(P,P) simulating to a final state and reporting halting proves that H didn't simulate for long enough.
> >>>>>>>>>
> >>>>>>>>> Therefore H(P,P) == false is provable INCORRECT.
> >>>>>>>> It is easily proven on the basis of verified facts that H(P,P) and
> >>>>>>>> H1(P,P) do correctly compute the halt function for their input parameters.
> >>>>>>>
> >>>>>>> You don't seem to understand. H1 proves that H is wrong
> >>>>>> Both H(P,P) and H1(P,P) correctly compute the mapping from their input
> >>>>>> parameters to the halt status specified by these inputs.
> >>>>>
> >>>>> FALSE. Remember, you said:
> >>>>>
> >>>>> A halt decider must simulate its input until it can prove that the simulation would never end.
> >>>>>
> >>>>> Proving that the simulation would never end means that NO simulator can simulate that input to a final state.
> >>>> You continue to believe that your imagination overrules verified facts:
> >>>>
> >>>> That the correct simulation of the input to H(P,P) provably would never
> >>>> end conclusively proves that H(P,P)==false is correct.
> >>>
> >>> It is a verified fact that H(P,P) does NOT perform a correct simulation of its input.
> >> That the execution trace of the simulated input to H(P,P) exactly
> >> matches the behavior specified by its x86 source-code provides the
> >> ultimate measure of a correct simulation thus overriding and superseding
> >> any and all other measures.
> >>
> >> _P()
> >> [000009d6](01) 55 push ebp
> >> [000009d7](02) 8bec mov ebp,esp
> >> [000009d9](03) 8b4508 mov eax,[ebp+08]
> >> [000009dc](01) 50 push eax // push P
> >> [000009dd](03) 8b4d08 mov ecx,[ebp+08]
> >> [000009e0](01) 51 push ecx // push P
> >> [000009e1](05) e840feffff call 00000826 // call H
> >> [000009e6](03) 83c408 add esp,+08
> >> [000009e9](02) 85c0 test eax,eax
> >> [000009eb](02) 7402 jz 000009ef
> >> [000009ed](02) ebfe jmp 000009ed
> >> [000009ef](01) 5d pop ebp
> >> [000009f0](01) c3 ret // Final state
> >> Size in bytes:(0027) [000009f0]
> >>
> >> Begin Local Halt Decider Simulation
> >> machine stack stack machine assembly
> >> address address data code language
> >> ======== ======== ======== ========= =============
> >> ...[000009d6][00211368][0021136c] 55 push ebp // enter P
> >> ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
> >> ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
> >> ...[000009dc][00211364][000009d6] 50 push eax // Push P
> >> ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
> >> ...[000009e0][00211360][000009d6] 51 push ecx // Push P
> >> ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
> >> ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
> >> ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
> >> ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
> >> ...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
> >> ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
> >> ...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
> >> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
> >> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> >> --
> >> Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
> >> Genius hits a target no one else can see." Arthur Schopenhauer
> >
> > All this trace shows is that H aborted its input.
> This trace of the correctly simulated input to H(P,P) conclusively
> proves that when P calls the same function with the same parameters from
> the same address that H has its reject (non-halting) criteria.

On 2022-05-05 19:06, olcott wrote:

> Both H(P,P) and H1(P,P) correctly compute the mapping from their input
> parameters to the halt status specified by these inputs.

Both H(P, P) and H1(P, P) compute *a* mapping from their input to their
accept/reject state, but not the *same* mapping. Therefore they do not
compute the same function. Therefore at most one of them can be
computing the halting function.

So which one (if either) is computing the halting function?

You can't talk about something 'correctly' computing a mapping unless
you specify some criterion by which correctness is to be judged. For the
halting problem, that would be whether the mapping corresponds to the
halting function.

André

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

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

But H1 is not H, so this is just admitting that H can't do the job?

>
>> For one thing, there is only one correct answer to the halting
>> or otherwise of a computation, and for another, H(X,Y) is obviously not
>> telling the world what it wants to know -- the halting of the
>> computation X(Y).
>>
>
> Since you know that a decider (halting or otherwise) only computes the
> mapping from its inputs and that you insist that a halt decider compute
> its mapping from non inputs it is either psychosis or deception on your
> part.

You may "KNOW" that, but you don't seem to understand the actual truth
about what it is requried to do, but can't in this case.

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

Nope. At least not for the question you claim to be asking. Maybe for
the question you are actually asking, but that isn't about the actual
Halting Problem.

>
> That you keep contradicting verified facts that you already accept as
> true seems quite nuts. Halt deciders (like all deciders) compute the
> mapping from their inputs.
>
> It turns out that the halting behavior of the correct simulation of the
> input to H1(P,P) is the same as the halting behavior of P(P).

But the halting problem isn't about the "correct simulation of the
input" but about the behavior of the machine represented by the input
applied to the input represented in the input.

Since this doesn't seem to be what you consider the "correct simulation
of the input", and you refuse to actually DEFINE what you mean by that,
we can plainly see that you aren't actually talking about Halting, but
only are incorrectly (or deceitfully) claiming to be.

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

There is nothing "invalid" about the program and input that is used to
prove that H is wrong.

Given ANY claimed halt decider that you can possible design, it is
simple to create the contradictory program, so that program does exist.

It is then trivial to look at what answer that decider will give, and
show that no matter what answer it gives, it is wrong.

If it gets into an infinite recursion, all that proves is that the claim
decider was invalid, not the proof.

On 5/5/2022 9:35 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/5/2022 8:29 AM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>
>>>> H1(P,P)==true is empirically proven to be correct
>>>> H(P,P)==false is empirically proven to be correct
>>>
>>>> Both take the machine code of P as input parameters and are provably
>>>> correct simulations of this same input yet one correctly determines
>>>> that its input halts and the other correctly determines that its input
>>>> does not halt. ALL THESE THINGS ARE VERIFIED FACTS !
>>>
>>> Your mantra is doing sterling work, allowing you to pretend you are
>>> taking about the halting problem while hiding what it is that your
>>> deciders are deciding. Whatever you are hiding behind the words
>>> "correct simulations of this same input" it is obviously not the halting
>>> of P(P).
>>
>> You seem to have a short-circuit in your brain, I have told you this
>> many times and you have not seen it once.
>>
>> H1(P,P) IS THE HALT STATUS OF P(P)
>
> So what? Everyone know that there are an infinity of functions that are
> correct about the halting of P(P). It's H that's wrong, not H1.
>
> The only interesting thing about H1 is that you say it does that same as
> H but gets a different answer. Now that's a rabbit hole that other
> people might follow you down, but I don't care. You are wrong about too
> many things to be bothered about all of them.
>
> The important point is that your H is wrong because H(P,P) == false even
> though P(P) halts.
>
>>> For one thing, there is only one correct answer to the halting
>>> or otherwise of a computation, and for another, H(X,Y) is obviously not
>>> telling the world what it wants to know -- the halting of the
>>> computation X(Y).
>>
>> Since you know that a decider (halting or otherwise) only computes the
>> mapping from its inputs and that you insist that a halt decider
>> compute its mapping from non inputs it is either psychosis or
>> deception on your part.
>
> Remember all those other times you thought I was mad? Remember the last
> time? It was because you didn't know what a sequence was.
>
> Hint: every time you think I am lying or playing games or psychotic it's
> because your conviction that you can't be wrong has butted up against
> cold facts. You know, at some level of consciousness, that a C-like
> halt decider, bool D(ptr X, ptr Y);, returns true or false based on the
> halting of X(Y) as here:
>
>>> Do you have anything at all left to say about the real halting problem?
>>> I really think you should at least state, explicitly, that you now
>>> accept that no function D exists such that D(X,Y) == true if an only if
>>> X(Y) halts and false otherwise.
>
> We could make progress if you would accept that no such D can exist for
> whatever reason you choose to give -- even it's because you think X(Y)
> is a "non-input". But then there's no reason to think you will make
> such a clear statement.
>
>> H1(P,P)==true is empirically proven to be correct
>> H(P,P)==false is empirically proven to be correct
>>
>> That you keep contradicting verified facts that you already accept as
>> true seems quite nuts.
>
> H1 is irrelevant, and H is wrong by definition. Whatever H has been
> "empirically proven to be correct" about you are clear that it's not
> correct about the halting of P(P).
>
>> Halt deciders (like all deciders) compute the
>> mapping from their inputs.
>
> ... to specified true/false properties of those inputs. In the case of
> H, we want it to report on the halting or otherwise of its first
> argument when called with the second argument. Your H fails at that.
>
>> It turns out that the halting behavior of the correct simulation of
>> the input to H1(P,P) is the same as the halting behavior of P(P).
>
> And that is true of an infinity of equally irrelevant functions.
>
>> It turns out that the halting behavior of the correct simulation of
>> the input to H(P,P) is NOT the same as the halting behavior of P(P).
>
> Which is why H does not meet the specification of being a halt decider.
>
>> The ultimate measure is that H(P,P) does compute the mapping from its
>> inputs to its final reject state. This can be easily verified by
>> anyone with sufficient expertise in the x86 language.
>
> Yes, H just wrong to reject (P,P) because of how the halting problem is
> defined. No one disputes the fact that H(P,P) == false even though P(P)
> halts. The /only/ fact is dispute is the specification that H should
> meet.
>
>> I made good progress on Simplest TM interpreter yesterday. The
>> detailed design is halfway done. The trickiest part is the state
>> change function. I think that I am going to use a std::set that is
>> indexed on state + input.
>>
>> struct Quintuple
>> {
>> u32 state;
>> u32 symbol;
>> u32 write_symbol;
>> u32 next_state;
>> u8 Tape_Head_Move;
>> }
>>
>> std::set<Quintuple> States;
>
> Why is a set of objects that are not states called "States"?
>

Each TM state requires all of the information in a Quintuple thus a set
of Quintuples is a set of States.

Each Quintuple instance is a line of TM description source-code.
When the interpreter needs to transition to another Quintuple instance
it executes its transition_function().

The most complex part of this transition uses std::set::find
based on current_state->next_state and Tape[Tape_Head].

> Would you like some help with the design? Over the years I've written
> about a dozen TM interpreters in at least three languages, as well as
> having graded literally dozens of students' attempts at doing the same.
> Having a set of quintuples is of little help. It's a dead end.
>

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

On 5/5/2022 9:35 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/5/2022 8:29 AM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>
>>>> H1(P,P)==true is empirically proven to be correct
>>>> H(P,P)==false is empirically proven to be correct
>>>
>>>> Both take the machine code of P as input parameters and are provably
>>>> correct simulations of this same input yet one correctly determines
>>>> that its input halts and the other correctly determines that its input
>>>> does not halt. ALL THESE THINGS ARE VERIFIED FACTS !
>>>
>>> Your mantra is doing sterling work, allowing you to pretend you are
>>> taking about the halting problem while hiding what it is that your
>>> deciders are deciding. Whatever you are hiding behind the words
>>> "correct simulations of this same input" it is obviously not the halting
>>> of P(P).
>>
>> You seem to have a short-circuit in your brain, I have told you this
>> many times and you have not seen it once.
>>
>> H1(P,P) IS THE HALT STATUS OF P(P)
>
> So what? Everyone know that there are an infinity of functions that are
> correct about the halting of P(P). It's H that's wrong, not H1.
>
> The only interesting thing about H1 is that you say it does that same as
> H but gets a different answer. Now that's a rabbit hole that other
> people might follow you down, but I don't care. You are wrong about too
> many things to be bothered about all of them.
>
> The important point is that your H is wrong because H(P,P) == false even
> though P(P) halts.
>
>>> For one thing, there is only one correct answer to the halting
>>> or otherwise of a computation, and for another, H(X,Y) is obviously not
>>> telling the world what it wants to know -- the halting of the
>>> computation X(Y).
>>
>> Since you know that a decider (halting or otherwise) only computes the
>> mapping from its inputs and that you insist that a halt decider
>> compute its mapping from non inputs it is either psychosis or
>> deception on your part.
>
> Remember all those other times you thought I was mad? Remember the last
> time? It was because you didn't know what a sequence was.
>
> Hint: every time you think I am lying or playing games or psychotic it's
> because your conviction that you can't be wrong has butted up against
> cold facts. You know, at some level of consciousness, that a C-like
> halt decider, bool D(ptr X, ptr Y);, returns true or false based on the
> halting of X(Y) as here:
>
>>> Do you have anything at all left to say about the real halting problem?
>>> I really think you should at least state, explicitly, that you now
>>> accept that no function D exists such that D(X,Y) == true if an only if
>>> X(Y) halts and false otherwise.
>
> We could make progress if you would accept that no such D can exist for
> whatever reason you choose to give -- even it's because you think X(Y)
> is a "non-input". But then there's no reason to think you will make
> such a clear statement.
>
>> H1(P,P)==true is empirically proven to be correct
>> H(P,P)==false is empirically proven to be correct
>>
>> That you keep contradicting verified facts that you already accept as
>> true seems quite nuts.
>
> H1 is irrelevant, and H is wrong by definition. Whatever H has been
> "empirically proven to be correct" about you are clear that it's not
> correct about the halting of P(P).
>
>> Halt deciders (like all deciders) compute the
>> mapping from their inputs.
>
> ... to specified true/false properties of those inputs. In the case of
> H, we want it to report on the halting or otherwise of its first
> argument when called with the second argument. Your H fails at that.
>
>> It turns out that the halting behavior of the correct simulation of
>> the input to H1(P,P) is the same as the halting behavior of P(P).
>
> And that is true of an infinity of equally irrelevant functions.
>
>> It turns out that the halting behavior of the correct simulation of
>> the input to H(P,P) is NOT the same as the halting behavior of P(P).
>
> Which is why H does not meet the specification of being a halt decider.
>
>> The ultimate measure is that H(P,P) does compute the mapping from its
>> inputs to its final reject state. This can be easily verified by
>> anyone with sufficient expertise in the x86 language.
>
> Yes, H just wrong to reject (P,P) because of how the halting problem is
> defined. No one disputes the fact that H(P,P) == false even though P(P)
> halts. The /only/ fact is dispute is the specification that H should
> meet.
>
>> I made good progress on Simplest TM interpreter yesterday. The
>> detailed design is halfway done. The trickiest part is the state
>> change function. I think that I am going to use a std::set that is
>> indexed on state + input.
>>
>> struct Quintuple
>> {
>> u32 state;
>> u32 symbol;
>> u32 write_symbol;
>> u32 next_state;
>> u8 Tape_Head_Move;
>> }
>>
>> std::set<Quintuple> States;
>
> Why is a set of objects that are not states called "States"?

They are states, what did you think that states are?

This is the first draft of my transition_function() its seems to exactly
match this design on the first page of the docs.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt

I am writing this in Open Office Writer not any compiler.
I don't even know that it compiles.

This is going to be a member function.
bool transition_function(std::set<Quintuple>::iterator& current_state)
{ u32 next_state = current_state->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;

Tape[Tape_Head] = current_state->write_symbol;
if (toupper(current_state->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right

it = NextState(current_input, next_state);
if (it == States.end())
return false;
current_state = it;
return true;
}

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

On 5/5/2022 9:35 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/5/2022 8:29 AM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>
>>>> H1(P,P)==true is empirically proven to be correct
>>>> H(P,P)==false is empirically proven to be correct
>>>
>>>> Both take the machine code of P as input parameters and are provably
>>>> correct simulations of this same input yet one correctly determines
>>>> that its input halts and the other correctly determines that its input
>>>> does not halt. ALL THESE THINGS ARE VERIFIED FACTS !
>>>
>>> Your mantra is doing sterling work, allowing you to pretend you are
>>> taking about the halting problem while hiding what it is that your
>>> deciders are deciding. Whatever you are hiding behind the words
>>> "correct simulations of this same input" it is obviously not the halting
>>> of P(P).
>>
>> You seem to have a short-circuit in your brain, I have told you this
>> many times and you have not seen it once.
>>
>> H1(P,P) IS THE HALT STATUS OF P(P)
>
> So what? Everyone know that there are an infinity of functions that are
> correct about the halting of P(P). It's H that's wrong, not H1.
>
> The only interesting thing about H1 is that you say it does that same as
> H but gets a different answer. Now that's a rabbit hole that other
> people might follow you down, but I don't care. You are wrong about too
> many things to be bothered about all of them.
>
> The important point is that your H is wrong because H(P,P) == false even
> though P(P) halts.
>
>>> For one thing, there is only one correct answer to the halting
>>> or otherwise of a computation, and for another, H(X,Y) is obviously not
>>> telling the world what it wants to know -- the halting of the
>>> computation X(Y).
>>
>> Since you know that a decider (halting or otherwise) only computes the
>> mapping from its inputs and that you insist that a halt decider
>> compute its mapping from non inputs it is either psychosis or
>> deception on your part.
>
> Remember all those other times you thought I was mad? Remember the last
> time? It was because you didn't know what a sequence was.
>
> Hint: every time you think I am lying or playing games or psychotic it's
> because your conviction that you can't be wrong has butted up against
> cold facts. You know, at some level of consciousness, that a C-like
> halt decider, bool D(ptr X, ptr Y);, returns true or false based on the
> halting of X(Y) as here:
>
>>> Do you have anything at all left to say about the real halting problem?
>>> I really think you should at least state, explicitly, that you now
>>> accept that no function D exists such that D(X,Y) == true if an only if
>>> X(Y) halts and false otherwise.
>
> We could make progress if you would accept that no such D can exist for
> whatever reason you choose to give -- even it's because you think X(Y)
> is a "non-input". But then there's no reason to think you will make
> such a clear statement.
>
>> H1(P,P)==true is empirically proven to be correct
>> H(P,P)==false is empirically proven to be correct
>>
>> That you keep contradicting verified facts that you already accept as
>> true seems quite nuts.
>
> H1 is irrelevant, and H is wrong by definition. Whatever H has been
> "empirically proven to be correct" about you are clear that it's not
> correct about the halting of P(P).
>
>> Halt deciders (like all deciders) compute the
>> mapping from their inputs.
>
> ... to specified true/false properties of those inputs. In the case of
> H, we want it to report on the halting or otherwise of its first
> argument when called with the second argument. Your H fails at that.
>
>> It turns out that the halting behavior of the correct simulation of
>> the input to H1(P,P) is the same as the halting behavior of P(P).
>
> And that is true of an infinity of equally irrelevant functions.
>
>> It turns out that the halting behavior of the correct simulation of
>> the input to H(P,P) is NOT the same as the halting behavior of P(P).
>
> Which is why H does not meet the specification of being a halt decider.
>
>> The ultimate measure is that H(P,P) does compute the mapping from its
>> inputs to its final reject state. This can be easily verified by
>> anyone with sufficient expertise in the x86 language.
>
> Yes, H just wrong to reject (P,P) because of how the halting problem is
> defined. No one disputes the fact that H(P,P) == false even though P(P)
> halts. The /only/ fact is dispute is the specification that H should
> meet.
>
>> I made good progress on Simplest TM interpreter yesterday. The
>> detailed design is halfway done. The trickiest part is the state
>> change function. I think that I am going to use a std::set that is
>> indexed on state + input.
>>
>> struct Quintuple
>> {
>> u32 state;
>> u32 symbol;
>> u32 write_symbol;
>> u32 next_state;
>> u8 Tape_Head_Move;
>> }
>>
>> std::set<Quintuple> States;
>
> Why is a set of objects that are not states called "States"?
>

They are states, what did you think that states are?

> Would you like some help with the design? Over the years I've written
> about a dozen TM interpreters in at least three languages, as well as
> having graded literally dozens of students' attempts at doing the same.
> Having a set of quintuples is of little help. It's a dead end.
>

This is the first draft of my transition_function() its seems to exactly
match this design (page 1 of the docs)

A Turing machine program consists of a list of 'quintuples', each one of
which is a five-symbol Turing machine instruction.

For example, the quintuple 'SCcsm' is executed by the machine
(a) if it is in state 'S'
(b) is reading the symbol 'C' on the tape.
(c) make a transition to state 's'
(d) overwrite the symbol 'C' on the tape with the symbol 'c'.
(e) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.

http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt

This is going to be a member function.
bool transition_function(std::set<Quintuple>::iterator& current_state)
{ u32 next_state = current_state->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;

Tape[Tape_Head] = current_state->write_symbol;
if (toupper(current_state->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right

it = NextState(current_input, next_state);
if (it == States.end())
return false;
current_state = it;
return true;
}

--
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-05 22:48, olcott wrote:
> On 5/5/2022 9:35 PM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> I made good progress on Simplest TM interpreter yesterday. The
>>> detailed design is halfway done.  The trickiest part is the state
>>> change function.  I think that I am going to use a std::set that is
>>> indexed on state + input.
>>>
>>> struct Quintuple
>>> {
>>>    u32 state;
>>>    u32 symbol;
>>>    u32 write_symbol;
>>>    u32 next_state;
>>>     u8 Tape_Head_Move;
>>> }
>>>
>>> std::set<Quintuple> States;
>>
>> Why is a set of objects that are not states called "States"?
>>
>
> They are states, what did you think that states are?

States are states. Quintuples are quintuples. They're not the same
thing. In a C implementation, a state is simply going to be an integer,
not some sort of struct.

André

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

On 5/6/2022 12:01 AM, André G. Isaak wrote:
> On 2022-05-05 22:48, olcott wrote:
>> On 5/5/2022 9:35 PM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>> detailed design is halfway done.  The trickiest part is the state
>>>> change function.  I think that I am going to use a std::set that is
>>>> indexed on state + input.
>>>>
>>>> struct Quintuple
>>>> {
>>>>    u32 state;
>>>>    u32 symbol;
>>>>    u32 write_symbol;
>>>>    u32 next_state;
>>>>     u8 Tape_Head_Move;
>>>> }
>>>>
>>>> std::set<Quintuple> States;
>>>
>>> Why is a set of objects that are not states called "States"?
>>>
>>
>> They are states, what did you think that states are?
>
> States are states. Quintuples are quintuples. They're not the same
> thing. In a C implementation, a state is simply going to be an integer,
> not some sort of struct.
>
> André
>
>

So then you don't disagree that my implementation of the TM transition
function matches its corresponding design?

This is the first draft of my transition_function() its seems to exactly
match this design (page 1 of the docs)
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt

A Turing machine program consists of a list of 'quintuples', each one of
which is a five-symbol Turing machine instruction.

For example, the quintuple 'SCcsm' is executed by the machine
(a) if it is in state 'S'
(b) is reading the symbol 'C' on the tape.
(c) make a transition to state 's'
(d) overwrite the symbol 'C' on the tape with the symbol 'c'.
(e) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.

This is going to be a member function.
bool transition_function(std::set<Quintuple>::iterator& current_state)
{ u32 next_state = current_state->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;

Tape[Tape_Head] = current_state->write_symbol;
if (toupper(current_state->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right

it = NextState(current_input, next_state);
if (it == States.end())
return false;
current_state = it;
return true;
}

--
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/6/2022 12:01 AM, André G. Isaak wrote:
> On 2022-05-05 22:48, olcott wrote:
>> On 5/5/2022 9:35 PM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>> detailed design is halfway done.  The trickiest part is the state
>>>> change function.  I think that I am going to use a std::set that is
>>>> indexed on state + input.
>>>>
>>>> struct Quintuple
>>>> {
>>>>    u32 state;
>>>>    u32 symbol;
>>>>    u32 write_symbol;
>>>>    u32 next_state;
>>>>     u8 Tape_Head_Move;
>>>> }
>>>>
>>>> std::set<Quintuple> States;
>>>
>>> Why is a set of objects that are not states called "States"?
>>>
>>
>> They are states, what did you think that states are?
>
> States are states. Quintuples are quintuples. They're not the same
> thing. In a C implementation, a state is simply going to be an integer,
> not some sort of struct.
>
> André

In Lex the lexical analyzer "states" all of the actions are considered
to be a part of the state.

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

On 5/5/2022 9:50 PM, Dennis Bush wrote:
> On Thursday, May 5, 2022 at 10:34:02 PM UTC-4, olcott wrote:
>> On 5/5/2022 9:18 PM, Dennis Bush wrote:
>>> On Thursday, May 5, 2022 at 10:08:31 PM UTC-4, olcott wrote:
>>>> On 5/5/2022 8:59 PM, Dennis Bush wrote:
>>>>> On Thursday, May 5, 2022 at 9:36:41 PM UTC-4, olcott wrote:
>>>>>> On 5/5/2022 8:17 PM, Dennis Bush wrote:
>>>>>>> On Thursday, May 5, 2022 at 9:06:12 PM UTC-4, olcott wrote:
>>>>>>>> On 5/5/2022 5:42 PM, Dennis Bush wrote:
>>>>>>>>> On Thursday, May 5, 2022 at 6:28:10 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/5/2022 5:06 PM, Dennis Bush wrote:
>>>>>>>>>>> On Thursday, May 5, 2022 at 5:47:07 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/5/2022 1:52 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Thursday, May 5, 2022 at 2:39:16 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/5/2022 12:28 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 5/5/2022 7:27 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>>>>> On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote:
>>>>>>>>>>>>>>>>>> On 5/4/22 11:54 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P) specifies
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely nested
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation to H.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about the halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation P(P) it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) == false
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H can report on the halting of non-input P(P) then it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider because deciders only compute the mapping from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inputs to final
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> states.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM deciders compute mappings from inputs to final states
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /according to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some property of the inputs/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That par is exactly correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- whether the input represents, for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That part has been the key error of everyone in that they
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all believe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that is can represent something other than what it actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So now, after thinking otherwise for years, you claim that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there is no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way to even specify the computation P(P) for you pseudo-C
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H. At least that is a clear admission that the halting of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calls like P(P) can not be decided because, apparently,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> passing P and P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to H does not specify that computation, and you can't say
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what two
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> arguments /would/ specify it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A clear and unambiguous statement that no D such that D(X,Y)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> == true if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and only if X(Y) halts and false otherwise is possible would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> honest way to move things on. If you were clear about this,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> someone will talk to you about [whatever] it is that your H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deciding.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you won't admit that no algorithm can do what D is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified to do?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You are just going to pretend that no one cares about actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>> halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I hope you see that by ignoring this point you are confirming
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that you
>>>>>>>>>>>>>>>>>>>>>>>>>>>> know D can't exist. If you thought such a D was possible,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> you'd be
>>>>>>>>>>>>>>>>>>>>>>>>>>>> shouting that from the roof tops since it's what everyone else
>>>>>>>>>>>>>>>>>>>>>>>>>>>> says is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> impossible.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I adapted my system so that I could empirically test this:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> But neither can tell us squat about the halting of P(P) -- the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that H was originally supposed to decide.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Are you simply wired to ignore my words so that you can
>>>>>>>>>>>>>>>>>>>>>>>>>>> disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>> everything that I say?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I try to ignore that bits that are irrelevant. These two deciders
>>>>>>>>>>>>>>>>>>>>>>>>>> decide all halting instances between them:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> bool H1(X, Y) { return true; }
>>>>>>>>>>>>>>>>>>>>>>>>>> bool H2(X, Y) { return false; }
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Neither is interesting. For H1, the key case is H1(H1_hat,
>>>>>>>>>>>>>>>>>>>>>>>>>> H1_hat) or
>>>>>>>>>>>>>>>>>>>>>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call
>>>>>>>>>>>>>>>>>>>>>>>>>> H_hat.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If that is so then H and H1 don't perform the same mapping. This
>>>>>>>>>>>>>>>>>>>>>>>> means that one (or both) do not compute the halting function.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> So which one doesn't compute the halting function?
>>>>>>>>>>>>>>>>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>>>>>>>>>>>>>>>>>>>> Both take the machine code of P as input parameters and are provably
>>>>>>>>>>>>>>>>>>>>>>> correct simulations of this same input yet one correctly determines
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> its input halts and the other correctly determines that its input does
>>>>>>>>>>>>>>>>>>>>>>> not halt.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Which means at least one is not computing the halting function. So
>>>>>>>>>>>>>>>>>>>>>> which one is it?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The above paragraph means that it makes no mistakes in computing the
>>>>>>>>>>>>>>>>>>>>> halting function. This is a verifiable fact, not any mere opinion. The
>>>>>>>>>>>>>>>>>>>>> reason that I did the HP in C/x86 was so that every detail can be shown
>>>>>>>>>>>>>>>>>>>>> thus gaps in reasoning revealed.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any decider that maps the halting function performs the *same* mapping
>>>>>>>>>>>>>>>>>>>> of inputs to outputs.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That is now proven to be factually incorrect.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If the above paragraph is proven to be a fact then this proves that both
>>>>>>>>>>>>>>>>>>> H and H1 compute the halting function correctly. The above paragraph can
>>>>>>>>>>>>>>>>>>> be proven to be a fact.
>>>>>>>>>>>>>>>>>> Yes, IF you can prove that cats are dogs, you can prove that H is
>>>>>>>>>>>>>>>>>> correctly computing the Halting Function.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Since you can't, you can't.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In fact, you have just proven that you don't know what you are talking
>>>>>>>>>>>>>>>>>> about, since you just asserted a LIE.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Two machines claiming to compute the same function must generate the
>>>>>>>>>>>>>>>>>> same answer from the same input or one of them is incorrect.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> BASIC FACT.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In parapsychology, there's something called "the experimenter effect". The same
>>>>>>>>>>>>>>>>> experiment will show a parapsychological effect or not, depending on who is
>>>>>>>>>>>>>>>>> performing the experiment. This has been described as parapsychology's one finding.
>>>>>>>>>>>>>>>>> If true in an interesting way, it also strikes at the heart of the scientific method.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But intuitively, it's not implausible that an experiment would "work" for an experimenter
>>>>>>>>>>>>>>>>> with gypsy blood, for example. You can't simply reject the experimenter effect on the
>>>>>>>>>>>>>>>>> basis that, if it means more than that certain experimenters are more gullible than
>>>>>>>>>>>>>>>>> others, it leaves the rest of science in tatters.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> PO says that a machine has one behaviour when run, and another behaviour when
>>>>>>>>>>>>>>>>> "correctly simulated". That claim, if true, similarly leaves the whole of computer science
>>>>>>>>>>>>>>>>> in tatters. Which means that it's his responsibility to provide a much better explanation
>>>>>>>>>>>>>>>>> of what he means than he has done currently.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But he's been clear about this. He's asserting what anyone who knows just a tiny amount
>>>>>>>>>>>>>>>>> about computers must consdier to be nonsense. At first glance. But the idea that
>>>>>>>>>>>>>>>>> i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
>>>>>>>>>>>>>>>>> difference is that more details were forthcoming.
>>>>>>>>>>>>>>>> Anyone knowing the x86 language can verify that H(P,P) and H1(P,P)
>>>>>>>>>>>>>>>> compute the mapping from their input parameters to their own final state
>>>>>>>>>>>>>>>> correctly. Arguing with verified facts is a fools folly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So in other words, a decider is always correct about what it's own input does.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes this is an easily verified fact on the basis of the execution trace
>>>>>>>>>>>>>> derived from the correct simulation of its input parameters.
>>>>>>>>>>>>>>> If you believe that to be true, then you also believe that anyone knowing the x86 language can verify that Ha3(N,5) correctly computes the mapping from its input to a non-halting state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H2(Ha3,N,5) would get the correct halt status for Ha3.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From what I recall Ha3(N,5) is merely a computation that was defined to
>>>>>>>>>>>>>> make sure it gets the wrong answer. If you disagree then remind me again
>>>>>>>>>>>>>> what it means.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ha3 uses as its abort criteria any computation that proceeds for more that 3 steps.
>>>>>>>>>>>> WHAT ARE YOU NUTS ???
>>>>>>>>>>>>
>>>>>>>>>>>> Trying to push total bullshit likes this proves that you are only a
>>>>>>>>>>>> troll playing head games and an honest dialogue is the last thing on
>>>>>>>>>>>> your mind.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Not at all, I'm just illustrating the flaws in your logic, as you can't show that Ha3 is wrong without also showing that H is also wrong....
>>>>>>>>>>>
>>>>>>>>>>>> A halt decider must simulate its input until it can prove that the
>>>>>>>>>>>> simulation would never end.
>>>>>>>>>>>
>>>>>>>>>>> ... just like this.
>>>>>>>>>>>
>>>>>>>>>>> What you states above is sufficient to show that Ha3(N,5) is not correct to abort, and Ha7(N,5) simulating to a final state and reporting halting proves that Ha3 didn't simulate for long enough.
>>>>>>>>>> OK finally back to an honest dialogue.
>>>>>>>>>
>>>>>>>>> It always was. You're apparently unable to see where I was going with this.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Now let's apply that to H(P,P).
>>>>>>>>>>>
>>>>>>>>>>> H(P,P) is not correct to abort, and H1(P,P) simulating to a final state and reporting halting proves that H didn't simulate for long enough.
>>>>>>>>>>>
>>>>>>>>>>> Therefore H(P,P) == false is provable INCORRECT.
>>>>>>>>>> It is easily proven on the basis of verified facts that H(P,P) and
>>>>>>>>>> H1(P,P) do correctly compute the halt function for their input parameters.
>>>>>>>>>
>>>>>>>>> You don't seem to understand. H1 proves that H is wrong
>>>>>>>> Both H(P,P) and H1(P,P) correctly compute the mapping from their input
>>>>>>>> parameters to the halt status specified by these inputs.
>>>>>>>
>>>>>>> FALSE. Remember, you said:
>>>>>>>
>>>>>>> A halt decider must simulate its input until it can prove that the simulation would never end.
>>>>>>>
>>>>>>> Proving that the simulation would never end means that NO simulator can simulate that input to a final state.
>>>>>> You continue to believe that your imagination overrules verified facts:
>>>>>>
>>>>>> That the correct simulation of the input to H(P,P) provably would never
>>>>>> end conclusively proves that H(P,P)==false is correct.
>>>>>
>>>>> It is a verified fact that H(P,P) does NOT perform a correct simulation of its input.
>>>> That the execution trace of the simulated input to H(P,P) exactly
>>>> matches the behavior specified by its x86 source-code provides the
>>>> ultimate measure of a correct simulation thus overriding and superseding
>>>> any and all other measures.
>>>>
>>>> _P()
>>>> [000009d6](01) 55 push ebp
>>>> [000009d7](02) 8bec mov ebp,esp
>>>> [000009d9](03) 8b4508 mov eax,[ebp+08]
>>>> [000009dc](01) 50 push eax // push P
>>>> [000009dd](03) 8b4d08 mov ecx,[ebp+08]
>>>> [000009e0](01) 51 push ecx // push P
>>>> [000009e1](05) e840feffff call 00000826 // call H
>>>> [000009e6](03) 83c408 add esp,+08
>>>> [000009e9](02) 85c0 test eax,eax
>>>> [000009eb](02) 7402 jz 000009ef
>>>> [000009ed](02) ebfe jmp 000009ed
>>>> [000009ef](01) 5d pop ebp
>>>> [000009f0](01) c3 ret // Final state
>>>> Size in bytes:(0027) [000009f0]
>>>>
>>>> Begin Local Halt Decider Simulation
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> ...[000009d6][00211368][0021136c] 55 push ebp // enter P
>>>> ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
>>>> ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
>>>> ...[000009dc][00211364][000009d6] 50 push eax // Push P
>>>> ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
>>>> ...[000009e0][00211360][000009d6] 51 push ecx // Push P
>>>> ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
>>>> ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
>>>> ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
>>>> ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
>>>> ...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
>>>> ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
>>>> ...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
>>>> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>> --
>>>> Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see." Arthur Schopenhauer
>>>
>>> All this trace shows is that H aborted its input.
>> This trace of the correctly simulated input to H(P,P) conclusively
>> proves that when P calls the same function with the same parameters from
>> the same address that H has its reject (non-halting) criteria.
>
> This trace is however missing the steps in the embedded call to H. Those steps contain a number of conditions that could abort, and in fact *will* abort if allowed to continue, but H is unable to account for that.

On 2022-05-05 16:54:01 +0000, Mr Flibble said:

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

No sentence in the proof of any of the proofs of the theorem that
the halting problem is not Turing solvable has been shown to
contain a category error. A category error is always contained
in a single sentence, so if no sentence contains the error it
is not present at all.

Mikko

On 2022-05-05 17:46:32 +0000, olcott said:

>> There is no category error in the theorem. An infinitely recursive
>> computation is still in the category of computations.

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

Where does Linz say so?

Mikko

On 2022-05-05 17:52:48 +0000, olcott said:

>>>>> On 5/3/2022 12:17 PM, Mikko wrote:
>>>>>> On 2022-05-03 14:38:57 +0000, olcott said:
>>>>>>
>>>>>>> On 5/3/2022 4:36 AM, Mikko wrote:

>>>>>>>> One of the rules that define Prolog language is
>>>>>>>>
>>>>>>>>  arguments ::= argument | argument "," arguments
>>>>>>>>
>>>>>>>> which is infinitely recursive. Is it invalid? Is Prolog invalid because
>>>>>>>> of this and other infinitely recursive rules?
>>>>>>>>
>>>>>>>> Mikko

>>>>>>> If would have to be invalid because it can never be resolved.

>>>>>> What would be invalid? Prolog? Definition of Prolog?
>>>>>> Why "would be" and not "is"?

> I never retracted anything.

So you still claim that Prolog is invalid?

Mikko

On 2022-05-05 22:12:51 +0000, olcott said:

> struct Quintuple
> {
> u32 state;
> u32 symbol;
> u32 write_symbol;
> u32 next_state;
> u8 Tape_Head_Move;
> }
>
> std::set<Quintuple> States;

I would recommend "Rule" pro "Quintuple" and "Rules" pro "States".
Then the code would be easier to understand.

Mikko

olcott <polcott2@gmail.com> writes:

> On 5/5/2022 9:35 PM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 5/5/2022 8:29 AM, Ben wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>
>>>>> H1(P,P)==true is empirically proven to be correct
>>>>> H(P,P)==false is empirically proven to be correct
>>>>
>>>>> Both take the machine code of P as input parameters and are provably
>>>>> correct simulations of this same input yet one correctly determines
>>>>> that its input halts and the other correctly determines that its input
>>>>> does not halt. ALL THESE THINGS ARE VERIFIED FACTS !
>>>>
>>>> Your mantra is doing sterling work, allowing you to pretend you are
>>>> taking about the halting problem while hiding what it is that your
>>>> deciders are deciding. Whatever you are hiding behind the words
>>>> "correct simulations of this same input" it is obviously not the halting
>>>> of P(P).
>>>
>>> You seem to have a short-circuit in your brain, I have told you this
>>> many times and you have not seen it once.
>>>
>>> H1(P,P) IS THE HALT STATUS OF P(P)
>> So what? Everyone know that there are an infinity of functions that are
>> correct about the halting of P(P). It's H that's wrong, not H1.
>> The only interesting thing about H1 is that you say it does that same as
>> H but gets a different answer. Now that's a rabbit hole that other
>> people might follow you down, but I don't care. You are wrong about too
>> many things to be bothered about all of them.
>> The important point is that your H is wrong because H(P,P) == false even
>> though P(P) halts.
>>
>>>> For one thing, there is only one correct answer to the halting
>>>> or otherwise of a computation, and for another, H(X,Y) is obviously not
>>>> telling the world what it wants to know -- the halting of the
>>>> computation X(Y).
>>>
>>> Since you know that a decider (halting or otherwise) only computes the
>>> mapping from its inputs and that you insist that a halt decider
>>> compute its mapping from non inputs it is either psychosis or
>>> deception on your part.
>> Remember all those other times you thought I was mad? Remember the last
>> time? It was because you didn't know what a sequence was.
>> Hint: every time you think I am lying or playing games or psychotic it's
>> because your conviction that you can't be wrong has butted up against
>> cold facts. You know, at some level of consciousness, that a C-like
>> halt decider, bool D(ptr X, ptr Y);, returns true or false based on the
>> halting of X(Y) as here:
>>
>>>> Do you have anything at all left to say about the real halting problem?
>>>> I really think you should at least state, explicitly, that you now
>>>> accept that no function D exists such that D(X,Y) == true if an only if
>>>> X(Y) halts and false otherwise.
>> We could make progress if you would accept that no such D can exist for
>> whatever reason you choose to give -- even it's because you think X(Y)
>> is a "non-input". But then there's no reason to think you will make
>> such a clear statement.
>>
>>> H1(P,P)==true is empirically proven to be correct
>>> H(P,P)==false is empirically proven to be correct
>>>
>>> That you keep contradicting verified facts that you already accept as
>>> true seems quite nuts.
>> H1 is irrelevant, and H is wrong by definition. Whatever H has been
>> "empirically proven to be correct" about you are clear that it's not
>> correct about the halting of P(P).
>>
>>> Halt deciders (like all deciders) compute the
>>> mapping from their inputs.
>> ... to specified true/false properties of those inputs. In the case of
>> H, we want it to report on the halting or otherwise of its first
>> argument when called with the second argument. Your H fails at that.
>>
>>> It turns out that the halting behavior of the correct simulation of
>>> the input to H1(P,P) is the same as the halting behavior of P(P).
>> And that is true of an infinity of equally irrelevant functions.
>>
>>> It turns out that the halting behavior of the correct simulation of
>>> the input to H(P,P) is NOT the same as the halting behavior of P(P).
>> Which is why H does not meet the specification of being a halt decider.
>>
>>> The ultimate measure is that H(P,P) does compute the mapping from its
>>> inputs to its final reject state. This can be easily verified by
>>> anyone with sufficient expertise in the x86 language.
>> Yes, H just wrong to reject (P,P) because of how the halting problem is
>> defined. No one disputes the fact that H(P,P) == false even though P(P)
>> halts. The /only/ fact is dispute is the specification that H should
>> meet.
>>
>>> I made good progress on Simplest TM interpreter yesterday. The
>>> detailed design is halfway done. The trickiest part is the state
>>> change function. I think that I am going to use a std::set that is
>>> indexed on state + input.
>>>
>>> struct Quintuple
>>> {
>>> u32 state;
>>> u32 symbol;
>>> u32 write_symbol;
>>> u32 next_state;
>>> u8 Tape_Head_Move;
>>> }
>>>
>>> std::set<Quintuple> States;
>> Why is a set of objects that are not states called "States"?
>
> They are states, what did you think that states are?

Not quintuples. There are lots of ways to represent a TM's states, but
states are not quintuples and quintuples are not states. This confusion
will (as you can see below) make lots of the code read badly.

> This is the first draft of my transition_function() its seems to exactly match this design on the first page of the docs.
> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>
> I am writing this in Open Office Writer not any compiler.
> I don't even know that it compiles.
>
> This is going to be a member function.
> bool transition_function(std::set<Quintuple>::iterator& current_state)

There's no point in putting the quintuples into a std::set. And the
parameter current_state is badly worded as it refers to a particular
rule (quintuple) and not to a state.

The main role of a state in a TM implementation is to collect together
all the rules (quintuples) that apply in that date. You could do a lot
worse than follow that as a key organisational principle.

> {
> u32 next_state = current_state->next_state;

States, as you make clear here are just unsigned integers (in your
implementation).

> u32 current_input = Tape[Tape_Head];

Why reference the tape here? If Tape[Tape_Head] != current_state.symbol
then something has gone very wrong already. Note how confusing my
writing the condition is since current_state.symbol should not make
sense.

(By all means reference the tape to put in a run-time assertion that
tape.head() == current_rule.symbol or some such but there's no need to
get the symbol from the tape as you will already have done this in order
to pass the right quintuple to this function.)

> std::set<Quintuple>::iterator it;
>
> Tape[Tape_Head] = current_state->write_symbol;

current_state.write_symbol

But if the parameter were correctly named it would make more sense:

Tape[Tape_Head] = current_rule.write_symbol

> if (toupper(current_state->tape_head_move) == “L”;
> Tape_Head--; // Left
> else
> Tape_Head++; // Right

Since the tape has a very limited number of operations, I'd abstract it
out into a class with a move member function (or a left and a right
function).

> it = NextState(current_input, next_state);

The next state should be right here in the current_rule (badly named
current_state). At least that would be the obvious way to implement
this. Maybe the bad name is leading you astray?

> if (it == States.end())
> return false;
> current_state = it;
> return true;
> }

I don't think you have the key parts properly structured yet. I'd back
up a bit and map out the very top-level loop. That will point you to
what objects you need and what methods those objects should provide.

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

On 5/6/22 2:35 AM, olcott wrote:
> On 5/5/2022 9:50 PM, Dennis Bush wrote:
>> On Thursday, May 5, 2022 at 10:34:02 PM UTC-4, olcott wrote:
>>> On 5/5/2022 9:18 PM, Dennis Bush wrote:
>>>> On Thursday, May 5, 2022 at 10:08:31 PM UTC-4, olcott wrote:
>>>>> On 5/5/2022 8:59 PM, Dennis Bush wrote:
>>>>>> On Thursday, May 5, 2022 at 9:36:41 PM UTC-4, olcott wrote:
>>>>>>> On 5/5/2022 8:17 PM, Dennis Bush wrote:
>>>>>>>> On Thursday, May 5, 2022 at 9:06:12 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/5/2022 5:42 PM, Dennis Bush wrote:
>>>>>>>>>> On Thursday, May 5, 2022 at 6:28:10 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 5/5/2022 5:06 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Thursday, May 5, 2022 at 5:47:07 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 5/5/2022 1:52 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Thursday, May 5, 2022 at 2:39:16 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 5/5/2022 12:28 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/5/2022 7:27 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>>>>>> On Thursday, 5 May 2022 at 12:54:54 UTC+1,
>>>>>>>>>>>>>>>>>> richar...@gmail.com wrote:
>>>>>>>>>>>>>>>>>>> On 5/4/22 11:54 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/4/2022 10:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 7:59 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/4/2022 9:16 AM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is clear that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely nested
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation to H.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What two pointers must be passed to H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for H to tell up
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about the halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halting of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation P(P) it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not a halt decider, and you have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> already told use that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) == false
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and that P(P) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H can report on the halting of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-input P(P) then it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider because deciders only compute
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the mapping from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inputs to final
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> states.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TM deciders compute mappings from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inputs to final states
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /according to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some property of the inputs/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That par is exactly correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- whether the input represents, for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That part has been the key error of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> everyone in that they
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all believe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that is can represent something other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> than what it actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So now, after thinking otherwise for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> years, you claim that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there is no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way to even specify the computation P(P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for you pseudo-C
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H. At least that is a clear admission
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the halting of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calls like P(P) can not be decided
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because, apparently,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> passing P and P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to H does not specify that computation,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and you can't say
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what two
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> arguments /would/ specify it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A clear and unambiguous statement that no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> D such that D(X,Y)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> == true if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and only if X(Y) halts and false
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> otherwise is possible would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> honest way to move things on. If you were
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clear about this,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> someone will talk to you about [whatever]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it is that your H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deciding.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you won't admit that no algorithm can do
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what D is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified to do?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You are just going to pretend that no one
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cares about actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I hope you see that by ignoring this point
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you are confirming
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> know D can't exist. If you thought such a D
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was possible,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you'd be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> shouting that from the roof tops since it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what everyone else
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> says is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> impossible.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I adapted my system so that I could
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> empirically test this:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But neither can tell us squat about the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halting of P(P) -- the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that H was originally supposed to decide.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Are you simply wired to ignore my words so
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that you can
>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>>> everything that I say?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H1(P,P)==true reports on the behavior of P(P).
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I try to ignore that bits that are
>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant. These two deciders
>>>>>>>>>>>>>>>>>>>>>>>>>>> decide all halting instances between them:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> bool H1(X, Y) { return true; }
>>>>>>>>>>>>>>>>>>>>>>>>>>> bool H2(X, Y) { return false; }
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Neither is interesting. For H1, the key case
>>>>>>>>>>>>>>>>>>>>>>>>>>> is H1(H1_hat,
>>>>>>>>>>>>>>>>>>>>>>>>>>> H1_hat) or
>>>>>>>>>>>>>>>>>>>>>>>>>>> maybe you call it H1(P1,P1) now since P is
>>>>>>>>>>>>>>>>>>>>>>>>>>> what you used to call
>>>>>>>>>>>>>>>>>>>>>>>>>>> H_hat.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If that is so then H and H1 don't perform the
>>>>>>>>>>>>>>>>>>>>>>>>> same mapping. This
>>>>>>>>>>>>>>>>>>>>>>>>> means that one (or both) do not compute the
>>>>>>>>>>>>>>>>>>>>>>>>> halting function.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So which one doesn't compute the halting function?
>>>>>>>>>>>>>>>>>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>>>>>>>>>>>>>>>>>>>>>>> Both take the machine code of P as input
>>>>>>>>>>>>>>>>>>>>>>>> parameters and are provably
>>>>>>>>>>>>>>>>>>>>>>>> correct simulations of this same input yet one
>>>>>>>>>>>>>>>>>>>>>>>> correctly determines
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> its input halts and the other correctly
>>>>>>>>>>>>>>>>>>>>>>>> determines that its input does
>>>>>>>>>>>>>>>>>>>>>>>> not halt.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Which means at least one is not computing the
>>>>>>>>>>>>>>>>>>>>>>> halting function. So
>>>>>>>>>>>>>>>>>>>>>>> which one is it?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The above paragraph means that it makes no
>>>>>>>>>>>>>>>>>>>>>> mistakes in computing the
>>>>>>>>>>>>>>>>>>>>>> halting function. This is a verifiable fact, not
>>>>>>>>>>>>>>>>>>>>>> any mere opinion. The
>>>>>>>>>>>>>>>>>>>>>> reason that I did the HP in C/x86 was so that
>>>>>>>>>>>>>>>>>>>>>> every detail can be shown
>>>>>>>>>>>>>>>>>>>>>> thus gaps in reasoning revealed.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any decider that maps the halting function performs
>>>>>>>>>>>>>>>>>>>>> the *same* mapping
>>>>>>>>>>>>>>>>>>>>> of inputs to outputs.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That is now proven to be factually incorrect.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If the above paragraph is proven to be a fact then
>>>>>>>>>>>>>>>>>>>> this proves that both
>>>>>>>>>>>>>>>>>>>> H and H1 compute the halting function correctly. The
>>>>>>>>>>>>>>>>>>>> above paragraph can
>>>>>>>>>>>>>>>>>>>> be proven to be a fact.
>>>>>>>>>>>>>>>>>>> Yes, IF you can prove that cats are dogs, you can
>>>>>>>>>>>>>>>>>>> prove that H is
>>>>>>>>>>>>>>>>>>> correctly computing the Halting Function.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Since you can't, you can't.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In fact, you have just proven that you don't know
>>>>>>>>>>>>>>>>>>> what you are talking
>>>>>>>>>>>>>>>>>>> about, since you just asserted a LIE.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Two machines claiming to compute the same function
>>>>>>>>>>>>>>>>>>> must generate the
>>>>>>>>>>>>>>>>>>> same answer from the same input or one of them is
>>>>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> BASIC FACT.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In parapsychology, there's something called "the
>>>>>>>>>>>>>>>>>> experimenter effect". The same
>>>>>>>>>>>>>>>>>> experiment will show a parapsychological effect or
>>>>>>>>>>>>>>>>>> not, depending on who is
>>>>>>>>>>>>>>>>>> performing the experiment. This has been described as
>>>>>>>>>>>>>>>>>> parapsychology's one finding.
>>>>>>>>>>>>>>>>>> If true in an interesting way, it also strikes at the
>>>>>>>>>>>>>>>>>> heart of the scientific method.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But intuitively, it's not implausible that an
>>>>>>>>>>>>>>>>>> experiment would "work" for an experimenter
>>>>>>>>>>>>>>>>>> with gypsy blood, for example. You can't simply reject
>>>>>>>>>>>>>>>>>> the experimenter effect on the
>>>>>>>>>>>>>>>>>> basis that, if it means more than that certain
>>>>>>>>>>>>>>>>>> experimenters are more gullible than
>>>>>>>>>>>>>>>>>> others, it leaves the rest of science in tatters.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> PO says that a machine has one behaviour when run, and
>>>>>>>>>>>>>>>>>> another behaviour when
>>>>>>>>>>>>>>>>>> "correctly simulated". That claim, if true, similarly
>>>>>>>>>>>>>>>>>> leaves the whole of computer science
>>>>>>>>>>>>>>>>>> in tatters. Which means that it's his responsibility
>>>>>>>>>>>>>>>>>> to provide a much better explanation
>>>>>>>>>>>>>>>>>> of what he means than he has done currently.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But he's been clear about this. He's asserting what
>>>>>>>>>>>>>>>>>> anyone who knows just a tiny amount
>>>>>>>>>>>>>>>>>> about computers must consdier to be nonsense. At first
>>>>>>>>>>>>>>>>>> glance. But the idea that
>>>>>>>>>>>>>>>>>> i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems
>>>>>>>>>>>>>>>>>> like nonsense at first glance. The
>>>>>>>>>>>>>>>>>> difference is that more details were forthcoming.
>>>>>>>>>>>>>>>>> Anyone knowing the x86 language can verify that H(P,P)
>>>>>>>>>>>>>>>>> and H1(P,P)
>>>>>>>>>>>>>>>>> compute the mapping from their input parameters to
>>>>>>>>>>>>>>>>> their own final state
>>>>>>>>>>>>>>>>> correctly. Arguing with verified facts is a fools folly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So in other words, a decider is always correct about
>>>>>>>>>>>>>>>> what it's own input does.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes this is an easily verified fact on the basis of the
>>>>>>>>>>>>>>> execution trace
>>>>>>>>>>>>>>> derived from the correct simulation of its input parameters.
>>>>>>>>>>>>>>>> If you believe that to be true, then you also believe
>>>>>>>>>>>>>>>> that anyone knowing the x86 language can verify that
>>>>>>>>>>>>>>>> Ha3(N,5) correctly computes the mapping from its input
>>>>>>>>>>>>>>>> to a non-halting state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H2(Ha3,N,5) would get the correct halt status for Ha3.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  From what I recall Ha3(N,5) is merely a computation that
>>>>>>>>>>>>>>> was defined to
>>>>>>>>>>>>>>> make sure it gets the wrong answer. If you disagree then
>>>>>>>>>>>>>>> remind me again
>>>>>>>>>>>>>>> what it means.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ha3 uses as its abort criteria any computation that
>>>>>>>>>>>>>> proceeds for more that 3 steps.
>>>>>>>>>>>>> WHAT ARE YOU NUTS ???
>>>>>>>>>>>>>
>>>>>>>>>>>>> Trying to push total bullshit likes this proves that you
>>>>>>>>>>>>> are only a
>>>>>>>>>>>>> troll playing head games and an honest dialogue is the last
>>>>>>>>>>>>> thing on
>>>>>>>>>>>>> your mind.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Not at all, I'm just illustrating the flaws in your logic,
>>>>>>>>>>>> as you can't show that Ha3 is wrong without also showing
>>>>>>>>>>>> that H is also wrong....
>>>>>>>>>>>>
>>>>>>>>>>>>> A halt decider must simulate its input until it can prove
>>>>>>>>>>>>> that the
>>>>>>>>>>>>> simulation would never end.
>>>>>>>>>>>>
>>>>>>>>>>>> ... just like this.
>>>>>>>>>>>>
>>>>>>>>>>>> What you states above is sufficient to show that Ha3(N,5) is
>>>>>>>>>>>> not correct to abort, and Ha7(N,5) simulating to a final
>>>>>>>>>>>> state and reporting halting proves that Ha3 didn't simulate
>>>>>>>>>>>> for long enough.
>>>>>>>>>>> OK finally back to an honest dialogue.
>>>>>>>>>>
>>>>>>>>>> It always was. You're apparently unable to see where I was
>>>>>>>>>> going with this.
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Now let's apply that to H(P,P).
>>>>>>>>>>>>
>>>>>>>>>>>> H(P,P) is not correct to abort, and H1(P,P) simulating to a
>>>>>>>>>>>> final state and reporting halting proves that H didn't
>>>>>>>>>>>> simulate for long enough.
>>>>>>>>>>>>
>>>>>>>>>>>> Therefore H(P,P) == false is provable INCORRECT.
>>>>>>>>>>> It is easily proven on the basis of verified facts that
>>>>>>>>>>> H(P,P) and
>>>>>>>>>>> H1(P,P) do correctly compute the halt function for their
>>>>>>>>>>> input parameters.
>>>>>>>>>>
>>>>>>>>>> You don't seem to understand. H1 proves that H is wrong
>>>>>>>>> Both H(P,P) and H1(P,P) correctly compute the mapping from
>>>>>>>>> their input
>>>>>>>>> parameters to the halt status specified by these inputs.
>>>>>>>>
>>>>>>>> FALSE. Remember, you said:
>>>>>>>>
>>>>>>>> A halt decider must simulate its input until it can prove that
>>>>>>>> the simulation would never end.
>>>>>>>>
>>>>>>>> Proving that the simulation would never end means that NO
>>>>>>>> simulator can simulate that input to a final state.
>>>>>>> You continue to believe that your imagination overrules verified
>>>>>>> facts:
>>>>>>>
>>>>>>> That the correct simulation of the input to H(P,P) provably would
>>>>>>> never
>>>>>>> end conclusively proves that H(P,P)==false is correct.
>>>>>>
>>>>>> It is a verified fact that H(P,P) does NOT perform a correct
>>>>>> simulation of its input.
>>>>> That the execution trace of the simulated input to H(P,P) exactly
>>>>> matches the behavior specified by its x86 source-code provides the
>>>>> ultimate measure of a correct simulation thus overriding and
>>>>> superseding
>>>>> any and all other measures.
>>>>>
>>>>> _P()
>>>>> [000009d6](01) 55 push ebp
>>>>> [000009d7](02) 8bec mov ebp,esp
>>>>> [000009d9](03) 8b4508 mov eax,[ebp+08]
>>>>> [000009dc](01) 50 push eax // push P
>>>>> [000009dd](03) 8b4d08 mov ecx,[ebp+08]
>>>>> [000009e0](01) 51 push ecx // push P
>>>>> [000009e1](05) e840feffff call 00000826 // call H
>>>>> [000009e6](03) 83c408 add esp,+08
>>>>> [000009e9](02) 85c0 test eax,eax
>>>>> [000009eb](02) 7402 jz 000009ef
>>>>> [000009ed](02) ebfe jmp 000009ed
>>>>> [000009ef](01) 5d pop ebp
>>>>> [000009f0](01) c3 ret // Final state
>>>>> Size in bytes:(0027) [000009f0]
>>>>>
>>>>> Begin Local Halt Decider Simulation
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> ...[000009d6][00211368][0021136c] 55 push ebp // enter P
>>>>> ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
>>>>> ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
>>>>> ...[000009dc][00211364][000009d6] 50 push eax // Push P
>>>>> ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
>>>>> ...[000009e0][00211360][000009d6] 51 push ecx // Push P
>>>>> ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
>>>>> ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
>>>>> ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
>>>>> ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
>>>>> ...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
>>>>> ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
>>>>> ...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
>>>>> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>> --
>>>>> Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
>>>>> Genius hits a target no one else can see." Arthur Schopenhauer
>>>>
>>>> All this trace shows is that H aborted its input.
>>> This trace of the correctly simulated input to H(P,P) conclusively
>>> proves that when P calls the same function with the same parameters from
>>> the same address that H has its reject (non-halting) criteria.
>>
>> This trace is however missing the steps in the embedded call to H.
>> Those steps contain a number of conditions that could abort, and in
>> fact *will* abort if allowed to continue, but H is unable to account
>> for that.
>
> This is moot. The halt decider knows that it never aborts an input until
> after it has proof that its input is non-halting. This means that it can
> safely ignores that thousands of pages of execution trace.
>
> The above trace proves that the correctly simulated into to H(P,P) calls
> H(P,P) to a recursion depth of two when H determine this would never stop.

On 2022-05-05 23:12, olcott wrote:
> On 5/6/2022 12:01 AM, André G. Isaak wrote:
>> On 2022-05-05 22:48, olcott wrote:
>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>>
>>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>>> detailed design is halfway done.  The trickiest part is the state
>>>>> change function.  I think that I am going to use a std::set that is
>>>>> indexed on state + input.
>>>>>
>>>>> struct Quintuple
>>>>> {
>>>>>    u32 state;
>>>>>    u32 symbol;
>>>>>    u32 write_symbol;
>>>>>    u32 next_state;
>>>>>     u8 Tape_Head_Move;
>>>>> }
>>>>>
>>>>> std::set<Quintuple> States;
>>>>
>>>> Why is a set of objects that are not states called "States"?
>>>>
>>>
>>> They are states, what did you think that states are?
>>
>> States are states. Quintuples are quintuples. They're not the same
>> thing. In a C implementation, a state is simply going to be an
>> integer, not some sort of struct.
>>
>> André
>>
>>
>
> So then you don't disagree that my implementation of the TM transition
> function matches its corresponding design?

I said nothing about your implementation. I simply pointed out that you
are incorrectly referring to quintuples as states. I have no idea what
"its corresponding design" refers to.

André

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

On 5/6/2022 8:36 AM, André G. Isaak wrote:
> On 2022-05-05 23:12, olcott wrote:
>> On 5/6/2022 12:01 AM, André G. Isaak wrote:
>>> On 2022-05-05 22:48, olcott wrote:
>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>>>> detailed design is halfway done.  The trickiest part is the state
>>>>>> change function.  I think that I am going to use a std::set that is
>>>>>> indexed on state + input.
>>>>>>
>>>>>> struct Quintuple
>>>>>> {
>>>>>>    u32 state;
>>>>>>    u32 symbol;
>>>>>>    u32 write_symbol;
>>>>>>    u32 next_state;
>>>>>>     u8 Tape_Head_Move;
>>>>>> }
>>>>>>
>>>>>> std::set<Quintuple> States;
>>>>>
>>>>> Why is a set of objects that are not states called "States"?
>>>>>
>>>>
>>>> They are states, what did you think that states are?
>>>
>>> States are states. Quintuples are quintuples. They're not the same
>>> thing. In a C implementation, a state is simply going to be an
>>> integer, not some sort of struct.
>>>
>>> André
>>>
>>>
>>
>> So then you don't disagree that my implementation of the TM transition
>> function matches its corresponding design?
>
> I said nothing about your implementation. I simply pointed out that you
> are incorrectly referring to quintuples as states. I have no idea what
> "its corresponding design" refers to.
>
> André
>

This design was cut from the TM interpreter linked below:
A turing machine program consists of a list of 'quintuples', each one of
which is a five-symbol turing machine instruction.

For example, the quintuple 'SCcsm' is executed by the machine
(a) is in state 'S'
(b) is reading the symbol 'C' on the tape.
(c) makes a transition to state 's'
(d) overwrite the symbol 'C' on the tape with the symbol 'c'.
(e) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt

transition_function() implements the transition_function() of the above
design. This is the hardest part of coding a TM interpreter (not very
hard).

struct Quintuple
{ u32 state;
u32 symbol;
u32 write_symbol;
u32 next_state;
u8 Tape_Head_Move;
};

bool transition_function(std::set<Quintuple>::iterator& current_state)
{ u32 next_state = current_state->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;

Tape[Tape_Head] = current_state->write_symbol;
if (toupper(current_state->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right

it = NextState(current_input, next_state);
if (it == States.end())
return false;
current_state = it;
return true;
}

--
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-06 09:32, olcott wrote:
> On 5/6/2022 8:36 AM, André G. Isaak wrote:
>> On 2022-05-05 23:12, olcott wrote:
>>> On 5/6/2022 12:01 AM, André G. Isaak wrote:
>>>> On 2022-05-05 22:48, olcott wrote:
>>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>
>>>>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>>>>> detailed design is halfway done.  The trickiest part is the state
>>>>>>> change function.  I think that I am going to use a std::set that is
>>>>>>> indexed on state + input.
>>>>>>>
>>>>>>> struct Quintuple
>>>>>>> {
>>>>>>>    u32 state;
>>>>>>>    u32 symbol;
>>>>>>>    u32 write_symbol;
>>>>>>>    u32 next_state;
>>>>>>>     u8 Tape_Head_Move;
>>>>>>> }
>>>>>>>
>>>>>>> std::set<Quintuple> States;
>>>>>>
>>>>>> Why is a set of objects that are not states called "States"?
>>>>>>
>>>>>
>>>>> They are states, what did you think that states are?
>>>>
>>>> States are states. Quintuples are quintuples. They're not the same
>>>> thing. In a C implementation, a state is simply going to be an
>>>> integer, not some sort of struct.
>>>>
>>>> André
>>>>
>>>>
>>>
>>> So then you don't disagree that my implementation of the TM
>>> transition function matches its corresponding design?
>>
>> I said nothing about your implementation. I simply pointed out that
>> you are incorrectly referring to quintuples as states. I have no idea
>> what "its corresponding design" refers to.
>>
>> André
>>
>
> This design was cut from the TM interpreter linked below:
> A turing machine program consists of a list of 'quintuples', each one of
> which is a five-symbol turing machine instruction.

The above does not claim that quintuples are states.

> For example, the quintuple 'SCcsm' is executed by the machine
> (a) is in state 'S'
> (b) is reading the symbol 'C' on the tape.
> (c) makes a transition to state 's'
> (d) overwrite the symbol 'C' on the tape with the symbol 'c'.
> (e) move the tape reading head one symbol to the left or right
>      according to whether 'm' is 'l' or 'r'.
> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt

Your (a)-(e) lettering are not part of the original and adding them
suggests you don't even understand the paragraph.

André

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

On 5/6/2022 6:36 AM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/5/2022 9:35 PM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 5/5/2022 8:29 AM, Ben wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>
>>>>>> H1(P,P)==true is empirically proven to be correct
>>>>>> H(P,P)==false is empirically proven to be correct
>>>>>
>>>>>> Both take the machine code of P as input parameters and are provably
>>>>>> correct simulations of this same input yet one correctly determines
>>>>>> that its input halts and the other correctly determines that its input
>>>>>> does not halt. ALL THESE THINGS ARE VERIFIED FACTS !
>>>>>
>>>>> Your mantra is doing sterling work, allowing you to pretend you are
>>>>> taking about the halting problem while hiding what it is that your
>>>>> deciders are deciding. Whatever you are hiding behind the words
>>>>> "correct simulations of this same input" it is obviously not the halting
>>>>> of P(P).
>>>>
>>>> You seem to have a short-circuit in your brain, I have told you this
>>>> many times and you have not seen it once.
>>>>
>>>> H1(P,P) IS THE HALT STATUS OF P(P)
>>> So what? Everyone know that there are an infinity of functions that are
>>> correct about the halting of P(P). It's H that's wrong, not H1.
>>> The only interesting thing about H1 is that you say it does that same as
>>> H but gets a different answer. Now that's a rabbit hole that other
>>> people might follow you down, but I don't care. You are wrong about too
>>> many things to be bothered about all of them.
>>> The important point is that your H is wrong because H(P,P) == false even
>>> though P(P) halts.
>>>
>>>>> For one thing, there is only one correct answer to the halting
>>>>> or otherwise of a computation, and for another, H(X,Y) is obviously not
>>>>> telling the world what it wants to know -- the halting of the
>>>>> computation X(Y).
>>>>
>>>> Since you know that a decider (halting or otherwise) only computes the
>>>> mapping from its inputs and that you insist that a halt decider
>>>> compute its mapping from non inputs it is either psychosis or
>>>> deception on your part.
>>> Remember all those other times you thought I was mad? Remember the last
>>> time? It was because you didn't know what a sequence was.
>>> Hint: every time you think I am lying or playing games or psychotic it's
>>> because your conviction that you can't be wrong has butted up against
>>> cold facts. You know, at some level of consciousness, that a C-like
>>> halt decider, bool D(ptr X, ptr Y);, returns true or false based on the
>>> halting of X(Y) as here:
>>>
>>>>> Do you have anything at all left to say about the real halting problem?
>>>>> I really think you should at least state, explicitly, that you now
>>>>> accept that no function D exists such that D(X,Y) == true if an only if
>>>>> X(Y) halts and false otherwise.
>>> We could make progress if you would accept that no such D can exist for
>>> whatever reason you choose to give -- even it's because you think X(Y)
>>> is a "non-input". But then there's no reason to think you will make
>>> such a clear statement.
>>>
>>>> H1(P,P)==true is empirically proven to be correct
>>>> H(P,P)==false is empirically proven to be correct
>>>>
>>>> That you keep contradicting verified facts that you already accept as
>>>> true seems quite nuts.
>>> H1 is irrelevant, and H is wrong by definition. Whatever H has been
>>> "empirically proven to be correct" about you are clear that it's not
>>> correct about the halting of P(P).
>>>
>>>> Halt deciders (like all deciders) compute the
>>>> mapping from their inputs.
>>> ... to specified true/false properties of those inputs. In the case of
>>> H, we want it to report on the halting or otherwise of its first
>>> argument when called with the second argument. Your H fails at that.
>>>
>>>> It turns out that the halting behavior of the correct simulation of
>>>> the input to H1(P,P) is the same as the halting behavior of P(P).
>>> And that is true of an infinity of equally irrelevant functions.
>>>
>>>> It turns out that the halting behavior of the correct simulation of
>>>> the input to H(P,P) is NOT the same as the halting behavior of P(P).
>>> Which is why H does not meet the specification of being a halt decider.
>>>
>>>> The ultimate measure is that H(P,P) does compute the mapping from its
>>>> inputs to its final reject state. This can be easily verified by
>>>> anyone with sufficient expertise in the x86 language.
>>> Yes, H just wrong to reject (P,P) because of how the halting problem is
>>> defined. No one disputes the fact that H(P,P) == false even though P(P)
>>> halts. The /only/ fact is dispute is the specification that H should
>>> meet.
>>>
>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>> detailed design is halfway done. The trickiest part is the state
>>>> change function. I think that I am going to use a std::set that is
>>>> indexed on state + input.
>>>>
>>>> struct Quintuple
>>>> {
>>>> u32 state;
>>>> u32 symbol;
>>>> u32 write_symbol;
>>>> u32 next_state;
>>>> u8 Tape_Head_Move;
>>>> }
>>>>
>>>> std::set<Quintuple> States;
>>> Why is a set of objects that are not states called "States"?
>>
>> They are states, what did you think that states are?
>
> Not quintuples. There are lots of ways to represent a TM's states, but
> states are not quintuples and quintuples are not states. This confusion
> will (as you can see below) make lots of the code read badly.
>

What did you think that states are?
Do you think that they are raw integers?

>> This is the first draft of my transition_function() its seems to exactly match this design on the first page of the docs.
>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>>
>> I am writing this in Open Office Writer not any compiler.
>> I don't even know that it compiles.
>>
>> This is going to be a member function.
>> bool transition_function(std::set<Quintuple>::iterator& current_state)
>
> There's no point in putting the quintuples into a std::set. And the
> parameter current_state is badly worded as it refers to a particular
> rule (quintuple) and not to a state.
>

It is simpler than a linear or binary search scan through the whole list
every-time we need to make a transition from the current_state to the
(next_state + current_Input).

> The main role of a state in a TM implementation is to collect together
> all the rules (quintuples) that apply in that date. You could do a lot
> worse than follow that as a key organisational principle.

A linear list of quintuples is specified in the filename.TM
TAPE_DATA // on a line by itself followed by
A linear list of ASCII text chars or hexadecimal bytes.

The tape has been initialized as a std::vector<u8> Tape;
We could have a Move_R past the end of the tape allocate more memory.
A move left prior to the beginning of the tape might be reported as an
error.

int Tape_Head = 0; // not a global

std::set<Quintuple>::iterator
NextState(int next_state, int current_input)
{ Quintuple QT(next_state, current_input);
return States.find(QT);
};

The above returns an iterator to state indexed by (state + symbol).

bool Transition_to_State_0(std::set<Quintuple>::iterator& current_state)
{ it = NextState(0, Tape[Tape_Head]);
if (it == States.end())
return false;
current_state = it;
return true;
}

>> {
>> u32 next_state = current_state->next_state;
>
> States, as you make clear here are just unsigned integers (in your
> implementation).
>

OK then I will use Quintuple_List as my designer implemented.

>> u32 current_input = Tape[Tape_Head];
>
> Why reference the tape here? If Tape[Tape_Head] != current_state.symbol
> then something has gone very wrong already. Note how confusing my
> writing the condition is since current_state.symbol should not make
> sense.

On 5/6/2022 10:43 AM, André G. Isaak wrote:
> On 2022-05-06 09:32, olcott wrote:
>> On 5/6/2022 8:36 AM, André G. Isaak wrote:
>>> On 2022-05-05 23:12, olcott wrote:
>>>> On 5/6/2022 12:01 AM, André G. Isaak wrote:
>>>>> On 2022-05-05 22:48, olcott wrote:
>>>>>> On 5/5/2022 9:35 PM, Ben wrote:
>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>
>>>>>>>> I made good progress on Simplest TM interpreter yesterday. The
>>>>>>>> detailed design is halfway done.  The trickiest part is the state
>>>>>>>> change function.  I think that I am going to use a std::set that is
>>>>>>>> indexed on state + input.
>>>>>>>>
>>>>>>>> struct Quintuple
>>>>>>>> {
>>>>>>>>    u32 state;
>>>>>>>>    u32 symbol;
>>>>>>>>    u32 write_symbol;
>>>>>>>>    u32 next_state;
>>>>>>>>     u8 Tape_Head_Move;
>>>>>>>> }
>>>>>>>>
>>>>>>>> std::set<Quintuple> States;
>>>>>>>
>>>>>>> Why is a set of objects that are not states called "States"?
>>>>>>>
>>>>>>
>>>>>> They are states, what did you think that states are?
>>>>>
>>>>> States are states. Quintuples are quintuples. They're not the same
>>>>> thing. In a C implementation, a state is simply going to be an
>>>>> integer, not some sort of struct.
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> So then you don't disagree that my implementation of the TM
>>>> transition function matches its corresponding design?
>>>
>>> I said nothing about your implementation. I simply pointed out that
>>> you are incorrectly referring to quintuples as states. I have no idea
>>> what "its corresponding design" refers to.
>>>
>>> André
>>>
>>
>> This design was cut from the TM interpreter linked below:
>> A turing machine program consists of a list of 'quintuples', each one
>> of which is a five-symbol turing machine instruction.
>
> The above does not claim that quintuples are states.

OK, so I will change the name current_state to Current_Quintuple and
States to Quintuple_List.

>
>> For example, the quintuple 'SCcsm' is executed by the machine
>> (a) is in state 'S'
>> (b) is reading the symbol 'C' on the tape.
>> (c) makes a transition to state 's'
>> (d) overwrite the symbol 'C' on the tape with the symbol 'c'.
>> (e) move the tape reading head one symbol to the left or right
>>       according to whether 'm' is 'l' or 'r'.
>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>
> Your (a)-(e) lettering are not part of the original and adding them
> suggests you don't even understand the paragraph.
>
> André
>

I trimmed the original and reformatted to make is easier to understand.
It is pretty callous to say that I made a mistake when no actual mistake
can be pointed out.

*The question was*
*Does the following implementation match the above design?*

bool transition_function(std::set<Quintuple>::iterator& current_quintuple)
{ u32 next_state = current_quintuple->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;

Tape[Tape_Head] = current_quintuple->write_symbol;
if (toupper(current_quintuple->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right

it = NextState(next_state, current_input);
if (it == Quintuple_List.end())
return false;
current_state = it;
return true;
}

--
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-06 10:45, olcott wrote:
> On 5/6/2022 10:43 AM, André G. Isaak wrote:
>> On 2022-05-06 09:32, olcott wrote:

>>> For example, the quintuple 'SCcsm' is executed by the machine
>>> (a) is in state 'S'
>>> (b) is reading the symbol 'C' on the tape.
>>> (c) makes a transition to state 's'
>>> (d) overwrite the symbol 'C' on the tape with the symbol 'c'.
>>> (e) move the tape reading head one symbol to the left or right
>>>       according to whether 'm' is 'l' or 'r'.
>>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>>
>> Your (a)-(e) lettering are not part of the original and adding them
>> suggests you don't even understand the paragraph.
>>
>> André
>>
>
> I trimmed the original and reformatted to make is easier to understand.

And destroyed the meaning in the process. That certainly doesn't make it
"easier" to understand.

First, you eliminate the crucial words "if it" from (a).

Second, you split (a) and (b) into two items thereby obscuring the fact
that these two go together and are both equally part of the condition
which the missing 'if it' describes.

Third, by formatting this as a list if five items you obscure the fact
that (a) and (b) are entirely different from (c)-(e).

(a) and (b) describe the CONDITION under which the transition described
by the rule apply.

(c) - (e) describe the ACTION taken when this transition is applied.

> It is pretty callous to say that I made a mistake when no actual mistake
> can be pointed out.

Answered above.

André

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

On 5/6/2022 12:01 PM, André G. Isaak wrote:
> On 2022-05-06 10:45, olcott wrote:
>> On 5/6/2022 10:43 AM, André G. Isaak wrote:
>>> On 2022-05-06 09:32, olcott wrote:
>
>>>> For example, the quintuple 'SCcsm' is executed by the machine
>>>> (a) is in state 'S'
>>>> (b) is reading the symbol 'C' on the tape.
>>>> (c) makes a transition to state 's'
>>>> (d) overwrite the symbol 'C' on the tape with the symbol 'c'.
>>>> (e) move the tape reading head one symbol to the left or right
>>>>       according to whether 'm' is 'l' or 'r'.
>>>> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
>>>
>>> Your (a)-(e) lettering are not part of the original and adding them
>>> suggests you don't even understand the paragraph.
>>>
>>> André
>>>
>>
>> I trimmed the original and reformatted to make is easier to understand.
>
> And destroyed the meaning in the process. That certainly doesn't make it
> "easier" to understand.
>
> First, you eliminate the crucial words "if it" from (a).
>

Yes you are correct this is my mistake.

> Second, you split (a) and (b) into two items thereby obscuring the fact
> that these two go together and are both equally part of the condition
> which the missing 'if it' describes.
>

Yes you are correct this is my mistake. I should have done a more
accurate job specifying the original design.

A turing machine is a model of a computer. It has a finite number of
states, and it is capable of reading and modifying a tape. A turing
machine program consists of a list of 'quintuples', each one of which is
a five-symbol turing machine instruction. For example, the quintuple
'SCcsm' is executed by the machine if it is in state 'S' and is reading
the symbol 'C' on the tape. In that case, the instruction causes the
machine to make a transition to state 's' and to overwrite the symbol
'C' on the tape with the symbol 'c'. The last operation it performs
under this instruction is to move the tape reading head one symbol to
the left or right according to whether 'm' is 'l' or 'r'.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt

For example, the quintuple 'SCcsm' is executed by the machine:
if is in state 'S' and is reading the symbol 'C' on the tape then
(a) make a transition to state 's'.
(b) overwrite the symbol 'C' on the tape with the symbol 'c'.
(c) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.

> Third, by formatting this as a list if five items you obscure the fact
> that (a) and (b) are entirely different from (c)-(e).
>

Not at all (a) is named S (b) is named C whereas
(c) is named s and (d) is named c.

> (a) and (b) describe the CONDITION under which the transition described
> by the rule apply.
>

Yes

> (c) - (e) describe the ACTION taken when this transition is applied.
>

Yes

>> It is pretty callous to say that I made a mistake when no actual
>> mistake can be pointed out.
>
> Answered above.
>

Good critique.

> André
>
>

Because there is no current_quintuple when quintuple_list::find fails
then the following function can safely assume that current_quintuple is
in state 'S' and is reading the symbol 'C' on the tape.

Does this transition_function() implement the above design?

bool transition_function(std::set<Quintuple>::iterator& current_quintuple)
{ u32 next_state = current_quintuple->next_state;
u32 current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator it;

Tape[Tape_Head] = current_quintuple->write_symbol;
if (toupper(current_quintuple->tape_head_move) == “L”;
Tape_Head--; // Left
else
Tape_Head++; // Right

it = NextState(next_state, current_input);
if (it == Quintuple_List.end())
return false;
current_state = it;
return true;
}

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