Determine if a language is context free - intersection

Lets say you have a language L and you want to determine if it is context free. Context free languages intersected with regular languages are context free. Is that enough to prove that L is context free?
Meaning,
L intersect P = T Where P is a regular language and T is context free. Does this imply that L is context free?

No, your statement is not true. Consider the following counter-example:
L = {0n1n2n | n > 0}, P = T = Ø. Clearly we have L ∩ P = L ∩ Ø = Ø = T, and Ø is both regular and context-free.
Note it is well-known that L is not context-free (see example on p.12 for a sketch proof by pumping lemma).

Related

proof L = {a^n b^m | n>=m} is irregular language

I am stuck in finding S for pumping lemma. is there any idea to proof that
L = {a^n b^m | n>=m} is an irregular language?
The pumping lemma states this:
If L is a regular language, then there exists a natural number p such that any string w of length at least p can be written as w = uvx where |uv| <= p, |v| > 0 and for all natural numbers n, u(v^n)x is also in the language.
To prove a language is not regular using the pumping lemma, we need to design a string w such that the rest of the statement fails: that is, there are no valid assignments of u, v and x.
Our language L requires the number of a's to be the same as the number of b's. The shortest string that satisfies the hypothesis that the string w has length at least p is a^(p/2) b^(p/2). We could guess this as our string. If we do, we have a few cases:
v is entirely made of a's. But then, pumping is going to result in a different number of a's and b's, so the resulting string is not in the language; a condtradiction.
v spans a's and b's. But then, pumping is going to cause a's and b's to be mixed up in the middle, whereas our language requires all the a's to come first. This is also a contradiction.
v is entirely made of b's. But then, we have the same contradiction as in case #1.
In all cases, this choice of w led to a contradiction. That means the guess worked.
There was a simpler choice for w here: choose w = a^p b^p, then there is only one case. But our choice worked out fine. If our choice had not worked out, we could have learned from that choice what went wrong and chosen a different candidate.
For the previous comment,(1) doesn't make sense, since we can have more a's then b's. n>=m. I probably bombed a midterm yesterday due to this question, but found that the answer is actually in the pumping part.
The solution is that we can pump down as well as up. The pumping lemma for regular languages says that for all i>=0, w=x(y^i)z.
CASE 1: y = only a's
So by using a^n b^m with w = a^p b^p, if y is some amount of a's then we see:
x = a^p-l
y = a^l
z = b^m
Now if we use y^0, then there will be less a's than b's.
The next two cases should be easy to prove but I'll add them regardless.
CASE 2: y = only b's
x = a^p
y = b^l
z = b^(p-l)
Pumping to xy^2z leaves more b's than a's so that is not an accepted word in L.
CASE 3: y = a's and b's
x = a^(p-l)
y = (a^l)(b^k)
z = b^(p-k)
Pumping x(y^2)z gives a^(p-l) [(a^l)(b^k)(a^l)(b^k)] b^(p-k) which is not included in L.

UCUM representation of liter

I'm confused about how the UCUM defines the symbol for "liter". Yes I'm aware that historically the symbol l has been used, and that more recently L has been added by standards bodies (see e.g. BIPM SI 8th Edition) as an alternative to l. But I thought the UCUM was supposed to give us a single, unambiguous set of symbols for interchange.
But reading UCUM more closely, I see that it provides both case-sensitive and case-insensitive versions of symbols. Moreover I see that, for case-sensitivity, "liter" is defined twice, once with a case-sensitive symbol of l and another with a case-sensitive symbol of L. So the way I interpret this is that, if you're in a case-sensitive environment, there are actually two liter symbols, l and L, and they both mean the same thing (effectively making the symbol case-insensitive---sheesh!).
So if I'm interpreting this correctly, it means that if a program supports UCUM, and even if it does so in a case-sensitive manner, _a UCUM program must always interpret l and L as synonyms, including derived units such as ml/mL. Is that a correct interpretation? Is UCUM forcing us to do equivalency lookups for certain symbols?
Interpreting the UCUM correctly has direct consequences in its implementations. Take for example JSR 363 (see UCUM UnitFormat for JSR 363 ), which superseded JSR 275 (which purported to support UCUM but never did), which has had UCUM support pulled and moved to Eclipse UOMo; read the horrible story. So I'm stuck with a the JSR 363 Reference Implementation, which serializes milliliter as ml. So when UOMo finally adds UCUM support for JSR 363, will it recognize the m" serialization from JSR 363 RI and "mL" from UCUM as interchangeable?
Werner Keil tells me (in the previously mentioned thread) that the UCUM considers l and L to be "two different distinct units". But ucum.js considers them to be the same units.
So here is my specific question: I'm using the JSR 363 RI to serialize units, which produces l for liters. I would prefer a UCUM implementation, but that's all that's available right now. If I use this implementation, it will produce loads of data using l instead of L. When my code is finally upgraded to a UCUM implementation, will it consider the currently serialized l data to be equivalent to L, or will it consider the data to be distinct from data using L units? What does the UCUM specification say should happen?
Let me ask this another way: let's say I'm going to write my own UCUM implementation of JSR 363. If my UnitFormat.parse(CharSequence csq) parses l and L, should the resulting unitLowercaseL.equals(unitUppercaseL) return true or false according to the UCUM specification and JSR 363?

Prove map id = id in idris?

I'm just starting playing with idris and theorem proving in general. I can follow most of the examples of proofs of basic facts on the internet, so I wanted to try something arbitrary by my own. So, I want to write a proof term for the following basic property of map:
map : (a -> b) -> List a -> List b
prf : map id = id
Intuitively, I can imagine how the proof should work: Take an arbitrary list l and analyze the possibilities for map id l. When l is empty, it's obvious; when
l is non-empty it's based on the concept that function application preserves equality.
So, I can do something like this:
prf' : (l : List a) -> map id l = id l
It's like a for all statement. How can I turn it into a proof of the equality of the functions involved?
You can't. Idris's type theory (like Coq's and Agda's) does not support general extensionality. Given two functions f and g that "act the same", you will never be able to prove Not (f = g), but you will only be able to prove f = g if f and g are defined the same, up to alpha and eta equivalence or so. Unfortunately, things only get worse when you consider higher-order functions; there's a theorem about such in the Coq standard library, but I can't seem to find or remember it right now.

Pumping Lemma for Regular Languages

I'm having some trouble with a rather difficult question. I'm being asked to prove the language {0^n 1^m 0^n | m,n >= 0} is irregular using the pumping lemma. In all the examples I've seen, the language is only being raised to the same variable (i.e. a^n b^n). So my question is, how do I pick a suitable string to test if this language is irregular?
Also a follow up to that question is once I have my string, how do you decompose the string into the form xyz where |xy| <= pumping length and |y| >=1?
In the examples you have seen before there were different letters: n as followed by bs. In the given example, the are n Os at the beginning and the end of the word. The language adds 0 or more 1s between those blocks of Os.
W in the pumping lemma is decomposed w = x y z with |xy| <= m and |y| > 0, where m is the pumping length. The way to pick a w is the same as before: you pick it such that the xy is completely inside a block consisting of one letter. For a^n b^n a word in L was selected such that xy would entirely consist of as, such that if it is 'pumped' there will be more as than bs. So you need at least m as and for the word to be in the language that means you need to pick m bs. The shortest is w = a^mb^m. For the new troublesome language, pick a word in this L such that xy consists entirely of Os (in the first block), such that if it is 'pumped' there will be more Os in the first block than the last block -and the number of 1s in the middle was not changed. However, you need to include at least one 1 in your original word otherwise there is only one block of Os - and pumped words in fact are in the language, which means there is no contradiction and thus not proof that L is irregular.

Converting EBNF to BNF

It's been a few years since my computer-language class and so I've forgotten the finer points of BNF's and EBNF's and I don't have a textbook next to me. Specifically, I've forgotten how to convert an EBNF into BNF.
From what little I remember, I know that one of the main points is to convert
{ term }
into
<term> | <many-terms>
But I don't remember the other rules. I've tried to look this up online but I can only find links to either homework questions, or a small comment about converting terms with curly braces. I can't find an exhaustive list of rules that define the translation.
See this page.🕗 It contains instructions for each production that needs to be converted:
From EBNF to BNF
For building parsers (especially bottom-up) a BNF grammar is often better, than EBNF. But it's easy to convert an EBNF Grammar to BNF:
Convert every repetition { E } to a fresh non-terminal X and add
X = ε | X E.
Convert every option [ E ] to a fresh non-terminal X and add
X = ε | E.
(We can convert X = A [ E ] B. to X = A E B | A B.)
Convert every group ( E ) to a fresh non-terminal X and add
X = E.
We can even do away with alternatives by having several productions with the same non-terminal.
X = E | E'. becomes X = E. X = E'.
Be warned: EBNF as it's listed in the ISO standard also includes exceptions to syntactic rules, which do not have a BNF equivalent. The conversion given by 500 - Internal Server Error only works for the portion of EBNF which overlaps with RBNF/ABNF.