User:Ryan Reich
My Commons user page, currently just a redirect here.
I am in my fifth year at Harvard University's math department, having graduated in June 2005 from The University of Chicago (with a degree in math, of course). Therefore every page I've significantly edited is on mathematics; I'm especially proud of my contributions to:
- Abel-Jacobi map
- Cayley-Hamilton theorem (I wrote the proofs)
- Exact category
- Knuth–Morris–Pratt algorithm
- Proj construction
- Mapping cylinder (I created this, but I can't claim any credit for the current version)
- Prime model
- Triangulated category (mainly the diagrams of the octahedral axiom)
- Zariski topology
I created, though I'm not sure if I should be proud of it, the page for Joe Harris.
You may be interested in a draft of Rational mapping that I have been planning to implement for a very long time. (I have now written Rational mapping based on this draft, but a little tidier.)
I am also writing an article on the Beauville-Laszlo theorem.
Rant against template syntax[edit]
My draft alterations to Template:Harvard citations: front, core. (After some reflection, it seems unlikely I'll go through with this. The Wikipedia template syntax is an embarrassment to programming, having made not even the most cursory nod towards iteration and actively suppressing recursion, in addition to simply ignoring most of the basic constructs of logic and arithmetic (meanwhile, well-meaning volunteers over at MediaWiki are busy reinventing the wheel in the form of parser extensions that will take many years to reach the stability necessary for inclusion in Wikipedia and still not address the inherent failings of the transclusion model of function calling). Together with the lack of support for variables, these make it impossible to perform any kind of page layout or format selection which depends in a manner even slightly more than trivial upon externally-supplied parameters. The appearance of functionality in existing templates is an illusion maintained by a massive repetition of code simulating all the unrolled loops that cannot be written rolled-up and variables which cannot be defined, as well as clumsy hacks and workarounds to effect the multitude of branching operations that are left unsupported by the "language". All of this is packaged in the eye-straining wrapping of triple-brace parameter dereferences. The result is megabytes of incomprehensible, unmaintainable, inextensible (and un-replaceable) code which is probably slower than what could be done with a real programming language.)
How to make SVG versions of LaTeX diagrams[edit]
It's easy enough, using LaTeX and perhaps the xy package, to create very intricate mathematical diagrams. Unfortuantely, they will all be output as .dvi or .pdf files, whereas the best format for uploading to Wikipedia is .svg (Scalable vector graphics). Figuring out how to make the conversion is a major pain, for reasons that the casual editor may not realize: SVG is, as the name says, both "scalable" and "vector" graphics, whereas other image formats are raster—they actually specify each and every pixel in the picture (probably with some compression afterwards). These are not scalable: changing their size will result in distortion and degradation. Although you can use various tools to convert raster images (i.e. PNG) to vector ones, you will get essentially a scalable version of the particular resolution you started with. That means that as you scale up, you will be scaling up the individual pixels of the original PNG; this is actually worse than scaling up the PNG, since at least the image manipulation programs for raster images are aware of sophisticated sampling techniques to improve the resulting quality, whereas a vector image is expected to give a precise "logical" description of how the image should look at any scale.
Another problem with LaTeX and SVG is that by default, TeX uses bitmap fonts: essentially, raster images of the letters. This does not lead to good results in SVGs even if the output is converted without being rasterized in the middle. There are Postscript versions of these fonts available; you can tell if you are using them by looking at the output of the "latex" command and checking whether the fonts which are loaded (in the jumble at the beginning of the output) have "type1" as part of their path name; these are the scalable Type 1 versions of the standard Computer Modern fonts. If you do not have these, you must install them from CTAN (they are called "bluesky" fonts). This is not all that hard, but it is intimidating. There are directions online how to install new packages in LaTeX. But you probably have them already; this is the 21st century, after all.
Yet another problem with LaTeX and mathematical diagrams is that TeX always thinks it's typesetting a paper, and we are actually typesetting pictures. The output stamps them onto a letter-sized (or A4-sized, if that's how you swing) paper with lots of superfluous space. The image must be cropped or else it will look awful. For this, we have the dedicated utility pdfcrop, which does exactly what it says.
Once you get LaTeX using the right fonts, conversion is actually quite straightforward. There are several utilities which purport to convert things into SVG. pstoedit is always recommended, but I do not advocate it, because the one and only output which it supports that is at all useful to us and that requires a commercial (read: not free) plugin is of course the SVG format. The free alternative, GNU libplot, is not that good: I have created perfectly reasonable diagrams (the ones at Cone (category theory)) which it, or pstoedit, couldn't handle properly. I recommend the small, rather alpha utility pdf2svg, which as advertised converts PDFs to SVGs. That's all it does; it doesn't do DVIs, and it doesn't change any formatting whatsoever. Despite being alpha it seems to do a good job even with really funky pictures (see mine at Triangulated category; these were all done by this method).
That said, the following three commands will give you your SVG:
pdflatex file.tex pdfcrop --clip file.pdf tmp.pdf pdf2svg tmp.pdf file.svg (rm tmp.pdf at the end)
And there you go.
The long and short of this is that you should not follow any of the other instructions you might find. They are all wrong in some way, or too long and complicated. Until someone writes a version of LaTeX that outputs directly to SVG (or until Blahtex is finally adopted on Wikipedia), this is the fastest possible way of getting such a file.
Word of warning[edit]
Watch out for editors who, in lieu of using their proper names, express their enthusiasm through a declarative handle, e.g. the former user:Topology Expert, who clashed heroically with the mathematical editing establishment and came to an unhappy end as a result. Other such users arise periodically, and have the same problems: their individual passions exist in conflict with the cooperative collective consensus-based incrementalism that pervades the culture here. Brilliant ideas are too personal for this impersonal medium, strong convictions insufficiently neutral, personal crusades too disruptive and confrontational. Wikipedia is no longer the wild American frontier, but the touchy modern politically-correct civilization. If you are one of these editors, you should consider whether your motivations are to share everything you know and love, or to write a reference work. If it is the former, you should start a blog instead.