cheaphack

The Foreign Registration office in Bangalore

2009-06-08T08:52:00.002-04:00

As a foreigner, the government of India requires that I register with the police within a fortnight of my arrival in India. I have no problem with this conceptually; I believe in India's sovereignty, and I think it is within their rights. However, the implementation of this policy leaves sucks.

First of all, I admit that I don't speak Kannada, and I don't speak Hindi (or Tamil, Telugu, Assamese, or any of the twenty some official languages of India), but in my defense, I strongly doubt that the cumulative language coverage of the officers would accommodate every citizen of India, and thus the difficult of communications issue is mute. Let me also qualify this by saying that my company has a liason team, whose mission is to try to make this process much easier for me.

Nonetheless, I had to visit the foreign registration office (FRO) six times over the last week, and had to pay a $30 fee for late registration.

(Visit 1) I arrive at the office, sign in, and am handed a bundle of forms. I don't know why my liason team doesn't keep these forms on file.
(Visit 2) Because of several work engagements, I couldn't start the process until 4:30pm. The liason and I drive across town to a notary, and then back to the FRO office. When we get within a block, he tells me to get out and run. I walk in a 5:25pm, but the clerk swears it's 5:30, that there's nothing I can do, and that he doesn't care that I have to pay a $30 late fee.
(Visit 3) I come back the next day, but I forgot my passport. D'oh
(Visit 4) Later that day, they review my paperwork, highlighting several mundane details. They hand me the signed form and tell me to go to the other counter. There, they tell me to sit and wait. Thirty minutes later, I ask why I'm waiting and he tells me to go back to the first counter. There, they take my forms, hand me a receipt, and tell me to come the next evening.
(Visit 5) I arrive the next evening, and hand them my receipts. They tell me to go to the other counter, and the second counter tells me to wait. Twenty minutes later, I ask why I'm waiting, and they tell me to go back to the first counter. There, the man gives me a deposit slip, and asks me to take it to the bank down the street, where I must deposit $30. When I return to the FRO, they give me a receipt and ask me to come back Monday.
(Visit 6) I arrive, sign-in, and deposit my receipt. He tells me to go to the other counter and ask for Ajita (sp?). I do so, he looks at it for 30 minutes, then hands it back and tells me to go to the other counter. Finally, I am a legal resident.

The other interns have similarly horrifying stories; some were given business visas instead of employment visas; others were given student visas. These people have a lot more work to do before they can be legally paid within India.

I'll leave it as an exercise to the reader to replace the FRO office with 100 lines of code in the language of your choice.

I'm off to India

2009-05-20T11:18:00.001-04:00

I leave for India tonight! I'll be back in September.

Power Steering Fluid Pump, Mercedes-Benz 190E (W201)

2009-05-19T20:56:00.003-04:00

The girlfriend and I spent an hour trying to find the power steering fluid reservior on a Mercedez-Benz 190E (a.k.a. W201). Even the internet didn't know. We found it again, in hopes that the next guy finds it easy.

This is the power steering pump in a Mercedes-Benz 190E (a.k.a W201). The top of the power steering pump is the power steering reservoir.

Simply unscrew the black nut on top, and remove the lid. You should extract the old fluid using something like a turkey baster (which, of course, you should never use on food again). Then fill it mostly to the top (owner's manual says 0.6L).

Good Quote: Le Corbusier

2009-05-19T20:40:00.002-04:00

... Man's stock of tools marks out the stages of civilization, the stone age, the bronze age, the iron age. Tools are the result of successive improvement; the effort of all generations is embodied in them. The too is the direct and immediate expression of progress; it gives man essential assistance and essential freedom also. We throw the out-of-date tool on the scrap-heap: the carbine, the culverin, the growler and the old locomotive. The action is a manifestation of health, of moral health, of morale also; it is not right that we should produce bad things because of a bad tool; nor is it right that we should waste our energy, our health and our courage because of a bad tool; it must be thrown away and replaced.

Le Corbusier
in "Towards a New Architecture"
Translated by Frederick Etchells

Cute typo: Turing Basin Park

2009-04-28T21:12:00.001-04:00

View Larger Map

This is supposed to be "Turning Basin Park," but apparently some geek over at google thought "Turing" would be more appropriate, given the proximity to Princeton.

walk score -- measuring pedestrian friendlyness

2009-03-24T12:34:00.002-04:00

As I've mentioned before, I don't have a car, don't want one, and don't think that people should have an unquestioned right to drive a car. I'm an urbanist, and I believe that people should be able to walk to all of their life's necessities, or in the worst case, ride a bike or public transportation. Since I've moved to Princeton, one of my major complaints has been how inconvenient it is for someone without a car.

Today, I discovered WalkScore (via the Freakonomics Blog). It is a google maps mash-up which tries to quantify how walkable an area is according to distance from common necessities, such as grocery stores and bars. Very clever. And for comparison:

My old neighborhood in Charlottesville: 85/100 - very walkable
My old neighborhood in Brooklyn: 88/100 - very walkable
My current neighborhood in Princeton: 29/100 - car-dependant
Washington Square Park, NYC: 100/100 - walker's paradise.

It's nice to have some external validation on my opinion of Princeton ;)

In all fairness to Princeton, if I were to live on Witherspoon at Spring St, I'd live in Walker's Paradise 95/100, but what grad student can afford that?

Melting metal in the backyard

2009-03-19T22:49:00.001-04:00

Bjarne Stroustrup is so metal!

2009-03-05T12:40:00.003-05:00

On Wednesday, Bjarne Stroustrup made a visit to Princeton, and the Liberty Research Group scheduled a private meeting with him before his colloquium. We spent a little over an hour discussing the C++0x and the future of C++. Overall, Bjarne is a cool guy, and I had an excellent time talking with him.

The wikipedia article about C++0x is painfully out of date. Bjarne mentioned some upcoming features that are hardly mentioned, if at all. Of these, the ones which took my interest the most were Concepts, Axioms, and the future of static typing in C++.

I'll disclaim that I haven't read any C++0x standardization documents, not even drafts, so take everything here as a grain of salt. These are simply my take-away points from the talk.

Bjarne is concerned that the template feature of C++ does not allow programmers to sufficiently constrain template parameters. For instance, a sort algorithm may be implemented to operate on a random-access iterator. However, recall that iterators in the C++ STL do not share a common inheritance (and there are fair arguments that they shouldn't). C++ templates cannot capture the notion that one of its formals must be a iterator-like type, and so specializing the template against, say a string, will likely yield hundreds of uninformative type errors instead of a simple error stating that we expect an iterator.

One solution to this problem would be to create base iterator classes in order to ensure an interface (this is the approach taken by Java, for instance). However, one could argue that this is an inappropriate use of inheritance---it's not code re-use, and although we give many concepts the name iterator, they really have little in common.

Some languages use a notion of structural equivalence (or, less formally, duck typing) to capture these constraints. I think this is the appropriate technique. The earlier example of a sorting algorithm simply requires some object which can provide random access to a data structure, and the most direct test for compatibility is whether the interface is a satisfied. In C++0x, Concepts are an implementation of structural equivalence (from the high-level, language view). In the low-level view, concepts are a special case of templating, and produce multiple implementations of the same code according to the specific type.

In a C++0x Concept, one can specify the methods which must be supported. For instance, one may have a Concept named TotalOrder, which must support a less-than-or-equal-to operator. Many types satisfy the TotalOrder concept, such as int, double, std::string, yet they are not required to have a common ancestor. In this sense, a concept allows you to communicate many of the traits to a type, without paying the penalty of multiple inheritance.

But Concepts get cooler. Although I describe them as a mechanism for structural equivalence in C++, they can also be viewed as mixins, since they allow a programmer to specify a default implementation for many methods. With the prior example of TotalOrder, one could also add default implementations of greater-than, equal-to, etc, operators as functions of less-than-or-equal-to. In this way, it becomes very easy for programmers to bootstrap support for all operators while writing minimal code.

Suppose that I implement some class that satisfies TotalOrder. This information simply means that my class supports comparison operators. One wonders, however, if these operations actually behave as a total order. As a counter example, I could write a random number generator to produce the result of the less-than-or-equal-to comparison---can a language be made to disallow this? Or, can a compiler be taught to rely upon deeper qualities of total orders, without having a special case for total orders?

Axioms allow the programmer to specify additional qualities of operations that transcend simple typing. For instance, one could write axioms that signify that the less-than-or-equal-to relation is transitive, or that it is always the logical inverse of the greater-than relation. With axioms, we can state that a sort algorithm not only requires a random-access-iterator, but also that there is a total order of the elements which satisfies transitivity. The use of concepts and axioms allows us to specify all of the constraints of the sort algorithm.

But how can the compiler use axioms? It is unlikely that any compiler will ever be able to verify that the listed axioms are true for a given implementation. Instead, axioms will provide additional transformations to the compiler's arsenal of optimizations. With support for axioms, many compiler optimizations including constant-folding (especially with associativity), reduction in strength, and common-subexpression elimination can be lifted from the compiler and expressed at the language level. I think this is really cool.

I think the notion of concepts and axioms struck home with me because they resemble some of my thinking on one of my side projects. I've been working on a language for years now (never enough time, alas!) in which I plan to feature structural equivalence in typing for reasons similar to those outlined by Bjarne. The axioms are a natural extension which I now realize I would like to support as well.

Finally, before the meeting was over, I had to ask a question about type safety. Throughout his book The Design and Evolution of C++, Bjarne laments the type (un)safety of C. Repeatedly, and with each new language feature, he attempts to make C++ more typesafe, but is repeatedly foiled by inherited features such as void pointers and unrestricted casting. So, I asked: are you ever going to take the plunge and drop support for pointers in C++? His answer was intelligent, and showed a great understanding of not simply the technical considerations of C++, but also the political considerations.

Mr. Stroustrup suggested that he hopes to add more and more features to C++ until type-safe alternatives are available for each and every unsafe aspect of C++. Once that has happened, he hopes to define a safe subset of C++. At that point, all existing C++ tools could be given a flag to provide warnings of unsafe features. This safe sub-C++ will immediately have rich toolchain support, but will be able to provide strong guarantees, such as those provided by ML. Excellent plan.

Bjarne is a very interesting person indeed; I recommend you talk with him if you ever have the chance.

A quick thought...

2009-03-01T13:02:00.003-05:00

The other day, Daya and I rode our bikes to the local grocer to buy some groceries. At the checkout line, we stuffed our groceries into our bags, when the teller asked, "Did you guys ride your bikes here?"

"Yes," I responded, "How else does one buy groceries?"

She deducted a dollar from our total, and told us the store offers a ride your bike discount. The guy in line behind us muttered something to the effect of "I'm glad you're doing your part."

It's at times like these that I want to say "No! I'm not being a responsible person; rather, you are being irresponsible!" Honestly, I think they should add a fee for driving to the grocer, perhaps charge for parking, or make you wear an "I hate the environment" shirt.

But, I bit my tongue.

On an unrelated note, Bjarne Stroustrup is visiting Princeton CS on the 4th for a 4:15 colloquium. If you're in the area, you should check it out. It will be packed.

Failed reasoning by an Ivy League Grad Student; Engineering and Approximation

2009-02-06T12:08:00.010-05:00

Let me babble for a little bit...

There was an extended power failure in Princeton last night---for two hours, all three power inlets to the boro went down, and so all the uninterruptible power supplies drove themselves dead. While the CS department's servers were hooked up to a secondary generator, the servers for my research group went down.

After power was restored, our machines booted back up, but in the incorrect order. One of the other students in the group had to go visit them to remount NFS partitions, make sure they all came back up, etc, etc.

While he was down there, he observed a chirping noise. Looking around underneath tables and racks, he found the culprit: an uninterruptible power supply that wasn't plugged into the wall, and had nothing plugged into it. Judging by its position, he decided that this was a power supply for a server that had been of commission for at least a decade. He reasoned that it took about ten years for the minute inefficiencies in this UPS to drain the battery.

But, the damned thing was still chirping. Looking around, he couldn't find a free plug, and so he couldn't restore power to the UPS. "How can I make this stop chirping?" he asked himself.

His solution amazes me: he plugged the UPS into itself.

Now, clearly, the UPS isn't going to charge, and he doesn't dispute that. He argued, however, that this should be enough to fool the UPS into thinking that it was charging. In other words, he conjectured that the UPS chirps iff it does not have wall power; he was wrong, because he assumed the UPS engineers had made an approximation they had not. In actuality, the UPS continued to chirp. This is because the UPS chirps iff there is a negative change in the charge of the battery. It takes some time to measure this change, and this is why UPSes will chirp for a short while after you plug them back in.

Why do I bring this up? Because it allows for an interesting analysis of approximation, and maybe we can pull out some principles of design. What semantics does the chirp noise carry? The chirp noise should denote battery discharge. Under the assumption that the UPS can always charge the battery as fast as it is discharged when plugged in, the UPS would stop chirping when plugged in. The question is: do you want to measure the real scenario, or can you get away with measuring symptoms of the scenario?

Engineering is the fine art of approximation. Approximation is so ingrained into our reasoning that we have mathematical operators to describe it: x << y means x is significantly smaller than y; x -> y means that as the value of x comes arbitrarily close to y; epsilon denotes an arbitrarily small number; we say a function f is O(g(x)) to mean that as x gets arbitrarily large f(x) is bounded by some constant times g(x). The meanings of significant, arbitrary, and some vary wildly by situation.

Engineers make jokes about it too: a horse is a sphere if it makes the numbers easier; 2+2==5 for very large values of 2. Approximation is critical, but only where appropriate.

In the UPS example, the charge of the battery can be measured more or less directly. In many other circumstances, the real scenario is hard to measure, but symptoms of it are easily measured, and an approximation can be computed from those measurements. A couple examples come to mind:

You use a compass to find North, but it actually tells you the direction to something that is mostly north of you and very far away. Sailors have shown that for navigation within a few hundred miles, this is perfectly sufficient.
It is difficult for a robot to measure its exact position in a room, but it can easily measure how much each of its wheels has moved and then deduce its relative position via dead reckoning. For short distances, the error of this approach is negligible.
People say you should change your oil every six months or 6,000 miles. In reality, it's a question of the quality of the oil (how much crud has accumulated?), not how long or how far you've used it. Oil is cheap and engines are expensive, so this method is successful.
When structural engineers design a building, they use a safety factor---building every piece n times as strong as need be---to account for variation in manufacturing, material aging, and unforeseeable events. Steel is cheap and wrongful-death lawsuits are expensive, so this method is successful.
Software engineering preaches: it's more important that the software works than that it works efficiently; instead of writing in machine code, we use high level languages that favor programmer time over execution time. Programmer time is expensive, but faster computers are cheap, so this method is successful.

So, next time you design something, take another look at the approximations you are making. More importantly, look for approximations that you are not yet making. So long as you are conservative enough to ensure your approximations are right enough, they can save you a lot of effort.

Maybe your robot can't read GPS, but there are other ways it can geolocate. Maybe your software cannot successfully identify some event, but if it can be right more often than not, it can pass the final say onto a human operator. Possibilities are endless.

Proposal for a future Interstate Rail Network

2009-02-01T14:27:00.004-05:00

From The Transport Politic:

The transport politic blog has run the numbers and made a proposal for a high-speed train network for the United States. I think they've done an incredible job, and so I want to mention them here. Their plan is based upon a few pillars:

This network would be funded 50--90% by the Fed; compare to roads and highways that are funded 80--90% by the Fed.
This funding would be part of the expected economic stimulus plans. In this respect, it sounds to me like a big WPA project instead of a bailout.
A new national authority (which they call NatTrack) will be responsible for acquiring land, building and maintaining tracks, and renting those tracks to service providers such as Amtrak.
They identify the ideal route as one that is (a) shorter than 500 miles, and (b) between two population centers of 100,000 or more. These numbers were chosen as they [a] typically beat an airplane in overall travel time, and [b] have enough potential customers to maintain the route.
The main network features high-speed (150 mph) trains; this is supplemented by low-speed (70--120 mph).
Their route choices were computed mathematically, under some well-defined assumptions. At the end of the article, they give numeric scores for each route to justify their choices.

Again, this is excellent work. I encourage you to read their article. I hope this has a chance.

Update to pipemiter.rb

2009-02-01T11:51:00.004-05:00

Last week I wrote about a simple script to miter pipes. As soon as I wrote it, I realized about a hundred ways it could be improved, and about a hundred new ways it could be used.

My first observation was that the old version would fail if the cutting template was too large to fit on one page. To solve this, I added pagination support---the image will be split across multiple pages, and alignment marks will be drawn at each corner so they can be stitched back together.

Next, I noticed that real pipes have some thickness, i.e. the inner diameter might be significantly smaller than the outer diameter. As a result, you can now specify an inner diameter, and it will draw a gray curve alongside the black curve of the outer diameter. This can make it easier to miter thick tubes.

Also, I realized that one often wants to miter several tubes against one. In this case, you don't just measure how to cut the smaller tubes, but also where the smaller tubes meet the larger one. For this reason, the software will now draw a guide for the large tube as well.

Beyond that, there are numerous little changes to make it easier to use or more fool-proof.

The script is now in three files:

pipemiter2.rb - the main executable,
units.rb - handles unit conversion in a not-too-painful way, and
postscript.rb - a library for drawing postscript images.

Save all of these files to some directory. Like before, we can either invoke this program from the command line, or in interactive mode.

You specify a pipe scenario as a single center pipe (i.e. the one that doesn't get mitered), and one or more radial pipes (i.e. the ones that get cut to fit the center pipe). The center pipe is simply specified as its diameter (or equivalently, its circumference or radius). Each radial pipe is specified as 3-D polar coordinates relative to the center pipe. The characteristics of the radial pipes are:

Its (outer) diameter (or equivalently, it's circumference or radius);
Optionally, its (inner) diameter;
Its latitude, i.e. the angle at which it meets the center pipe, where a latitude of 0 means along the equator, and a latitude of +/- 90 means at the north or south pole;
Its longitude, i.e. the angle around the center pipe, which defaults to 0; and
Its projection, i.e. placement along the length of the center pipe.

That can be complicated, so lets go through a few examples. I'm going to write these examples in command line format, but if you don't specify any command line arguments it will go into interactive mode.

First, the example from my previous post: two toilet paper rolls (1.75" diameter) meet at a 30-degree angle. All I need to specify is the center pipe, and the diameter and latitude for the radial pipe:

$ ./pipemiter2.rb 1.75 1.75 30 >eg1.ps

Notice the output is more elaborate than last time. In particular, it's now a two page document. The first page shows the cutting profile, and then second page shows the profile on the pipe that you don't cut.

Let's try something more complicated. Suppose you wanted to build a sort of tripod-like thing. You have a center pipe 9-inch in circumference, and you have three 2-inch-diameter radial pipes. Each radial pipe meets the center pipe at a 60 degree angle, and each is evenly spaced along the circumference of the center pipe. Then you could type something like this:

$ ./pipemiter2.rb 9in-circ and 2in 60 and 2 60 by 120 and 2 60 by 240 >eg2.ps

There are a few things to note about this line. First, it specifies the center pipe (9in-circ). Next, it specified the three radial pipes: 2in 60 by x. The word and goes between each pipe specification, but is completely optional. Each pipe is specified as its diameter (2in), it's latitude (60), and its longitude (by 120, by 240, etc). The output file has four pages---a cutting template for each of the radial pipes, and then an alignment template for the center pipe.

So what's up with the units? Units are optional, though I often write them for clarity's sake. Diameter units default to inches, but could also be mm-circ (millimeters of circumference), cm-rad (centimeters of radius), ft (feet), etc. Length units default to inches, but could also be mm, cm, m, ft, etc. Angle units default to degrees, but could also be radians. Once you use a {length, diameter, angle} unit once, all future {length, diameter, angle} units default to that unit, just to save some typing. When in doubt, type the units.

So far, we've explained units, diameters, longitude, and latitude. What about projection and inner diameter? Notice that, in the previous example, the center points of each radial pipe all lined up along the equator of the center pipe. The projection parameter moves the center points up or down the length of the center pipe relative to the equator.

For example, suppose you have a center pipe of 9-inch-circumference, and want to attach five 1-inch-diameter radial pipes to it. Each of the radial pipes has an inner diameter of 0.5-inches. Next, suppose that the pipes should be connected at 60, 30, 0, -30, and -60 degrees, and that there should have a projection of +0.4-inch, +0.2-inch, 0-inch, -0.2-inch and -0.4-inch, respectively. Enter the command,

$ ./pipemiter2.rb 9in-circ \
and 1in id 0.5 60 by 0 up .4 \
and 1 id .5 30 by 72 up .2 \
and 1 id .5 0 by 144 \
and 1 id .5 -30 by 216 down .2 \
and 1 id .5 -60 by 288 down .4 \
>eg3.ps

The backslash character tells your shell that the command will span multiple lines. For each of the radial pipes, I use the id .5 command to specify the inner diameter of the pipe.

When you look at the output, you see that each cutting profile additionally has a gray curve. This gray curve is the shape of the miter along the inner diameter of the pipe---it gives you a few more hints of how to grind the pipes to meet perfectly. Also note how, on the sixth page, the inner diameter is drawn on the alignment guide. The projection is specified using up .2 or down .4, and causes the center of each pipe to move up or down the length of the center pipe on the alignment guide.

In case your wondering, that last example looks like this and this.

And that's it. Now you can specify the many-pipes-meet-one scenario, and have cutting and alignment guides automatically generated. This can make mitering pipes much easier for you.

Also of note is that this is not limited to mitering pipes. I've realized that it can be used to make paper/cardboard models, and that those models can be used as molds for plaster or concrete. I'll talk about pipe sculptures in a future post.

Related: Commenter Flemming gives a link to a similar online tool.

Too little, too late: plug-ins for gcc

2009-01-27T22:12:00.005-05:00

The GCC Steering Committee announced that they have created a new license exception that will---among other things---allow for the creation of a plug-in framework in GCC. In effect it will create a means by which compiler writers, researchers and tinkerers can write additions to the compiler without having to understand the vast majority of GCC.

I argue this is too little, too late.

GCC is open source software. This means that they give everyone the blueprints, so anyone can (potentially) go out and modify it to suite their needs. Such modifications might be fixing a bug, adding a new feature, or making it work slightly better in their situation. In that respect, GCC has done a wonderful job on providing a platform on which innovation can occur. But...

Software can be complicated. People have dedicated their careers to making software easier to write, understand, modify and maintain, or even prove that software does what it should. Despite all the effort, there's still no silver bullet. As software gets more mature---with more features and more compatibilities to maintain---it gets worse. And as software goes, compilers are typically some of the most complicated to write (not to toot my own horn as a compiler writer).

GCC suffers from the trifecta of software nightmares. GCC is as old as I am, and uses ancient techniques such as an RTL intermediate representation. GCC is feature-rich; its standard release supports at least seven source languages and at least twenty target architectures. GCC is a compiler. Take a look inside and you'll find a mind boggling nine hundred eighty four thousand lines of code (according to conservative estimates by David Wheeler in 2001). I'm not saying that GCC is bad software, but that it would be very difficult for even the most talented programmer to learn its internals in a short time.

Software engineers have seen this growth pattern before, and have come up with schemes to try to mitigate this risk. One such scheme is a plug-in framework. In a plug-in framework, the original developers present small, clean, easy to understand interface, and then anyone can write a plug-in that talks to that interface. This plug-in can do everything it needs to do, but it is significantly easier to create a plug-in than it is to modify the original code. Because of the constraints on the interface, the programmer can be blissfully ignorant of the operation of majority of the software.

Or, as an analogy: suppose you are a doctor, and your patient has a broken ankle. It's a really bad break, and you need to operate. So, you decide to remove all of the patient's skin so you can get to the break. Oh wait, that would be ridiculous... Instead, you only open up the ankle... much less risk of disturbing something else.

With compilers, there are some easy ways to support plug-ins. The easiest is to write the intermediate representation to disk in some form, let the plug-in do whatever to it, and then read it back and verify that it is well-formed. Implementing this sort of plug-in framework is very little additional work; in any sane software effort, this might be one of the earliest things designed, if for no other reason than convenience during the debugging phase.

But, for some reason GCC has not supported plug-ins until now. Twenty five years of software enthusiasts suggesting it, and the project hasn't done it. Why would GNU ignore feature requests, and even software engineering best practices?

From the GCC Exception FAQ:

...For a while now, the GCC developers have considered adding a plugin framework to the compiler. This would make it easier for others to contribute to the project, and accelerate the development of new compilation techniques for GCC. However, there have also been concerns that unscrupulous developers could write plugins that called out to proprietary software to transform the compiled code—effectively creating proprietary extensions to GCC and defeating the purpose of the GPL. The updated exception prevents such abuse, enabling the GCC team to look forward to plugin developments. [emphasis is mine].

Yes, that is correct. They were afraid people would write software plug-ins---completely separate from GCC---and that those plug-ins would not be free software. They think that any software that interacts with GCC should be governed by GCC's license. In effect, the GNU and the GCC project tried to strong-arm other developers into writing free software. I'm all for free software, but I think this was (1) a prick move, and (2) the wrong decision from a project management perspective.

Why is this a prick move?

In short, I don't like having my hand forced. Let's ask again: what is open source? According to the Open Source Initiative's (OSI) definition (which is about as close as we'll get to a standard, accepted definition):

6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
...
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

9. License Must Not Restrict Other Software
The license must not
place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
...

Although this definition has been carefully crafted to dodge the question, it seems to me that GNU could not place the no-proprietary-plug-in restriction in their license, and so instead they mutilated their code to discourage such unscrupulous behavior.

But, ultimately, my code is my code, and my code is separate from GCC. The GCC project cannot accept that, and so they try to prevent me from writing it.

Why was this a bad project management decision?

For all of the reasons that make plug-ins a good idea, and then some.

I presented the notion of plug-ins as a best practice---and they are---but realize that all best-practices are just rules-of-thumb. We could never get universal agreement that GCC is bad code because it doesn't support plug-ins. In my opinion, the lack of this feature is a flaw in GCC, but there are bigger problems.

At the end of the day, I don't care if open source software is good code. Authors can write code however they want to. But it doesn't mean I'm going to take part in their software project if they are working against me. If you write code to prevent me from participating, then it cannot be open source.

As academics researching compilers (that's fun to say), we have simply moved away from GCC as an experimentation platform. There are compilers with less restrictive licenses and which encourage third party development. This, ultimately, is GCC's loss and not ours.

Take for instance llvm, introduced by Chris Lattner's thesis in 2002. The llvm project not only has better documentation (including howtos on writing plugins), but also has a bit of a social contract. From llvm intermediate representation documentation:

The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler), and as a human readable assembly language representation. This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations. The three different forms of LLVM are all equivalent. [emphasis is mine].

Or, in other words "yeah, we're not going to pull that crap." Because of all of the llvm project's support, llvm is quickly becoming a popular platform for compiler research, and will assuredly overtake it (if it hasn't already). I'm not saying that we don't use GCC; rather that the next hundred cool optimizations are being developed for other compilers, and will only later be back-ported to GCC.

In summary, an important part of the management of an open-source software project should be to enable new programmers to enter the project with little initial investment. GCC has not only missed this opportunity, but actively avoided it. As a result, GCC has alienated some of the community, and is losing ground to newer open source projects.

Easily miter tubes

2009-01-22T23:26:00.008-05:00

[Update: see version 2]

Have you ever want to join two tubes at some specific angle? For example, imagine you were building a bicycle frame. To ensure a good clean weld, you want to miter one of the tubes so that it perfectly fits against the surface of the other. This, unfortunately, can be a pain in the butt.

So, I created a quick and dirty ruby script to do the math for me. I enter the diameter of the two tubes, and the angle at which they should join, and it draws the curve as a postscript document. I can then print that template, tape it to the smaller tube, and cut along its length.

Say for instance I wanted to join two toilet paper rolls (1.75" diameter) at 30 degrees. I simply type:

$ ./pipemiter.rb 1.75 1.75 30 in >tp.ps

or, if you prefer something more guided and interactive,

$ ./pipemiter.rb >tp.ps
Preferred unit (one of mm, m, ft, in, cm): in
Outer Diameter of larger pipe: 1.75
Outer Diameter of smaller pipe: 1.75
Angle of joint (degrees): 30

and it gives me a postscript document, which looks like this curve on the right.

As a proof of principle, I tried it out with two toilet paper rolls
(to your left). They join perfectly!

The source code for the script is available for free.

Happy OBAMA day!

2009-01-20T11:46:00.001-05:00

Or, more importantly, happy NO MORE BUSH DAY!

Know that your people will judge you on what you can build, not on what you can destroy.

-O

This town sucks...

2008-12-22T21:41:00.002-05:00

I get home every night around 9pm. All I want to do is order some food. Everything in this town is closed.

Princeton sucks.

What to do about Detroit

2008-12-10T08:56:00.001-05:00

(Caution, politics follow)

Seth Godin has a brilliant post on what to do about the big three auto makers:

Not only should Congress encourage/facilitate the organized bankruptcy of the Big Three, but it should also make it easy for them to be replaced by 500 new car companies.

Or perhaps a thousand.

That's how many car companies there were 90 years ago.

Read the rest.

JFC it's a hovering muderbot!

2008-12-08T23:27:00.001-05:00

From Engadget,

Are you ready for a vision of your inevitable end at the hands of a hovering murderbot? Feast your eyes, then, on this video of the Missile Defense Agency's MKV-L -- or as we like to call it, the Multiple Kill Vehicle. The device -- meant to be used in a bundle of missile interceptors deployed by a larger "carrier" -- has apparently just completed its first flight test, so... you've been warned, resistance is futile, he'll be back, and in space no one can hear you scream.

Stop-motion video.

2008-12-08T22:59:00.001-05:00

Not sure if the term ``stop-motion'' even applies, but this is spectacular:

Watch Nightmare in the Valley of the Dolls in Entertainment Videos | View More Free Videos Online at Veoh.com

And it doesn't seem too hard to make (though getting David Byrne to write the score may be harder). Perhaps a weekend project...

Only in grad school...

2008-11-25T23:38:00.002-05:00

Last night, the research group and I were up all night working on a paper. I was modifying some benchmarks to collect another kind of data, and I got to a point where the code didn't work, and I had no idea how to fix it.

The code boiled down to something like this:

int x = 0;

int f()
{
...
x++;
}

int main()
{
...
f();
...
printf("%d\n",x);
...
}

But every time, it would print out zero. I asked one of the other grad students, and after a few perplexed moments, he came up with the solution:

"Oh, Nick! You forgot that we loaded the kernel module which drastically changes the semantics of memory."

Ah... gradschool.

Amused by SMLtoJs

2008-11-23T00:27:00.003-05:00

I love Standard ML -- its excellent type system finds nearly all of my bugs before I run the code even once, and the idea of restricting side-effects to a small portion of my code makes the whole easier to reason about. Not to mention, disjoint union types seem to cover 99% of my previous use of object oriented programming. Runtime performance sucks, but honestly, how frequently does that even matter?

I hate javascript, even more than I hate perl. It is a language with no definition. It is a language with no reference implementation---and even individual implementations are self-inconsistent. It's a classic example: very little planning went into its beginnings, and the remaining planning only came about after every vendor had pushed their own solutions.

I recently discovered SMLtoJs -- a compiler that translates Standard ML into Javascript. I can't decide if I'm disgusted or pleased by this. I'm definitely amused...

Cool Plot :: Gibbs Sampling and a (mostly) independant Bayes Network

2008-11-10T11:33:00.003-05:00

Here's a cool plot that came up while I was doing a homework assignment. It is the result of the Gibbs Sampling algorithm approximating a 50-50% variable over a billion iterations on a probability space of dimensionality close to 2^25.

Imagine you have a random coin toss which we'll call the leader. Now imagine you have one or more followers who choose to agree with the leader x% of the time, or disagree otherwise. Suppose that you can't "see" what the leader chose, but only what the followers have chosen. Determine the probability distribution of the leader's coin. We'll call this the leader-follower problem.

In this particular instance of the problem, the leader's coin is unbiased (50-50%), followers agree with 90% probability, and we have 25 followers. Each of the followers depends only on the leader and not on each other, and so each follower represents a nearly independent dimension. I claim that the probability space P(Leader|Followers) is nearly 2^25 in size.

When we put a Gibbs Sampler to the task, it's performance kind of sucks. Effectively, it is running a Monte-Carlo simulation of the scenario, and attempting to count the probability distributions over the network. But, since the space is so large, it cannot effectively explore the whole space, and so there is a lot of error.

What I find so intriguing about this plot is its smooth upward or downward trends, with sharp turns.

You can think of any trend away from the solution (50-50%) as a situation in which more than half of the followers disagree with the leader, and any trend towards it as a situation in which more than half agree with the leader. Since Gibbs Sampling changes one variable at a time, we effectively have a "momentum" effect; once more than half disagree, each one needs to be independently fixed, on at a time, before we can turn around.

Also observe that the slope of these traces is proportional to the number of followers in disagreement. This is why the slope tends to flatten out as we reach the extrema.

Enjoy.

Modding my minilathe :: Adding locks to the X-,Y-Axes

2008-11-09T16:14:00.002-05:00

I posted before about a few modifications to my minilathe. These cheap lathes are fun and accessible to many, but they have a few weaknesses. Now that I'm taking the machine shop course at Princeton, and learning a lot more about machine work, I've realized a few more deficiencies.

In particular, since a lathe provides several degrees of freedom to the tool holder, it's possible for the tool holder to drift along these dimensions while cutting. Decent lathes provide a locking mechanism along each degree of freedom to prevent this, but for the most part, the minilathe does not.

My minilathe's tool holder has five degrees of freedom: left-to-right (X), forward-backward (Y), rotation (Theta), compound (Z), and tool orientation (Phi). The factory stock lathe provides locks for rotation and tool orientation, however the remaining three cannot be locked.

It turns out it's pretty easy to add locks for the X and Y dimensions.

To add a lock to the X dimension, one needs only to drill and tap a hold along the X-carriage so that a bolt will press against the X-ways.

A very similar approach will work for the Y dimension, though care should be taken to prevent this bolt interfering with the rotation of the tool holder, or from coming in contact with the work piece or chuck.

The Z dimension is trickier because of the shape of the tool post, and I don't have an answer yet for how to add a lock. In the best case, I can't figure out how to provide a lock over more than a small region of the Z-travel. Even then, there are two counterbored holes through the Z-ways (to lock the rotation) which would make this more difficult. If you have any suggestions, I'd like to hear them.

Also, I've been putting a lot of thought into rotation. With a stock minilathe, you have to half-remove the compound to unlock the rotation, adjust the rotation, and then replace the compound. This is really a pain in the butt, and I've been thinking about a way to add a dial to rotate the tool post. My plan is to cut threads along the perimeter of the rotation-clamp part, and then add another screw that will slowly rotate the tool holder. This is still in the works, and I'll let you know when I get it working.

And now...

2008-11-05T09:27:00.002-05:00

[warning: politics follow]

I'm excited about the results of the election, not because I'm glad that the Democrats won, but for the hope that an opposition party has taken control of the legislature and executive. The distinction is subtle, and all hinges on whether or not the Democrats will finally step up to the plate and offer a new direction.

Over the last eight years, I saw the Democratic party crippled. They were afraid to even speak against Bush for many years after September 11. More recently, they have felt more free to criticize the Republican Platform, but as far as I can tell, they didn't present any alternative. Anyone who is surprised that Bush won in 2004 should observe that it was a failing of the Democrats in 2004.

But now, the future is open. Obama has inherited a huge mess, and I don't know how well he will be able to deal with it---the war, the economy, and the nations energy policy at large. I hope they can accomplish something. I hope we don't just see four years of apologists.

VOTE

2008-11-04T08:43:00.001-05:00

VOTE TODAY