if 1 <= A[i] <= 100 || 1 <= B[i] <= 100
for the above line I get these two error.
1. Adjacent operators are in non-associative precedence group 'Comparision Precendence'
2. Binary operator "<=" can not be applied to type BOOL and Int.
try if (1 <= A[i] && A[i] <= 100) || (1 <= B[i] && B[i] <= 100)
Joe's answer and Leo's comment would both work. My preference would be Leo's approach (using 1...100 ~= A[i]), but whatever floats your boat.
That said, let me explain WHY what you did is giving you an error. Without any parenthesis to break it up, it evaluates that going left to right. So if first checks "is 1 <= A[i]?", and that results in a boolean answer. It then tries to ask "is true <= 100?", which makes no sense.
Related
I have various inputs that vary in width. I have to detect if each input falls within some specific ranges. For example, an input may be 6 bits and hence in theory have values of 0-63. However, I want to check if it happens to be 2-5, 8, 14-50, 52, 54, 56-58, 61-63. Is there any method that is more area-efficient for synthesis than doing straight-up range or equal comparisons? Currently I would have:
always_comb begin
value_is_in_special_range = 1'b0;
if (
(value >= 'd2 && value <= 'd5) ||
(value == 'd8) ||
(value >= 'd14 && value <= 'd50) ||
(value == 'd52) ||
(value == 'd54) ||
(value >= 'd56 && value <= 'd58) ||
(value >= 'd61 && value <= 'd63) ||
) begin
value_is_in_special_range = 1'b1;
end
end
The specific ranges for various inputs are quite random and could fall nicely within relatively few large ranges, or they could be scattered all over the place.
You should be able to put this code into the synthesis tool and optimization should take care of sharing common sub expressions to make all these comparisons most efficient. This assumes all the values and ranges you want comparisons to are constants.
BTW, a simpler way of writing this expression in SystemVerilog is using the set membership operator:
assign value_is_in_special_range =
value inside {[2:5], 8, [14:50], 52, 54, [56:58], [61:63]};
I'm trying to create a function that would verify if a value is within chosen boundaries and if it's not, the user must retry until verification.
I wanted to know why my code skips the if condition for any given value and it returns me for the input prompt : "Error: Invalid expression. Check for missing multiplication operator, missing or unbalanced delimiters, or other syntax error."
A=limit(5pi/6,-pi/2,pi/2) for example jumps directly to the else condition while it's true for the if condition
Here is my code :
function alpha = limit(pos,min,max)
if (pos >= max) && (pos <= min)
alpha=pos;
else
while pos >= max || pos <= min
prompt = 'Enter value between max and min';
alpha = input(prompt);
end
end
end
The function first checks whether pos is both greater than or equal to max and less than or equal to min.
I expect you intend max to be greater than min. Therefore, the if line should be:
if (pos <= max) && (pos >= min)
I assume your val_max/val_min are typos (and should be max/min) Then, your while loop depends on the value of pos. But pos is never updated in the loop, so your loop is just going to iterate forever.
You need to update pos inside the while loop for this to work. Try something like this:
function alpha = limit(pos,min,max)
while pos > max || pos < min
prompt = 'Enter value between min and max';
pos = input(prompt);
end
alpha = pos;
end
Let's suppose x ~ Poisson(2.5); I would like to calculate something like E(x | x > 2).
I assumed that this could be done with the .dist.expect operator, i.e.:
D = stats.poisson(2.5)
cond_expect = D.dist.expect(lambda x: x, D.args,lb=2)
This evaluates to cond_expect = 2.29478750344
However, if I just calculate the mean of a random sample from that distribution
D = stats.poisson(2.5)
test = D.rvs(size = 100000)
empirical_expectation = np.mean(test[test>=2])
empirical_expectation evaluates to 3.20875563063.
If anyone could clarify what I'm misunderstanding about the API, it would be greatly appreciated.
The method expect takes a Boolean parameter conditional, which is False by default. Set it to True:
cond_expect = D.dist.expect(lambda x: x, D.args, lb=2, conditional=True)
returns 3.219839256818051 in agreement with empirical result.
What this does:
conditional : bool, optional
If true then the expectation is corrected by the conditional probability of the summation interval. The return value is the expectation of the function, func, conditional on being in the given interval (k such that ul <= k <= ub). Default is False.
So, if False then you get E(X if X >= 2 else 0) instead of conditional expectation, which is adjusted by division by P(X >= 2): E(X | X >= 2) = E(X if X >= 2 else 0) / P(X >= 2)
I don't know why you would ever want conditional=False when providing an upper or lower bound, but it's the default.
I need to know if something is between two limits, but I keep getting the same 2 errors in playground and I can't seem to find a solution on the web. Any idea how to do this in Swift?
var upperLimit = 20
var a = 10
var lowerlimit = 5
if a > lowerlimit < upperLimit{
println(a)
}
if lowerlimit < a < upperLimit{
println(a)
}
Both of these methods give the same (2) error messages:
---> ! Non-associative operator is adjacent to operator of same precedence
--> Cannot invoke '<'with an argument of list type '($t4, #Ivalue Int)'
That's not a valid way to make the comparison. You need to check against the bounds with two comparisons:
if a > lowerlimit && a < upperLimit {
println(a)
}
Although I prefer this way using pattern recognition on a range.
if lowerlimit..<upperLimit ~= a {
println(a)
}
Note that the pattern recognition way requires the lower bound to be inclusive, so you'd need to increase the lowerLimit variable by one.
I am trying to compare two integers. One is the row of an NSIndexPath, the other is the count of an NSArray. The row is equal to 0 and the count is equal to 2. I have them in an if statement as follows:
if([self.selectedSetpoint row] < ([self.theCategories count]-3))
{
//Do true stuff
}
So by my math, the if statement should be false as I am comparing 0 < -1. However, I keep getting this statement coming through as true, and the block inside the if is being run. I have tried to NSLog the values to make sure that I am not just getting the wrong value. I placed this right BEFORE the if statement:
NSLog(#"%d",[self.selectedSetpoint row]);
NSLog(#"%d",[self.theCategories count]-3);
NSLog(#"%#",[self.selectedSetpoint row] < ([self.theCategories count]-3)?#"Yes":#"No");
and got this on the console:
2012-07-17 08:58:46.061 App[61345:11603] 0
2012-07-17 08:58:46.061 App[61345:11603] -1
2012-07-17 08:58:46.062 App[61345:11603] Yes
Any ideas why this comparison is coming up as true? Am I misunderstanding something about comparing integers?
I have another if statement just above this one that compares
[self.selectedSetpoint row]<([self.theCategories count]-2)
Which is 0 < 0, and it works fine (returns NO). So I feel like there is some issue with the use of negative integers that I am not getting.
Thank you in advance.
I suspect the issue is that the return of count is an unsigned integer, and subtracting more than it's magnitude, it underflows and becomes quite large. I have run some tests, and I get the same basic behavior as you (it looks like it's -1, and in certain contexts it appears to be working as expected... however it is clearly being underflowed in the context of the if() block.
Silly problem, but luckily there is a simple solution: Cast it in place in the if statement:
if([self.selectedSetpoint row] < ( (int)[self.theCategories count] -3 ))
{
//Do true stuff
}
I was going to propose an alternative solution - namely to avoid using subtraction and instead use addition on the other side of the equation:
if ([self.selectedSetpoint row] + 3 < [self.theCategories count])
{
//Do true stuff
}
This sidesteps getting caught by these kind of underflow bugs, however it leaves another gotcha untouched... Namely the conversion rules referred to in the answer to this question: What are the general rules for comparing different data types in C?
Quoting from an answer to that question, you see the C99 spec states:
(when one operand is signed and the other unsigned) Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.
So if you have a negative value for [self.selectedSetpoint row] + 3 then the comparison will fail...
The other answers here have advocated casting (NSUInteger) to (NSInteger) - but note that this may cause overflow problems if your unsigned values are significantly massive. For e.g:
(NSInteger) -3 < (NSInteger) 4294967289 == false...
Figuring there must be an easy way to solve this, I first came up with a hard way to solve it...
#define SafeLT(X, Y) \
({ typeof (X) _X = (X); \
typeof (Y) _Y = (Y); \
( _X < (NSInteger) 0 ? (( _Y > 0) ? YES : _X < _Y ) : ( _Y < (NSInteger) 0 ? NO : _X < _Y));})
This should work regardless of how you mix NSUInteger and NSInteger, and will ensure that the operands are evaluated at most once (for efficiency).
By way of proof of correctness:
For _X < (NSInteger) 0 to evaluate to True, _X must be NSInteger and < 0, so we check if _Y > 0. The compiler will make the correct comparison here by evaluating the type of _Y. If Y > 0 then by definition we return YES. Otherwise we know both X and Y are signed and < 0 and can compare them safely.
However, if X is either NSUInteger or > 0 then we test Y to see if it is < 0. If Y is < 0 then by definition we return NO. So now we have X is NSUInteger or NSInteger > 0 and Y is NSUInteger or NSInteger > 0. Since mixed comparisons will be promoted to NSUInteger we will have a safe conversion every time because there is no chance of underflow.
A simpler solution, however, would be to just typecast to a longer signed integer (iff your system has one):
#define EasySafeLT(X, Y) \
({ long long _X = (X); \
long long _Y = (Y); \
( _X < _Y);})
Although this depends on having the larger type available so may not always be feasible.
This does appear to be a case of comparing signed ints to unsigned ints. Your log statements will throw your assumptions because you are asking for the numbers to be printed signed.
NSLog(#"%d", -1); //Signed
-1;
NSLog(#"%u", -1); //Unsigned (tested on ios, 32 bit ints)
4294967295;
And then when you compare: 0 < 4294967295 certainly is true.
Casting as #ctrahey suggests should fix your problem:
if([self.selectedSetpoint row] < ( (int)[self.theCategories count] -3 ))
{
//Do true stuff
}
the problem is the count property is kind of NSUInteger and when you subtract a higher number from a smaller you won't get a less than zero number, you will get a very large positive number, it cause the strange behaviour.
try this way, and you would get the good result:
NSLog(#"%#",(NSInteger)[self.selectedSetpoint row] < ((NSInteger)[self.theCategories count]-3)?#"Yes":#"No");