I realized that if I were to create a swap function in Idris, its type signature is almost exactly the same as its definition
swap : (a, b) -> (b, a)
swap (x, y) = (y, x)
Are there any implications or significance to this with regards to dependent typing?
For example, can I define some type/value agnostic swap and use it for both definitions here? Is there a special name for this parallelism?
I don't think this has any significance to dependent typing. Your function is already fully polymorphic (i.e. agnostic). I am unaware of a term for type-level between symmetric with term level syntax.
Related
What is the arity of the sql BETWEEN expression? I thought it was three (ternary) since the expression usually looks like:
WHERE...
1 BETWEEN 2 AND 3
But it's listed as binary on BigQuery's documentation, and I assume other places as well.
Source: Operators.
What is the arity of the BETWEEN expression and why? I think the answer is 3 from the following example:
select
~ (SELECT -1 AS expr_1) AS 'bitwise_arity_1',
(SELECT 1 AS expr_1) * (SELECT 2 AS expr_2) AS 'times_arity_2',
(SELECT 1 AS expr_1) BETWEEN
(SELECT 2 AS expr_2) AND (SELECT 3 AS expr_3) AS 'bitwise_arity_3?'
I suppose one way to interpret it might just be that the grammar is:
expr 'BETWEEN' logicalAndExpr
And so the two expressions in the logicalAnd are just grouped into one. Is that a correct understanding?
SQLFiddle: http://www.sqlfiddle.com/#!9/b28da2/2156
It's binary, in syntactic terms. See below for a discussion of syntax vs. semantics, where I note that a better syntactic term is "infix".
Similarly, function calls and array subscripting are postfix unary operators and the C family's conditional operator (often misnamed "the ternary operator" as though it were the only such thing) is also infix. The reason is that the interior operands (the operands between BETWEEN...AND, (...), [...], and ?...:, respectively) are fenced off from the rest of the syntax by the pair of surrounding terminal tokens which function as a syntactic barrier, like parentheses. Precedence does not penetrate to the enclosed operands; only the outer operand(s) remain floating in the syntax.
The semantic view is quite different, of course. BETWEEN...AND and ?...: are certainly three-argument functions, although since the latter is short-circuiting, only two of the three arguments are ever evaluated, which makes it hard to discuss in strict mathematical terms [Note 1]. Moreover, the semantic view is complicated by the fact that there is not just a single way to look at what an argument is. As noted in a comment, you can always curry functions into a series of unary applications of higher-order functions. Although you might be tempted to try to redefine "arity" as the length of that sequence, you will soon find higher-order functions which have different sequence lengths depending on the values of their arguments. Also, in most programming languages (unlike SQL) the function being called is a full expression which does not need to be evaluated at compile-time, and since different functions have different argument counts, there is no good way to describe the arity of a function call unless you respecify the call to be the application of a list-of-arguments object to a callable object. That's often done, but it's a bit unsatisfying because (in most languages), the list object does not really exist and cannot be observed as an object.
I'd suggest taking the Wikipedia article on arity with a good-sized saline dosage, because it completely misses the distinction between semantics and syntactic structure, giving rise to the confusing ambiguity between the semantic and syntactic view of SQL's range operator or C's conditional operator. Personally, I prefer to reserve "arity" for the semantic meaning, using "fixity" or "valence" for the syntactic feature. (The advantage of "fixity" is that it encourages the distinction between prefix and postfix, which is a real distinction hidden by calling both cases "unary operators".)
Notes
BETWEEN...AND could short-circuit, too, but standard SQL doesn't guarantee short-circuiting, as far as I know (although some SQL implementations do.)
I am doing some SPARQL proofs where I use multisets to establish the proofs (instead of patterns). When applying the results in actual SPARQL queries, I need to make sure that every pattern used produces a multiset so that my proofs still hold.
EXAMPLE
Let JOIN be the SPARQL JOIN (aka AND) operator, and eval be the evaluation function.
Lemma A: Assume two multisets of solution mappings; M1 and M2: I made the proof that JOIN(M1, M2) = JOIN(M2, M1).
In order to apply this in an actual query (in algebraic form): JOIN(P1, P2) ≡ JOIN(P2, P1) which is correct if eval((JOIN(P1, P2)) = eval(JOIN(P2, P1)) which can be written as JOIN(eval(P1), eval(P2() ≡ JOIN(eval(P2), eval(P1)). In order to use Lemma A, it needs to hold that eval(P1) and eval(P2) yield multisets of solution mappings. However, not all SPARQL patterns yield multisets of solution mappings (I am not talking about sequences here as a sequence can be converted into a multiset). For example GROUP BY yields a set of mappings from solution mappings to multisets of solution mappings.
QUESTION
Which constraints on the structures of P1 and P2 I need to impose in order to ensure that, e.g., my Lemma A, is applicable?
Is there a way to simplify declaring a tuple of parameters in AMPL? For example, if a three-dimensional point was needed as a parameter, what I'm doing is declaring it as
param Point {{'a', 'b', 'c'}};
and then accessing it through P['a'], P['b'], and P['c']. The problem with this is, first, that it's ugly. To specify the point (1, 2, 3) in the data file you would have to write
param Point := a 1 b 2 c 3;
. I tried using the ordered keyword—i.e. param Point {{'a', 'b', 'c'} ordered};—so that the label was implied by the order—i.e. param Point := 1 2 3—, but that's not allowed inline, and having to define a separate "dummy" set is even uglier. I tried searching through the AMPL book, but found nothing for this specific purpose.
The other alternative is even worse:
param a;
param b;
param c;
It seems very stupid that there isn't a special syntax/shortcut for this.
Also note that I don't want to declare a set; I want an actual tuple parameter, of fixed length (specified through the model), whose entries are to be used as numerical parameters, and not labels.
So, is there a good way to do this?
If I've understood correctly, what you're looking for here is a way to input values for an AMPL tuple (indexed over some set S) without having to include the names of the indices (members of S) alongside the values - i.e. requiring that the index for each value is deduced from the order in which the values are provided.
I'm not aware of a simple way to do this. In AMPL, indexed numeric parameters (and variables) work in a similar way to e.g. a Python dict(): elements are referenced by key (index value), not by position. Because of this, all the methods of data input that I've seen require giving the indices alongside the values.
Given that AMPL does support ordered sets, I presume it would be possible to provide an input mode that allows for indices to be implied by position instead of stated explicitly. However, I'm not aware of this existing. It might be that it simply isn't a priority, or it might be a deliberate design decision to improve code robustness.
I suspect position-dependent inputs might be a bit more fragile for many of the problems AMPL is intended to handle; they certainly would be for the ones I've used it for. Often I want to reuse the same model with small changes to the index sets, in which case explicitly indexing the inputs helps prevent assigning the wrong values to the wrong places.
If we have the the grammer
how to correctly prove that this is unambigious? In my opinion it's hard to describe it so is there a mathematical or logic proof for that?
And then how to proove that L(G) = G? Next thing where it is hard for me to give a logic proof.
Hope somebody can help.
You can prove that a grammar is unambiguous by constructing a deterministic parser. You can prove that it is ambiguous by finding a sentence with two different parse trees (or, better said, with two different leftmost or rightmost derivations).
There is no definitive algorithm for producing such proofs, because the ambiguity of a grammar is undecidable.
I have no idea what you mean by proving that L(G) = G. That's clearly not true, because L(G) is a set of strings, while G is a grammar. The two objects are from different universes, so they cannot be equal. Perhaps you meant proving that some set of strings S is equal to L(G)? Again, this problem is, in general, undecidable, but in many useful cases you can construct such a proof. A common strategy is to use induction on the length of the string.
I've searched the web but I've found no solution to this problem.
What is the logical priority for operators NAND, NOR and XNOR?
I mean, considering as example the expression
A AND B NAND C
which operator should be evaluated first?
Obviously NAND can be translated as NOT-AND (as NOR is NOT-OR and XNOR is NOT-XOR), but
(A AND B) NAND C != A AND (B NAND C) = A AND NOT(B AND C)
According to my researches there's no a defined priority for such an expression, so I think the simplest solution is to evaluate the operators according to the order they appear in the expression, but I may be wrong.
Any suggestions?
This actually depends on your precedence rules. If there is no order (no precedence rules or everything of the same importance), it should be solved left to right. Here is an example with C++.
operator precedence have to be defined by a language, and what you have here doesn't seem to be a formal language, in such cases it's often assumed to be evaluated as you read from left to right.
Though, you could use the same operator precedence as verilog , or look at wikipedia which has a small table precedence commonly used for logic operators
If the expression is written like the way it is mentioned in the question(without brackets in between), it should be solved in the order they are written. Thats the only correct way to do this.
eg. If its written line A NOR B XOR C, It simply means (A NOR B) XOR C
Boolean operators have analogues in conventional arithmetic, so one way of deciding what the precedence rules should be is to follow the rules for conventional arithmetic, e.g. AND is analogous to multiplication, while OR is analogous to addition, hence AND should have higher precedence than OR. If you look at the operator precedence table for a language such as C or C++ you will see that this is indeed the case in these and other related languages.
I suppose this could be language specific, ALL operators must have an order of precedence defined or implied by a specific implmentation.
Here is what another site has to say about that.