I'm finally done with the first part "Basic Set Theory" :-) The two last chapters:
Friday, January 25 2013
By fredw on Friday, January 25 2013, 22:25
Tuesday, January 22 2013
By fredw on Tuesday, January 22 2013, 23:33
I’ve recently been working on automated testcase reduction tools for the MathJax project and thus I had the chance to study Jesse Ruderman’s Lithium tool, itself inspired from the ddmin algorithm. This paper contains good ideas, like for example the fact that the reduction could be improved if we rely on the testcase structure like XML nodes or grammar tokens instead of just characters/lines (that’s why I’ve started to write a version of Lithium to work with abstract data structure). However, the authors of the ddmin paper really don’t analyse precisely the complexity of the algorithm, except the best and worst case and there is a large gap between the two. Jesse's analysis is much better and in particular introduces the concepts of monotonic testcase and clustered reduction where the algorithm performs the best and which intuitively seems the usual testcases that we meet in practice. However, the monotonic+clustered case complexity is only “guessed” and the bound for a monotonic testcase (of size with final reduction of size ) is not optimal. For example if the final reduction is relatively small compared to , say then and we can’t say that the number of verifications is small compared to . In particular, Jesse can not deduce from his bound that Lithium’s algorithm is better than an approach based on binary search executions! In this blog post, I shall give the optimal bound for the monotonic case and formalize that in some sense the clustered reduction is near the best case. I’ll also compare Lithium’s algorithm with the binary search approach and with the ddmin algorithm. I shall explain that Lithium is the best in the monotonic case (or actually matches the ddmin in that case).
Thus suppose that we are given a large testcase exhibiting an unwanted behavior. We want to find a smaller test case exhibiting the same behavior and one way is to isolate subtestcases that can not be reduced any further. A testcase can be quite general so here are basic definitions to formalize a bit the problem:
A testcase is a nonempty finite sets of elements (lines, characters, tree nodes, user actions) exhibiting an “interesting” behavior (crash, hang and other bugs…)
A reduction of is a testcase with the same “interesting” behavior as .
A testcase is minimal if .
Note that by definition, is a reduction of itself and is not a reduction of . Also the relation “is a reduction of” is transitive that is a reduction of a reduction of is a reduction of .
We assume that verifying one subset to check if it has the “interesting” behavior is what takes the most time (think e.g. testing a hang or user actions) so we want to optimize the number of testcases verified. Moreover, the original testcase is large and so a fast reduction algorithm would be to have a complexity in . Of course, we also expect to find a small reduction that is .
Without information on the structure on a given testcase or on the properties of the reduction , we must consider the subsets , to find a minimal reduction. And we only know how to do that in operations (or with Grover’s algorithm ;-)). Similarly, even to determine whether is minimal would require testing subsets which is not necessarily (e.g. ). Hence we consider the following definitions:
For any integer , is -minimal if .
In particular, is -minimal if .
is monotonic if .
Finding a -minimal reduction will give a minimal testcase that is no longer interesting if we remove any portion of size at most . Clearly, is minimal if it is -minimal for all . Moreover, is always -minimal for any . We still need to test exponentially many subsets to find a -minimal reduction. To decide whether is -minimal, we need to consider subsets obtained by removing portions of size that is subsets. In particular whether is -minimal is and so if . If is monotonic then so is any reduction of . Moreover, if is a reduction of and , then and so is a reduction of . Hence when is monotonic, is -minimal if and only if it is minimal. We will target -minimal reduction in what follows.
Let’s consider Lithium’s algorithm. We assume that is ordered and so can be identified with the interval (think for example line numbers). For simplicity, let’s first assume that the size of the original testcase is a power of two, that is . Lithium starts by steps . At step , we consider the chunks among the intervals of size . Lithium verifies if removing each chunk provides a reduction. If so, it permanently removes that chunk and tries another chunk. Because is not a reduction of , we immediately increment if it remains only one chunk. The -th step is the same, with chunk of size 1 but we stop only when we are sure that the current testcase is -minimal that is when after attempts, we have not reduced any further. If is not a power of 2 then where . In that case, we apply the same algorithm as (i.e. as if there were dummy elements at the end) except that we don’t need to remove the chunks that are entirely in that additional part. This saves testing at most subtests (those that would be obtained by removing the dummy chunks at the end of sizes ). Hence in general if is the number of subsets of tried by Lithium, we have . Let be the size of the -minimal testcase found by Lithium and .
Lithium will always perform the initial steps above and check at least one subset at each step. At the end, it needs to do operations to be sure that the testcase is -minimal. So . Now, consider the case where monotonic and has one minimal reduction . Then is included in the chunk from step . Because is monotonic, this means that at step , we do two verifications and the second chunk is removed because it does not contain the (and the third one too if is not a power of two), at step it remains two chunks, we do two verifications and the second chunk is removed etc until . For , the number of chunk can grow again: 2, 4, 8… that is we handle at most chunks from step to . At step , a first round of at most verifications ensure that the testcase is of size and a second round of verifications ensure that it is -minimal. So and after simplification . Hence the lower bound is optimal. The previous example suggests the following generalization: a testcase is -clustered if it can be written as the union of nonempty closed intervals . If the minimal testcase found by Lithium is -clustered, each is of length at most and so intersects at most 2 chunks of length from the step . So intersects at most chunks from the step and a fortiori from all the steps . Suppose that is monotonic. Then if is a chunk that does not contain any element of then is a reduction of and so Lithium will remove the chunk . Hence at each step , at most chunks survive and so there are at most chunks at the next step. A computation similar to what we have done for shows that if the final testcase found by Lithium is -clustered. Note that we always have and . So if then is small as wanted. Also, the final testcase is always -clustered (union of intervals that are singletons!) so we found that the monotonic case is . We shall give a better bound below.
Now, for each step , Lithium splits the testcase in at most chunk and try to remove each chunk. Then it does at most steps before stopping or removing one chunk (so the testcase becomes of size at most ), then it does at most steps before stopping or removing one more chunk (so the testcase becomes of size at most ), …, then it does at most steps before stopping or removing one more chunk (so the testcase becomes of size at most ). Then the testcase is exactly of size and Lithium does at most additional verifications. This gives verifications. This bound is optimal if (this is asymptotically true since we assume ): consider the cases where the proper reductions of are exactly the segments and . The testcase will be preserved during the first phase. Then we will keep browsing at least the first half to remove elements at position . So .
We now come back to the case where is monotonic. We will prove that the worst case is and so our assumption gives as we expected. During the steps , we test at most chunks. When , chunks but at most distinct chunks contain an element from the final reduction. By monocity, at most chunks will survive and there are at most chunks at step . Again, only chunks will survive at step and so on until . A the final step, it remains at most elements. Again by monocity a first round of tests will make elements survive and we finally need additional tests to ensure that the test case is minimal. Hence . This bound is optimal: if , consider the case where is the only minimal testcase (and monotonic) ; if is not a power of two, consider the same with points removed at odd positions. Then for each step , no chunks inside are removed. Then some chunks in are removed (none if is a power of two) at step and it remains chunks. Then for steps there are always exactly chunks to handle. So .
We note that we have used two different methods to bound the number of verifications in the general monotonic case, or when the testcase is -clustered. One naturally wonders what happens when we combine the two techniques. So let . From step to , the best bound we found was ; from step to , it was ; from step to it was again ; from step to , it was and finally from step to , including final verifications, it was . Taking the sum, we get Because , this becomes . If , then we get . At the opposite, if , we get . If is not but then and and so the expression can be simplified to . Hence we have obtained an intermediate result between the worst and best monotonic cases and shown how the role played by the number of clusters: the less the final testcase is clustered, the faster Lithium finds it. The results are summarized in the following table:
|Number of tests|
|is monotonic ; is -clustered|
|is monotonic ; is -clustered ( and unbounded)|
In the ddmin algorithm, at each step we add a preliminary round where we try to immediately reduce to a single chunk (or equivalently to remove the complement of a chunk). Actually, the ddmin algorithm only does this preliminary round at steps where there are more than 2 chunks for otherwise it would do twice the same work. For each step , if one chunk is a reduction of then for some chunk at the previous step . Now if is monotonic then, at level , removing all but the chunk gives a subset that contains and so a reduction of by monocity. Hence on chunk survive at level and there are exactly 2 chunks at level and so the ddmin algorithm is exactly Lithium’s algorithm when is monotonic. The ddmin algorithm keeps in memory the subsets that we didn’t find interesting in order to avoid repeating them. However, if we only reduce to the complement of a chunk, then we can never repeat the same subset and so this additional work is useless. That’s the case if is monotonic.
Finally, if is monotonic Jesse proposes a simpler approach based on a binary search. Suppose first that there is only one minimal testcase . If then intersects and so . Then is not a reduction of for otherwise a minimal reduction of would be a minimal reduction of distinct from which we exclude by hypothesis. If instead then does not intersect and is a reduction of because is monotonic. So we can use a binary search to find by testing at most testcases (modulo some constant). Then we try with intervals to find the second least element of in at most . We continue until we find the -th element of . Clearly, this gives verifications which sounds equivalent to Jesse’s bound with even a better constant factor. Note that the algorithm still works if we remove the assumption that there is only one minimal testcase . We start by and find : if then contains at least one mininal reduction with least element and so is a reduction because is monotonic. If then is not a reduction of or a minimal reduction of would be a minimal reduction of whose least element is greater than . So is a reduction of . The algorithm continues to find etc and finally returns a minimal reduction of . However, it is not clear that this approach can work if is not monotonic while we can hope that Lithium is still efficient if is “almost” monotonic. We remark that when there is only one minimal testcase , the binary search approach would require something like . So that would be the worst case of the binary search approach whereas Lithium handles this case very nicely in ! In general, if there is only one minimal testcase of size then can be anywhere between and if is placed at random, with probability at least . So the average complexity of the binary search approach in that case will be at least which is still not as good as Lithium’s optimal worst case of …
Friday, January 11 2013
By fredw on Friday, January 11 2013, 13:24
For those who missed the news, Google Chrome 24 has recently been released with native MathML support. I'd like to thank Dave Barton again for his efforts during the past year, that have allowed to make this happen. Obviously, some people may ironize on how long it took for Google to make this happen (Mozilla MathML project started in 1999) or criticize the bad rendering quality. However the MathML folks, aware of the history of the language in browsers, will tend to be more tolerant and appreciate this important step towards MathML adoption. After all, this now means that among the most popular browsers, Firefox, Safari and Chrome have MathML support and Opera a basic CSS-based implementation. This also means that about three people out of four will be able to read pages with MathML without the need of any third-party rendering engine.
After some testing, I think the Webkit MathML support is now good enough to be used on my Website. There are a few annoyances with stretchy characters or positioning, but in general the formulas are readable. Hence in order to encourage the use of MathML and let people report bugs upstream and hopefully help to fix them, I decided to rely on the native MathML support for Webkit-based browsers. I'll still keep MathJax for Internet Explorer (when MathPlayer is not installed) and Opera.
I had the chance to meet Dave Barton when I was at the Silicon Valley last October for the GSoC mentor summit. We could exchange our views on the MathML implementations in browsers and discuss the perspectives for the future of MathML. The history of MathML in Webkit is actually quite similar to Gecko's one: one volunteer Alex Milowski decided to write the initial implementation. This idea attracted more volunteers who joined the effort and helped to add new features and to conduct the project. Dave told me that the initial Webkit implementation did not pass the Google's security review and that's why MathML was not enabled in Chrome. It was actually quite surprising that Apple decided to enable it in Safari and in particular all Apple's mobile products. Dave's main achievement has been to fix all these security bugs so that MathML could finally appear in Chrome.
MathML with CSS
dir attributes as
HTML and animated SVG inside MathML tokens
MathML inside animated SVG (via the
Note that although Dave was focused on improving MathML, the language
integrates with the rest of Webkit's technologies and almost all the demos
above work as expected, without any additional efforts. Actually,
Gecko's MathML support relies less on the CSS layout engine than Webkit
does and this has been a recurrent source of bugs. For example in the
first demo, the
text-shadow property is not applied to some operators
827039) while it is in Webkit.
In my opinion, one of the problem with MathML is
that the browser vendors never really shown a lot of interest in
this language and the standardization and implementation efforts were mainly
lead and funded by organizations from the publishing industry or by volunteer
As the MathML WG members keep repeating, they would love to get more
feedback from the browser developers.
This is quite a problem for a language that has among the main goal
the publication of mathematics on the Web.
This leads for example to MathML features
(some of them are now deprecated) duplicating CSS properties or
<mstyle> element which has most of its
attributes unused and do similar things as CSS inheritance in an
incompatible way. As a consequence, it was difficult to implement
all MathML features properly in Gecko and this is the source of many bugs like the one
I mention in the previous paragraph.
Hopefully, the new MathML support in Chrome will bring more interest to MathML from contributors or Web companies. Dave told me that Google could hire a full-time engineer to work on MathML. Apparently, this is mostly because of demands from companies working on Webkit-based mobile devices or involved in EPUB. Although I don't have the same impression from Mozilla Corporation at the moment, I'm confident that with the upcoming FirefoxOS release, things might change a bit.
Finally I also expect that we, at MathJax, will continue to accompany the MathML implementations in browsers. One of the ideas I proposed to the team was to let MathJax select the output mode according to the MathML features supported by the browser. Hence the native MathML support could be used if the page contains only basic mathematics while MathJax's rendering engine will be used when more advanced mathematical constructions are involved. Another goal to achieve will be to make MathJax the default rendering in Wikipedia, which will be much better than the current raster image approach and will allow the users to switch to their browser's MathML support if they wish...
Thursday, January 3 2013
By fredw on Thursday, January 3 2013, 22:27
During last December, I've made more progress on the exercises from Thomas Jech's book "Set Theory". After the six first chapters and the seventh chapter, I've worked on chapters 8, 9 and 10. I've published the solutions for most of the exercices here:
I also typeset a couple of exercises from chapter 12 that I solved some years ago but didn't get the opportunity to work on new exercises yet.
Tuesday, November 27 2012
By fredw on Tuesday, November 27 2012, 14:10
Since my previous blog post, I have been working on exercises from chapter 7 of Thomas Jech’s book "Set Theory". I’ve published my solutions but I’m not yet done with exercises 7.22 and 7.28 which seem to be generalizations of theorems 4.3 and 3.2. I guess that before coming back to these two exercises, I’ll consider the content and exercises of subsequent chapters…
I had the opportunity to read chapter 7 again and to study more precisely the correctness of some claims (you know, those that are "clearly seen to be obvious via an easy proof based on a straightforward argument that makes them trivial" but actually take time before really being understood) I describe below the two statements for which the ratio between the time I spent on them and the length of the proof provided was the largest. I indicate the arguments I used to convince myself. I also had trouble to understand the proof of theorem 7.15 but most of the required arguments can actually be found in the exercises.
The first part of the chapter essentially deals with ultrafilters on an infinite set (a topic that should be familiar to Peter Krautzberger, MathJax’s manager). In particular, a nonprincipal ultrafilter on is a Ramsey ultrafilter if for every partition of into pieces such that , there exists such that . We have:
The continuum hypothesis implies the existence of a Ramsey ultrafilter.
The proof given in the book is to consider an enumeration of all partitions of and to construct by induction a sequence of infinite subsets. is chosen to be included in some element of or to intersect each of them at, at most, one element. For limit, is chosen such that is finite for all . Such a is claimed to exist because is countable. Finally, is claimed to be a Ramsey ultrafilter.
There were several points that were not obvious to me. First, it’s good to count the number of partitions of . On the one hand, given any which is neither empty nor cofinite we can define a partition of by and so there are at least such partitions (cofinite subsets are in bijection with finite subsets and ). On the other hand, a partition is determined by the family of subsets and so there are at most such partitions. Since we assume the continuum hypothesis we get the enumeration .
Next, I’m not even sure that as it is defined is a filter. Because is infinite and but if and , it does not seem really clear which . However, if is a nonprincipal ultrafilter a remark from chapter 10 suggests that does not contain any finite set. By exercise 7.3, this is equivalent to the fact that does not contain any singleton . This latter point is easy to verify: if we assume the contrary, because is nonprincipal, there exists such that and so would be in . Hence any ultrafilter containing should also contain . is a filter: the arguments above still hold and and so we only need to verify that is finite if . This is already what is claimed for a limit ordinal. In general if is the greatest limit ordinal such that then by construction, and so is empty if and is finite if . So we can replace by a "ultrafilter extending ". It’s not too difficult to check that a ultrafilter containing must be Ramsey. For any partition then by construction either for some and so or . In the latter case we can find (so ) such that (we pick one element from each such that and put these elements into ).
Finally, the most difficult part was to understand how the sequence can be built. We can choose arbitrarily as this set is not involved in the arguments above. For any , if there exists some such that is infinite, we just set . Otherwise, since is infinite, is nonempty for infinitely many . Pick one element from each nonempty set to form the set . By definition, . Now we consider the case limit. Let be a cofinal -sequence in . Note that it is the only place where we use the continuum hypothesis! For each , we define . We have infinite and finite so is infinite. Similarly, and are finite so is infinite etc and finally is infinite. Thus we can use a classical technique from Cantor (I can’t find a reference) and construct the set by picking each so that is finite. Moreover for each consider some : is finite.
The second part of the chapter is about Boolean algebras. A Boolean algebra is a completion of a Boolean algebra if it is complete (every subset has a least upper bound ) and if is a dense subalgebra of (for any there exists such that ). I got stuck on the apparently easy proof of the following lemma:
The completion of a Boolean algebra is unique up to isomorphism
Let are two completions of . It is indicated in the book that the density of in and is used to prove that defines an isomorphism between and . The example of is given: indeed if we can find an element such that and so . ∎
Two or three pages before, it is mentioned that "if is a one-to-one mapping such that then is an isomorphism". That seems to be the most natural method to prove the lemma above. However, this statement is false: consider the morphism of Boolean algebra which is one-to-one but not surjective. Actually, the property implies the fact that is one-to-one, which becomes vacuous. So I suspect the author rather means "surjective" instead of "one-to-one". Indeed, in that case is a bijection that preserves the order in both directions and since all the operations of the Boolean algebra can be described in terms of this order, is an isomorphism.
So first, given , we want to find such that . By symmetry, the natural candidate is . For all , we have and so . If then by density we can find such that . Hence and . The latter implies that for all we have an so . Combining this with the former, we would have . Thus is surjective.
It remains to prove . If then . Let’s consider the contrapositive of the converse implication: suppose . Then and (we use the hint given in the book). If we are able to prove then we would have and so as desired. It suffices to show two inequalities on the and operations. Note that . Let . Let . Then for all , so . Similarly, we have for all , . So .
As a conclusion, I notice a similarity between these too cases: both have a sketchy proof based on a statement that seems incorrect (" is a filter", "any one-to-one mapping between Boolean algebra that preserves the order in both directions is an isomorphism"). Sometimes, I’m wondering if these kinds of inaccuracy are not intentional in order to force readers to try and find the proof themselves :-)