I was reading Stable Marriage Problem(SMP, https://en.wikipedia.org/wiki/Stable_marriage_problem) with indifference and I came across the terms strongly stable, weakly stable and super stable matching. What is the difference between them?
In my opinions, they are three stable matching status with different degrees of requirements for matching on preference lists with ties.
Super stable is the most strict among them, and then the strongly stable, weakly stable has the least restriction at last.
Suppose there is a rogue couple (m,w) who don't match with each other in a matching, they will break the properties of the matching when:
if m strictly prefers (>) w to his current partner and w strictly prefers m to her current partner, the matching is not even a weakly stable matching.
if m stictly prefers (>) w to his current partner and w considers m no worse than (>=) her current partner, the matching cannot be a strongly stable matching.
if m considers w no worse than (>=) his current partner and w strictly prefers(>) m to her current partner, the matching also cannot be a strongly stable matching.
if m considers w no worse than (>=) his current partner and w considers m no worse than (>=) her current partner, the matching will no longer be a super stable matching.
Related
So I have a set of grammar
S -> X Y
X -> a X
X ->
Y -> b
Z -> a Z
Z -> a
My only confusing with this grammar is that 2nd Production for X
There is nothing there. Is that the equivalent of using Epsilon ε, or Lamda λ
I am assuming it is merely a difference in notation for the grammars but wanted to be sure as I am trying to build the first and follow sets
Both ε and λ (and sometimes Λ) are used by different writers to represent the empty string. In modern writing, ε is much more common but you'll often find λ in older textbooks, and Λ in even older ones.
The point of using these symbols is to make the empty sequence visible. However it is written, it is the empty sequence and should be read as though it were nothing, as in your production X ⇒ .
If you find it difficult getting your head around the idea that a symbol means nothing, then you might enjoy reading Charles Seife's Zero: The Biography of a Dangerous Idea or Robert Kaplan's The Nothing that Is: A Natural History of Zero, both published in the emblematic year 2K and both of which explore the long and difficult struggle to understand the concept of nothing. ("No one goes out to buy zero fish" -- Alfred North Whitehead).
It has been suggested that Λ/λ comes from the German word "leer", meaning empty, while ε comes from English "empty". There was a time when German was more common in academic discussion of mathematical logic, so the theory seems reasonable.
I need to express the countable property over a specific subset defined by a certain predicate P. My first idea was to explicitly state that there exists a function f which is bijective between my subset and, let's say, the natural numbers. Is there another more general way to express that property in the standard library ?
Thank you in advance
If you are using a set that is isomorphic to the natural numbers why don't you just use the natural numbers?
There is no way to distinguish isomorphic sets and in HoTT (or cubical agda) isomorphic sets are equal. Hence asking for a set that is isomorphic to Nat is the same as asking for a number that is equal to 3.
I am trying to understand an already annotated the sentence When this happens, the two KIMs show a magnetism that causes the first KIM to move toward the second KIM.
What does number 1 in POS tag WHADVP-1 for When mean/signify?
Similarly what does number 1 in POS tag WHNP-1 for that mean/signify?
I think I understand well POS tags, after reading http://web.mit.edu/6.863/www/PennTreebankTags.html and
notes by Andrew McIntyre.
They are indices for coreference resolution. I think this guide from the University of Tübingen, Germany puts it quite nicely.
4.1.2 Indexing
Indices are used only when they can be used to indicate a relationship
that would otherwise not be unambiguously retrievable from the
bracketing. Indices are used to express such relationships as
coreference (as in the case of controlled PRO or pragmatic coreference
for arbitrary PRO), binding (as in the case of wh-movement), or close
association (as in the case of it-extraposition). These relationships
are shown only when some type of null element is involved, and only
when the relationship is intrasentential. One null element may be
associated with another, as in the case of the null wh-operator.
Coreference relations between overt pronouns and their antecedents are
not annotated.
I work quite a lot with POS taggers and I usually just ignore the numbers chained on, unless I am debugging a parse error and want to know why a sentence is tagged wrong. They can be very useful for training sequencing algorithms such as MMEM, CRFs, etc.
What does "lg" mean in the following phrase?
"... we ignore the least significant lg t bits of x when referring to Mt[x]." (Knuth, 2005, pp. 4-5).
From the context, it seems like "lg t" means "t -1" so that lg 2 would be 1 and lg 5 would be 4. That said, what is the strict meaning of "lg" here?
References
Knuth, D. E. (2005). The art of computer programming: Volume 1, fascicle 1 : MMIX, a RISC computer for the new millennium. Upper Saddle River, New Jersey: Addison-Wesley.
lg means log to the base 2.
i.e. lg(4) = 2, lg(2) = 1.
"lg" is commonly used to represent base 2 logarithms but this is a misuse is propagated in a few computer science texts.
Logarithm abbreviations are governed by standards. The abbreviation "lg" is reserved under DIN (DIN 1302) and ISO standards (ISO-31-11, ISO 80000-2) for a logarithm base 10. Since "lg" is widely used in other science and engineering fields in this manner, no one should use "lg" to refer to a base 2 logarithm.
The correct abbreviation for base 2 logarithm is logarithmus binaris (the binary logarithm) is "lb," though some Germans still use "ld" (for logarithmus dualis).
One of the most popular texts misusing the abbreviation (Cormen et alli: Introduction to Algorithms) commits several other mathematical sins (such as misusing "asymptotic") that make it more difficult for students to connect the material to their precalculus and calculus courses.
References:
Wikipedia - Binary Logarithm: Notation
Guide for the Use of the International System of Units (SI) — NIST Special Publication 811, 2008 Edition — Second Printing
Quantities and units – Part 2: Mathematical signs and symbols to be used in the natural sciences and technology
Probably logarithm of t with base 2.
The quoted passage refers to Knuth Vol. 1 [1]. Section 1.2.2 of this monumental work is entitled "Numbers, Powers, and Logarithms". Here's how Knuth explains his notation:
"One might expect that in computer work binary logarithms (to the base 2) would be more useful, since most computers do binary arithmetic. Actually, we will see that binary logarithms are indeed very useful, but not only for that reason; the reason is primarily that a computer algorithm often makes two-way branches. Binary logarithms arise so frequently, it is wise to have a shorter notation for them. Therefore we shall write , following a suggestion of Edward M. Reingold."
1: Knuth, The Art of Computer Programming, third edition, Addison-Wesley, 1997.
Let's take the following context-free grammar:
G = ( {Sum, Product, Number}, {decimal representations of numbers, +, *}, P, Sum)
Being P:
Sum → Sum + Product
Sum → Product
Product → Product * Number
Product → Number
Number → decimal representation of a number
I am trying to parse expressions produced by this grammar with a bottom-up-parser and a look-ahead-buffer (LAB) of length 1 (which supposingly should do without guessing and back-tracking).
Now, given a stack and a LAB, there are often several possibilities of how to reduce the stack or whether to reduce it at all or push another token.
Currently I use this decision tree:
If any top n tokens of the stack plus the LAB are the begining of the
right side of a rule, I push the next token onto the stack.
Otherwise, I reduce the maximum number of tokens on top of the stack.
I.e. if it is possible to reduce the topmost item and at the same time
it is possible to reduce the three top most items, I do the latter.
If no such reduction is possible, I push another token onto the stack.
Rinse and repeat.
This, seems (!) to work, but it requires an awful amount of rule searching, finding matching prefixes, etc. No way this can run in O(NM).
What is the standard (and possibly only sensible) approach to decide whether to reduce or push (shift), and in case of reduction, which reduction to apply?
Thank you in advance for your comments and answers.
The easiest bottom-up parsing approach for grammars like yours (basically, expression grammars) is operator-precedence parsing.
Recall that bottom-up parsing involves building the parse tree left-to-right from the bottom. In other words, at any given time during the parse, we have a partially assembled tree with only terminal symbols to the right of where we're reading, and a combination of terminals and non-terminals to the left (the "prefix"). The only possible reduction is one which applies to a suffix of the prefix; if no reduction applies, we must be able to shift a terminal from the input to the prefix.
An operator grammar has the feature that there are never two consecutive non-terminals in any production. Consequently, in a bottom-up parse of an operator grammar, either the last symbol in the prefix is a terminal or the second-last symbol is one. (Both of them could be.)
An operator precedence parser is essentially blind to non-terminals; it simply doesn't distinguish between them. So you cannot have two productions whose right-hand sides contain exactly the same sequence of terminals, because the op-prec parser wouldn't know which of these two productions to apply. (That's the traditional view. It's actually possible to extend that a bit so that you can have two productions with the same terminals, provided that the non-terminals are in different places. That allows grammars which have unary - operators, for example, since the right hand sides <non-terminal> - <non-terminal> and - <non-terminal> can be distinguished without knowing the names of the non-terminals; only their presence.
The other requirement is that you have to be able to build a precedence relationship between the terminals. More precisely, we define three precedence relations, usually written <·, ·> and ·=· (or some typographic variation on the theme), and insist that for any two terminals x and y, at most one of the relations x ·> y, x ·=· y and x <· y are true.
Roughly speaking, the < and > in the relations correspond to the edges of a production. In other words, if x <· y, that means that x can be followed by a non-terminal with a production whose first terminal is y. Similarly, x ·> y means that y can follow a non-terminal with a production whose last terminal is x. And x ·=· y means that there is some right-hand side where x and y are consecutive terminals, in that order (possibly with an intervening non-terminal).
If the single-relation restriction is true, then we can parse as follows:
Let x be the last terminal in the prefix (that is, either the last or second-last symbol), and let y be the lookahead symbol, which must be a terminal. If x ·> y then we reduce, and repeat the rule. Otherwise, we shift y onto the prefix.
In order to reduce, we need to find the start of the production. We move backwards over the prefix, comparing consecutive terminals (all of which must have <· or ·=· relations) until we find one with a <· relation. Then the terminals between the <· and the ·> are the right-hand side of the production we're looking for, and we can slot the non-terminals into the right-hand side as indicated.
There is no guarantee that there will be an appropriate production; if there isn't, the parse fails. But if the input is a valid sentence, and if the grammar is an operator-precedence grammar, then we will be able to find the right production to reduce.
Note that it is usually really easy to find the production, because most productions have only one (<non-terminal> * <non-terminal>) or two (( <non-terminal> )) terminals. A naive implementation might just run the terminals together into a string and use that as the key in a hash-table.
The classic implementation of operator-precedence parsing is the so-called "Shunting Yard Algorithm", devised by Edsger Dijkstra. In that algorithm, the precedence relations are modelled by providing two functions, left-precedence and right-precedence, which map terminals to integers such that x <· y is true only if right-precedence(x) < left-precedence(y) (and similarly for the other operators). It is not always possible to find such mappings, and the mappings are a cover of the actual precedence relations because it is often the case that there are pairs of terminals for which no precedence relationship applies. Nonetheless, it is often the case that these mappings can be found, and almost always the case for simple expression grammars.
I hope that's enough to get you started. I encourage you to actually read some texts about bottom-up parsing, because I think I've already written far too much for an SO answer, and I haven't yet included a single line of code. :)