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.

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

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

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

>> (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, nor does it explain why you used the
⊢* notation when you did not have a Turing machine. 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.

>> (3c) Did you really think you could write a C interpreter in "a week or
>> two"?
>
> What I thought that I could do in a week or two was write a very
> simple virtual machine language lacking all high level control flow
> structure. Since I have done this before in two weeks I new that I
> could do it again.

Ah, I see. Why call is a UTM? And why, when I offered to write the UTM
for you in a couple of days did you not say "sorry, I don't have a
Turing machine but C code"? Your poetic license seems to extend over
many posts and many terms. From my position it looks like you meant
what you wrote.

>> (3d) Why write an interpreter when C code is better compiled and a
>> debugger can then be used to give any required level of detail
>> about the execution?
>
> I never wrote a C interpreter. I never intended to write a C
> interpreter. The initial idea was to write a compiler for a tiny
> subset of C that is compiled into a very simple virtual machine
> language.

That's an odd way to run C code, but maybe when you post it (you will
post it, yes?) it will be clear why you can't just tidy up the details
and run it, using existing tools to get traces if you need them.

>> In the spirit of mutual understanding, I hope you can see that these
>> mysterious quotes will have led everyone away from the truth (that you
>> had C code) while re-forcing the mistaken impression that you had what
>> you had said you had: an actual Turing machine.
>>
>>>> (4) Using [X] to denote the string that encodes TM X, did your Dec 2018
>>>> H^ halt on input [H^]?
>>>> (5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
>>>> Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
>>>> Either way you should post what you had in Dec 2018. Your conflicting
>>>> claims about what it was are one of the biggest obstacles to honest
>>>> dialogue. With what you had out in the open, we could get some
>>>> agreement on modified versions of (4) and (5).
>> These become
>> (4) Did your Dec 2018 C code for H^ halt on H^?
>
> 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. I was only concerned with
> H(P,P) where P is always aborted and can't ever possibly halt.

Are you able and willing to answer (4)? If you can't, can I help by
explaining the question?

>> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
>> Dec 2018 code come to about "(Ĥ, Ĥ)"?
>
> The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
> H(P,P)==0 now except that the never halting criteria is much more
> elaborate. The initial criteria was very crude.

Ah, so you never had H and H^ that do anything that anyone would say is
impossible. Had you said, back in Dec 2018, "I have C code such that
H(H^,H^) == 0 but H^(H^) halts" no one would have been interested.

I think you owe everyone an apology. Even if there was no indent to
deceive, your words back then did everything possible to suggest some
impossible Turing machine. And you wouldn't say, even when explicitly
asked, what decision H came to.

>>> It is on a single piece of hand-written paper. I don't think that I
>>> ever scanned it.
>> Unless you post it, we can't reach a mutual understanding about your
>> claim to have something that everyone else says is impossible. Maybe
>> you just had some C that does something entirely possible and
>> unsurprising. That is certainly the case now.
>
> It is what I have now that counts. What I had years ago has been
> superseded by newer technology.

Being honest about what you had back then is important if you want
people to trust you. And the technology is immaterial. You are
challenging a mathematical theorem. You must bring mathematical
arguments to the table.

--
Ben.