cheaphack

DIY long recumbent

2011-02-06T20:13:00.007-05:00

Another cabin fever project: a long-wheel base racer recumbent. This is based on Atomic Zombie's Marauder from his book, but with modifications as I go along. Why a long recumbent? Supposedly, above 20 mph or so, a rider is primarily limited by wind resistance. If you want to go faster, you must overcome that.

Unfortunately, recumbents (and their riders) usually look like this.

Atomic Zombie works hard to make recumbents look a little bit cooler...

I'm not sure I'll look much cooler than either of these guys, but fuck it... I want to ride fast!

The main frame is made from three pieces of 1"-square tubing. The front wheel is 20", and will be steered via rod (much like my Bakfiets), the rear is 26". The rear fork is made from an old fork (the seat stays) and some 1/2"-square tubing (the chain stays). The wheel-base is 6'10".

I've got a lot more work to do, but progress is coming along very well: I've got two wheels and cranks. Still need: steering, brakes, transmission.

This thing is so long it's hard to photograph. See the whole set on flickr.

Thank you Cyclab for letting me keep the intermediates and a lot of tools in your shop!

DIY Grow Lamp

2011-02-06T19:16:00.013-05:00

We've had snow on the ground since the day after Christmas, and I'm getting a little bit of cabin fever. We're also getting exciting about the upcoming gardening season, and Daya started sprouting vegetables inside. When she started searching for indoor grow lamps online, I was disgusted by the prices. So, I walked into my workshop to see if I had any LEDs laying around.

And that's when I remembered that I had LED strip.

I bought 3 meters of this at a great price while I was in India a year and a half ago. I thought I'd use it to bling-out my bike, but never got around to it. On later thought, glowing bikes are tacky. The grow lamp is a better use.

Each white rectangle is three LEDs: red, green and blue. The black rectangles are SMT resistors, 150 Ohm for the red and green channels, 330 Ohm for the blue channel. Each channel can be controlled independently to produce any color. The strip is printed on flexible circuit board with an adhesive backing. The strip can be cut at 3-LED increments. This stuff is pretty damn cool, and very easy to use in nearly anything.

I put the strips onto a piece of scrap wood grid that I found in the dumpster. I wired them together, and use an old laptop power supply to power them. Wiring requires a little bit of thought. A contiguous length of strip puts all of the LEDs in parallel. It's tempting to wire connect this directly to the power supply. However, the voltage drop of the lights is only about 0.7V. Putting 20V across that will draw a huge amount of current, and the LEDs will run hot. I chose instead to wire the strips in series. This gives as much light, but draws less current.

The light is intentionally purple. I use only the red and blue channels, since those are (approximately) the frequencies of light that plants can use. Said another way; plants are green because green is the only color they don't absorb. Adding green would give a whiter color, but add nothing for the plants while burning more power.

Underwriters Laboratories would not approve. Exposed soldered connections, no enclosure, and hand-wavy electrical engineering on an appliance that will be near water. Still, the power supply and LEDs run cool, and give intensely bright light.

We hang the lamp from a shelving unit in our living room. Underneath, we're sprouting Mustard Greens, Lettuce, Parsley, and Collards, and below that, a space heater to keep the seedlings warm. At least a month more before Jersey thaws and we can put them in the ground.

Steinbeck quote

2010-11-03T21:35:00.001-04:00

If I seem to be over-interested in junk, it is because I am, and I have a lot of it too -- half a garage full of bits and broken pieces. ... I do have a genuine and mostly miserly interest in worthless objects. My excuse is that in this era of planned obsolescence, when a thing breaks down I can usually find something in my collection to repair it -- a toilet, or a motor, or a lawn mower. But I guess the truth is that I simply like junk.

-- John Steinbeck, Travels With Charley

Someone finally made the right kind of vacation planner.

2010-10-24T16:01:00.004-04:00

If you're like me, you love traveling, but don't want to break the bank. The cost usually is more important than the destination. I know a few languages and I'd like to speak them. I want warm weather. I know a general time of travel. Where can I go?

I usually think about vacation in terms of "I want to go to a Spanish, French or English speaking nation in December, where the average daytime temperature is at least 62F, and with tickets for less than $1K." Kayak has made this nifty map application to answer that for me.

Thank you Kayak, this is brilliant.

Maker Faire was Awesome

2010-09-26T21:04:00.004-04:00

Two thoughts.

(1) If you're going to build a robot, make it a crowd pleaser:

(2) I'd saw my arm off for a thing-o-matic

Photos from Guatemala

2010-07-16T12:07:00.003-04:00

I just got back from a month long vacation in Guatemala. I've uploaded pictures.

If you just want highlights, check out Semuc Champey and Tikal.

DIY Bakfiets

2010-07-11T10:38:00.013-04:00

I don't have a car---not even a license---and so transportation is a problem for me. It wasn't a problem back in Charlottesville or in Brooklyn, since both cities offered walkable communities. But now that I live in Princeton, my grocery stores are far away. I use a bike for personal transport, but even then, I can only carry a small amount of groceries at a time. I need a better solution; I need a sport utility bike.

The spark that moved me into action was one of bike-machismo. My friend Sean-not-douche of the Cyclab asked me to help him build a tall bike. That went well, but I was embarrassed that we needed a pickup truck to transport my welder and tools to his shop. Why do we need to burn gas for a bike-geek activity!? It seemed wrong.

Sure, I could simply buy a trailer, but I don't really like trailers. I had built a trailer back in my Virginia days, but I didn't like how it affected the feel of the ride. The joint between the frame and the weight added an unsettling resonance to the ride, especially around corners. I wanted a design that offeres a more rigid ride.

The dutch have long ago perfected a design known as the Bakfiets ("box bike") for transporting cargo. These literally are the SUVs of Holland; Dutch moms even use these to carry their children to school. I thought about it, and the design seemed perfect for my needs. In short, the design is a two-wheel bicycle, with a large cargo platform between a 20" front wheel and the steering column.

I ran off to lowes and bought a lot of 1" square steel tubing. The new steering column is made from 1-1/2" EMT conduit. The headset, fork and wheel were scavenged from a child's huffy. The cargo platform is made from two 1" tubes, one above the other, with 1/2" tubes supporting between them.
I didn't really measure anything---I eyeballed everything. I found out later that the angle between steering column and front half was important and incorrect. I would need to correct this later.

Next, my friend Hjalmar gave me a small, purple schwinn to serve as the rear half. I cut-off the headset and mitered it to fit the steering column, and added another 1" square tube from the bottom bracket. Alignment is important, but not critical. So, I used a string to aid alignment. I made a loop of string, joined by a rubber band for tension. I wrapped this around the dropouts and the headset, then tapped the steering column left or right until it was centered between the two lengths of string. Clamp, weld, and repeat until the frame is straight.

I achieved the steering using an offset arm. An old fork was cut and extended with a piece of plumber's pipe so it would span the steering column. At the end, I welded a bold at a 90-degree angle, and added a complementary bold on one tine of the fork. I added a length of rebar, which connects to these two bolts using univeral (aka ball) joints. I built it up, adding components and wheels, and took it for a test ride.

Honestly, the first time I tried it, it rode like crap. The bottom bracket was too low, and the pedals would strike the ground. It felt very unstable, and the rider would tire very quickly. But why? I can't say I knew enough about bicycle geometry---was the slope of the front wheel incorrect? Was it misaligned? I was lost.

Luckily, my friend Joe figured it out for me. I welded the front half to the steering column at a 90-degree angle, and the steering column met the top-tube at a 90-degree angle as well. However, the purple schwinn had a rising top tube. Effectively, the 90-degree angle caused the rear frame to tilt forward unnaturally and lowered the bottom bracket. The solution was to change the angle.

From what I had, the easiest solution was to cut just in front of the steering column, and then reattach at a more obtuse angle. This raises the bottom bracket, moves it forward of the seet, gives a comfortable slope to the steering column, and leveled the cargo platform. Indeed, this simple change made the bike much more comfortable.

Per Zach's suggesting, I added a triangular piece from the steering column to the cargo platform, for strength.

Next, I welded two 27"-long 1/2" square tubes perpendicular to the cargo platform. These will help to support the platform.

Once I had achieved a ridable frame, and could not forsee any major changes to geometry, I build a box out of scrap plywood I found in the dumpster. These three boards rest against the frame. I didn't have any hardware to attach the wood. I searched my junk pile, and found some scrap copper sheets, leftover from some roofers. I cut, bent, pierced these into brackets, and then screwed the frame tight against the frame. Copper is expensive---if you were buying it, I'd recommend you use sheet tin or steel.

Now the bike is done-ish. I can carry cargo. The next few things I'll do are: add sides to the box, add cable stops so I can shift gears, and also strip it all down and paint it. In the mean time, it's certainly strong enough to carry 8 bags of groceries, or a hundred-or-so pound of tools. Success.

But this is better than just a hack---this is a liberating technology. I want a life without gasoline yet without sacrificing quality of life. This machine gets me one step closer.
The whole set of photos is on flickr.

If you can solve this one...

2009-09-23T20:31:00.001-04:00

http://ubuntuforums.org/showthread.php?t=1273513

I'll give you a high-five.

Welcome Back to America: Door-to-Door Christians

2009-09-09T22:02:00.002-04:00

So, I've been back in the country for a week now. In some ways it's really nice to be here, and in others it's driving me crazy. In particular, I've have two visits from door-to-door Christians in as many days.

The first visit came during the daytime, and I tried to politely refuse. I even wished them a good afternoon.

But tonight, they started banging on my door at 9pm, while I was in bed. I tried to ignore them, but they banged again, making me think that my neighbors had some emergency. So, I got up, opened the door, and a well-dressed young man proudly announced "Hi, we're Christians!"

I slammed the door in their face.

And although, in this second situation, I think that the solicitors were behaving obnoxiously, I still feel a need to explain why. Certainly, they thought they were doing something good. Let me express an alternate interpretation of the interaction. When you come to my house and try to tell me about your religion, here is what I hear:

"Hello, we don't really care what you believe because we are right and you are wrong. Although popular culture has presented ample evidence that many people do not appreciate our presence, and although we should respect that you may have a different opinion, we chose to ignore what you believe and what you want, and to instead impose our will on you."

No matter how you sugar-coat it, it's as rude a statement as is possible. I shouldn't have to post "no soliciting" to escape this.

Just be glad I don't knock on your door to tell you how you're wrong.

Excellent Quote: Chomsky on English Spelling

2009-08-24T10:36:00.005-04:00

conventional orthography is ... a near optimal system for the lexical representation of English words.

Chomsky, N. & Halle, M. (1968) The Sound Pattern of English

Compare to Mark Twain's "Spelling Reform: A Plan for the Improvement of English Spelling,"

Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld.

One of my few Indian Victories: Cheap Tech Books.

2009-08-22T08:40:00.004-04:00

One of the most respected algorithm text books out there, Cormen et al's Introduction to Algorithms will cost you $62 from Amazon (2nd Ed, paperback). On the other hand, I just bought it here for Rs 350 in India, brand new. That's about $7 US. Wonderful. I may have to go back for TAOCP 1-3.

Excellent Quote: How programmers think

2009-08-12T10:56:00.002-04:00

I can't tell you how correct this passage is:

Most programmers above a certain level are very good at conceptualising large, complex systems. They can interrogate perceived weaknesses in a program before it is even written. This is how good programmers manage to write programs that are largely free of defects and that generally work in the way that is expected. Small-scale errors aside, a good high-level conceptual understanding of the system, coupled with an ability to mentally simulate the behaviour of any portion of a program provides programmers with most of the tools they need to construct good-quality programs. The programmer is likely to know (at least at some high level) how the entire system is going to work any any given moment.

From Adventures in Programming Languages and Semantics, "If concurrency is easy, you're either absurdly smart or you're kidding yourself." The full article is a good read.

Review and Analysis of C# Part 1: Partial Definitions are an Anti-pattern

2009-08-04T15:24:00.003-04:00

I've had to use C# a lot at work recently. Like everything else, I have very strong opinions about C#. So, I've decided to write an N-part series reviewing, critisicing, and sometimes even praising its design.

So, here's the first installment: Partial Definitions are an Anti-Pattern.

C# introduces the partial keyword. In short, the partial keyword allows a programmer to partially define a class at several places. According to MSDN, the rationale for this feature is:

When working on large projects, spreading a class over separate files enables multiple programmers to work on it at the same time.
When working with automatically generated source, code can be added to the class without having to recreate the source file. Visual Studio uses this approach when it creates Windows Forms, Web service wrapper code, and so on. You can create code that uses these classes without having to modify the file created by Visual Studio.

The first argument, holds no water. Yes, projects sometimes grow large, and often multiple programmers need to work on it concurrently. But, this problem is better handled by version control software.

To make this argument, let me introduce the notion of a section of code. Let's say that a section a collection of lines of code such that a significant modification to any one requires modification to (or at least a critical evaluation of) the other lines within that section. For example, changing the type of a variable requires you to revisit each use of that variable. For example, changing an invariant of a class requires you to revisit all lines which assume that invariant. It's a loose definition, but all the programmers out there know what I'm talking about.

Now suppose that two or more programmers are trying to modify some large class. At any given moment, either they work on the same sections of code, or they do not. If they work on different sections (which implies they are working on different lines), then common version control software will be able to automatically combine their efforts. On the other hand, if these two programmers are working on the same section of code, the programmers will need to coordinate their efforts---even if they are able to isolate their changes to disjoint lines of code or separate files. Said another way, the ability to split the class into two separate files does nothing to solve the original problem.

The second argument is no stronger. Suppose a code generator produces a large class definition. Further suppose that, across multiple runs of the code generator, much of the output is common. Why then, I ask, would the code generator repeatedly emit redundant code? Wouldn't it make more sense for the code generator to place the common code into a runtime library, or even a base class from which the situation specifics may derive? Just because it is a code generator, there is no excuse to emit code which ignores good software engineering practice.

There may be efficiency concerns pushing towards this style of code generation output. It could be that there is a significant difference in run time. I argue that this is a symptom of a problem elsewhere in the software stack. If two different implementations differ only on a cosmetic level, but the compiler exhibits a drastic performance difference, then it is the compiler's responsibility to decrease that performance difference. In a high level language---and especially in the case of a language stack as complicated as the CLR---these kinds of implementation details should be below the programmer's cognitive radar.

I have argued against the claimed benefits of partial classes, and I'll be happy to argue against any others that people suggest. Let me next argue that partial classes not only give no benefit, but that they also do harm.

The primary goal of software engineering is to create software engineering best practices in which programmers can reason about software in a modular fashion. Classes, for instance, enable us to think about one algorithm at a time, and to ignore all of the other parts of the software. Imagine trying to prove that your implementation of a binary tree is correct if it depends upon the operation of your GUI? Yeah, that's ridiculous, and that's why we write modular programs.

Now suppose that you have written a module so complicated---so multi-faceted---that you believe that some parts of its definition should be expressed separately from the rest. This suggests you believe (1) that your module expresses at least two different aspects of the problem, (2) that a programmer can reason about each independently, and (3) that any attempt to reason about them as a single unit will lead to unnecessary confusion. All of these are reasons to place the second aspect of your module into a separate module, not a separate file. In fact, many design patterns describe interfaces which tackle precisely this sort of fine-grained interaction among modules. The only reason to keep them in one module is programmer laziness. In this case, the partial feature enables the programmer to defer good design; he may get the code to work faster, but may cause headaches for all of the programmers who must maintain the code.

Additionally, as a programmer, I find it valuable to see the entire definition of an algorithm (feel free to disagree; let me know why in the comments). I don't necessarily look at the entire definition, but I think it is critical to be able to find any code which contradicts my understanding of code. In this case, a single definition (or at least a single file) enables me to quickly gather all factors which contribute to the operation of an algorithm. From my experience with C#, partial class definitions make it harder to gather all factors, and make it difficult to be sure I have found all of them.

Virtual methods might cause this problem as well. However, virtual methods are more restricted. First, they are marked virtual. Second, I know immediately where to find refinements of virtual methods: lower in the inheritance tree. Partial definitions have an arbitrary number of components---they can be anywhere provided they are combined at compile time.

Some may counter that these arguments all suggest a feature-rich integrated development environment. Sure. I'm in favor of good tools. But (1) I appreciate languages which don't require IDE support to read, because sometimes you read code on a website, a book, or other media, and (2) even the best of the best tools don't yet support this style of code browsing. I've been using Visual Studio 2008 at work, and it can't even list all of the subclasses of a base class for me! Enumerating all parts of a partial definition is equally challenging.

My recommendation: avoid the partial keyword, and instead decompose your software into modules sensibly.

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.