XPost: comp.theory, sci.logic

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)