In the context of DO-178B, the number of conditions and inputs might differ: (A && B) or (A && C) has three inputs but four conditions because each occurence of A is considered a unique condition.
Multiple condition coverage requires 2^n test cases, where n is the number of inputs.
But what about this:
if(X>100 && X<200 && X!=50)
There are three conditions using the same input but I am sure that is not what the authors mean, otherwise I would need just two test cases to cover all combinations among those conditions.
Then I wonder, what is then meant by input - a boolean value in the decision? That would make sense in the quote I mentioned, as A will have the same value in all occurences. But I would like to understand and know if my thought is correct.
I am not familiar with DO-178B, but from the statement that they require
2^n test cases, where n is the number of inputs
I would deduce that the number of inputs in this context is the number of different (or independent) conditions.
This has nothing to do with the fact that in your example all conditions depend on only one integer variable.
However, in your example you will not be able to generate all 2^3 test cases because the 3rd condition is redundant. So in practice you would remove it and end up with two inputs.
Related
When two variables is logically compared, the logic gate that tests the equivalence ..
If XOR please explain Why ?
if XNOR Please explain Why?
The answer is XNOR. As for why, just look at the truth table for 2 inputs:
You see that it returns 1 if either both inputs are 1 or both inputs are 0, or in different words, when the inputs are of the same value. This can be described as checking for equivalence.
This can also be seen by looking at what XNOR means: "eXclusive Not OR". That means that it is the opposite of checking whether exactly one input is 1 (since "exclusive OR" means either one of the outputs may be 1 but not both), i.e. checking whether either none or both of the inputs are 1, i.e. checking whether either both inputs are 1 or both inputs are 0, i.e. whether both inputs are equivalent.
(It can also be called NXOR, which in my opinion is clearer. Because an exclusive OR of two inverted values would give the same result as without the negation, but this is the inversion of an exclusive OR.)
I need to anonymyze personal data in our MySql database. The problem is that I still need to be able to link two persons together after they have been anonymized.
I thought this could be done by hashing their social security number or e-mail address, which lead to my question:
When hashing two equal strings (s1 and s1) I get two hash values (h1 and h2), how sure can I be that:
1) the hashed value is equal (h1 = h2)
2) no not equal (s3 = s1) will produce the same hash value
1) Same strings will always produce equal hash values
2) Different strings theoretically might produce same hash if you choose small hash length compared to data volume. But using default hash lengths (32 or 40) wont cause such problems.
1) (h1 = h2) is always true for equal strings (s1 and s2) per definition, when using a correct hash function.
2) Two different strings can have the same hash value. This is called a "collsison". The probability depends on the hash function used and the length of the resulting hash. For MD5 for example there are websites and tables for finding collisions, which is quite interesting.
I'm not sure what you mean by linking persons together or what your requirements are, so I cannot help you with that. But you could link two persons together with their ids.
This seems to me pretty obvious, There is not but I might be leaving a special case.
As I see it 1SAT (only one literal per clause) and 2SAT can be easily transformed into 3SAT.
An any clause with more than 3 literas has been proven it can be transformed into 3SAT.
So maybe the question should be asked as:
Do all boolean algebra can be put into SAT? or
can we define boolean algebra with ony these operators? AND OR and NOT
No, there is not.
I will not give the full proof but here is the main idea: Write the given formula in a normal form i.e. conjunction of disjunctions. Use induction on the number of variables on an expression. Pick the longest subexpression with n+1 variables, introduce a new variable for some part of subexpression to leave an expression of n variables, add the constraints for the new variable to the formula, repeat the procedure as many times as needed to have a formula where the longest subexpression has n variables.
Referring to the while rule for total correctness, WP seems to tell me that just finding a loop variant that strictly decreases is enough to prove termination. I can't accept that, either because I'm missing something or the rule is wrong. Consider
int i = 1000;
while(true) i--;
in which the value of variable i is a strictly decreasing loop variant, but the loop certainly doesn't terminate.
Surely the rule needs to have an additional precondition, something like i<0 → ¬B (where B is the loop condition in the axiom schema) so that the loop condition eventually 'catches' the loop variant and exits.
Or have I missed something?
The loop-variant must be a natural number. A natural number cannot decrease past zero. Using big words, the loop variant is a value that is monotonically decreasing with respect to a well-founded relation. It's the well-foundedness that's missing from your reasoning.
As noted in the Wikipedia article:
[...] the condition B must imply that t is
not a minimal element of its range,
for otherwise the premise of this rule
would be false.
In the case at hand, B is true and t is i. true makes no implication about the minimality of i, so the premise of the rule is not met.
The usual ordering "<" is well-founded on the natural numbers, but not on the integers. In order for a relation to be well-founded, every non-empty subset of its domain must have a minimal element. Since it can be shown that there is no infinite descending chain with respect to a well-founded relation, it follows that a loop with a variant must terminate.
Of course the condition of the loop must be false in the case of a minimal element!
A variant need not be restricted to the natural numbers, however. Transfinite ordinals are also well-ordered.
I am faced with a problem where I have to calculate intersections between all pairs in a collection of sets. None of the sets are smaller than a small constant k, and I'm only interested in whether two sets have an intersection larger than k-1 elements or not. I do not need the actual intersections nor the exact size, only whether it's larger than k-1 or not. Is there some clever pre-processing trick or a neat set intersection algorithm that I could use to speed things up?
More info that can be useful to answer the question:
The sets represent maximal cliques in a large, undirected, sparse graph. The number of sets can be in the order of tens of thousands or more, but most of the sets are likely to be small.
The sets are already sorted members of each set are in increasing order. Effectively they are sorted lists - I receive them this way from an underlying library for maximal clique search.
Nothing is known about the distribution of elements in the sets (i.e. whether they are in tight clumps or not).
Most of the set intersections are likely to be empty, so the ideal solution would be a clever data structure that helps me cut down the number of set intersections I have to make.
Consider a mapping with all sets of size k as the keys and corresponding values of lists of all sets from your collection that contain the key as a subset. Given this mapping, you don't need to perform any intersection tests: for each key, all pairs of sets from the list will have an intersection of size at least k. This approach can produce the same pair of sets more than once, so that will need to be checked.
The mapping is easy enough to calculate. For each set in the collection, calculate all the size-k subsets and append the original set to the list for that key set. But is this actually faster? In general, no. The performance of this approach will depend on the distribution of the sizes of the sets in the collection and the value of k. With d distinct elements in the sets, you could have as many as d choose k keys, which can be very large.
However, the basic idea is usable to reduce the number of intersections. Instead of using sets of size k, use smaller ones of fixed size q as the keys. The values are again lists of all sets that have the key as a subset. Now, test each pair of sets from the list for intersection. Thus, with q=1 you only test those pairs of sets that have at least one element in common, with q=2 you only test those pairs of sets that have at least two elements in common, and so on. The optimal value for q will depend on the distribution of sizes of the sets, I think.
For the sets in question, a good choice might be q=2. The keys are then just the edges of the graph, giving a predictable size to the mapping. Since most sets are expected to be disjoint, q=2 should eliminate a lot of comparisons without much additional overhead.
One possible optimization, which is more effective the smaller the range of values contained in each set:
Create a list of all the sets, sorted by their kth-greatest element (this is easy to find, since you already have each set with its elements in order). Call this list L.
For any two sets A and B, their intersection cannot have as many as k elements in it if the kth-greatest element in A is less than the least element in B.
So, for each set in turn, calculate its intersection only with the sets in the relevant part of L.
You can use the same fact to exit early from computing the intersection of any two sets - if there are only n-1 elements left to compare in one of the sets, and the intersection so far contains at most k-n elements, then stop. The above procedure is simply this rule applied to all the sets in L at once, with n=k, at the point where we're looking at the least element of set B and the kth-greatest element of A.
The following strategy should be quite efficient. I've used variations of this for intersecting ascending sequences on a number of occasions.
First I assume that you have some sort of priority queue available (if not, rolling your own heap is pretty easy). And a fast key/value lookup (btree, hash, whatever).
With that said, here is pseudocode for an algorithm that should do what you want quite efficiently.
# Initial setup
sets = array of all sets
intersection_count = key/value lookup with keys = (set_pos, set_pos) and values are counts.
p_queue = priority queue whose elements are (set[0], 0, set_pos), organized by set[0]
# helper function
def process_intersections(current_sets):
for all pairs of current_sets:
if pair in intersection_count:
intersection_count[pair] += 1
else:
intersection_count[pair] = 1
# Find all intersections
current_sets = []
last_element = first element of first thing in p_queue
while p_queue is not empty:
(element, ind, set_pos) = get top element from p_queue
if element != last_element:
process_intersections(current_sets)
last_element = element
current_sets = []
current_sets.append(set_pos)
ind += 1
if ind < len(sets[set_pos]):
add (sets[set_pos][ind], ind, set_pos) to p_queue
# Don't forget the last one!
process_intersections(current_sets)
final answer = []
for (pair, count) in intersection_count.iteritems():
if k-1 < count:
final_answer.append(pair)
The running time will be O(sum(sizes of sets) * log(number of sets) + count(times a point is in a pair of sets). In particular note that if two sets have no intersection, you never try to intersect them.
What if you used a predictive subset as a prequalifier. Pre-sort, but use a subset intersection as a threshold condition. If subset intersection > n% then complete the intersection, otherwise abandon. n then becomes the inverse of your comfort level with the prospect of a false positive.
You could also sort by the subset intersections(m) calculated earlier and begin running the full intersection ordered by m descending. So presumably the majority of your highest m intersections would likely cross your k threshold on the full subset and the probably of hitting your k threshold would continually decrease.
This really starts to treat the problem as NP-Complete.