Adam's Entropy

Sunday, September 02, 2012

Sometimes you need Feynman diagrams in papers. It turns out there are quite a few ways to get there, but the handiest is FeynMP. I'm using, in particular, MikTeX and TeXMaker, but something like this should work for other setups. Here are the steps:

First, get the feynmf package from your package manager.

Next, add the following to your $\LaTeX$ preamble:
I know the package name says feynmp; if you use that, you'll have a lot more errors. The feynmp package is nicer, and included when you install feynmf.

Now, let's say you want to add a diagram for Compton scattering (the point of the whole exercise). I suggest wrapping it in a $\LaTeX$ figure for convenience; doing so will lead to something like this:
Note the name of the file is compton. In your $\LaTeX$ working directory, there will be a file called compton.mp. You need to run the mpost command on it, like so:

Wednesday, January 04, 2012

Anki is a neat spaced repetition system that allows you to maximize memorization efficiency, or something like that. Interestingly, I came across it on the Clojure group, and there are already decks available for learning Clojure. It accepts LaTeX, so I've decided to make a flash-deck of some handy formulas that pop up in General Relativity, because there's enough to learn without forgetting!

You can see the typical Leiningen project layout, with /src and /test folders and subfolders. First, we'll write a function test for a function we want which sums over all values in a given sequence:

The test is in C:\Projects\CDT\Newton\test\Newton.test\core.clj, and the :use [Newton.utilities] tells it to look in the file C:\Projects\CDT\Newton\src\Newton\utilities.clj for our function. Note the use of metadata ^{:utilities true} to mark this as a utilities test, which we'll use later for organization. Our test checks that our to-be-defined sum test sums correctly over both a list and a vector.

Now here's the contents of C:\Projects\CDT\Newton\src\Newton\utilities.clj:

Finally, Leiningen allows us to choose test selectors so that we can specify which tests we want to run via project.clj:

Now by running lein at a command prompt (to save startup time) we can pick our tests:

Note in the first case, we don't expect any tests to run (test! means fetch dependencies and then run tests) because our sole test has been marked as a :utility. In the second case, we tell it to run :utility and it does, telling us that our test passed. Success!

If our test had failed, clojure's test suite would give us good information. Here, I'm going to modify the second assertion to fail. Watch what happens:

One of the neat modern takes on Lisp s-expressions in modern virtual machines like the CLR is Reflection. At least, I think that it will be useful in reversing Lisp macros and expressions into the F#/OCAML equivalents.

Next, we want a (recursive) function (called, straightforwardly enough, type_of) that reflects (using FSharpType) and translates a given System.Type object into one of the 'a ty union types defined previously:

This then allows us to emit the following two liner which can parse objects such as the List.fold function! (Note: everything after the ;; is the F# Interactive response.)

Neat stuff! I've a thousand or two lines of Lisp to look at, so this is not something I want to have to remember later.

Tuesday, March 01, 2011

Vernor Vinge prophetically wrote of a time when programmer-archaeologists maintained the fabric of civilization by diving into and modifying legacy code which ran the systems that society depended upon.

Various other folks have picked up on this notion, from the serious to the humorous. Here, though, I'll talk about this from my own perspective (which is what you came here for, right?).

Kernighan's saw goes that debugging code is twice as hard as writing it; therefore we ought to keep our meaning clear and our code as simple as possible. How to do so?

But in the meantime, you've either got to a) emit working code or b) manage those who do a). And if you could do so without too badly embarrassing yourself in the future (which is nigh impossible), or at least, be willing to chalk them up as learning experiences, you're well on your way to some sort of nirvana of ineffable, crystallized logic which is a perfect solution to your problem.

(Getting a clear problem statement itself being at least half of the battle and most of the difficulty, given business processes that aren't well understood, or mutate depending upon who's doing them or in which context. But that discussion more properly belongs in the realm of project management and business analysis, and won't be further remarked upon here.)

If you're not a coder yourself (or horribly out of date), you can still make a fair crack at judging the product by the team. The Mythical Man-Month is the canonical reference, but Joel Spolsky'sJoel Test is pretty concise, descriptive, and useful.

Archaeology can imply adventurous, sunburned types digging around fossil layers high in vast dusty mesas of stratified rock. And truth be told, that's not a bad analogy for the cacophony of systems that the average IT organization has inherited, cobbled together, purchased (often from a now-defunct vendor), or perhaps in a fit of creativity -- produced. After all, post dot-com, Greenfield development is rare.

But Brownfield development is often so painful that most developers will throw up their hands and rewrite from scratch, rather than attempting to piece together the workings of an often poorly documented system written with "ancient" methods/languages.

Why GitHub? Well, first, it has the elusive "Alpha Coder mindshare". While it may not matter one way or another to your business that the Linux kernel, Git itself, jQuery, Ruby on Rails, and a host of other important projects exist on GitHub, it matters to your programmers, whether they know it or not (and the good ones will know it).

All of these actively maintained open source projects provide something more interesting than mindshare: examples. Pick a programming language, and you will very likely find an interesting project or two on GitHub that has something worth learning. It may even prove to be the Rosetta stone of programming languages -- you may find solutions to the same problem in many different programming languages.

Second, Social Coding. Everyone knows of the usefulness of social networks -- they existed before, but it's the tools that made them marketable/actionable. Social coding in GitHub takes the usual forms -- followers, blogs, wikis, issues, teams, organizations -- plus some more useful ones (e.g. the GitHub API).

We used Team Foundation Server. It was a nice tool in our .NET development shop -- a bit painful to setup with it's dependence on SharePoint, but useful. However, it didn't scale too well in terms of collaborators. We needed to add them as users into Active Directory, fuss about with SharePoint and licensing, and so forth.

So next we tried CodePlex. CodePlex was, essentially, TFS in the cloud, and it mostly worked. There were capacity issues, and it wasn't always friendly with non .NET languages, but the main reason we didn't adopt it wholesale was:

No way to make private repositories

Often painful to connect into

Went down/was slow often enough that we didn't want to rely on it.

This really illustrates the third virtue of GitHub, that it's a true cloud service -- but cloud computing is all the hype right now and I really wanted to illustrate it's particular benefits in this instance.

In going with GitHub, we created an organization for our, well, organization. This gives us several important advantages over CodePlex:

Private repositories

Teams

Unlimited collaborators (in particular, we can mix and match between general GitHub accounts and team members)

Blogs, Wikis, Gists, Issue Trackers with voting, per-line file commenting, and other social features

Works well with any programming language

Fast, decentralized development (Git works locally, so you can get on a plane, code, and upload your changes once you've got internet access)

Reliable versioning (Git uses hashes for files)

Works well with any OS/IDE (Git has integration with Visual Studio, Eclipse, XCode plus command-line versions in most every OS)

Git is a well-regarded distributed version control system (DCVS)

My programming team ported projects over from TFS and CodePlex in under a day. By following projects, I can watch check-ins, view version differences, open/close issues, and do all the usual software management stuff without getting in the way. (Or better yet, delegate.)

The fees are pretty nominal (organizations get charged based on the numbers of private repositories they want; public ones are free). GitHub is hosted by RackSpace, so the reliability has been better than our in-house TFS boxes. Today I just added someone outside our organization to one of our projects with minimal hassle.

If you're going to be digging up fossilized code, Git and GitHub are fairly pleasant tools for the job.

Look at the time! This isn't really everything I wanted to say, but I've probably said enough for now (and I have other pressing priorities including my own research), so I'll leave further pontificating for another time.

Friday, December 03, 2010

(Yes, I'm procrastinating. The cluster is down for maintenance, and I need a break from technical reading and writing.)

My Pop shared an interesting article during Thanksgiving, which noted that way back in the beginning of the direct founding of the U.S.A., colonists in the 1600's tried a form of socialism wherein the results of the season's harvest were shared equally amongst the colonists.

(The account was written by the governor at the time, direct citations anyone?)

The official noted that there were many deaths due to starvation, much inequity in terms of labor given vs. food received, and so forth. On the whole, the colony was in danger of perishing as the vicious cycle of famine made the remaining colonists weaker and less able to work, thus reducing the harvest, and so forth.

In these dire straits, the next thing they tried was that they divided the land up equally amongst the families instead. Each family was free to keep the results of their work, and if they had excess, sell it for profit.

The results were immediate: the next season's harvest was so bountiful that many families had excess, and those families that did not were able to buy from those that did. No one starved.

The official also notes the changes in motivation (paraphrasing): "Women who claimed infirmity and poor health when compelled to serve the community went willingly into their own fields with their children. The high (and unacceptable) costs that might have necessary to compel this behavior were no longer required ..."

Score one for capitalism, individual thrift and perseverance, and ....

But wait. Where did they get the land?

Oh, that's right. They were given it. Or, from another perspective, perhaps they stole it. (I don't want to get into those issues since there's even more controversy about that and it's incidental to my point.)

The point is: the colonists were given the tools to feed themselves, and they then were allowed to make their own way.

Capitalism is a fine system for efficient distribution of goods, services, and products. But it was an act of socialism (specifically, the land grant) that gave those first colonists the means to start on their new lives. (They had to supply the effort.)

That last item may be even more difficult to quantify, except that you know it when you see it: wars, famines, natural disasters, stock market crashes, etc. Things too big for any individual or family to handle alone, something that requires a societal solution.

The world is chaotic. Trying to impose too much stability results in a dead/fragile/stratified society (see history for numerous examples). Too little, and no one can plan for the future.

Define suffering: again, you know it when you see it. Death, disease, famine, wasted lives, inability to meaningfully affect your own destiny, loss of freedoms, etc. These are broad brush strokes, individuals/society will naturally have their own values.

So how do we provide the above to our citizenry in our society? How do we give the tools to be successful, without redistributing the results of that success unfairly?

(This is not meant as an exhaustive analysis, but a mere framing of the problem.)

Government spending:

Now let me say from the outset, that like general relativity, I prefer solutions to be as localized as possible. I'd also like to remain as free as possible from any equations of constraint enforced by some larger entity. I don't dispute that some are necessary (anarchy is cool until you live in it), but I wonder if we are half as good at removing laws as we are at making them.

These entities need money to do their work. Right away that suggests a neat solution: don't give them any. Unfortunately, that only works if you already have the means to provide the 4 items mentioned above. Clearly, not all individuals do, so a society based strictly upon "to each their own" would be manifestly unfair, and I do retain the silly idea that the universe ought to be as fair as possible.

Now spending itself is a moderately abstract formulation of reality: there are only so much goods, services, information, and time available.

Spend less than you make, and you have savings: for a rainy day, or to help someone else start something they couldn't otherwise do (perhaps with the hopes that you'll be compensated in the future for lending your resources today).

Spend more than you make (if you're allowed to), and you have debt, or future restrictions on your earning potential.

Pretty straightforward stuff.

It seems that Americans in general are now used to the consumption economy fueled by credit and debt, and we've passed that along to our government. Or perhaps it's the other way around.

That's a fairly common rant, and I'll not repeat it except to say: we've obviously hit the limit on how much debt (monetary, environmental, etc.) we've incurred, and we should be looking to pay it off instead of increase it.

Tuesday, January 19, 2010

So, my colleagues have developed a CDT program that's usable. Fortunately for me, it's in LISP, which lacks parallel processing, modern libraries, a nice IDE, and the other goodies I've become accustomed to in my work life. (That means I get to figure these features out and thereby contribute!)