On 2022-05-06 12:03, olcott wrote:
> 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.

The way to do that would be to have just left the original quote alone
given that it was already perfectly clear. "Quoting" it without
indicating that it has been altered is simply deceptive.

André

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

On 5/6/2022 1:18 PM, André G. Isaak wrote:
> On 2022-05-06 12:03, olcott wrote:
>> 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:
>>>
>> Yes you are correct this is my mistake. I should have done a more
>> accurate job specifying the original design.
>
> The way to do that would be to have just left the original quote alone
> given that it was already perfectly clear. "Quoting" it without
> indicating that it has been altered is simply deceptive.
>
> André
>

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

This does more succinctly (and thus more clearly) list the essential
elements of the design, that the above paragraph specifies.
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'.

// This must occur before the state transition or we lose access to
// current_quintuple->write_symbol

(c) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'.

When we assume that current_quintuple was found in quintuple_list then
this does seem to correctly 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 next_quintuple;

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

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

Do you think that the above function matches its design?

--
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 12:50, olcott wrote:
> On 5/6/2022 1:18 PM, André G. Isaak wrote:
>> On 2022-05-06 12:03, olcott wrote:
>>> 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:
>>>>
>>> Yes you are correct this is my mistake. I should have done a more
>>> accurate job specifying the original design.
>>
>> The way to do that would be to have just left the original quote alone
>> given that it was already perfectly clear. "Quoting" it without
>> indicating that it has been altered is simply deceptive.
>>
>> André
>>
>
> 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
>
>
> This does more succinctly (and thus more clearly) list the essential
> elements of the design, that the above paragraph specifies.
> 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'.
>
> // This must occur before the state transition or we lose access to
> // current_quintuple->write_symbol
>
> (c) move the tape reading head one symbol to the left or right
>      according to whether 'm' is 'l' or 'r'.
>
> When we assume that current_quintuple was found in quintuple_list then
> this does seem to correctly implement the above design:

Design? Do you mean 'specification'?

> 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 next_quintuple;
>
>   Tape[Tape_Head]   = current_quintuple->write_symbol;
>   if (toupper(current_quintuple->tape_head_move) == “L”;
>     Tape_Head--;  // Left
>   else
>     Tape_Head++;  // Right
>
>   next_quintuple = NextState(next_state, current_input);
>   if (next_quintuple == Quintuple_List.end())
>     return false;
>   current_state = it;
>   return true;
> }
>
> Do you think that the above function matches its design?

I have no idea what 'its design' is supposed to mean.

If by design you mean 'specification', then how is anyone supposed to
tell? You've got a bunch of horribly-named variables and undefined
functions.

What is the point of this exercise? You already have access to a TM
interpreter which written by someone who actually knows what they are
doing. If you can't write a TM which decides evenness, what on earth
would possess you to think you understand TMs well enough to write a TM
interpreter?

André

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

On 5/5/2022 9:51 PM, André G. Isaak wrote:
> 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é
>
>

A correct halt decider must only compute the mapping from its input
parameters to its own final state entirely on the basis of the actual
behavior specified by this actual input.

If this does not work out the way you expect then your expectations are
necessarily incorrect.

--
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 4:42 AM, Mikko wrote:
> 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
>
>

I am currently calling it Quintuple_List.

--
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 4:23 AM, Mikko wrote:
> 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
>

I said exactly the opposite.
When Prolog implements its system based on Facts and Rules it implements
the sound deductive inference model by applying only truth preserving
operations to expressions of language known to be true.

Also negation as failure can detect and reject expressions that are
neither true nor false. Conventional logic cannot possibly do this
because it presumes that ~True entails False (even when it doesn't).

--
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 13:07, olcott wrote:
> On 5/5/2022 9:51 PM, André G. Isaak wrote:
>> 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é
>>
>>
>
> A correct halt decider must only compute the mapping from its input
> parameters to its own final state entirely on the basis of the actual
> behavior specified by this actual input.
>
> If this does not work out the way you expect then your expectations are
> necessarily incorrect.

What on earth does this have to do with my post? I pointed out that
H(P,P) and H1(P,P) have *different* mappings and thus compute
*different* functions. I asked which, if either of these, supposedly
computes the halting function.

I made no claims at all about what the mappings involved were. I only
noted that they are *different* and thus must compute different functions.

André

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

On 5/6/2022 2:05 PM, André G. Isaak wrote:
> On 2022-05-06 12:50, olcott wrote:
>> On 5/6/2022 1:18 PM, André G. Isaak wrote:
>>> On 2022-05-06 12:03, olcott wrote:
>>>> 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:
>>>>>
>>>> Yes you are correct this is my mistake. I should have done a more
>>>> accurate job specifying the original design.
>>>
>>> The way to do that would be to have just left the original quote
>>> alone given that it was already perfectly clear. "Quoting" it without
>>> indicating that it has been altered is simply deceptive.
>>>
>>> André
>>>
>>
>> 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
>>
>>
>> This does more succinctly (and thus more clearly) list the essential
>> elements of the design, that the above paragraph specifies.
>> 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'.
>>
>> // This must occur before the state transition or we lose access to
>> // current_quintuple->write_symbol
>>
>> (c) move the tape reading head one symbol to the left or right
>>       according to whether 'm' is 'l' or 'r'.
>>
>> When we assume that current_quintuple was found in quintuple_list then
>> this does seem to correctly implement the above design:
>
> Design? Do you mean 'specification'?
>
>> 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 next_quintuple;
>>
>>    Tape[Tape_Head]   = current_quintuple->write_symbol;
>>    if (toupper(current_quintuple->tape_head_move) == “L”;
>>      Tape_Head--;  // Left
>>    else
>>      Tape_Head++;  // Right
>>
>>    next_quintuple = NextState(next_state, current_input);
>>    if (next_quintuple == Quintuple_List.end())
>>      return false;
>>    current_state = it;

correction: current_state = next_quintuple;

>>    return true;
>> }
>>
>> Do you think that the above function matches its design?
>
> I have no idea what 'its design' is supposed to mean.
>
> If by design you mean 'specification', then how is anyone supposed to
> tell? You've got a bunch of horribly-named variables and undefined
> functions.
>

A design is a kind of specification.

The functionality of the functions can be inferred from their use.
What do you think is horribly named?

> What is the point of this exercise? You already have access to a TM
> interpreter which written by someone who actually knows what they are
> doing. If you can't write a TM which decides evenness, what on earth
> would possess you to think you understand TMs well enough to write a TM
> interpreter?
>
> André
>

--
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 13:19, olcott wrote:
> On 5/6/2022 2:05 PM, André G. Isaak wrote:
>> On 2022-05-06 12:50, olcott wrote:
>>> On 5/6/2022 1:18 PM, André G. Isaak wrote:
>>>> On 2022-05-06 12:03, olcott wrote:
>>>>> 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:
>>>>>>
>>>>> Yes you are correct this is my mistake. I should have done a more
>>>>> accurate job specifying the original design.
>>>>
>>>> The way to do that would be to have just left the original quote
>>>> alone given that it was already perfectly clear. "Quoting" it
>>>> without indicating that it has been altered is simply deceptive.
>>>>
>>>> André
>>>>
>>>
>>> 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
>>>
>>>
>>> This does more succinctly (and thus more clearly) list the essential
>>> elements of the design, that the above paragraph specifies.
>>> 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'.
>>>
>>> // This must occur before the state transition or we lose access to
>>> // current_quintuple->write_symbol
>>>
>>> (c) move the tape reading head one symbol to the left or right
>>>       according to whether 'm' is 'l' or 'r'.
>>>
>>> When we assume that current_quintuple was found in quintuple_list
>>> then this does seem to correctly implement the above design:
>>
>> Design? Do you mean 'specification'?
>>
>>> 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 next_quintuple;
>>>
>>>    Tape[Tape_Head]   = current_quintuple->write_symbol;
>>>    if (toupper(current_quintuple->tape_head_move) == “L”;
>>>      Tape_Head--;  // Left
>>>    else
>>>      Tape_Head++;  // Right
>>>
>>>    next_quintuple = NextState(next_state, current_input);
>>>    if (next_quintuple == Quintuple_List.end())
>>>      return false;
>>>    current_state = it;
>
> correction: current_state = next_quintuple;
>
>>>    return true;
>>> }
>>>
>>> Do you think that the above function matches its design?
>>
>> I have no idea what 'its design' is supposed to mean.
>>
>> If by design you mean 'specification', then how is anyone supposed to
>> tell? You've got a bunch of horribly-named variables and undefined
>> functions.
>>
>
> A design is a kind of specification.

No. That's not how these words are used. A design and a specification
are entirely different things.

> The functionality of the functions can be inferred from their use.
> What do you think is horribly named?

Well, you've got a variable called current_state that represents a
quintuple rather than a state, for one.

André

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

On 5/6/2022 2:14 PM, André G. Isaak wrote:
> On 2022-05-06 13:07, olcott wrote:
>> On 5/5/2022 9:51 PM, André G. Isaak wrote:
>>> 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é
>>>
>>>
>>
>> A correct halt decider must only compute the mapping from its input
>> parameters to its own final state entirely on the basis of the actual
>> behavior specified by this actual input.
>>
>> If this does not work out the way you expect then your expectations
>> are necessarily incorrect.
>
> What on earth does this have to do with my post? I pointed out that
> H(P,P) and H1(P,P) have *different* mappings and thus compute
> *different* functions. I asked which, if either of these, supposedly
> computes the halting function.

The only relevant point is that H(P,P) and H1(P,P) do correctly compute
the mapping of their inputs to an accept or reject state based on the
actual behavior specified by these inputs.

This is ALL that a halt decider must to to be considered correct on an
input parameter.

That H(P,P) does not derive that same result as H1(P,P) is as relevant
to this discussion as the fact that cats are not dogs.

>
> I made no claims at all about what the mappings involved were. I only
> noted that they are *different* and thus must compute different functions.
>
> André
>

That is moot.
Are H(P,P)==false and H1(P,P)==true correct? Yes, then done.

--
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 2:23 PM, André G. Isaak wrote:
> On 2022-05-06 13:19, olcott wrote:
>> On 5/6/2022 2:05 PM, André G. Isaak wrote:
>>> On 2022-05-06 12:50, olcott wrote:
>>>> On 5/6/2022 1:18 PM, André G. Isaak wrote:
>>>>> On 2022-05-06 12:03, olcott wrote:
>>>>>> 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:
>>>>>>>
>>>>>> Yes you are correct this is my mistake. I should have done a more
>>>>>> accurate job specifying the original design.
>>>>>
>>>>> The way to do that would be to have just left the original quote
>>>>> alone given that it was already perfectly clear. "Quoting" it
>>>>> without indicating that it has been altered is simply deceptive.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>> This does more succinctly (and thus more clearly) list the essential
>>>> elements of the design, that the above paragraph specifies.
>>>> 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'.
>>>>
>>>> // This must occur before the state transition or we lose access to
>>>> // current_quintuple->write_symbol
>>>>
>>>> (c) move the tape reading head one symbol to the left or right
>>>>       according to whether 'm' is 'l' or 'r'.
>>>>
>>>> When we assume that current_quintuple was found in quintuple_list
>>>> then this does seem to correctly implement the above design:
>>>
>>> Design? Do you mean 'specification'?
>>>
>>>> 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 next_quintuple;
>>>>
>>>>    Tape[Tape_Head]   = current_quintuple->write_symbol;
>>>>    if (toupper(current_quintuple->tape_head_move) == “L”;
>>>>      Tape_Head--;  // Left
>>>>    else
>>>>      Tape_Head++;  // Right
>>>>
>>>>    next_quintuple = NextState(next_state, current_input);
>>>>    if (next_quintuple == Quintuple_List.end())
>>>>      return false;
>>>>    current_state = it;
>>
>> correction: current_state = next_quintuple;

current_quintuple = next_quintuple;

>>
>>>>    return true;
>>>> }
>>>>
>>>> Do you think that the above function matches its design?
>>>
>>> I have no idea what 'its design' is supposed to mean.
>>>
>>> If by design you mean 'specification', then how is anyone supposed to
>>> tell? You've got a bunch of horribly-named variables and undefined
>>> functions.
>>>
>>
>> A design is a kind of specification.
>
> No. That's not how these words are used. A design and a specification
> are entirely different things.
>

I don't do it that way.
I have designs at various levels of abstraction/versus specificity.
The most specific level of design is the actual coding in C++.
Just above this is the pseudo code.

>> The functionality of the functions can be inferred from their use.
>> What do you think is horribly named?
>
> Well, you've got a variable called current_state that represents a
> quintuple rather than a state, for one.
>
> André
>

Yet another typo.

--
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 13:34, olcott wrote:
> On 5/6/2022 2:23 PM, André G. Isaak wrote:
>> On 2022-05-06 13:19, olcott wrote:

>>> A design is a kind of specification.
>>
>> No. That's not how these words are used. A design and a specification
>> are entirely different things.
>>
>
> I don't do it that way.

And that's a major part of your problem: You keep inventing your own
meanings for words which already have well-established usage and thus
have absolutely no hope of ever communicating your ideas to anyone.

Worse, you misinterpret most everything you read because you substitute
your own private meanings for whatever the author actually intended to say.

André

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

On 5/6/2022 2:37 PM, André G. Isaak wrote:
> On 2022-05-06 13:34, olcott wrote:
>> On 5/6/2022 2:23 PM, André G. Isaak wrote:
>>> On 2022-05-06 13:19, olcott wrote:
>
>>>> A design is a kind of specification.
>>>
>>> No. That's not how these words are used. A design and a specification
>>> are entirely different things.
>>>
>>
>> I don't do it that way.
>
> And that's a major part of your problem: You keep inventing your own
> meanings for words which already have well-established usage and thus
> have absolutely no hope of ever communicating your ideas to anyone.
>

A software requirements specification (SRS) is a document that describes
what the software will do and how it will be expected to perform. It
also describes the functionality the product needs to fulfill all
stakeholders (business, users) needs.

https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-document#what-is-a-software-requirements-specification-document

So it is merely a design with enough detail that the system can be
implemented on the basis of the spec. This is exactly the same thing as
my next to last level of detailed design.

My designs start with very high level abstractions

---Begin Design of Simplest TM Interpreter---
(1) Parse Lines of text in the filename.tm file into
(a) structure of five fields.
(1) current state // possibly redundant
(2) current symbol
(3) next state
(4) write symbol
(5) Move tape head L(eft) or R(ight)
(b) single contiguous sequence of tape elements
(2) Make executable TM

And are progressively refined until working code is derived.

> Worse, you misinterpret most everything you read because you substitute
> your own private meanings for whatever the author actually intended to say.
>
> André
>

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

André G. Isaak <agisaak@gm.invalid> writes:

> What is the point of this exercise?

It's a delaying tactic. PO can now claim that he's started to write the
TM I called E, but since no existing interpreter meets his exacting
standards, he simply must sort that out first.

There may also be a legitimate purpose. It's possible that PO hopes
that by writing an interpreter he will gain enough understanding of TMs
to write E.

--
Ben.

On 5/6/2022 6:47 PM, Ben wrote:
> André G. Isaak <agisaak@gm.invalid> writes:
>
>> What is the point of this exercise?
>
> It's a delaying tactic. PO can now claim that he's started to write the
> TM I called E, but since no existing interpreter meets his exacting
> standards, he simply must sort that out first.
>
> There may also be a legitimate purpose. It's possible that PO hopes
> that by writing an interpreter he will gain enough understanding of TMs
> to write E.
>

I wanted a Minimal TM interpreter that has <= three minute learning
curve for people that already know TM's very well.

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 then
(a) make a transition to state 's'.

(b) overwrite the symbol 'C' on the tape with the symbol 'c'.
// Must do this before transition to state 's' or we lose 'c' from S.

(c) move the tape reading head one symbol to the left or right
according to whether 'm' is 'l' or 'r'

THIS SEEMS TO EXACTLY MATCH THE SPEC PROVIDED ABOVE.
THE SPEC SEEMS TO HAVE AN ERROR (see above) THAT WAS ACCOUNTED FOR.

bool Quintuple_List::transition_function
(std::set<Quintuple>::iterator& current_quintuple)
{ unsigned int next_state = current_quintuple->next_state;
unsigned int current_input = Tape[Tape_Head];
std::set<Quintuple>::iterator next_quintuple;

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

next_quintuple = NextState(next_state, current_input);
if (next_quintuple == States.end())
return false;
current_quintuple = next_quintuple;
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

olcott <polcott2@gmail.com> writes:

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

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

Their only properties are that they are distinct and finite in number.
I have written an interpreter in which the states are instances of a
class State, that holds all the information a TM might need when in that
state. But there are a hundreds of other ways to represent the states.

> Do you think that they are raw integers?

No, that's not what they are, though you could use integers to represent
them. You could also use characters, strings and pointers to state
objects.

A key consideration, though, is that you might want to print information
about the states to help the user of the interpreter so the states
should be identifiable in some what that matches the way the user writes
the TM. So I tend to favour labelling the sates with strings so that
messages can report things like:

In state 'open_(_seen': no transition for symbol '+'.

If you are matching the input scheme for the implementation you posted a
link to, then you should be able to report the state's name as the
character the user will have entered.

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

Of course, but a set is not, in my opinion, the natural container for
quintuples. Do you even know how to make it work in your case? It
would involve what I would consider a bit of trickery.

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

It returns an iterator to a quintuple, not a state, so the name is bad.
And why does the function take things called 'next_state' and
'current_input'? The next quintuple is determined by the current state
and the current input.

> 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;
> }

This looks all messed up but mainly because I don't think you are using
the right names.

And it's still a very loose sketch. Setting current_state is
essentially pointless.

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

I think the best way to judge that will be to compare code. At the
moment you only have a very rough sketch.

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

Let's see how it turns out in the end.

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

I think a lot of the problems a down to your uses state when you mean
quintuple. NextState seems all wrong, but maybe it makes more sense if
it does not find the next state but the next quintuple.

> 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;
> }

With proper renaming this sketch makes a bit more sense. You take a
current rule (I am getting tired typing quintuple) and NextState really
finds the next rule, not state.

But the details are still all wrong. NextRule (as I'd call it) needs to
use next_state and the new current_input, not the input you find at the
top of the function. And setting current_state (which should be called
current_rule) is pointless since it's about to be thrown away.

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

You take my remarks how you like. When you show this code to a
compiler, you'll see more problems.

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

olcott <polcott2@gmail.com> writes:

> bool Quintuple_List::transition_function
> (std::set<Quintuple>::iterator& current_quintuple)
> {
> unsigned int next_state = current_quintuple->next_state;
> unsigned int current_input = Tape[Tape_Head];
> std::set<Quintuple>::iterator next_quintuple;
>
> Tape[Tape_Head] = current_quintuple->write_symbol;
> if (toupper(current_quintuple->tape_head_move) == 'L')
> Tape_Head--; // Left
> else
> Tape_Head++; // Right
>
> next_quintuple = NextState(next_state, current_input);
> if (next_quintuple == States.end())
> return false;
> current_quintuple = next_quintuple;
> return true;
> }

Much better names, but still not right. There's no point is setting
current_quintuple at the end, and the symbol used to look up the next
quintuple is the wrong one. And Sates is still misnamed: the iterators
are into a set of Quintuples, not states.

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

On 5/6/2022 8:57 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> 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:
>
>>>>>> 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?
>
> Their only properties are that they are distinct and finite in number.

Ah so you are only seeing the mathematical abstraction that uses
directed graphs. That is not enough for an actual hardware machine to go
on.

> I have written an interpreter in which the states are instances of a
> class State, that holds all the information a TM might need when in that
> state. But there are a hundreds of other ways to represent the states.
>

In other words this:
struct Quintuple
{ int state;
int symbol;
int write_symbol;
int next_state;
char tape_head_move;
};

>> Do you think that they are raw integers?
>
> No, that's not what they are, though you could use integers to represent
> them. You could also use characters, strings and pointers to state
> objects.
>
> A key consideration, though, is that you might want to print information
> about the states to help the user of the interpreter so the states
> should be identifiable in some what that matches the way the user writes
> the TM. So I tend to favour labelling the sates with strings so that
> messages can report things like:
>

I am going to make it compatible with the TM interpreter files and I
will always output the full execution trace. I am aiming for a three
minute learning curve for everyone that knows TM's very well.

> In state 'open_(_seen': no transition for symbol '+'.
>
> If you are matching the input scheme for the implementation you posted a
> link to, then you should be able to report the state's name as the
> character the user will have entered.
>

full execution trace.

>>>> 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).
>
> Of course, but a set is not, in my opinion, the natural container for
> quintuples. Do you even know how to make it work in your case? It
> would involve what I would consider a bit of trickery.
>
>> 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).
>
> It returns an iterator to a quintuple, not a state, so the name is bad.
> And why does the function take things called 'next_state' and
> 'current_input'? The next quintuple is determined by the current state
> and the current input.

It is specified by the TM interpreter specs.

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 then
(a) make a transition to state 's'.

(b) overwrite the symbol 'C' on the tape with the symbol 'c'.
// Must do this before transition to state 's' or we lose 'c' from S.

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

>> 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;
>> }
>
> This looks all messed up but mainly because I don't think you are using
> the right names.
>
> And it's still a very loose sketch. Setting current_state is
> essentially pointless.
>

It performs ALL of the steps of transitioning to the start state.

>>>> {
>>>> 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.
>
> I think the best way to judge that will be to compare code. At the
> moment you only have a very rough sketch.

The "rough sketch" is fully operational code.
I am adding parse capability.

>>>> 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.
>
> Let's see how it turns out in the end.
>
>> 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.
>
> I think a lot of the problems a down to your uses state when you mean
> quintuple. NextState seems all wrong, but maybe it makes more sense if
> it does not find the next state but the next quintuple.
>

NextState does this:
(a) make a transition to state 's'.

>> 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;
>> }
>
> With proper renaming this sketch makes a bit more sense. You take a
> current rule (I am getting tired typing quintuple) and NextState really
> finds the next rule, not state.
>

On 5/6/2022 9:04 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> bool Quintuple_List::transition_function
>> (std::set<Quintuple>::iterator& current_quintuple)
>> {
>> unsigned int next_state = current_quintuple->next_state;
>> unsigned int current_input = Tape[Tape_Head];
>> std::set<Quintuple>::iterator next_quintuple;
>>
>> Tape[Tape_Head] = current_quintuple->write_symbol;
>> if (toupper(current_quintuple->tape_head_move) == 'L')
>> Tape_Head--; // Left
>> else
>> Tape_Head++; // Right
>>
>> next_quintuple = NextState(next_state, current_input);
>> if (next_quintuple == States.end())
>> return false;
>> current_quintuple = next_quintuple;
>> return true;
>> }
>
> Much better names, but still not right. There's no point is setting
> current_quintuple at the end, and the symbol used to look up the next
> quintuple is the wrong one. And Sates is still misnamed: the iterators
> are into a set of Quintuples, not states.
>

It is a reference parameter thus current_state is set to the state that
was transitioned to. true / false is returned on success / failure.

My execution engine simple loops until NextState() returns false.

--
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 9:04 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> bool Quintuple_List::transition_function
>> (std::set<Quintuple>::iterator& current_quintuple)
>> {
>> unsigned int next_state = current_quintuple->next_state;
>> unsigned int current_input = Tape[Tape_Head];
>> std::set<Quintuple>::iterator next_quintuple;
>>
>> Tape[Tape_Head] = current_quintuple->write_symbol;
>> if (toupper(current_quintuple->tape_head_move) == 'L')
>> Tape_Head--; // Left
>> else
>> Tape_Head++; // Right
>>
>> next_quintuple = NextState(next_state, current_input);
>> if (next_quintuple == States.end())
>> return false;
>> current_quintuple = next_quintuple;
>> return true;
>> }
>
> Much better names, but still not right. There's no point is setting
> current_quintuple at the end, and the symbol used to look up the next
> quintuple is the wrong one. And Sates is still misnamed: the iterators
> are into a set of Quintuples, not states.
>

I got the whole thing almost done.
I figured out a simpler way to parse the tape data.
The std::set:find works perfectly.

--
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 19:14:24 +0000, olcott said:

> On 5/6/2022 4:23 AM, Mikko wrote:
>> 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
>>
>
> I said exactly the opposite.

As can be seen above:
You did not.
I asked: "Is Prolog invalid?"
You said "It would have to be invalid."
Here "It" apparently means "Prolog" but I wansn't quite sure
so I asked whether you meant something else. In your reply
you didn't say I was misinterpreting you so obviously I wasn't.
If you now say otherwise it can only mean that you have changed
your mind.

Mikko

On 5/7/2022 3:42 AM, Mikko wrote:
> On 2022-05-06 19:14:24 +0000, olcott said:
>
>> On 5/6/2022 4:23 AM, Mikko wrote:
>>> 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
>>>
>>
>> I said exactly the opposite.
>
> As can be seen above:
> You did not.
> I asked: "Is Prolog invalid?"
> You said "It would have to be invalid."
> Here "It" apparently means "Prolog" but I wansn't quite sure
> so I asked whether you meant something else. In your reply
> you didn't say I was misinterpreting you so obviously I wasn't.
> If you now say otherwise it can only mean that you have changed
> your mind.
>
> Mikko
>

Prolog is valid, it is much valid, much more valid than symbolic or
classical logic.

--
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 8:57 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> 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:
>
>>>>>> 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?
>
> Their only properties are that they are distinct and finite in number.
> I have written an interpreter in which the states are instances of a
> class State, that holds all the information a TM might need when in that
> state. But there are a hundreds of other ways to represent the states.
>
>> Do you think that they are raw integers?
>
> No, that's not what they are, though you could use integers to represent
> them. You could also use characters, strings and pointers to state
> objects.
>
> A key consideration, though, is that you might want to print information
> about the states to help the user of the interpreter so the states
> should be identifiable in some what that matches the way the user writes
> the TM. So I tend to favour labelling the sates with strings so that
> messages can report things like:
>
> In state 'open_(_seen': no transition for symbol '+'.
>
> If you are matching the input scheme for the implementation you posted a
> link to, then you should be able to report the state's name as the
> character the user will have entered.
>
>>>> 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).
>
> Of course, but a set is not, in my opinion, the natural container for
> quintuples. Do you even know how to make it work in your case? It
> would involve what I would consider a bit of trickery.
>
>> 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).
>
> It returns an iterator to a quintuple, not a state, so the name is bad.
> And why does the function take things called 'next_state' and
> 'current_input'? The next quintuple is determined by the current state
> and the current input.
>
>> 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;
>> }
>
> This looks all messed up but mainly because I don't think you are using
> the right names.
>
> And it's still a very loose sketch. Setting current_state is
> essentially pointless.
>
>>>> {
>>>> 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.
>
> I think the best way to judge that will be to compare code. At the
> moment you only have a very rough sketch.
>
>>>> 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.
>
> Let's see how it turns out in the end.
>
>> 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.
>
> I think a lot of the problems a down to your uses state when you mean
> quintuple. NextState seems all wrong, but maybe it makes more sense if
> it does not find the next state but the next quintuple.
>
>> 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;
>> }
>
> With proper renaming this sketch makes a bit more sense. You take a
> current rule (I am getting tired typing quintuple) and NextState really
> finds the next rule, not state.
>

http://www.lns.mit.edu/~dsw/turing/turing.html
David S. Woodruff calls it next state:

This is his spec:
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 then
(a) make a transition to state 's'.
(b) overwrite the symbol 'C' on the tape with the symbol 'c'.
// Must do this before transition to state 's' or we lose 'c' from S.
(c) 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

olcott <polcott2@gmail.com> writes:

> On 5/6/2022 8:57 PM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> 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:
>>
>>>>>>> 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?
>> Their only properties are that they are distinct and finite in number.
>
> Ah so you are only seeing the mathematical abstraction that uses
> directed graphs. That is not enough for an actual hardware machine to
> go on.

Nonsense. It's perfectly practical and entirely natiral to implement
this using a directed graph.

>> I have written an interpreter in which the states are instances of a
>> class State, that holds all the information a TM might need when in that
>> state. But there are a hundreds of other ways to represent the states.
>
> In other words this:
> struct Quintuple
> {
> int state;
> int symbol;
> int write_symbol;
> int next_state;
> char tape_head_move;
> };

This is not a state. States are not quintuples and vice-versa. Please
don't pick this hill fight on.

>>> 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;
>>> }
>> This looks all messed up but mainly because I don't think you are using
>> the right names.
>> And it's still a very loose sketch. Setting current_state is
>> essentially pointless.
>
> It performs ALL of the steps of transitioning to the start state.

Nope. I really don't like arguing about programming because the hard
test is will it work. This won't, and you'll find out when you run your
first tests.

>>> My way is clearer.
>> I think the best way to judge that will be to compare code. At the
>> moment you only have a very rough sketch.
>
> The "rough sketch" is fully operational code.

That's very revealing. You've claimed to have other "fully operational
code" and since these sketches are clearly not operational, you must be
using the phrase in some rather loose way.

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

On 5/7/2022 6:01 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/6/2022 8:57 PM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> 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:
>>>
>>>>>>>> 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?
>>> Their only properties are that they are distinct and finite in number.
>>
>> Ah so you are only seeing the mathematical abstraction that uses
>> directed graphs. That is not enough for an actual hardware machine to
>> go on.
>
> Nonsense. It's perfectly practical and entirely natiral to implement
> this using a directed graph.
>

A directed graph with labeled edges would seem to require all this (node
and edge) info kept in a single struct when physically implemented as
software. One node could have a list of edge data, yet that is cumbersome.

>>> I have written an interpreter in which the states are instances of a
>>> class State, that holds all the information a TM might need when in that
>>> state. But there are a hundreds of other ways to represent the states.
>>
>> In other words this:
>> struct Quintuple
>> {
>> int state;
>> int symbol;
>> int write_symbol;
>> int next_state;
>> char tape_head_move;
>> };
>
> This is not a state. States are not quintuples and vice-versa. Please
> don't pick this hill fight on.

I want to grok this.

>
>>>> 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;
>>>> }
>>> This looks all messed up but mainly because I don't think you are using
>>> the right names.
>>> And it's still a very loose sketch. Setting current_state is
>>> essentially pointless.
>>
>> It performs ALL of the steps of transitioning to the start state.
>
> Nope. I really don't like arguing about programming because the hard
> test is will it work. This won't, and you'll find out when you run your
> first tests.
>
>>>> My way is clearer.
>>> I think the best way to judge that will be to compare code. At the
>>> moment you only have a very rough sketch.
>>
>> The "rough sketch" is fully operational code.
>

More accurately the The "rough sketch" is my best estimate of is fully
operational code.

> That's very revealing. You've claimed to have other "fully operational
> code" and since these sketches are clearly not operational, you must be
> using the phrase in some rather loose way.
>

I was trying to make it clear that it is not a more sketch with many
missing pieces. All the pieces are there.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer