Musings

Austin, as I’ve said, is WiFi heaven. But, then there are the times when you’re just plain out of range.

Last weekend, on the train from Seattle to Eugene I needed to access the 'Net. Amtrak, alas, has not added WiFi service to Business Class, but, fortunately, cell phone service works quite well. So I plugged the Bluetooth dongle into my iBook, and connected, wirelessly via cell phone to the UT dialup service. It was only 9600 baud, but we were on a train, after all.

Tonight, I found myself with 20 minutes to kill, waiting for my daughter’s rehearsal to finish at the Zach Scott Theater. Not really enough time to make a trip to the Schlotzky’s Deli down the street (with its free WiFi) worthwhile. So I pulled out my laptop, fired up the old Bluetooth and caught up on my email … right there in the parking lot.

Hard on the heels of fixing bug 228804, which, for years, had bedevilled the rendering of MathML in Mozilla/Mac, Yamashita Makoto has been busy fixing other bugs.

• The disappearing minus sign bug is now fixed, so you don’t need to map U+2212 to some explicit choice of font, as I recommended previously.
• The Symbol font is now recognized, and can be used with MathML.
• Most surprisingly, Computer Modern Fonts can now be used with Mozilla (at least, in MacOSX 10.4).
  1. Download the CM/PS Fonts (and, if you want, the AMS/PS Fonts as well).
  2. Grab the screen fonts files from the Screen Fonts folder and drag it into the PS Fonts folder
  3. Drag the PS Fonts folder into /Library/Fonts or ~/Library/Fonts

Now, that sounds wonderful. But, alas, it is not a panacea. The nice calligraphic letters in CMSY10, or the blackboard bold letter in MSBM10, or the fraktur letters in EUFM10 still won’t work in Mozilla. There’s no way, apparently, to remap Plane-1 characters, so you still need to rely on a Unicode font like Code2001.

And there are more glitches. The circumflex accent gets rendered too high, when used in MathML. So do =, +, and × (but not −), because (apparently) they’re taken from some stupid fallback font, instead of one of the desired mathematical fonts.

Still, it’s real progress. And Makoto is even offering a version of Camino with MathML support enabled. So, if you want a MathML-capable Cocoa browser, Makoto’s your man …

Inline SVG

On a completely different topic, Firefox nightly builds are now SVG-enabled. That’s slightly old news. What’s new is that the native SVG support coexists nicely with the Adobe plugin. The native SVG support is missing some key features (no font-module support, for instance), so it doesn’t work properly with the SVG figures we use here at Musings. Fortunately, the Adobe plugin handles those just fine. On the other hand, the Adobe plugin doesn’t work at all with inline SVG (as used by … well, OK, nobody’s actually using inline SVG for anything other than the odd cutesy demo; but they could¹), which is handled reasonably well by the native SVG support.

One of the amusements of this past weekend was listening to Cumrun talk about the Swampland in perpetually-damp Eugene Oregon. I’ve discussed the subject here, before but what surprised me, when I asked him about it in person, was how modest his goals for the program are. He was very focussed on broad, qualitative features of vacua that could (or could not) arise in String Theory. More detailed, quantitative, questions he didn’t think were likely to be addressable in his framework. Perhaps, he was simply being cautious, sticking to things that might reasonably be proven in the near-term. But I think it’s important to state that more ambitious results are conceivable and — if String Theory is to usefully make contact with experiment — even necessary.

For concreteness, let us assume, it turns out that physics at low energies (below a few TeV) is described by the MSSM. This is a theory with no massless moduli, so any String vacua of this type are necessarily isolated. We don’t, currently, know of any String vacuum whose low-energy effective theory is precisely the MSSM (there are examples that come close). But many people confidently assert that the String Theory Landscape ought to contain a large number of such vacua. Let us be charitable and assume that they are correct.

Even so, these points form a set of measure zero in the MSSM parameter space¹. The generic point in the MSSM moduli space is part of the Swampland! Let me say that again: the generic point in the MSSM moduli space does not have a consistent UV completion including gravity; only a set of points of measure zero are UV-consistent.

Moreover, it’s far from clear how those UV-consistent points are distributed within the MSSM parameter space.

• Are they everywhere dense²?
• Or are there “voids” where there are no, or only a few vacua?
• Or do the points lie on, or near, a subspace of positive codimension?

Even if you believe that there are a large number of MSSM String Theory vacua, it’s an entirely separate, and far less plausible assertion that they are dense in the MSSM parameter space. Indeed, the whole point of the “Friendly Landscape” is that (if the Landscape is friendly) they are not dense, indeed, that they are peaked around some low-dimensional subspace of the parameter space³.

Finding genuinely realistic String vacua is a hard task. If we manage to find a large number of them, understanding how they are distributed within the relevant parameter space is yet another challenge. But it may be the one we ultimately need to face, to extract falsifiable predictions from String Theory.

Back at the end of June, I reported that trackback spam directed against this site had soared to nearly 13,000/month. That was, by any measure, a pretty hefty amount of spam. You might well have wondered what has happened since then.

LEP closed down in 2000, to make way for the LHC. There were, towards the end, intriguing hints that there was, perhaps, a bit of a bump in the number of b-jet events, indicating the possibility of a Higgs. Arguments were made that the LEP run should be extended. But, in the end, LEP was shut down on schedule, and the consensus was that it had established a lower limit of $m_h \gt 115$ GeV.

Still, people continue to pore over the data and, recently, Dermisek and Gunion have challenged the above consensus. The limit seems to be rather neatly evaded in the NMSSM¹. Rather than the dominant decay being $h\to b\overline{b}$, one expects the dominant decay mode to be $h\to a a$, where $a$ is a CP-odd boson of mass, $m_a\sim 30-40$ GeV. The $a$ subsequently decays, $a\to b\overline{b}$. The upshot is that, rather than a big excess of two b-jet events, from $Z h\to Z b\overline{b}$, we expect smaller excesses of both two b-jet and four b-jet events (from $Z h\to Z a a \to Z b\overline{b}b\overline{b}$). That, according to Dermisek and Gunion, is what’s seen in the LEP data, and is consistent with $m_h\sim 105$ GeV.

If correct, that’s very bad news for direct detection of the Higgs at the LHC. [As I emphasize to Sean, below we’ll see other stuff, just not a Higgs.]

As Sam repeatedly reminds us, HTTP GETs should be idempotent.

Usually, it’s “granny” who must be protected from GETting some unsafe resource. In the case of blogs, however, it’s not granny you need to worry about. It’s search engine spiders.

sv-crawl.looksmart.com - - [03/Nov/2005:14:37:47 -0600] "GET /cgi-bin/MT-2.5/sxp-comments.pl?comments_form&static=1&entry_id=75&author=affiliate%20software&email=ciali@mail.com&url=http://www.partnersmanager.com&text=great%20site&bakecookie=1&post=%20POST HTTP/1.1" 302 571 "-" "Mozilla/4.0 compatible ZyBorg/1.0 (wn-14.zyborg@looksmart.net; http://www.WISEnutbot.com)"
sv-crawl.looksmart.com - - [03/Nov/2005:14:37:47 -0600] "GET /cgi-bin/MT-3.0/sxp-comments.pl?comments_form&static=1&entry_id=75&author=affiliate%2520software&email=ciali@mail.com&url=http://www.partnersmanager.com&text=great%2520site&bakecookie=1&post=%2520POST HTTP/1.1" 200 6139 "-" "Mozilla/4.0 compatible ZyBorg/1.0 (wn-14.zyborg@looksmart.net; http://www.WISEnutbot.com)"
sv-crawl.looksmart.com - - [03/Nov/2005:22:10:26 -0600] "GET /cgi-bin/MT-2.5/sxp-comments.pl?comments_form&static=1&entry_id=75&author=levitra&email=ciali@mail.com&url=http://www.one-levitra.com&text=great%20site&bakecookie=1&post=%20POST HTTP/1.1" 302 552 "-" "Mozilla/4.0 compatible ZyBorg/1.0 (wn-14.zyborg@looksmart.net; http://www.WISEnutbot.com)"
sv-crawl.looksmart.com - - [03/Nov/2005:22:10:26 -0600] "GET /cgi-bin/MT-3.0/sxp-comments.pl?comments_form&static=1&entry_id=75&author=levitra&email=ciali@mail.com&url=http://www.one-levitra.com&text=great%2520site&bakecookie=1&post=%2520POST HTTP/1.1" 200 6084 "-" "Mozilla/4.0 compatible ZyBorg/1.0 (wn-14.zyborg@looksmart.net; http://www.WISEnutbot.com)"

Does your blogging system accept comments via HTTP GET?

i18n is hard. Don’t let anyone tell you any different.

Some people snigger at the fact that this blog (still) uses iso-8859-1 encoding. “Use utf-8, man! It’s the solution to all your troubles.” Oh yeah? Let me tell you a story.

Zack Ajmal has a MovableType blog. He’s using the very latest version of MovableType (3.2), on an enlightened host with very recent versions of Perl (5.8.4) and MySQL (4.1.14). He sometimes posts some mathematics, so his blog is XHTML+MathML, served with the correct application/xhtml+xml MIME type. He’s implemented comment validation, and many of the other bells 'n whistles you’ve seen here at Musings that make doing this practical. But he also posts a lot in Urdu (a right-to-left language), so he has to grapple with BiDi and Internationalization issues that I don’t much have to worry about.

Naturally, his blog’s encoding is utf-8.

Although using XHTML+MathML named entities is perfectly valid, Zack knows that sending named entities over the wire is dangerous. A non-validating XML parser, which is not specifically XHTML+MathML-aware, will choke on any but the “safe” 5 (', ", &, < and >). So Zack uses my NumericEntities plugin (a wrapper around MathML::Entities) to convert them into something safe.

“Hmmm…,” said Zack, “since I’m using utf-8, why don’t I use the option in Distler’s plugin to convert named entities to utf-8 characters?” So he did. And, while the named entities were correctly converted to utf-8, the rest of his blog suddenly looked like gibberish.

Naturally, he wrote me to tell me that it appeared that my plugin was broken. But the truth was that the problem lay elsewhere.

Appearances to the contrary, the rest of the code-path was not really utf-8-safe. Even when you set the PublishCharset of your blog to utf-8, MovableType doesn’t actually mark its strings with Perl’s UTF-8 flag. So they’re really strings of bytes, which are treated internally by Perl as if they were iso-8859-1.

The proximate cause of his problem arose when one of these phony “iso-8859-1” strings (the rest of his page) was concatenated with an actual utf-8 string (the output of my plugin in utf-8 mode): Perl “converted” the former string to utf-8 before concatenating them, hopelessly spooging the result.

But the problem didn’t end with MovableType. Older versions of MySQL are equally Unicode-unaware. Even after his hosting provider upgraded to MySQL 4.1.14, which supports utf-8 text, the tables in his MT database were still encoded as “iso-8859-1”.

And, even after he patched MovableType and converted the tables in the MySQL database to use utf-8, the Perl module, DBD::mysql, for interfacing between them, remains blissfully Unicode-unaware.

You can read all about Zack’s (ongoing) travails. But my main message is: if anyone tells you, “i18n is easy, just use utf-8!” … go ahead and smack them.

Nikita’s paper, based on the talk discussed by Urs, and mentioned here previously, has appeared.

I’ll refer to my previous posts for the background on Berkovits’s pure spinor approach. The space of (Euclidean) pure spinors is a complex cone over $\tilde{Q}=SO(10)/U(5)$. As I guessed, one of the difficulties Nikita faced is what to do with singularity at the tip of the cone.

Smoothing it, turns the space of pure spinors into the total space of a certain line bundle $\hat{Q}\to\tilde{Q}$. That space has a nonvanishing $c_1(\hat{Q})$ and $p_1(\hat{Q})$, which means that the transition functions for the local $\beta$-$\gamma$ systems cannot be consistently-defined (don’t satisfy the requisite cocycle conditions, respectively over the worldsheet and over $\hat{Q}$).

Deleting it, yields the total space of a $\mathbb{C}^*$ bundle, $X\to \tilde{Q}$, with $c_1(X)=p_1(X)=0$. That’s better, though, as Nikita notes, it’s a little strange to exclude the point $\lambda=0$ from the path integral.

Anyway, one can then go on to check that the $SO(10)$ generators, say, are global sections of the sheaf of local operators.

The stress tensor, too, exists globally. But, as discussed by Urs, the composite operator, $B$, where $$T = \{Q, B\}$$ does not. Rather, according to Nikita, the Čech coboundary of $B$ is $Q$-exact. I’d like to see the details. But, in any case, it’s rather problematic. The genus-$g$ string measure involves insertions of $B$. Since the latter is not globally-defined in field space, the string measure then depends on some choice of “partition-of-unity” in field space. The difference between two such choices is, at least formally, a total derivative on moduli space.

If those words give you nightmares about “integration ambiguities,” they should.