As a first step towards turning SubEthaEdit into a capable LaTeX editing machine, let's address citations. Citations are a challenge to keep consistent and accurate, so mechanized assistance is quite useful. For LaTeX, that means BibTeX. BibTeX separates content from presentation in much the way that TeX does. Considering the many different formatting styles for bibliographies and citations that are required by different journals, this is something that I won't give up on -- I'll type the citation keys by hand if needed.
Fortunately, getting citation support in SubEthaEdit is trivial! Just install BibDesk, if you're not already using it, and set up autocompletion for SubEthaEdit. Inside a \cite, hit F5 or command-escape, and you get a list of completions for a partial citation key. This works really well. I hadn't used BibDesk for that for a while, since TextMate had its own method (not that it has worked in recent versions), so I'd forgotten how slick this is.
Completions in general, not just for citations, can be made a little bit easier. In your user Library folder, there may be a KeyBindings folder; if not, create it. Create a file DefaultKeyBinding.dict in the KeyBindings folder. The file is an XML file with a list of key-action pairs; bind the escape key to a string "complete:" (with the colon, without the quotes). The Property List Editor works nicely for doing this. The end result is that you just press escape instead of command-escape to get a completion. It doesn't cause any problems for using escape to, say, select cancel in dialogs, so there's no down side, just completions that are easier to activate.
Friday, June 29, 2007
Thursday, June 28, 2007
Mac OS X editors for writing LaTeX
Well, it's taken a bit longer for me to get back to writing than I'd expected. I do intend to follow up on the one million answers post, but for now I'll take a look at something else.
In short, I am fed up with the LaTeX mode for TextMate, and maybe TextMate in general. Writing text, instead of programming, really seems to highlight the worst aspects of TextMate. Besides the well known failings of its undo, TextMate has two other serious annoyances that are relevant here.
First, you can only use monospace fonts. I accept it as the reality for a lot of programming, even if I don't like it. For writing LaTeX, it's terrible. Literally headache inducing.
The second flaw is how words are selected using the mouse. Standard behavior for Mac OS X is that when you double-click on a word, it is selected. Extending this, if you "click and a half," (double click, but keep the mouse button held down on the second click) you can then drag and select text by words instead of characters. In most applications, this works very well, and is often simpler than character-based selection. However, in TextMate, this works poorly, because you can't select a sentence including the period at the end. You can get to the last word, and then the selection jumps to include the first word of the next sentence.
All three of these problems make writing text a little bit harder, but aren't that big of a deal for programming. Taken all together, they make writing LaTeX into a stressful experience, and formal writing is hard enough. These troubles all come from the use of a custom text view instead of the standard Cocoa NSTextView. The author of TextMate, Allan Odgaard, has written that it would be easier to write a replacement for NSTextView than to get NSTextView to do what he wanted. I'm not sure I believe him; for me, at least, behaving like the rest of the Mac OS X text system is pretty important. In this sense, he hasn't written a replacement for NSTextView.
TextMate does have a LaTeX mode, though. It has a lot of nice features, like integrating with PDF viewers through pdfsync, text completion for citations and cross references, assorted functions for project management, and various snippets for simplifying typing. Unfortunately, not all of that works very well -- I've never got citation completion to work reliably, and not for lack of trying. Text completions have some funny behavior. Showing an outline of the document fails if it includes a file that started with the letter 'x' (no, I'm not kidding).
Because of all this, I've downloaded the current version of SubEthaEdit and will give that a try for the next month. So far, I'm finding the basic editing to be much more pleasant. I'm using a proportional font, undos work sanely, and I can select by words using the mouse. The basic task of writing seems a lot more pleasant. I haven't used SubEthaEdit much since getting TextMate, and the last version I'd used was version 2.2. It's still the same elegant, minimalist editor, but things have changed a bit. There are now language modes with mode-dependent scripting, not just syntax highlighting. There are now tabs, and a quite elegant implementation at that (no projects, yet, though).
That said, the LaTeX mode just has syntax highlighting. No pdfsync support. No keystroke to compile the file into a PDF and send it to a viewer. No completion of citations. However, SubEthaEdit is extendable by scripting and, thanks to its reliance on Mac OS X standards, the editing features can be extended by input managers. Over the thirty-day trial period, I'll see what I can do to extend SubEthaEdit's LaTeX mode into something a little more capable.
In short, I am fed up with the LaTeX mode for TextMate, and maybe TextMate in general. Writing text, instead of programming, really seems to highlight the worst aspects of TextMate. Besides the well known failings of its undo, TextMate has two other serious annoyances that are relevant here.
First, you can only use monospace fonts. I accept it as the reality for a lot of programming, even if I don't like it. For writing LaTeX, it's terrible. Literally headache inducing.
The second flaw is how words are selected using the mouse. Standard behavior for Mac OS X is that when you double-click on a word, it is selected. Extending this, if you "click and a half," (double click, but keep the mouse button held down on the second click) you can then drag and select text by words instead of characters. In most applications, this works very well, and is often simpler than character-based selection. However, in TextMate, this works poorly, because you can't select a sentence including the period at the end. You can get to the last word, and then the selection jumps to include the first word of the next sentence.
All three of these problems make writing text a little bit harder, but aren't that big of a deal for programming. Taken all together, they make writing LaTeX into a stressful experience, and formal writing is hard enough. These troubles all come from the use of a custom text view instead of the standard Cocoa NSTextView. The author of TextMate, Allan Odgaard, has written that it would be easier to write a replacement for NSTextView than to get NSTextView to do what he wanted. I'm not sure I believe him; for me, at least, behaving like the rest of the Mac OS X text system is pretty important. In this sense, he hasn't written a replacement for NSTextView.
TextMate does have a LaTeX mode, though. It has a lot of nice features, like integrating with PDF viewers through pdfsync, text completion for citations and cross references, assorted functions for project management, and various snippets for simplifying typing. Unfortunately, not all of that works very well -- I've never got citation completion to work reliably, and not for lack of trying. Text completions have some funny behavior. Showing an outline of the document fails if it includes a file that started with the letter 'x' (no, I'm not kidding).
Because of all this, I've downloaded the current version of SubEthaEdit and will give that a try for the next month. So far, I'm finding the basic editing to be much more pleasant. I'm using a proportional font, undos work sanely, and I can select by words using the mouse. The basic task of writing seems a lot more pleasant. I haven't used SubEthaEdit much since getting TextMate, and the last version I'd used was version 2.2. It's still the same elegant, minimalist editor, but things have changed a bit. There are now language modes with mode-dependent scripting, not just syntax highlighting. There are now tabs, and a quite elegant implementation at that (no projects, yet, though).
That said, the LaTeX mode just has syntax highlighting. No pdfsync support. No keystroke to compile the file into a PDF and send it to a viewer. No completion of citations. However, SubEthaEdit is extendable by scripting and, thanks to its reliance on Mac OS X standards, the editing features can be extended by input managers. Over the thirty-day trial period, I'll see what I can do to extend SubEthaEdit's LaTeX mode into something a little more capable.
Wednesday, February 14, 2007
One Million Answers
I was thinking about the game of Twenty Questions recently. In particular, I became curious about just how many different subjects could be distinguished by asking twenty yes-or-no questions. As it turns out, answering this question touches on a number of interesting matters. I will explore those later, but, first, let us address the basic question: how many different items can one identify?
Consider first what you can find out with just one question. The best case is to ask a question that distinguishes between two items. It is not possible to do any better: a question can be posed such that yes matches one subject and no matches a second subject, but there is no third response to match a third subject. Of course, a poor question won't tell you anything at all; this doesn't affect the maximum number of subjects possible, so we will ignore it and assume the best case.
So far, we have not said those two subjects are. They could be anything: people, animals, plants, rocks, cars, fungi. They could also be sets. Take each item to be a set containing two other items. Now, for whichever set that we determine with the first question, a second question allows us to distinguish between the members of that set.
It should be clear how we proceed. We take the second item to again be a set with two items, each of which we take to be a set with two items, and so on. In order to identify a specific item, we must stop this progression with the twentieth question. Putting it all together, we have nested sets constructed such that each yes-or-no question peels away a layer until we are left with a unique item. Each question doubles the number of items that can be identified, so that one question distinguishes two possibilities, two questions distinguish four possibilities, three questions distinguish eight possibilities, and so on. In general,
Although it made a nice post title, the number of possible solutions to a game of twenty questions may not actually be one million. There is a traditional question of “animal, vegetable, or mineral?” at the beginning of the game. It is not clear to me whether that is supposed to be the first question, or if it is extra information provided. Either way, there are three possible response. Additionally, identifying the subject may or many not also count as a question, with a necessary positive answer. Given that, there may be as many as 3,145,728 possibilities, or as few as 786,432 possibilities.
Whatever the precise total, it is, to put it mildly, a big number. To put it in perspective, the Merriam-Webster unabridged dictionary has fewer than half a million entries. In fact, a sizable dictionary could be used as a solution key: pick the middle page of the dictionary and ask whether the object of interest occurs (or, better, would occur under the assumption it is in the dictionary) before the first word on the page, pick the middle page of the identified half of the dictionary and ask a similar question, and so on, continually halving the possible results. Strictly speaking, each question in this approach does not halve the number of words under consideration, but it is close enough to be an effective strategy. More generally, any effective strategy aims to halve the number of remaining possibilities, which leads naturally to beginning with general questions and moving to successively more specific matters.
The above questioning strategy is an example of a divide and conquer algorithm, where a problem is recursively broken down into smaller subproblems until a direct solution is trivial. More specifically, the strategy is a binary search procedure, where the space of possible solutions is continually halved in size until an answer is found. Such algorithms are important and effective ways to solve many problems of diverse character; Twenty Questions is an amusing parlor game, but also a model for efficient problem solving.
Consider first what you can find out with just one question. The best case is to ask a question that distinguishes between two items. It is not possible to do any better: a question can be posed such that yes matches one subject and no matches a second subject, but there is no third response to match a third subject. Of course, a poor question won't tell you anything at all; this doesn't affect the maximum number of subjects possible, so we will ignore it and assume the best case.
So far, we have not said those two subjects are. They could be anything: people, animals, plants, rocks, cars, fungi. They could also be sets. Take each item to be a set containing two other items. Now, for whichever set that we determine with the first question, a second question allows us to distinguish between the members of that set.
It should be clear how we proceed. We take the second item to again be a set with two items, each of which we take to be a set with two items, and so on. In order to identify a specific item, we must stop this progression with the twentieth question. Putting it all together, we have nested sets constructed such that each yes-or-no question peels away a layer until we are left with a unique item. Each question doubles the number of items that can be identified, so that one question distinguishes two possibilities, two questions distinguish four possibilities, three questions distinguish eight possibilities, and so on. In general,
n questions allows us to distinguish 2n possibilities. For n=20 questions, that gives 220=1,048,576 possibilities—roughly one million possibilities.Although it made a nice post title, the number of possible solutions to a game of twenty questions may not actually be one million. There is a traditional question of “animal, vegetable, or mineral?” at the beginning of the game. It is not clear to me whether that is supposed to be the first question, or if it is extra information provided. Either way, there are three possible response. Additionally, identifying the subject may or many not also count as a question, with a necessary positive answer. Given that, there may be as many as 3,145,728 possibilities, or as few as 786,432 possibilities.
Whatever the precise total, it is, to put it mildly, a big number. To put it in perspective, the Merriam-Webster unabridged dictionary has fewer than half a million entries. In fact, a sizable dictionary could be used as a solution key: pick the middle page of the dictionary and ask whether the object of interest occurs (or, better, would occur under the assumption it is in the dictionary) before the first word on the page, pick the middle page of the identified half of the dictionary and ask a similar question, and so on, continually halving the possible results. Strictly speaking, each question in this approach does not halve the number of words under consideration, but it is close enough to be an effective strategy. More generally, any effective strategy aims to halve the number of remaining possibilities, which leads naturally to beginning with general questions and moving to successively more specific matters.
The above questioning strategy is an example of a divide and conquer algorithm, where a problem is recursively broken down into smaller subproblems until a direct solution is trivial. More specifically, the strategy is a binary search procedure, where the space of possible solutions is continually halved in size until an answer is found. Such algorithms are important and effective ways to solve many problems of diverse character; Twenty Questions is an amusing parlor game, but also a model for efficient problem solving.
Sunday, February 4, 2007
Inaugural Post
My major intention for this blog is to look at abstraction as a conceptual and practical tool. In this light, abstraction should be understood as the process of considering something independently of some or all of its concrete attributes or properties. So viewed, many fields of thought can be seen as critically dependent on abstraction, but everyday life is filled with abstractions.
An example may be useful. Students at US schools and universities are quite familiar with tests that require the use of a number 2 pencil. Consider that pencil: does it matter whether it is wooden or a mechanical contrivance of metal and plastic? Clearly not; it is only relevant that the pencil is a tool with which to darken a response from A to E in a manner sufficient for reading by an optical scanner. That nature is summed up by describing the pencil lead, with other details being usefully suppressed.
Of course, I will not spend much time on pencils! There are many other areas where abstraction is key, and of considerably greater interest. Computers. Programming. Mathematics. We will sample from each of these, and more.
An example may be useful. Students at US schools and universities are quite familiar with tests that require the use of a number 2 pencil. Consider that pencil: does it matter whether it is wooden or a mechanical contrivance of metal and plastic? Clearly not; it is only relevant that the pencil is a tool with which to darken a response from A to E in a manner sufficient for reading by an optical scanner. That nature is summed up by describing the pencil lead, with other details being usefully suppressed.
Of course, I will not spend much time on pencils! There are many other areas where abstraction is key, and of considerably greater interest. Computers. Programming. Mathematics. We will sample from each of these, and more.
Subscribe to:
Posts (Atom)