On 7/30/21 5:42 PM, olcott wrote:
> On 7/30/2021 2:22 PM, Ben Bacarisse wrote:
>> I lost internet connection after writing a reply to this so it's
>> possible both versions will appear.   I hope not...
>>
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/30/2021 6:00 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> (I answered your other belligerent reply before I read this.)
>>>>>>
>>>>>>> I would prefer to move away from division and animosity to
>>>>>>> achieve an
>>>>>>> honest dialogue striving for mutual agreement, are you game?
>>>>>> Sure.  Here are some other things about which I would like to seek
>>>>>> mutual agreement:
>>>>>> (1) A TM, M, halts on input s if the sequence of machine
>>>>>> configurations
>>>>>>        generated by M's state transition function, along with the
>>>>>> input s,
>>>>>>        is finite.
>>>>>
>>>>> I like André's reaches one of its own finite states better.
>>>>> Is this OK with you?
>>>> What you say here is too vague.  If you can write it clearly and
>>>> formally, I'm sure we could agree on it, but I suspect you can't.  In
>>>> the spirit of reaching an agreement, is there anything you object to in
>>>> my definition?
>>>
>>> Your definition seems to be ambiguous when the simulation of a
>>> computation has been aborted, André's definition is not ambiguous in
>>> this case.
>>
>> It's not ambiguous.  On the other hand, your definition (I won't call
>> it André's unless he says you've got it right) uses too many vague
>> words.  If you can write it formally, we may be able to agree on it.
>>
>
> _P()
> [00000c25](01)  55          push ebp
> [00000c26](02)  8bec        mov ebp,esp
> [00000c28](03)  8b4508      mov eax,[ebp+08]
> [00000c2b](01)  50          push eax       // 2nd Param
> [00000c2c](03)  8b4d08      mov ecx,[ebp+08]
> [00000c2f](01)  51          push ecx       // 1st Param
> [00000c30](05)  e820fdffff  call 00000955  // call H
> [00000c35](03)  83c408      add esp,+08
> [00000c38](02)  85c0        test eax,eax
> [00000c3a](02)  7402        jz 00000c3e
> [00000c3c](02)  ebfe        jmp 00000c3c
> [00000c3e](01)  5d          pop ebp
> [00000c3f](01)  c3          ret
> Size in bytes:(0027) [00000c3f]
>
> All of the inputs to H are complete functions that were translated by
> the Microsoft C compiler have well-defined final states. The above
> function has 0xc3f as its sole final state. If it reaches this final
> state it halts. If its execution trace proves that it can never reach
> this final state then it never halts.

But the execution trace of main calling P(P) directly shows that P(P)
itself WILL halt, the problem is that H makes the mistake of thinking it
won't and stops it too soon. Thus H is wrong.

Behavior of the machine the input represent is the REAL ACTUAL
DEFINITION of Halting.

If you claim H can be right here, then we can just define a differnt
decider that immediately aborts the simulation and declair its input
never reached a halting state, and thus is non-halting.

FAIL.

>
>>>>>> M is said to accept s if the final state is an accepting
>>>>>>        state.  Otherwise M is said to reject the input s.
>>>>>>
>>>>> Yes
>>>>>
>>>>>> (2) A halt decider is a TM, D, that accepts only and all inputs of
>>>>>> the
>>>>>>        form <m,s> where m encodes a TM that halts on input s.  D
>>>>>> rejects
>>>>>>        all others inputs.
>>>>>
>>>>> Yes with André's definition of halting.
>>>>> Is this OK with you?
>>>> Not unless you can write it clearly, no.
>>>
>>> We can work on this.
>>
>> Well, I can't.  You can have another go at saying what you mean, but
>> I've already had my say.  I don't want to change my definition though
>> I'll add to it if you think some parts need more explanation.  By the
>> way, it's the one with which you agreed before.
>>
>
> We must have a perfectly definitive way of dividing inputs that stop
> running because their computation has fully completed from inputs that
> stop running for any other reason.

WHY?

And we do, we run the machines that the input represents and see what
they do. P(P) Halts. There is NO requirement that H needs to be able to
get the answer right, just that there IS a correct answer to the ACTUAL
question, does P(I) reach a halting state in a finite number of steps.
>
>>> The input to my partial halt decider is always a complete function
>>> compiled from C and complete functions always have the explicit final
>>> state of their last address.
>>
>> I'm talking about Turing machines.  If you want to talk about the
>> halting theorem, you should be prepared to discuss a formal model of
>> computation.  It would take a lot of work for you to pin down
>> a C-based model of computation and I don't think you want to do that
>> work.
>>
>
> Because it is utterly impossible to specify all of the relevant details
> in the TM model of computation I created the x86utm system. All of the
> formal proofs leave out most of the relevant details because these key
> details cannot be specified in any reasonably compact and concise form.

But it isn't. Maybe for you it is, but by the Turing Equivalence Theorem
you are using, if your machine actually is the Computational Equivalent
of a Turing Machine, such a Turing Machine can be made.

If you REALLY mean that can't be done, then it says your 'program' isn't
a computation and thus doesn't fullfil the requirements.

>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> if M applied to wM halts, and
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if M applied to wM does not halt
>
> The second ⊢* wildcard state has millions of unspecified steps that are
> mere hand-waving. Because all of the conventional proofs are mostly
> hand-waving it never occurred to anyone that a simulating halt decider
> at Ĥ.qx would correctly decide that it must stop the simulation of its
> input thus proving that its input never halts.

They aren't hand waving, YOU do hand waving.

Note, you in effect are admitting to your flaw, because a simulator
stopping its simulation NEVER actual PROVES anything.

UNSOUND LOGIC, FAIL.

>
>>>>>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>>>>>>        defined in any of the usual textbooks) that you called H to
>>>>>> which
>>>>>>        Linz's "hat" constriction could be applied to get another
>>>>>> TM, H^?
>>>>>
>>>>> I never had a Turing machine.
>>>> OK, thanks.  That's clear.
>>>>
>>>>> It was encoded in nearly complete C.
>>>> This raises lots of questions:
>>>> (3a) What are "the exact TMD instructions of the Linz Turing machine H"
>>>>        that you had encoded by Dec 14th in relation to this C code?
>>>
>>> Like I said I did not have a Turing Machine.
>>
>> Right, so why did you say words that make no sense in relation to what
>> you did have?  I'm trying to build trust so we can reach some mutual
>> understanding, but that means I need to know why you repeatedly tried to
>> make it seem as if you had what you incorrectly said you had, rather
>> than what you did have.
>>
>
> I had the essence of the computational equivalent of what I claimed and
> would have simply claimed that I has the essence of he computational
> equivalent if I had known that TM equivalence was a thing that other
> people knew about and not just private knowledge that I had.
>
> At the end of 2018 I had only heard of TM complete and I knew that this
> required unlimited memory. TM equivalence for a subset of computations
> still seems to be a thing that no one else knows about. C is equivalent
> to a TM for the subset of computations where it has all the memory that
> it needs. I don't think that anyone else beside me says this.

I.E you didn't and still don't understand what a Turing Machine actually
is, and are just lying out of your a** when you make claims about them.

>
>>>> (3b) What does "I provide the exact ⊢* wildcard states after the Linz
>>>>        H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H
>>>> would
>>>>        correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?
>>>
>>> the proof ...is so short and simple that
>>> it may be of interest to casual readers.
>>> The version below uses CPL...
>>>
>>>    rec routine P
>>>      §L:if T[P] go to L
>>>        Return §
>>>
>>> Strachey, C 1965.  An impossible program The Computer Journal, Volume
>>> 7, Issue 4, January 1965, Page 313,
>>> https://doi.org/10.1093/comjnl/7.4.313
>>>
>>> In the same way that Strachey claims that his little CPL program sums
>>> up the entire proof my premise is that this C code sums up the entire
>>> proof.
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>>
>>> What I had in 2018 was a crude way that code determined that the above
>>> does specify infinitely nested simulation.  "the exact ⊢* wildcard
>>> states" refers to this code.
>>
>> Is this the best, most diligent answer to (3b) that you have?  I must
>> say it does not come close to explaining what these "exact states after
>> the Linz H.q0 and after Ĥ.qx" are,
>
> I was a crude kludge that worked.

No, it didn't. Maybe it was good enough to gaslight you.

>
>> nor does it explain why you used the
>> ⊢* notation when you did not have a Turing machine. 
>
> So you are not aware that all comutations have state transitions?
> I count the x86 state transition as moving from one instruction to the
> next.

An H^(H^) reaches its terminal state when directly run in a finite
number of them, so is halting.

>
>> Was that a poetic
>> usage as well, like the license you used to call your C code an "actual
>> Turing machine"?
>>
>>>> Given that you had C code, the "UTM in C++" that you were writing that
>>>> would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
>>>> interpreter.
>>>
>>> It was not a C interpreter. It is an x86 emulator.
>>
>> Below you say it was not an x86 emulator but I not you say "is" not
>> "was".  I'm asking about what the "UTM in C++" that you planned to write
>> was.  You do explain that below.
>>
>
> It matters not what I had. It only matters what I have. If you are
> sincere about an honest dialogue then we must quit focusing on details
> of obsolete technology.
>

You STILL have nothing. H^(H^) Halts, H(H^,H^) says not halting.

BY DEFINITION that is wrong.

Only by changing defintions and thus NOT working on the problem you are
claiming or by asuming untruee premises do you even come close to a
so-called proof.

IT IS UNSOUND.