Design a FA to accept L, where L = {Strings in which ‘a’ always appears tripled} over the input set Σ = {a, b}.
This is my solution (A is start state):
From what I understand the question doesn't say it should always contain "a",
it should also accept strings like {b,bb,bbb}. Is this correct?
Your solution appears right to me! It really depends on the interpretation of the question. I also interpreted that a's could also be separated, as long as they were always tripled.
abbabbbab should be accepted as a's are tripled always, come in threes.
You should make sure of that! I also did this FA in the case above, but my generic understanding of the question would be your interpretation which looks fine!
When speaking of coverage criteria such as MCDC (Modified Condition/Decision Criteria)...
It is stated that "Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken all possible outcomes at least once, and each condition has been shown to affect that decision outcome independently. A condition is shown to affect a decision's outcome independently by varying just that condition while holding fixed all other possible conditions. [...]"
- https://en.wikipedia.org/wiki/Modified_condition/decision_coverage
This description is rather vague of what constitutes an independent criteria... So, what are they? Examples are helpful in any language (C-family/python/haskell preferred).
The wikipedia definition is an informal statement, a more precise definition of MDCD is:
For each condition c, in each decision d, there is a test such that:
There is a test such that c == true
There is a test such that c == false
If the outcome of d when c == true is x, then the result of d when c == false must be !x.
All other conditions in d evaluate identically in both test cases.
If it is possible to create test set which meet these criteria, then this shows that each condition is not redundant: each condition at least influences the control of the program in some situation (as there is a test case that demonstrates this). This is what is meant by "independently influences the outcome".
I'm trying to understand this algorithm the DFA minimization algorithm at http://www.cs.umd.edu/class/fall2009/cmsc330/lectures/discussion2.pdf where it says:
while until there is no change in the table contents:
For each pair of states (p,q) and each character a in the alphabet:
if Distinct(p,q) is empty and Distinct(δ(p,a), δ(q,a)) is not empty:
set distinct(p,q) to be x
The bit I don't understand is "Distinct(δ(p,a), δ(q,a))" I think I understand the transition function where δ(p,a) = whatever state is reached from p with input a. but with the following DFA:
http://i.stack.imgur.com/arZ8O.png
resulting in this table:
imgur.com/Vg38ZDN.png
shouldn't (c,b) also be marked as an x since distinct(δ(b,0), δ(c,0)) is not empty (d) ?
Distinct(δ(p,a), δ(q,a)) will only be non-empty if δ(p,a) and δ(q,a) are distinct. In your example, δ(b,0) and δ(c,0) are both d. Distinct(d, d) is empty since it doesn't make sense for d to be distinct with itself. Since Distinct(d, d) is empty, we don't mark Distinct(c, b).
In general, Distinct(p, p) where p is a state will always be empty. Better yet, we don't consider it because it doesn't make sense.
Consider the DFA :
What will be δ(A,01) equal to ?
options:
A) {D}
B) {C,D}
C) {B,C,D}
D) {A,B,C,D}
The correct answer is option B) but I don't get how. Please some one explain me the steps to solve it and also in general how do we solve sit for any DFA and any transition?
Thanks.
B) Option is not Correct answer! for this transition graph.
In Transition Graph(TG) symbol ε means NULL-move (ε-move). There is two NULL-moves in TG.
One: (A) --- `ε` ---->(B)
Second: (A) --- `ε` ---->(C)
A ε-move means without consume any symbol you can change state. In your diagram from A to B, or A to C.
What will be δ(A,01) equal to ?
Question asked "what is path from state A if input is 01". (as I understand because there is only one final state)
01 can be processed in either of two ways.
(A) -- ε --->(B) -- 0 --> (B) -- 1 --> (D)
(A) -- ε --->(C) -- 0 --> (B) -- 1 --> (D)
Also, there is no other way to process string 01 even if you don't wants to reach final state.
[ANSWER]
So there is misprinting in question (or either you did).
You can learn how to remove NULL-move from transition graph. Also HOW TO WRITE REGULAR EXPRESSION FOR A DFA
If you remove null-moves from TG you will get three ways to accept 01.
EQUIVALENT TRANSITION GRAPH WITHOUT NULL-MOVE
Note there is three start-states in Graph.
Three ways:
{ABD}
{CBD}
{BBD}
In all option state-(B) has to be come.
Also, you have written Consider the DFA : is wrong. The TG is not deterministic because there is there is non-deterministic move δ(A,ε) and next states are either B or C.
I want to check whether a value is equal to 1. Is there any difference in the following lines of code
Evaluated value == 1
1 == evaluated value
in terms of the compiler execution
In most languages it's the same thing.
People often do 1 == evaluated value because 1 is not an lvalue. Meaning that you can't accidentally do an assignment.
Example:
if(x = 6)//bug, but no compiling error
{
}
Instead you could force a compiling error instead of a bug:
if(6 = x)//compiling error
{
}
Now if x is not of int type, and you're using something like C++, then the user could have created an operator==(int) override which takes this question to a new meaning. The 6 == x wouldn't compile in that case but the x == 6 would.
It depends on the programming language.
In Ruby, Smalltalk, Self, Newspeak, Ioke and many other single-dispatch object-oriented programming languages, a == b is actually a message send. In Ruby, for example, it is equivalent to a.==(b). What this means, is that when you write a == b, then the method == in the class of a is executed, but when you write b == a, then the method in the class of b is executed. So, it's obviously not the same thing:
class A; def ==(other) false end; end
class B; def ==(other) true end; end
a, b = A.new, B.new
p a == b # => false
p b == a # => true
No, but the latter syntax will give you a compiler error if you accidentally type
if (1 = evaluatedValue)
Note that today any decent compiler will warn you if you write
if (evaluatedValue = 1)
so it is mostly relevant for historical reasons.
Depends on the language.
In Prolog or Erlang, == is written = and is a unification rather than an assignment (you're asserting that the values are equal, rather then testing that they are equal or forcing them to be equal), so you can use it for an assertion if the left hand side is a constant, as explained here.
So X = 3 would unify the variable X and the value 3, whereas 3 = X would attempt to unify the constant 3 with the current value of X, and be equivalent of assert(x==3) in imperative languages.
It's the same thing
In general, it hardly matters whether you use,
Evaluated value == 1 OR 1 == evaluated value.
Use whichever appears more readable to you. I prefer if(Evaluated value == 1) because it looks more readable to me.
And again, I'd like to quote a well known scenario of string comparison in java.
Consider a String str which you have to compare with say another string "SomeString".
str = getValueFromSomeRoutine();
Now at runtime, you are not sure if str would be NULL. So to avoid exception you'll write
if(str!=NULL)
{
if(str.equals("SomeString")
{
//do stuff
}
}
to avoid the outer null check you could just write
if ("SomeString".equals(str))
{
//do stuff
}
Though this is less readable which again depends on the context, this saves you an extra if.
For this and similar questions can I suggest you find out for yourself by writing a little code, running it through your compiler and viewing the emitted asembler output.
For example, for the GNU compilers, you do this with the -S flag. For the VS compilers, the most convenient route is to run your test program in the debugger and then use the assembeler debugger view.
Sometimes in C++ they do different things, if the evaluated value is a user type and operator== is defined. Badly.
But that's very rarely the reason anyone would choose one way around over the other: if operator== is not commutative/symmetric, including if the type of the value has a conversion from int, then you have A Problem that probably wants fixing rather than working around. Brian R. Bondy's answer, and others, are probably on the mark for why anyone worries about it in practice.
But the fact remains that even if operator== is commutative, the compiler might not do exactly the same thing in each case. It will (by definition) return the same result, but it might do things in a slightly different order, or whatever.
if value == 1
if 1 == value
Is exactly the same, but if you accidentally do
if value = 1
if 1 = value
The first one will work while the 2nd one will produce an error.
They are the same. Some people prefer putting the 1 first, to void accidentally falling into the trap of typing
evaluated value = 1
which could be painful if the value on the left hand side is assignable. This is a common "defensive" pattern in C, for instance.
In C languages it's common to put the constant or magic number first so that if you forget one of the "=" of the equality check (==) then the compiler won't interpret this as an assignment.
In java, you cannot do an assignment within a boolean expression, and so for Java, it is irrelevant which order the equality operands are written in; The compiler should flag an error anyway.