I am trying to use a comparison operator in SQL to say where not equal to or less than zero.
I have tried this but it comes up with an error
WHERE amount (<> 0 or < 0)
I have also tried:
WHERE amount !<= 0
but get syntax errors. Any help greatly appreciated
You can simply use:
WHERE amount > 0
With propositional logic, your condition is the same as a != 0:
a != 0 or a < 0
(a < 0 or a > 0) or a < 0
(a < 0) or (a > 0) or (a < 0)
two repeated conditions with or, you can just remove one
(a < 0) or (a > 0)
equivalent to a != 0
aka a <> 0
"not equal to and not less than" <=> "not (equal to or less than)" (see the De Morgan formulas here https://www.cuemath.com/data/de-morgans-law/), I have attached the screenshot of the relevant formula:
foo equal 0 to is represented as
foo = 0
foo less than 0 is represented as
foo < 0
foo equal to 0 or foo is less than 0 is represented as
foo = 0 OR foo < 0
this can be shortened to
foo <= 0
its negation is
NOT (foo <= 0)
alternatively, you can use
foo > 0
Note that NULL is a special case and you need to define what you intend NULL to yield. Since that was not specified, I'm focusing only on numeric inputs, but, at the end of the line, you will need to take into account NULL as a possible value as well if... Well, if it's possible in your scenario.
Related
I just realize that you can actually compare String in Kotlin with < > or <= >=.
enter image description here
But I cannot find the documentation about this? Is this undocumented?
This ends up calling compareTo(). There is no implicit conversion occurring.
The documentation is here:
https://kotlinlang.org/docs/operator-overloading.html#comparison-operators
a > b a.compareTo(b) > 0
a < b a.compareTo(b) < 0
a >= b a.compareTo(b) >= 0
a <= b a.compareTo(b) <= 0
All comparisons are translated into calls to compareTo, that is required to return Int.
I was working on making a game, and I was wondering why the construct with the == operator doesn't work while the lower one does. I used an NSLog message afterwards to test.
if (pipe.position.x == bird.position.x){ no idea why this doesn't work
if ((pipe.position.x <= bird.position.x) & (pipe.position.x > bird.position.x - 1)){
This is because one (or both) of the position.x's are a floating-point2 value with a non-zero difference1 between the two position values such that only the second condition is true.
Since p <= b is true for all values that make p == b true, to see why this works "unexpectedly" let's choose some values such that the expression p == b is false2 yet p < b is true and p > b - 1 is true.
Given p = 3.2 (pipe) and b = 3.7 (bird), as an example, then
p == b
-> 3.2 == 3.7
-> false
but
(p <= b) & (p > b - 1)
-> (3.2 <= 3.7) & (3.2 > 3.7 - 1)
-> (3.2 <= 3.7) & (3.2 > 2.7)
-> true & true
-> true
Instead, to detect when the bird "is crossing" the pipe, assuming that x increases to the right, consider
// The bird's head to the "right" of the pipe leading edge..
bird_x >= pipe_x
// ..but bird's butt is not to the "right" of the pipe trailing edge.
// (Also note use of the &&, the logical-AND operator)
&& (bird_x - bird_width <= pipe_x + pipe_width)
Of course, using a non-rectangle (or forgiving overlap) collision detection would lead to less frustrating flapping!
1 This issue occurs because there are some particular floating-point values (but there are no integer values) which can cause the observed effect.
First, reiterate the assumption that p is not equal to b, given that the first condition does not succeed. Let's suppose then that p <= b is written as p == b || p < b but since p == b is false , we can write it as p < b by tautology.
Since both clauses in the second condition are true (such that true && true -> true), we have the rules: 1) p < b is true, and 2) p > b - 1 is true.
Rewriting p < b as p - b < 0 and p > b - 1 as p - b > -1, and then replacing p - b with x yields: x < 0 and x > -1. However, there is no integer value of x which satisfies -1 < x < 0.
(In first section, where p = 3.2 and b = 3.7, x = (p - b) = 0.5 which satisfies the given constraints when x is not restricted to an integer value.)
2 With all above aside, it is possible for p and b to be "very close but different" floating-point values such that there is a non-zero difference between them - due to rounding, they may even be displayed as the same integer value! See How dangerous is it to compare floating point values? and related questions for the cause and "odd" behavior of such when using ==.
If this is the case then round to integer values and use an integer comparison, or; rely entirely on relational comparison such as shown in the proposed condition, or; use epsilon comparison for "nearly equal" of floating-point values.
if you choose abs(pipe.position.x) == abs(bird.position.x) the first condition may satisfy.
I am trying to verify that a variable is NOT equal to either this or that. I tried using the following codes, but neither works:
if x ~=(0 or 1) then
print( "X must be equal to 1 or 0" )
return
end
if x ~= 0 or 1 then
print( "X must be equal to 1 or 0" )
return
end
Is there a way to do this?
Your problem stems from a misunderstanding of the or operator that is common to people learning programming languages like this. Yes, your immediate problem can be solved by writing x ~= 0 and x ~= 1, but I'll go into a little more detail about why your attempted solution doesn't work.
When you read x ~=(0 or 1) or x ~= 0 or 1 it's natural to parse this as you would the sentence "x is not equal to zero or one". In the ordinary understanding of that statement, "x" is the subject, "is not equal to" is the predicate or verb phrase, and "zero or one" is the object, a set of possibilities joined by a conjunction. You apply the subject with the verb to each item in the set.
However, Lua does not parse this based on the rules of English grammar, it parses it in binary comparisons of two elements based on its order of operations. Each operator has a precedence which determines the order in which it will be evaluated. or has a lower precedence than ~=, just as addition in mathematics has a lower precedence than multiplication. Everything has a lower precedence than parentheses.
As a result, when evaluating x ~=(0 or 1), the interpreter will first compute 0 or 1 (because of the parentheses) and then x ~= the result of the first computation, and in the second example, it will compute x ~= 0 and then apply the result of that computation to or 1.
The logical operator or "returns its first argument if this value is different from nil and false; otherwise, or returns its second argument". The relational operator ~= is the inverse of the equality operator ==; it returns true if its arguments are different types (x is a number, right?), and otherwise compares its arguments normally.
Using these rules, x ~=(0 or 1) will decompose to x ~= 0 (after applying the or operator) and this will return 'true' if x is anything other than 0, including 1, which is undesirable. The other form, x ~= 0 or 1 will first evaluate x ~= 0 (which may return true or false, depending on the value of x). Then, it will decompose to one of false or 1 or true or 1. In the first case, the statement will return 1, and in the second case, the statement will return true. Because control structures in Lua only consider nil and false to be false, and anything else to be true, this will always enter the if statement, which is not what you want either.
There is no way that you can use binary operators like those provided in programming languages to compare a single variable to a list of values. Instead, you need to compare the variable to each value one by one. There are a few ways to do this. The simplest way is to use De Morgan's laws to express the statement 'not one or zero' (which can't be evaluated with binary operators) as 'not one and not zero', which can trivially be written with binary operators:
if x ~= 1 and x ~= 0 then
print( "X must be equal to 1 or 0" )
return
end
Alternatively, you can use a loop to check these values:
local x_is_ok = false
for i = 0,1 do
if x == i then
x_is_ok = true
end
end
if not x_is_ok then
print( "X must be equal to 1 or 0" )
return
end
Finally, you could use relational operators to check a range and then test that x was an integer in the range (you don't want 0.5, right?)
if not (x >= 0 and x <= 1 and math.floor(x) == x) then
print( "X must be equal to 1 or 0" )
return
end
Note that I wrote x >= 0 and x <= 1. If you understood the above explanation, you should now be able to explain why I didn't write 0 <= x <= 1, and what this erroneous expression would return!
For testing only two values, I'd personally do this:
if x ~= 0 and x ~= 1 then
print( "X must be equal to 1 or 0" )
return
end
If you need to test against more than two values, I'd stuff your choices in a table acting like a set, like so:
choices = {[0]=true, [1]=true, [3]=true, [5]=true, [7]=true, [11]=true}
if not choices[x] then
print("x must be in the first six prime numbers")
return
end
x ~= 0 or 1 is the same as ((x ~= 0) or 1)
x ~=(0 or 1) is the same as (x ~= 0).
try something like this instead.
function isNot0Or1(x)
return (x ~= 0 and x ~= 1)
end
print( isNot0Or1(-1) == true )
print( isNot0Or1(0) == false )
print( isNot0Or1(1) == false )
I have an if statement followed by several else if statements. All of the if/else if statements have an argument structured something like this:
if (100 <= x <= 149) //do this
else if (150 <= x <= 199) //do that
else if ...etc...
However, for some reason only the first if statement ever gets executed. X can be 200 and only the first if statement will be recognized.
I'm not sure why it isn't moving on to the next else if statement when X doesn't fit the argument of the preceding statement. Does this not work in Obj-C? Any help is appreciated. Thanks
You need to rephrase the statements like:
if (x >= 100 && x <= 149) {
} else if (x >= 150 && x <= 199) {
} ...
Your first if is evaluated like:
if ((100 <= x) <= 149)
Let's have a look how that evaluates:
If x = 200, then (100 <= 200) is true and thus evaluates to the value 1 (which means true). And then 1 <= 149 is also true.
If x has a value smaller than 100, for example 10, then (100 <= 10) is false and thus evaluates to the value 0 (which means false). Again, 0 <= 149 is true.
So regardless of the value of x, the whole expression will always be true.
C is not math, so
if (100 <= x <= 149)
is NOT the same as
if (100 <= x && x <= 149)
Which is what you meant. The former will be true always, because 100 <= x <= 149 becomes
((100 <= x) <= 149)
leaving two possibilities: (1 <= 149) or (0 <= 149). Both are always true.
Chained comparisons like these don't work in C-based languages. Or rather, they do, but not how you'd expect.
100 <= x <= 149 gets evaluated as (100 <= x) <= 149. If x is over 100, then (100 <= x) will evaluate to true, or 1. If x is under 100, it's false, or 0. In either case, 0 <= 149 or 1 <= 149 is true, so the overall expression is true.
To fix this, change your conditions to look like this:
if (100 <= x && x <= 149)
That will make it work as you expect.
The compiler sees an expression formulated from binary operators. The <= symbol is a binary operator, as are =, >=, ||, &&, and so forth.
Just as with arithmetic, there is an order of precedence that the compiler must follow, evaluating the expression formed around each binary operator.
In arithmetic, you are probably familiar with this, as with these two examples:
2+5*7 This evaluates to 2+(5*7) or 37, because multiplication has precedence over addition.
2+3+21 is evaluated in the order the terms are read from left to right, since there is no other precedence rule. It becomes (2+3)+21.
So 100<=x<=150 is an expression of a similar type, where the binary operators are all the same, and thus have the same precedence. Once again, this is resolved by evaluating it from left to right, so it becomes (100<=x)<=150. If x>=100 the term in parentheses evaluates to TRUE, which has a numeric value of 1. Since 1 is less than 150, the rest evaluates to 1<=150, or TRUE, if x is greater than or equal to 100. On the other hand, it also evaluates to TRUE if x is less than 100, because the second comparison becomes 0<=150, which is TRUE.
The other recommendations to break this down with parentheses are correct if you aren't sure of the order of precedence for binary operators: (100<=x) && (x<=150). You can also write it as 100<=x && x<=150 since the order of precedence for value comparisons is higher than for logical operators.
Because if (100 <= x <= 149) is the same as if(1<=149) if you give 200 or another number to x. And that is correct always.
For example.
x=1
100<=1 is false so you get if(0<=149) which is true
x=200
100<=200 is true so you get if(1<=149) which is true
So you always get true for it.
So you must do it in another way, like this
if(x>=100 && x<=149) ...
Adding some additional parenthesis may help.
if ((100 <= x) && (x <= 149)) //do this
I don't think you can write math functions like this in objective-c... Try separating them and combining with an && statement:
if ( (100 <= x) && (x <= 149) ) { // "&&" = and, "||" = or, other math comparison operators are: <=, >=, <, >, ==, != (!= is does not equal))
//do this
} else if ( (150 <= x) && (x <= 199) ) {
//do that
} else if ...etc...
You've already got a lot of answers, but I'll add one more to cover one other possible point of confusion.
In C & Obj-C the boolean (and character) types are treated as integer types, which is not the case in call languages. So expressions like 'z' * true make perfect sense!
(Modern) C uses the type _Bool for boolean, which is defined to be large enough to hold 0 & 1. Cocoa uses the type BOOL for boolean, which is defined as signed char. CoreFoundation uses the type Boolean which is defined as unsigned char. All three define YES/true as 1 and NO/false as 0, while C itself treats any non-zero value as true.
The relation operators such as <, <= etc. are defined to return the int (yes, none of the booleans, not even _Bool) value 0 if the relation is false, and the int value 1 if the relation is true.
Given this and the left-to-right associativity of relational operators your:
if (100 <= x <= 149)
is parsed as:
if ((100 <= x) <= 149)
then 100 <= x evaluates to the int value 1 if x is greater than or equal to 100, otherwise it evaluates to the int value 0, so we get:
if (1 <= 149)
or
if (0 <= 149)
both of these evaluate to 1 so we get:
if (1)
and the if statement branches to the "then" branch if it's expression is non-zero.
It may be surprising, but the whole statement is evaluated without any use of booleans at all - it is all done with integers.
To achieve what you intended you need:
if((100 <= x) && (x <= 149))
etc. - which also doesn't use any booleans (&& is defined in terms of integers).
SELECT foo FROM bar
WHERE id >= (abs(random()) % (SELECT max(id) FROM bar))
LIMIT 1;
I saw this in another answer as an alternative to ORDER BY random(). I need to make sure id would always be greater than zero. Do I have to change >= to >?
Since x % y returns 0 when x is a multiple of y, the answer is "Yes, your expression could return 0".
So, if id must be greater than 0, you need to use > rather than >=. Of course, if the modulo operator didn't return 0, you could still use > instead of >= and you'd get the same effect.
Yes. If abs(random()) returned the value of max(id), then the modulo's result would be zero. Since abs(random()) can return any value between 0 & 9223372036854775807, this is definitely possible.
Yes it can return 0 in two ways
Consider that 3 % 3 == 0, 6 % 3 == 0, etc. Then you would get 0 if random() happens to be max(id) or an even divider thereof.
random() can also return 0 and 0 % anything == 0, that is the other possibility.
Yes, it should be > because modulo division can return 0( a mod a ==0, 0 mod a == 0). Also, you might want to check if (SELECT max(id) is not null/0 (a mod 0 is undefined in some systems, or a)