I have been Googling around and haven't been able to find a solution. If anyone can link me or explain this, I'd appreciate it.
I have this expression:
¬aΛb | aΛ¬b. Λ is AND, ¬ is NOT.
The truth table is:
A B Expression
--------------
T T F
T F T
F T F
F F T
I am confused as to why they aren't all FALSE. For example, if I were to consider a and b as false: ¬a and ¬b gets precedence, so they become true. But ¬a (TRUE) Λ b (FALSE) is FALSE. And since Λ gets precedence, a (FALSE) Λ ¬b (TRUE) is again FALSE. So FALSE | FALSE = FALSE, right?
Likewise, for a|b|c|d|e, where | is OR. Why is it that when only d is FALSE, and the other are true:
T T T F T
= FALSE
The calculator you're using uses | to mean NAND, not OR. You should use + for OR. Then the truth table comes out as expected. x NAND y is TRUE except when x AND y are true; and NAND has the same precedence as AND, so without parentheses the operators bind leftmost first. A fully parenthesized version of your formula is:
((((not a) and b) nand a) and (not b))
Generating a truth table based on this gives the observed result.
Related
Let's say I have a table, which has four columns (a, b, oper and c) and some primary key column. oper means arithmetic operation (+ - * /) here.
a b oper c
-------------
2 3 + 5
4 2 / 3
6 1 * 9
8 5 - 3
As, we can see in some cases, a <oper> b != c. So, my question is how to filter out such cases?
I've heard of execute, which is used for executing statements, but I don't know how to use it inside where clause.
Also, I'm not generalizing the oper to any arithmetic operation, but it would be nice to know, if any function exists.
SELECT *
FROM table
WHERE с != CASE oper WHEN '+' THEN a+b
WHEN '-' THEN a-b
WHEN '*' THEN a*b
WHEN '/' THEN a/b
ELSE NULL END
fiddle
I have a doubt regarding how to implement this statement with constraints:
Only if A or B or both, then C or D or both.
I want to implement it with constraints that take binary values.
This is an example:
If A then B, means that A=B;
A or B or both, means that A+B>=1.
Thank you so much.
Let me try.
First A => B is not the same as A=B. It is however the same as B >= A. If we want: A <=> B then indeed A=B.
The real question seems to be: A+B>=1 <=> C+D>=1 or
A+B>=1 => C+D>=1
A+B=0 => C+D=0
We can write this as a system of inequalities:
C+D >= A
C+D >= B
C+D <= 2(A+B)
All variables are assumed to be binary.
So let's say you have n boolean inputs of x1, x2, x3, ..., xn. How do you determine that <= k of your boolean inputs are True using only And/Or/Not logic gates, and doing so in polynomial time?
I'm quite honestly befuddled.
There are many ways to do it. One is to (recursively) make two nets:
one (A) determining that <= k-1 of boolean inputs x1 ... x[n-1] are True.
another (B) determining that <= k of boolean inputs x1 ... x[n-1] are True.
Connect them as (B And Not x[n]) Or A
So I noticed that after n=20 the factorial function given in LearnYouAHaskell (below) craps out because of the finite work range of the Int type.
factorial :: Int -> Int
factorial 0 = 1
factorial n * factorial (n-1)
Using factorial :: Integer -> Integer fixes the issue nicely, but it brought to mind the question. Supposedly Integer is slightly slower than Int so ideally (and I know I'm pinching pennies here) I'd want my factorial function to only resort to Integer when the input is greater than 20 and retain the Int->Int type for the smaller numbers. Seems like there should be an elegant solution for this using if-then-else or guards, but keep running into syntactic pepper (error messages)
You can make a hackish solution without dependent types by using either a sum type and growing when needed or delaying the cast to Integer till the end in some cases. I don't expect either solution would perform better than using Integer - do not fear the Integer, gmp and mpir are quite good.
The casting solution is something like:
selectiveFactorial :: Integer -> Integer
selectiveFactorial i
| i < 20 = fromIntegral $ factorial (fromIntegral i :: Int)
| otherwise = factorial i
factorial :: Integral a => a -> a
factorial 0 = 1
factorial n = n * factorial (n - 1)
As Rein Henrichs said you could do these things in a language with dependent types, which Haskell does not (yet, quite) have. In Idris, say, it would look something like
factorial : (n : Int) -> if n <= 20 then Int else Integer
factorial n with (n <= 20)
factorial n | True = thisfactorial n
factorial n | False = thatfactorial n
But how will you use this result? Well, you'll need to do the comparison to figure out what type to expect, and when all is said and done, I don't see how you've won anything. For completeness, the use site could look something like this:
use : Int -> Integer
use n with (factorial n)
use n | fn with (n <= 20)
use n | fn | False = fn
use n | fn | True = cast fn
Note that the order of the with clauses is significant! The fn binding gets type if n <= 20 then Int else Integer; for reasons I don't entirely understand, the n <= 20 test must be to the right of that in order for the pattern match to affect its type.
It can't be done. There are things you can do however:
Make the type more generic: factorial :: Num a => a -> a;
This allows the user of your function to decide what runtime penalties he wants to occur vs. what range of numbers is permissible.
Use a sum type like data PossiblyBig = Small Int | Big Integer, and then have an implementation instance Num PossiblyBig that encodes things that fit into Int as Small, and things that don't fit as Big; AFAIK Integer already works like that (look up the GMP implementation if you want to know for sure), so this is more of a general example than advice as to what you should do in this particular situation.
Making the type of a function depend on its values is exactly what dependent types are for. Unfortunately, Haskell does not have dependent types so this cannot be done.
I'm investigating the mysql's SQL parser at the moment.
And here is the interesting thing I have noticed and cannot explain:
(in sql_yacc.yy)
predicate:
...
| bit_expr BETWEEN_SYM bit_expr AND_SYM predicate
{
$$= new (YYTHD->mem_root) Item_func_between($1,$3,$5);
if ($$ == NULL)
MYSQL_YYABORT;
}
The same is on the Expression Syntax page:
predicate:
...
| bit_expr [NOT] BETWEEN bit_expr AND predicate
That means that
foo BETWEEN 1 AND bar BETWEEN 1 AND 2
query syntactically correct, while it makes no sense at all.
My question: what this could be used for? What would we miss if used
bit_expr [NOT] BETWEEN bit_expr AND bit_expr
instead?
LOL (not a LOL anymore actually)
this query executes WITHOUT errors:
select * from users where id between 1 and id between 1 and 10;
// returns row with id = 1
select * from users where id between 2 and id between 2 and 10;
Empty set (0.00 sec)
(update is added here) ... and actually it is expected.
Presumably it converts the second expression straight to 0 or 1 and uses it as an operand.
UPD:
I've filed a bug - http://bugs.mysql.com/bug.php?id=69208
It's definitely not an expected syntax at all
UPD 2: so looks like it's just a minor typo that doesn't change a parser behaviour at all (well, to be clear it makes it unnoticeable slower for a common BETWEEN expression).
Your analysis is basically correct:
foo BETWEEN 1 AND bar BETWEEN 1 AND 2
is parsed as:
foo BETWEEN 1 AND (bar BETWEEN 1 AND 2)
and the second (parenthesized) predicate will presumably evaluate to either 0 or 1 (for false or true). Therefore, if bar is not between 1 and 2, the set of selected values from foo will be empty (because foo BETWEEN 1 AND 0 is a shorthand for foo >= 1 AND f <= 0 and there are no values for which that is true, even allowing for NULLs). Contrariwise, if bar is between 1 and 2, then the set of selected values from foo will be the set where `foo1 equals 1.
And alternative question to your "what would you lose if you replaced the 'predicate' term with 'bit_expr'?" might be "would you gain anything if you replaced the 'bit_expr' with 'predicate'?"
Without a careful scrutiny of the complete grammar (or, at least, scrutiny of the parts referenced by bit_expr and predicate, and possibly a review of places where bit_expr and predicate are used), it is hard to know the answer to either question.