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.

Although after successful find current_state->symbol would have the same
value as Tape[Tape_Head] it is more clear that we are referring to the
current input with the latter.

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

My way is clearer.

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

I think that it is more clear the way it is.

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

Since the current state must refer to every element of its related
Quintuple and current_state is actually current_state + current_input,
this a single integer does not uniquely identify a Quintuple it seems to
make the most sense to call each Quintuple a state.

It may be more conventional to have a two layered system where an
integer indexes into a list of states each one having a list of inputs
that they respond to. The ads extraneous complexity.

I could call current_state current_quintuple.

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

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(next_state, current_input);
if (it == States.end())
return false;
current_state = it;
return true;
}

The top level loop initializes
int Tape_Head = 0;
std::set<Quintuple>::iterator current_state;

if (!Transition_to_State_0(current_state))
return false;

The top level loop then simply executes transition_function() until false.

while (transition_function(current_state) == true)
;

> That will point you to
> what objects you need and what methods those objects should provide.
>

The key part that I have mapped out the transition_function and the TM
file format. The transition_function is the core of the TM execution
engine.

You didn't point out any actual errors, you simply critiqued my design
aesthetics.

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