What is the difference between if(++x < 0){something} and if(x + 1 < 0){something}
Thanks in advance
The ++x increments the value of x immediately by 1 and this new value of x is compared with 0.
While x+1 does not increment the value of x and it's original value remains the same, only the output of x+1 is compared with 0.
++x increases x by one and returns the result. x + 1 leaves x as is and returns its value increased by one. So the difference is in the value of x after the operation.
The context (inside if condition or not) is irrelevant here.
Related
I've came across this snippet of code on a book:
public static short countBits(int x) {
short numBit = 0;
while(x != 0) {
numBit += (x&1);
x >>>= 1;
}
return numBit;
}
However, I'm not really sure how numBit += (x&1); and x >>>= 1 works.
I think that numBit += (x&1) is comparing AND for a single digit and 1. Does it mean that if my binary number is 10001, the function is ANDing the 1000"1" bit with 1 on the first iteration of the while loop?
Also, what's the point of >>>= 1 ? I think that ">>>" is shifting the bits to the right by three but I can't figure out the purpose of doing so in this function.
Any help would be much appreciated. Thank you!
This function counts the number of bits that are set to "1". x & 1 is a bitwise-AND with the least significant bit of x's current value (either 1 if x is odd, or 0 if it's even). As such it makes perfect sense to add it to result. x >>>= 1 is equivalent to x = x >> 1 and this means "shift bits in x by 1 position to the right" (or, for unsigned integers, divide x by 2).
I'm currently stuck on a loop invariant proof in my home assignment. The algorithm that I need to prove correctness of, is:
Multiply(a,b)
x=a
y=0
WHILE x>=b DO
x=x-b
y=y+1
IF x=0 THEN
RETURN(y)
ELSE
RETURN(-1)
I've tried to look at several examples of loop invariants and I have some sense of idea of how its supposed to work out. However in this algorithm above, I have two exit conditions, and I'm a bit lost on how to approach this in a loop invariant proof. In particular its the termination part I'm struggling with, around the IF and ELSE statements.
So far what I've constructed is simply by looking at the termination of the algorithm in which case if x = 0 then it returns the value of y containing the value of n (number of iterations in the while loop), where as if x is not 0, and x < b then it returns -1. I just have a feeling I need to prove this some how.
I hope someone can help share some light on this for me, as the similar cases I've found in here, have not been sufficient.
Thanks alot in advance for your time.
Provided that the algorithm terminates (for this let's assume a>0 and b>0, which is sufficient), one invariant is that at every iteration of your while loop, you have x + by = a.
Proof:
at first, x = a and y = 0 so that's ok
If x + by = a, then (x - b) + (y + 1)b = a, which are the values of x and y for your next iteration
Illustration:
Multiply(a,b)
x=a
y=0
// x + by = a, is true
WHILE x>=b DO
// x + by = a, is true
x=x-b // X = x - b
y=y+1 // Y = y + 1
// x + by = a
// x - b + by + b = a
// (x-b) + (y+1)b = a
// X + bY = a, is still true
// x + by = a, will remain true when you exit the loop
// since we exited the loop, x < b
IF x=0 THEN
// 0 + by = a, and 0 < b
// y = a/b
RETURN(y)
ELSE
RETURN(-1)
This algorithm returns a/b when b divides a, and -1 otherwise. Multiply does not quite sound like an appropriate name for it...
We can't prove correctness without a specification of exactly what the function is supposed to do, which I can't find in your question. Even the name of the function doesn't help: as noted already, your function returns a/b most of the time when b divides a, and -1 otherwise. Multiply is an inappropriate name for it.
Furthermore, if b=0 and a>=b the "algorithm" doesn't terminate so it isn't even an algorithm.
As Alex M noted, a loop invariant for the loop is x + by = a. At the moment the loop exits, we also have x < b. There are no other guarantees on x because (presumably) a could be negative. If we had a guarantee that a and b are positive, then we could guarantee that 0<=x<b at the moment the loop exits, which would mean that it implements the division with remainder algorithm (at the end of the loop, y is quotient and x is remainder, and it terminates by an "infinite descent" type argument: a decreasing sequence of positive integers x must terminate). Then you could conclude that if x=0, b divides a evenly, and the quotient is returned, otherwise -1 is returned.
But that is not a proof, because we are lacking a specification for what the algorithm is supposed to do, and a specification on restrictions on its inputs. (Are a and b any positive integers? Negative and 0 not allowed?)
I am trying to evaluate if a selected item meats a requirement. I am trying to evaluate the result of nominal + x against required.
I am using the following code:
if #weight.nominal + x = required
weights << #weight.id
end
However, it adds nominal + x together. Why is that, and how do I do what I want?
As #Pavan said in the comment, your conditional might be wrong. It should be == instead of =. = is the assignment.
if #weight.nominal + x == required ... end
Here what happens "behind the scene" with your original code:
required is assigned to x.
Add x to #weight.nominal (#weight.nominal + x)
Evaluate the result from step 2, which is always true.
Execute the code within if block, which is weights << #weight.id
Eventually, your x's value is lost, it will take required value instead and your conditional is useless since it always true.
I need to write a loop
for x in (1..y)
where the y variable can be changed somehow. How can I do that?
For example:
for x in (1..y/x)
But it does not work.
Normally we'd use a loop do with a guard clause:
x = 1
loop do
break if x >= y
x += 1
...
end
Make sure y is larger than x or it'll never do anything. y can change if necessary and as long as it's greater than x the loop will continue. As soon as y drops below x the loop will terminate on the next iteration.
Note: I use >= because testing for equality is a bug-in-waiting. Sometimes we try to compare where x starts out greater than y or we are incrementing a float and comparing it to an integer or another float and using == and never hit the magic "equal" causing the loop to run away. Instead always check for a greater-than-or-equal to end the loop.
I think you might be confused about return values. This actually works fine, it's just that the return value is equal to the original range.
y = 4
for x in (1..y)
puts x
end
# 1
# 2
# 3
# 4
#=> 1..4
Here's a code snippet to prove it.
For y = 1 to 10
y = y+1
print(y)
Next
For the above code the output which I get is 2,4,6,8,10. Shouldn't the o/p be 2,3,4,5,6,7,8,9,10
Can I consider y = y+1 as y++
The default step increment for a vbscript for loop is 1. By adding in y=y+1, you are effectively increasing your increment by 2 each cycle:
For y = 2 to 10 step 2
Wscript.echo y
Next
There is no "increment operator" as such; However you could consider step an increment operator in this context (both positive and negative).
y = y + 1 is similar as the intended concept y++.
You would probably be best using that type of operation inside a do/while loop where there are no auto increments eg:
y = 0
do while y < 10
y = y + 1
wscript.echo y
Loop
See this previous post:
Does VBScript have Increment Operators
in a For...Next loop, you won'T need to increase the counter value manualy.
You are increasing the value that is increased by the For loop:
For y = 1 to 10 ' starts at 1, next is 3
y = y+1 ' but you increase it to 2, increased to 4
print(y) ' prints 2, 4
Next ' Increases to 3, 5, up to 11, then stops because it's greater than 10
No, VB Script doesn't have an increment operator. VB script is based on BASIC which is a language meant for learning and the increment operator is considered to be confusing by many so it was never added on purpose.
As for your second question, to get the output you want remove y = y+1 line and change loop to For y = 2 to 10. Also, yes, y=y+1 is the same as y++ in most languages.