Is the following claim true? if not how to prove it?
log_2(n+1)-log_3(2n+1)=O(1)
I think it's probably true from what I have tried.
it's true iff there is c,n+0>0 such that log_2(n+1)-log_3(2n+1) <= c I don't now log laws but from this step it makes sense to be true
The function grows quite slowly, but there is no constant upper bound. So no, the statement is false.
To show this, you do need to know some log laws. The original formula is
Changing base-3 to base-2 gives us
Now changing to a common denominator and combining both logs yields
So the argument inside the log is
which diverges slowly towards infinity, so the logarithm of that also diverges. And hence the whole function cannot be in O(1).
I need to calculate the number of 1's in a binary number, lets say 5, so 00001001 would be 2 or n=2. I am using MIPS. Best way to do this?
The best way to do this is to count them.
You can check if the least significant bit is set (a 1) by anding it with one. If you get a non-zero result, it was set, so you should increment a counter (that was originally initialised to zero of course).
You can shift all the bits of a value right by using logical shifty operators.
You can loop doing both those operations until your value ends up as zero. There are conditional branch instructions in most architectures.
Your task, then, is to find those instructions for MIPS and put them in the correct order :-)
In no particular order, I'd be looking into the following set of instructions: {andi, srl, beq, addi}, though there may be a few others you'll need.
I am trying to prove ~s=>~p (not s implies not p) given the following 2 premises.
r=>s [r implies s]
(p|q)=>(r|s) [(p or q) implies (r or s)]
I have tried several ways, trying to use OR elimination or Negation Introduction, but I can't even visualize which assumptions I will need to use. Would appreciate any and all help that can be provided.
Maybe you're missing that you can combine the two givens before anything else, to eliminate an r term. I don't think you need negation introduction, contrapositing a statement is sufficient.
(p|q)=>(r|s)
(p|q)=>(s|s) //r=>s
(p|q)=>s //simplify
~s=>~(p|q) //by contraposition
~s=>~p and ~s=>~q
~s=>~p
I will prove this by contradiction.
~S=>~P is logically equivalent to P=>S.
P=>S is logically equivalent to ~PvS.
Let v mean "or" and & mean "and".
Suppose ~PvS is false.
Therefore, ~(~PvS) is true. (This just means that the negation of it will be true.)
~(~PvS) = P&~S (De Morgan's Law) -----------(1)
So, if our assumption is correct, then all three statements that we have: P&~S, R=>S,
and (PvQ)=>(RvS) should be all true.
(PvQ)=>(RvS) is logically equivalent to ~(PvQ)v(RvS).
Which is equivalent to (~P&~Q)v(RvS).-------------------(2)
The other premise R=>S is equivalent to ~RvS. ----------(3)
If (1) is true from out assumption, then both P and ~S have to be true. This is because of the nature of the & logical connective.
~S is true, so S must be false. Now we substitute P=True and S=False into (2).
On the Left hand side: If P is true, then ~P must be false. Because of the nature of the & connective, (~P&~Q) must be false regardless of what ~Q is.
So now the Right hand side: (RvS) must be true if we need (2) to be true. Since S is false, then R must be true.
We have now deduced that: S is false, R is true, P is true.
Now we can substitute these truth values into (3). Since S is false. Then ~R must be true.
Hence, ~(~R) is false. Thus, R is false.
However, contradiction with the fact that R is true. So, our original assumption that ~S=>~P is false was wrong. Therefore, ~S=>~P is true.
At the end of the day, the logical equivalences that were mentioned previously can be verified by using a truth table. But it is good to memorize them. Cheers.
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.
The word seems to get used in a number of contexts. The best I can figure is that they mean a variable that can't change. Isn't that what constants/finals (darn you Java!) are for?
An invariant is more "conceptual" than a variable. In general, it's a property of the program state that is always true. A function or method that ensures that the invariant holds is said to maintain the invariant.
For instance, a binary search tree might have the invariant that for every node, the key of the node's left child is less than the node's own key. A correctly written insertion function for this tree will maintain that invariant.
As you can tell, that's not the sort of thing you can store in a variable: it's more a statement about the program. By figuring out what sort of invariants your program should maintain, then reviewing your code to make sure that it actually maintains those invariants, you can avoid logical errors in your code.
It is a condition you know to always be true at a particular place in your logic and can check for when debugging to work out what has gone wrong.
The magic of wikipedia: Invariant (computer science)
In computer science, a predicate that,
if true, will remain true throughout a
specific sequence of operations, is
called (an) invariant to that
sequence.
This answer is for my 5 year old kid. Do not think of an invariant as a constant or fixed numerical value. But it can be. However, it is more than that.
Rather, an invariant is something like of a fixed relationship between varying entities. For example, your age will always be less than that compared to your biological parents. Both your age, and your parent's age changes in the passage of time, but the relationship that i mentioned above is an invariant.
An invariant can also be a numerical constant. For example, the value of pi is an invariant ratio between the circle's circumference over its diameter. No matter how big or small the circle is, that ratio will always be pi.
I usually view them more in terms of algorithms or structures.
For example, you could have a loop invariant that could be asserted--always true at the beginning or end of each iteration. That is, if your loop was supposed to process a collection of objects from one stack to another, you could say that |stack1|+|stack2|=c, at the top or bottom of the loop.
If the invariant check failed, it would indicate something went wrong. In this example, it could mean that you forgot to push the processed element onto the final stack, etc.
As this line states:
In computer science, a predicate that, if true, will remain true throughout a specific sequence of operations, is called (an) invariant to that sequence.
To better understand this hope this example in C++ helps.
Consider a scenario where you have to get some values and get the total count of them in a variable called as count and add them in a variable called as sum
The invariant (again it's more like a concept):
// invariant:
// we have read count grades so far, and
// sum is the sum of the first count grades
The code for the above would be something like this,
int count=0;
double sum=0,x=0;
while (cin >> x) {
++count;
sum+=x;
}
What the above code does?
1) Reads the input from cin and puts them in x
2) After one successful read, increment count and sum = sum + x
3) Repeat 1-2 until read stops ( i.e ctrl+D)
Loop invariant:
The invariant must be True ALWAYS. So initially you start out your code with just this
while(cin>>x){
}
This loop reads data from standard input and stores in x. Well and good. But the invariant becomes false because the first part of our invariant wasn't followed (or kept true).
// we have read count grades so far, and
How to keep the invariant true?
Simple! increment count.
So ++count; would do good!. Now our code becomes something like this,
while(cin>>x){
++count;
}
But
Even now our invariant (a concept which must be TRUE) is False because now we didn't satisfy the second part of our invariant.
// sum is the sum of the first count grades
So what to do now?
Add x to sum and store it in sum ( sum+=x) and the next time
cin>>x will read a new value into x.
Now our code becomes something like this,
while(cin>>x){
++count;
sum+=x;
}
Let's check
Whether code matches our invariant
// invariant:
// we have read count grades so far, and
// sum is the sum of the first count grades
code:
while(cin>>x){
++count;
sum+=x;
}
Ah!. Now the loop invariant is True always and code works fine.
The above example was taken and modified from the book Accelerated C++ by Andrew-koening and Barbara-E
Something that doesn't change within a block of code
All the answers here are great, but i felt that i can shed more light on the matter:
Invariant from a language point of view means something that never changes. The concept though comes actually from math, it's one of the popular proof techniques when combined with induction.
Here is how a proof goes, If you can find an invariant that is in the initial state, And that this invariant persists regardless of any [legal] transformation applied to the state, then you can prove that If a certain state does not have this invariant then it can never occur, no matter what sequence of transformations are applied to the initial state.
Now the previous way of thinking (again combined with induction) makes it possible to predicate the logic of computer software. Especially important when the execution goes in loops, in which an invariant can be used to prove that a certain loop will yield a certain result or that it will never change the state of a program in a certain way.
When invariant is used to predicate a loop logic its called loop invariant. It can be used outside loops, but for loops it is really important, because you often have a lot of possibilities, or an infinite number of possibilities.
Notice that i use the word "predicate" the logic of a computer software, and not prove. And that's because while in math invariant can be used as a proof, it can never prove that the computer software when executed will yield what is expected, due to the fact that the software is executed on top of many abstractions, that can never be proved that they will yield what is expected (think of the hardware abstraction for example).
Finally while theoretically and rigorously predicting software logic is only important for high critical applications like Medical, and Military ones. Invariant can still be used to aid the typical programmer when debugging. It can be used to know where at a certain location The program failed because it has failed to maintain a certain invariant - many of us use it anyway without giving a thought about it.
Class Invariant
Class Invariant is a condition which should be always true before and after calling relevant function
For example balanced tree has an Invariant which is called isBalanced. When you modify your tree through some methods (e.g. addNode, removeNode...) - isBalanced should be always true before and after modifying the tree
Following on from what it is, invariants are quite useful in writing clean code, since knowing conceptually what invariants should be present in your code allows you to easily decide how to organize your code to reach those aims. As mentioned ealier, they're also useful in debugging, as checking to see if the invariant's being maintained is often a good way of seeing if whatever manipulation you're attempting to perform is actually doing what you want it to.
It's typically a quantity that does not change under certain mathematical operations.
An example is a scalar, which does not change under rotations. In magnetic resonance imaging, for example, it is useful to characterize a tissue property by a rotational invariant, because then its estimation ideally does not depend on the orientation of the body in the scanner.
The ADT invariant specifes relationships
among the data fields (instance variables)
that must always be true before and after
the execution of any instance method.
There is an excellent example of an invariant and why it matters in the book Java Concurrency in Practice.
Although Java-centric, the example describes some code that is responsible for calculating the factors of a provided integer. The example code attempts to cache the last number provided, and the factors that were calculated to improve performance. In this scenario there is an invariant that was not accounted for in the example code which has left the code susceptible to race conditions in a concurrent scenario.