On 5/14/2024 4:44 AM, Mikko wrote:
On 2024-05-12 15:58:02 +0000, olcott said:
On 5/12/2024 10:21 AM, Mikko wrote:
On 2024-05-12 11:34:17 +0000, Richard Damon said:
On 5/12/24 5:19 AM, Mikko wrote:
On 2024-05-11 16:26:30 +0000, olcott said:
I am working on providing an academic quality definition of this >>>>>>> term.
The definition in Wikipedia is good enough.
I think he means, he is working on a definition that redefines the
field to allow him to claim what he wants.
Here one can claim whatever one wants anysay.
In if one wants to present ones claims on some significant forum then
it is better to stick to usual definitions as much as possible.
Sort of like his new definition of H as an "unconventional" machine
that some how both returns an answer but also keeps on running.
There are systems where that is possible but unsolvable problems are
unsolvable even in those systems.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
This notation does not work with machines that can, or have parts
that can, return a value without (or before) termination.
⊢* specifies a wildcard set of state transitions that could
include a transition to a non-final state embedded_H.qn.
On 5/14/2024 1:30 PM, Fred. Zwarts wrote:
Op 14.mei.2024 om 19:52 schreef olcott:
On 5/14/2024 12:49 PM, Fred. Zwarts wrote:
Op 14.mei.2024 om 19:14 schreef olcott:
On 5/14/2024 11:13 AM, Fred. Zwarts wrote:
Op 14.mei.2024 om 17:45 schreef olcott:
On 5/14/2024 10:42 AM, Fred. Zwarts wrote:
Op 14.mei.2024 om 17:30 schreef olcott:
On 5/14/2024 10:08 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 5/14/2024 4:44 AM, Mikko wrote:
On 2024-05-12 15:58:02 +0000, olcott said:
On 5/12/2024 10:21 AM, Mikko wrote:
On 2024-05-12 11:34:17 +0000, Richard Damon said:
On 5/12/24 5:19 AM, Mikko wrote:
On 2024-05-11 16:26:30 +0000, olcott said:
I am working on providing an academic quality >>>>>>>>>>>>>>>>> definition of this
term.
The definition in Wikipedia is good enough.
I think he means, he is working on a definition that >>>>>>>>>>>>>>> redefines the
field to allow him to claim what he wants.
Here one can claim whatever one wants anysay.
In if one wants to present ones claims on some significant >>>>>>>>>>>>>> forum then
it is better to stick to usual definitions as much as >>>>>>>>>>>>>> possible.
Sort of like his new definition of H as an
"unconventional" machine
that some how both returns an answer but also keeps on >>>>>>>>>>>>>>> running.
There are systems where that is possible but unsolvable >>>>>>>>>>>>>> problems are
unsolvable even in those systems.
When Ĥ is applied to ⟨Ĥ⟩This notation does not work with machines that can, or have >>>>>>>>>>>> parts
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>
that can, return a value without (or before) termination. >>>>>>>>>>
00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>> 01 int D(ptr x)
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 H(D,D);
12 }
In any case you diverged away form the whole point of this >>>>>>>>>>> thread.
Richard is wrong when he says that there exists an H/D pair such >>>>>>>>>>> that D simulated by H ever reaches past its own line 03.
Yes, in the same way that you are wrong. The above "C code" >>>>>>>>>> is garbage;
as already pointed out, it doesn't even compile. So any talk of >>>>>>>>>> "reaching line 3" or "matching" that "code" is vacuous nonsense. >>>>>>>>>>
Any H/D pair matching the above template where D(D) is simulated >>>>>>>>> by the same H(D,D) that it calls cannot possibly reach past its >>>>>>>>> own
line 03. Simple software engineering verified fact.
Since nobody knows who has verified this fact en there have been >>>>>>>> counter examples,
*See if you can show that your claim of counter-examples is not a >>>>>>> lie*
*See if you can show that your claim of counter-examples is not a >>>>>>> lie*
*See if you can show that your claim of counter-examples is not a >>>>>>> lie*
*YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
IS THAT BECAUSE YOU KNOW IT IS FALSE?
*YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
IS THAT BECAUSE YOU KNOW IT IS FALSE?
*YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
IS THAT BECAUSE YOU KNOW IT IS FALSE?
Olcott is trying to stay at this point for several weeks now, but
he does not succeed. The reason probably is, that it is already a
few steps too far. First there must be agreement about the words
and terms used in what he says. So, we should delay this subject
and go back a few steps.
Before we can talk about this, first there must be 100% agreement
about:
1) What is a "verified fact"? Who needs to do the verification
before it can be said that it is a verified fact?
I am ONLY referring to expressions that are PROVEN
to be {true entirely on the basis of their meaning}.
*CONCRETE EXAMPLES*
How do we know that 2 + 3 = 5?
If needed we can write out the proof for this, starting from the
axioms for natural numbers. That proof is well known.
But nobody here knows the proof for your assertion above, that it is
a verified fact that it cannot reach past line 03. So, we would like
to see that proof. Just the claim that it has been proven is not
enough.
The "nobody here" you are referring to must be clueless
about the semantics of the C programming language.
Are you honest? Please, give the proof, instead of keeping away from it.
I have been an expert C/C++ programmer for decades.
If you knew C will enough yourself you would comprehend
that my claim about:
Any H/D pair matching the above template where
D(D) is simulated by the same H(D,D) that it calls
cannot possibly reach past its own line 03.
This is a simple software engineering verified fact.
My grandfather was a diagnostician and pathologist
said: "You can't argue with ignorance".
You give the impression that you are clueless about how to prove it.
The only evidence you gave, are the personal attacks to people who ask
for it, which does not convince anybody.
It is your claim. You have the burden of the proof.
We need to be 100% sure before we can proceed to the next step.
On 5/15/2024 3:21 AM, Mikko wrote:
On 2024-05-14 19:42:08 +0000, olcott said:
On 5/14/2024 2:36 PM, Fred. Zwarts wrote:
Op 14.mei.2024 om 20:40 schreef olcott:
On 5/14/2024 1:30 PM, Fred. Zwarts wrote:
Op 14.mei.2024 om 19:52 schreef olcott:
On 5/14/2024 12:49 PM, Fred. Zwarts wrote:
Op 14.mei.2024 om 19:14 schreef olcott:
On 5/14/2024 11:13 AM, Fred. Zwarts wrote:
Op 14.mei.2024 om 17:45 schreef olcott:
On 5/14/2024 10:42 AM, Fred. Zwarts wrote:
Op 14.mei.2024 om 17:30 schreef olcott:
On 5/14/2024 10:08 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 5/14/2024 4:44 AM, Mikko wrote:
On 2024-05-12 15:58:02 +0000, olcott said:
On 5/12/2024 10:21 AM, Mikko wrote:
On 2024-05-12 11:34:17 +0000, Richard Damon said: >>>>>>>>>>>>>>
On 5/12/24 5:19 AM, Mikko wrote:
On 2024-05-11 16:26:30 +0000, olcott said:
I am working on providing an academic quality >>>>>>>>>>>>>>>>>>>>> definition of this
term.
The definition in Wikipedia is good enough.
I think he means, he is working on a definition that >>>>>>>>>>>>>>>>>>> redefines the
field to allow him to claim what he wants.
Here one can claim whatever one wants anysay. >>>>>>>>>>>>>>>>>> In if one wants to present ones claims on some >>>>>>>>>>>>>>>>>> significant forum then
it is better to stick to usual definitions as much as >>>>>>>>>>>>>>>>>> possible.
Sort of like his new definition of H as an >>>>>>>>>>>>>>>>>>> "unconventional" machine
that some how both returns an answer but also keeps >>>>>>>>>>>>>>>>>>> on running.
There are systems where that is possible but >>>>>>>>>>>>>>>>>> unsolvable problems are
unsolvable even in those systems.
When Ĥ is applied to ⟨Ĥ⟩This notation does not work with machines that can, or >>>>>>>>>>>>>>>> have parts
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>
that can, return a value without (or before) termination. >>>>>>>>>>>>>>
00 int H(ptr x, ptr x) // ptr is pointer to int function >>>>>>>>>>>>>>> 01 int D(ptr x)Yes, in the same way that you are wrong. The above "C >>>>>>>>>>>>>> code" is garbage;
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 H(D,D);
12 }
In any case you diverged away form the whole point of >>>>>>>>>>>>>>> this thread.
Richard is wrong when he says that there exists an H/D >>>>>>>>>>>>>>> pair such
that D simulated by H ever reaches past its own line 03. >>>>>>>>>>>>>>
as already pointed out, it doesn't even compile. So any >>>>>>>>>>>>>> talk of
"reaching line 3" or "matching" that "code" is vacuous >>>>>>>>>>>>>> nonsense.
Any H/D pair matching the above template where D(D) is >>>>>>>>>>>>> simulated
by the same H(D,D) that it calls cannot possibly reach past >>>>>>>>>>>>> its own
line 03. Simple software engineering verified fact.
Since nobody knows who has verified this fact en there have >>>>>>>>>>>> been counter examples,
*See if you can show that your claim of counter-examples is >>>>>>>>>>> not a lie*
*See if you can show that your claim of counter-examples is >>>>>>>>>>> not a lie*
*See if you can show that your claim of counter-examples is >>>>>>>>>>> not a lie*
*YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
IS THAT BECAUSE YOU KNOW IT IS FALSE?
*YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
IS THAT BECAUSE YOU KNOW IT IS FALSE?
*YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
IS THAT BECAUSE YOU KNOW IT IS FALSE?
Olcott is trying to stay at this point for several weeks now, >>>>>>>>>> but he does not succeed. The reason probably is, that it is >>>>>>>>>> already a few steps too far. First there must be agreement >>>>>>>>>> about the words and terms used in what he says. So, we should >>>>>>>>>> delay this subject and go back a few steps.
Before we can talk about this, first there must be 100%
agreement about:
1) What is a "verified fact"? Who needs to do the verification >>>>>>>>>> before it can be said that it is a verified fact?
I am ONLY referring to expressions that are PROVEN
to be {true entirely on the basis of their meaning}.
*CONCRETE EXAMPLES*
How do we know that 2 + 3 = 5?
If needed we can write out the proof for this, starting from the >>>>>>>> axioms for natural numbers. That proof is well known.
But nobody here knows the proof for your assertion above, that >>>>>>>> it is a verified fact that it cannot reach past line 03. So, we >>>>>>>> would like to see that proof. Just the claim that it has been
proven is not enough.
The "nobody here" you are referring to must be clueless
about the semantics of the C programming language.
Are you honest? Please, give the proof, instead of keeping away
from it.
I have been an expert C/C++ programmer for decades.
If you knew C will enough yourself you would comprehend
that my claim about:
Any H/D pair matching the above template where
D(D) is simulated by the same H(D,D) that it calls
cannot possibly reach past its own line 03.
This is a simple software engineering verified fact.
My grandfather was a diagnostician and pathologist
said: "You can't argue with ignorance".
Again no trace of a proof. Only your authority and personal attacks
about lack of knowledge and ignorance. So, the text below still stands: >>>>
*The only sufficient proof is being an expert in C yourself*
I know what a proof is and I know what C is so I know that that is false.
What I said was not precisely correct. None-the-less claiming that
I am wrong without knowing the subject matter is the
https://dictionary.findlaw.com/definition/reckless-disregard-of-the-truth.html
of defamation cases and dishonest.
Claiming that I am wrong knowing that no single valid counter-example
proving that I am wrong exists is dishonest and defamation.
typedef int (*ptr)(); // ptr is pointer to int function
00 int H(ptr x, ptr x);
01 int D(ptr x)
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 H(D,D);
12 return 0;
13 }
Any H/D pair matching the above template where
D(D) is simulated by the same H(D,D) that it calls
cannot possibly reach past its own line 03.
This is a simple software engineering verified fact.
On 5/15/2024 11:20 AM, joes wrote:
Am Wed, 15 May 2024 10:10:24 -0500 schrieb olcott:
On 5/15/2024 3:17 AM, Mikko wrote:Contradiction in three lines.
On 2024-05-14 19:34:52 +0000, olcott said:Not at all. Not in the least. Deductive proofs cannot rely on an
*Anyone that says that I am wrong without knowing C is dishonest*First you should prove that you know C.
argument from authority.
Anyone that knows C and claims that I am wrong either provides theOr doesn’t care.
required single valid counter-example proving that I am wrong or meets
the [definition] of defamation cases.
If the simply don't care they won't take a position
against me. If the baselessly take a position against
me THAT IS DEFAMATION !!!
*I will update my words to say this*
It is self-evidently true to anyone having sufficient knowledge
of the semantics of the C programming language.
Again no proof. But it seems that olcott is slowly starting to
understand that it is not self-evident, because he now shows a small
beginning of an attempt for a proof. It is a pity for him that he
ignored the rest of my post where I told him a brief outline for a proof.
What we still miss are the requirements for H.
I try to do the best that I can to write my words so that even people
with attention deficit disorder (ADD) can understand them.
The ONLY requirement for H as I have said many many hundreds of times
is that H simulates D.
The self-evident meaning of what D correctly simulated by H means is
now specified so that people trying as hard as possible to make sure
to find any loophole to intentionally misinterpret my words will look
much more foolish.
A working example is not enough to define an infinite set of H. So,
define the requirements.
I did and always have. Possibly not well enough for people having
ADD that can hardly pay any attention. Not well enough for people
having insufficient knowledge of the semantics of C.
Then, do not only claim that there is a simulation invariant, but
prove it.
Prove that 2 + 3 = 5 to someone that does not know what numbers are.
No need for any proof for people that understand arithmetic.
Of course you need to master a language to express such a proof. If
you don't master such a language, try to learn it. Claiming, without
evidence, that it is self-evident is not part of the correct language.
If you have ADD and can't pay attention or do not know the semantics
of C well enough to understand that I have proved my point I don't
know what I can do to help you understand that what I have said has
always been self-evidently true for everyone having sufficient
knowledge of the semantics of C.
Tell me which part you don't understand and I might be able to help.
If you have no idea what infinite recursion is then I cannot help.
Then explain how H determines that there is a recursive simulation, so
that it can abort the simulation.
*That is not any part of what I claimed above*
*That is not any part of what I claimed above*
*That is not any part of what I claimed above*
*You must pay 100% complete attention to my exact words*
*You must pay 100% complete attention to my exact words*
*You must pay 100% complete attention to my exact words*
If you don't have that much attention span, I can't help.
If you don't have that much attention span, I can't help.
If you don't have that much attention span, I can't help.
On 5/17/24 12:34 PM, olcott wrote:
The key thing to note is that no D correctly simulated by any H of
every H/D pair specified by the template below ever reaches its own
line 06 and halts.
Which, since I posted over two weeks ago how to do it in C, means that
you don't have the needed knowledge of the C programming language, or
about what truth actually is.
And the fact that you refuse to take up any of my challenges to have me repost the link (because you clearly prefer to just lie rather that try
to do some research) it is clear that you are not actually certain of
your claim, so you know you may be lying, but you do it anyway.
And you are proven to just be an ignorant damned pathological liar.
There are several correct diagnostic messages, what one are you suggesting? >>
If there are correct diagnostic messages, then your code is not "C" code.
On 2024-05-18 01:07:17 +0000, Richard Damon said:
On 5/17/24 12:07 PM, olcott wrote:
On 5/17/2024 4:28 AM, Mikko wrote:
On 2024-05-16 14:37:59 +0000, olcott said:
On 5/16/2024 5:15 AM, Mikko wrote:
On 2024-05-15 15:03:20 +0000, olcott said:
On 5/15/2024 3:04 AM, Mikko wrote:
On 2024-05-14 14:21:10 +0000, olcott said:
On 5/14/2024 4:44 AM, Mikko wrote:
On 2024-05-12 15:58:02 +0000, olcott said:
On 5/12/2024 10:21 AM, Mikko wrote:This notation does not work with machines that can, or have parts >>>>>>>>>> that can, return a value without (or before) termination.
On 2024-05-12 11:34:17 +0000, Richard Damon said:
On 5/12/24 5:19 AM, Mikko wrote:Here one can claim whatever one wants anysay.
On 2024-05-11 16:26:30 +0000, olcott said:
I am working on providing an academic quality definition >>>>>>>>>>>>>>> of this
term.
The definition in Wikipedia is good enough.
I think he means, he is working on a definition that >>>>>>>>>>>>> redefines the field to allow him to claim what he wants. >>>>>>>>>>>>
In if one wants to present ones claims on some significant >>>>>>>>>>>> forum then
it is better to stick to usual definitions as much as possible. >>>>>>>>>>>>
Sort of like his new definition of H as an "unconventional" >>>>>>>>>>>>> machine that some how both returns an answer but also keeps >>>>>>>>>>>>> on running.
There are systems where that is possible but unsolvable >>>>>>>>>>>> problems are
unsolvable even in those systems.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>
⊢* specifies a wildcard set of state transitions that could >>>>>>>>> include a transition to a non-final state embedded_H.qn.
The term "wildcard" is usually not used in this context. And the >>>>>>>> word
"set" is not sufficiently specific, so "sequence" should be used >>>>>>>> instead.
Yes that is better.
⊢* specifies a wildcard sequence of state transitions
That still has the problem that "wildcard" has no well known meaning >>>>>> that could be applicable in that context.
*Here is how Linz says it*
The Linz term “move” means a state transition and its corresponding >>>>>>> tape head action {move_left, move_right, read, write}.
⊢* indicates an arbitrary number of moves.
I.e., a sequence of moves.
Not as easy for software engineers.
Wildcard as * was one of the first things that I learned.
It is well known in the field of regular expressions.
In the usual language of regular expressions the wildcard
metacharecter is point "." and the metacaracters "*", "+"
denote repetition, "+" at least once.
That is not the term used when computer science students are taught
how to find files matching a pattern. I know a lot about deterministic
finite automatons having two issued patents on them.
Nope, that IS the definition of REGULAR EXPRESSION, it isn't the
definitoin of GLOBBING like is done at the command line.
Look at https://en.wikipedia.org/wiki/Regular_expression
The asterisk indicates zero or more occurrences of the preceding
element. For example, ab*c matches "ac", "abc", "abbc", "abbbc", and
so on.
I know a lot about regular expressions because I used regular
expressions in the AWK programming language to search a massive
code-base of millions of lines to analyze the system that required
maintenance.
That a "wildcard" is a well known word is one of the reasons
why the term should not be used when the same meaning is not
applicable.
It does include zero or more state transitions in a sequence of state
transitions. Linz calls this moves to also include tape head actions.
Another reason is that one should never use a word where it
does not affect the meaning of the containing expression. As
"⊢*" means 'a sequence of moves' you shold not use more words
to express its meaning.
Several of my reviewers took a very long time to understand that
the Linz proof refers to Turing machine description templates and
not a single Turing machine. We had to go over this exact same
thing many hundreds of times.
Nope, Linz CLEARLY refers to H in the singular as a single machine.
The diagram is a requirements statement that H must meet, but H is not
"at once" all machines that meet that requirement.
Yeat another reason is that when one borrows a notation one
should also borrow the terms used in discussion of the notation
unles they conflict with terms borrowed from elsewhere.
It might be best if I simply directly quote Linz and then explain his
words in terms that software engineers can understand.
Try it.
Anyway, the language cannot handle a situation where one part of a >>>>>>>> machine gives its result to another parts and then both continue >>>>>>>> their
execution.
The language of Turing machine descriptions certainly can handle >>>>>>> TM's that do not halt. It can also handle transitioning through
a specific state to another state.
Yes, but a machine were one part of a machine gives its result to
aonter part and then both continue their exection is not a Truing
machine.
Sure it is. A Turing machine that transitions through a specific state >>>>> and never stops running IS A TURING MACHINE.
No, it is not. A machine where several parts are executed at the same
time is not a Turing machine.
(1)--->(2)--->(3) is a DFA that transitions through its state (2).
A TM can transition through a specific state because a TM is more
powerful than a DFA.
If a part of a Turing machine never
stops it execution it perevents all execution of other parts.
If a machine is stuck in an infinite loop it can say
"I am stuck in an infinite loop" infinitely.
No, because Turing Machines don't "say" anything until they halt.
In Turing's original formulation they do. Turing had a special subset
of tape characters that could not be erased. His main focus was on
machines that never halt but keep producing more and more digits of
some real number or some other endless output.
On 5/17/24 12:07 PM, olcott wrote:
On 5/17/2024 4:28 AM, Mikko wrote:
On 2024-05-16 14:37:59 +0000, olcott said:
On 5/16/2024 5:15 AM, Mikko wrote:
On 2024-05-15 15:03:20 +0000, olcott said:
On 5/15/2024 3:04 AM, Mikko wrote:
On 2024-05-14 14:21:10 +0000, olcott said:
On 5/14/2024 4:44 AM, Mikko wrote:
On 2024-05-12 15:58:02 +0000, olcott said:
On 5/12/2024 10:21 AM, Mikko wrote:This notation does not work with machines that can, or have parts >>>>>>>>> that can, return a value without (or before) termination.
On 2024-05-12 11:34:17 +0000, Richard Damon said:
On 5/12/24 5:19 AM, Mikko wrote:
On 2024-05-11 16:26:30 +0000, olcott said:
I am working on providing an academic quality definition of this >>>>>>>>>>>>>> term.
The definition in Wikipedia is good enough.
I think he means, he is working on a definition that redefines the >>>>>>>>>>>> field to allow him to claim what he wants.
Here one can claim whatever one wants anysay.
In if one wants to present ones claims on some significant forum then
it is better to stick to usual definitions as much as possible. >>>>>>>>>>>
Sort of like his new definition of H as an "unconventional" machineThere are systems where that is possible but unsolvable problems are
that some how both returns an answer but also keeps on running. >>>>>>>>>>>
unsolvable even in those systems.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>
⊢* specifies a wildcard set of state transitions that could
include a transition to a non-final state embedded_H.qn.
The term "wildcard" is usually not used in this context. And the word >>>>>>> "set" is not sufficiently specific, so "sequence" should be used instead.
Yes that is better.
⊢* specifies a wildcard sequence of state transitions
That still has the problem that "wildcard" has no well known meaning >>>>> that could be applicable in that context.
*Here is how Linz says it*
The Linz term “move” means a state transition and its corresponding >>>>>> tape head action {move_left, move_right, read, write}.
⊢* indicates an arbitrary number of moves.
I.e., a sequence of moves.
Not as easy for software engineers.
Wildcard as * was one of the first things that I learned.
It is well known in the field of regular expressions.
In the usual language of regular expressions the wildcard
metacharecter is point "." and the metacaracters "*", "+"
denote repetition, "+" at least once.
That is not the term used when computer science students are taught
how to find files matching a pattern. I know a lot about deterministic
finite automatons having two issued patents on them.
Nope, that IS the definition of REGULAR EXPRESSION, it isn't the
definitoin of GLOBBING like is done at the command line.
Look at https://en.wikipedia.org/wiki/Regular_expression
The asterisk indicates zero or more occurrences of the preceding
element. For example, ab*c matches "ac", "abc", "abbc", "abbbc", and so
on.
I know a lot about regular expressions because I used regular
expressions in the AWK programming language to search a massive
code-base of millions of lines to analyze the system that required
maintenance.
That a "wildcard" is a well known word is one of the reasons
why the term should not be used when the same meaning is not
applicable.
It does include zero or more state transitions in a sequence of state
transitions. Linz calls this moves to also include tape head actions.
Another reason is that one should never use a word where it
does not affect the meaning of the containing expression. As
"⊢*" means 'a sequence of moves' you shold not use more words
to express its meaning.
Several of my reviewers took a very long time to understand that
the Linz proof refers to Turing machine description templates and
not a single Turing machine. We had to go over this exact same
thing many hundreds of times.
Nope, Linz CLEARLY refers to H in the singular as a single machine.
The diagram is a requirements statement that H must meet, but H is not
"at once" all machines that meet that requirement.
Yeat another reason is that when one borrows a notation one
should also borrow the terms used in discussion of the notation
unles they conflict with terms borrowed from elsewhere.
It might be best if I simply directly quote Linz and then explain his
words in terms that software engineers can understand.
Try it.
Anyway, the language cannot handle a situation where one part of a >>>>>>> machine gives its result to another parts and then both continue their >>>>>>> execution.
The language of Turing machine descriptions certainly can handle
TM's that do not halt. It can also handle transitioning through
a specific state to another state.
Yes, but a machine were one part of a machine gives its result to
aonter part and then both continue their exection is not a Truing
machine.
Sure it is. A Turing machine that transitions through a specific state >>>> and never stops running IS A TURING MACHINE.
No, it is not. A machine where several parts are executed at the same
time is not a Turing machine.
(1)--->(2)--->(3) is a DFA that transitions through its state (2).
A TM can transition through a specific state because a TM is more
powerful than a DFA.
If a part of a Turing machine never
stops it execution it perevents all execution of other parts.
If a machine is stuck in an infinite loop it can say
"I am stuck in an infinite loop" infinitely.
No, because Turing Machines don't "say" anything until they halt.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 498 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 31:48:28 |
| Calls: | 9,798 |
| Calls today: | 17 |
| Files: | 13,751 |
| Messages: | 6,188,908 |