My Other Car Decapitates Lists

Sweet Jesus, it's been a long time since I updated this.  Judging by the total lack of emails or comments asking for new updates, I can safely conclude that it was indeed only my mother reading this.  Hi, Mom!  Happy Mother's Day!

Anyway, I felt that urge to spill my guts all over the internet and decided to do a bit of writing about my hero Paul Graham's fairly insulting essay, You Weren't Meant to Have a Boss.  Paul likens programmers working for actual bosses in companies larger than say, three, to caged and listless zoo animals, while he and his co-founders are the glorious lions romping about on the plains, living a life of danger and adventure.

Uh, sure.  Ok, Paul.  While I understand how you can (and often DO) advocate the life of a founder or co-founder since you were one, how can you begin to paint a picture of working in a large company?  I mean, have you ever worked in one of these "large" companies?  Yes, you co-founded Viaweb, and it sure was awesome.  Now you have this YC thing, and even more recently the increasingly popular founder/startup news forum, Hacker News.  And we all know the tales of horror and stupidity that arise from people working braindead jobs for huge companies.  Bosses that ignore your every suggestion, waste your time endlessly, and insult your intelligence with busy work and useless projects.  Bosses that micromanage and constantly pepper you with requests for the dreaded status report.

But, Paul, there are also magnificent bosses.  Bosses that encourage you to learn new technologies and methods, that send you to useful seminars and conferences, and that listen to what you have to say.  Bosses who wade into the trenches and code with you, and admit when they are wrong.  Best of all, bosses that respect your estimate of when a project will be completed and acknowledge that you probably know what you are talking about, since you wrote the damn thing. 

I've had both kinds of bosses.  The good kind are rarer, but they definitely exist.  Find one and work for her/him.  They are worth sticking with. 

And to extend your caged lion analogy a bit further, do you know what happens to a lion that is hurt or ill in a zoo?  A team of people step in to make him better, at great cost to themselves and little to the lion.  Enter the wonderful world of cheap health insurance, found in these "large" companies.

Now, this isn't a prefect analogy, of course.  All you glorious co-founders and dashing entrepreneur lions can certainly acquire a healthcare plan, though at greater cost.  But many founders seem to ignore the possibility that they may be injured and forge ahead putting every spare cent into their startup.  It certainly isn't cool or edgy to worry about health insurance, but when these super-cool founders need hospital help and have to sideline their startup (or even bail on it) to pay their hospital bills, they have ceased to be hunting lions.

Food for thought, Mr. Graham.

Woo, non-AI-related update!

I started thinking recently about the sorry state of the world.  War, famine, poverty, disease.  Genocide, atrocities, crime, racism. 

As an (Ugly) American, most of this is just stuff I see on reuters.com.  I watch things like the war in Iraq and brutal crackdowns on protesting monks in Myanmar with little more than desultory interest.  "I feel bad, but what can I do?  I'm all the way over here; they're all the way over there."  This is what most people think.  Making it doubly hard to empathize is the fact that nothing like that is happening outside your window.  For most Americans, nothing like that has ever happened outside their windows.

And my situation is more insular than most.  I live in a very rural, very affluent community with essentially no population diversity.  In short, it is Whitelandia, and rich Whitelandia at that.

So what the fuck do I care about all these downtrodden people in the rest of the world for?  I've got the good life!  Right?  Right?

Sure.  The good life.  When I was young, though, I met someone who told me that leading a good life just isn't enough.  At first the idea was foreign to me.  My parents had raised me to believe that if I just was kind and generous in the course of my daily life, I could make a difference.  This isn't true.  No matter how kind and generous I am, it just isn't going to make a difference for some poor kid in the Philippines living in a trash heap.

So what is one to do?  Join the peace corps?

You're still thinking too small.  One of my favorite quotes is this:

"If our goal is to write poetry, the only way we are likely to be any good is to try to be as great as the best."

Donald Hall wrote that, in his piece "Poetry and Ambition," and I always thought it was an excellent point applicable to much more than poetry.  If you are going to lead a useful life, why not try to do great things?  Don't just join the Peace Corps or the Red Cross, create the next Peace Corps or Red Cross.

My goal in life is to create something as long-lasting and as useful to the future of philanthropy as these great organizations.  Something that genuinely helps people in need, instead of aiding and abetting people who watch the world on TV.

There are two organizations right now that I aim to emulate, which as you can see from the quote above is my highest praise:

1)  Room To Read

2)  One Laptop Per Child

Both of these are, I think, outstanding ideas and completely unconventional.  There are a great number of agencies devoted to the eradication of disease, and these too are worthy ways to help, but I think the greatest benefit will come from the eradication of ignorance.

With any luck, I can lend a hand in the future as well.

This is the seventh piece in a series of journal entries written about various aspects of artificial intelligence.  This piece contains a short discussion of how programming languages deal with constraints.

Constraint satisfaction in artificial intelligence interested me when we went over it in class.  I became particularly interested in how to represent a constraint in a programming language.  What would be the best way?  Clearly one could sometimes easily model a constraint with conventional logic available in any programming environment or language; consider Sudoku, the mathematical puzzle in which a square is divided as thought it is a tic-tac-toe board, with 9 subsquares.  Each subsquare is again divided, for a total of 81 squares.  The puzzle is partially filled in with integers 1 through 9 in various places, and the player must fill in the correct digits in the correct subsquares such that each row, each column, and each square contains only the digits 1 through 9, and each digit only one time.  This kind of constraint-based problem could be easily modeled in nearly any programming language worth its salt.

But what about more complex constraints?  I searched around for a bit, examining possible ways to deal with a complex constraint before I found an interesting language named Kaleidoscope, which seems to have constraints built directly into the language specification, probably as a basic type.  I wish I could say with more certainty, but few details seem to exist outside of research paper form online, and my subscription to the ACM no longer seems valid.

However, even if you don't feel like using Kaleidoscope, some options exist in more common languages such as C++ and Java, both of which have constraint-satisfaction libraries available. 

I have been thinking of an idea for a good final project based on Kaleidoscope.  My next journal entry will probably be a project idea fleshed out in full about constraint satisfaction programming,

This is the sixth entry in a series of journals I am writing for my AI class this semester.  It concerns some thoughts of mine on the Cyc project, and the usefulness of OpenCyc.

As we learned in class, Cyc is an attempt by the company Cycorp to create a knowledge base of basic, common-sense facts about everyday objects and events that could someday be used to create new assertions about these objects and events, based solely on what has already been added to the ontology and some basic logical inference rules.

I'm going make a bit of a blanket disclaimer before I delve into my feelings about Cyc and OpenCyc:  I am extremely interested in AI in general, and knowledge representation in particular.  Ever since I had heard of Cyc (sometime back in junior high, I think), I have considered it an excellent idea.  With the addition of the OpenCyc program (and the ability to allow the great mass of people able to access the internet to augment the knowledge base), I think the idea has only become more useful. 

However, is this really artificial intelligence?  I was leafing through an old AI book the other day and was reminded of the Chinese Room gedankenexperiment.  The Chinese Room (in case someone other than Wheeler happens to read this!) is a thought experiment in which an English-speaking person is placed in a locked room and passed messages under the door which are written in Chinese, which he has no natural knowledge of.  However, he is equipped with a series of books written in English which detail precisely how to respond in Chinese to any given set of characters.  So as he receives a message under the door, he examines it, looks up the appropriate response in one of his books, copies the squiggles shown onto a new sheet of paper and passes it out underneath the door to the entity waiting for a response.

Now assuming that the man is a flawless follower of directions, the entities on the other side of the door have no idea that he has absolutely no idea how to write in Chinese.  To them, he is perfectly fluent.  John Searle, creator of this thought experiment, suggests that this is an excellent model for the way computers deal with knowledge input to them by humans.  If we consider the knowledge base of Cyc combined with the logical inference rules Cyc could use as equal to the books of rules the man has in the Chinese Room, isn't Cyc just a Chinese Room simulation?  In fact, can't we posit that most knowledge representations just lapse into revisions and variants of the Chinese Room?  The computer has no underlying knowledge of the Cyc contents just as the man has no intrinsic knowledge of Chinese.

This kind of made me sad for a little while, as I liked Cyc as a project and wanted to see something good come of it.  But then I cogitated a little further, and decided maybe it is exactly how our brains work as well, at least in the beginning.  When I began thinking as an infant, I had an inbuilt set of rulebooks in my genes.  Without devolving too much into a nature vs. nurture discussion, I think I had a very basic set of rules to allow me to interact on a very primitive basis with the objects around me.  And really, how is that different from the rulebooks the man in the Chinese Room is given?  After a while, wouldn't the man in the room (as an intelligent being) begin to remember shortcuts about which books to look in?  After a long enough amount of time, he might indeed emerge from the room as fluent as if he had been born and raised in Beijing!

So since I have decided to think of Cyc as a very early stage of the rules handed down to me by genetics (assuming nature is indeed dominant over nurture, which is what I suspect), I suggest that Cyc is a very important project indeed.  Perhaps one day the knowledge base will grow large enough for the rules of inference to begin making those shortcuts.  Once that happens, I think we are in for exciting times indeed!

This is the fifth entry in my ongoing series of journal entries concerning stuff I find interesting in AI.  This entry will consider a thought I had about a possible final project.

More often than not, I find that programming geeks are somewhat obsessed with optimization even before they have any interest in programming.  When I was younger, I used to play with Lego before all other toys.  After I built my contraptions, I always wondered if I could do it with fewer pieces.  The point of this little aside is that programmers are often thinking about the fewest pieces, the lowest time, and especially the shortest path.  

While wandering around campus with my friend Brad (usually just heading from the MUB to Kingsbury, or vice versa), we often consider whether the path we are taking is the fastest.  This is not just idle speculative chatter; we are both usually pretty cold and wish to get to our destination as soon as possible.  Suddenly at the end of class on Thursday, an idea dawned on me:  why not implement a route-planner to figure out the fastest route from one location on campus to another?  

The idea is quite straightforward.  Use Dijkstra's shortest path algorithm to find the best way to get from place to place.  The sidewalks could be edges, and buildings and sidewalk crossings could be nodes.  Edge weights would be proportional to distances between sidewalk crossings and buildings in real life.  The most interesting part might be a “Winter” mode, where special emphasis is put on paths that cross through mostly buildings as opposed to sidewalks.  Both Brad and I were constantly ducking through Hamilton Smith on our way along Main St.  

The only issue for this idea:  is this too easy?  Dijkstra's shortest path algorithm isn't all that hard to implement.  Maybe more of a challenge would be a multi-stage algorithm, for multi-part trips?  That way it would be possible to simulate a whole day on campus.  Or possibly a program that analyzes a set of various possible days, and generates a set of rules that could guide a program deciding which paths to take on the fly.  This idea greatly appeals to that Lego maniac I used to be.  Build it with fewer pieces!

This is the 4th in a series of AI journals for my class at UNH.  The third is missing due to my contracting mono a few weeks ago and spending most of my time actively trying not to die.  In the course of events I managed to forget about my journal entry.  Well, maybe at the end I will throw another on as a bonus.

Anyway, my timely and topical journal entry will revolve around this piece in recent BBC News,  As soon as I saw the headline I started to become extremely skeptical.  Only twenty-two years to match human thought capability?  Then I noticed the quote's originator:  Ray Kurzweil.  Ah-ha!

Ray is a borderline-manic future-holic.  Having read The Singularity Is Near, I would hardly consider him an unbiased source about the future of technology.  However, having considered the source, let us give equal thought to what he is saying.  I have no doubt that most, if not all, of what he claims will happen will eventually come true.  His visions of nanobots and other nanotechnological marvels are almost certainly in the cards, as well as his suggestions of future man-machine symbiosis.  I am even a believer in his suggestions that humans will eventually upload their consciousness into a computer system and live immortally as sentient software.  But in the next twenty-two years?  It seems highly unlikely. 

This started me thinking, though.  If twenty-two years aren't long enough, what is?  I started thinking about the level of change necessary to move from the current level AI is at compared to where it would need to be to be considered human equivalent. Then I considered the length of time it took AI to go from its inception as a concept to what it is today.  Even considering that technological progress as an exponential function over time, I still think it will take more than a few decades to get weakly humanlike AI.  But who knows?  I could be wrong, and Ray could be right.  I hope he is!  The AI Winter has lasted far too long in my opinion, and here's hoping Spring is just around the corner...

This is the second entry in my series of articles about my experiences with AI, in and out of the classroom at UNH.

I have been doing some thinking about possible projects, and what I might feel like working on at the end of the year concerning artificial intelligence.  One of the most interesting areas of technology for me is the idea of distributed processing.  I firmly believe that many, many processors working in harmony to solve a problem is the future of computing.  The benefits of more hands working on any particular problem are obvious, but so are the drawbacks.  How do you synchronize tens to hundreds of nodes so that no work is repeated?

While we have not discussed in class any intelligent ways of dealing with this problem of many agents working on the same problem without repeating work, I felt as though this was certainly within the realm of artificial intelligence.  I did a little searching to see if I could discover the applications of AI to this problem.

And I found some interesting results!  I was less interested in artificial intelligence in high school because I felt it was too abstract to be of any use, but if I had known better and done my research, I may have ended up paying more attention to my UMASS Amherst acceptance letter, if only to see the MAS Lab in action.  Founded in 1968, they have published a great many papers concerning the many uses of AI to control many hands all working on the same project.  Perhaps most interesting to me is their ANTs project, which created some very interesting Autonomous Negotiating Teams.  One of the coolest aspects of AI, to me, is definitely autonomy.  And to pair autonomy with my interest in control systems made me pretty much pre-destined to write about ANTs!  Give the project a read and check out all their other projects if you have an interest in that stuff. 

That title is probably the most misleading thing I have ever typed on here.  The Wall Street in New York interests me not at all.  The WallStreet made by Apple is what I am going to discuss (albeit briefly) today.

I always, always liked Apple's hardware design, and since they are primarily a hardware company, I guess this makes me an Apple fan.  For quite some time I trashed them, though, not realizing that Apple was more than just a crumby OS.  I relentlessly slagged them for having such a slow, unreliable, and just plain useless operating system back in the OS 8 and 9 days.  While I secretly admired their sleek hardware, I assumed I would never use it due to its seeming dependence on disgusting (pre-OS X) Apple operating systems.

I had a particular proclivity for the G3 PowerBooks.  They were simply very well-designed and particularly rugged laptops.  I began thinking about them again when reading Douglas Coupland's Microserfs, in which several characters use them and reference them frequently.  Admittedly, they were earlier models than the Wall Street, but it rekindled a desire to own one of the oldies-but-goodies.

So when I saw that I could pick one up for $90 dollars, I jumped on it.  I plan to double the batteries in it (for up to 9 hours of life!) and jam either OpenBSD or Ubuntu on it.  By adding an old Wifi PCMCIA card, I could easily have a super-sweet road machine!  I encourage anyone who liked these old machines to jump on this deal.

Perhaps most psychotic is Paul Graham's family of admirers, which includes me.  We have been clamoring for YEARS for the Grahamster to release Arc, and lo and behold, he finally has.  This news was met with resounding cheers, but even before these cheers had begun to soften, dissenting voices arose.  Many people, far too many people, were quite displeased with the fact that Paul had neglected to support UTF-8.  This move pretty much shuts out the non-English speaking world from using Arc, at least for the time being.  He has also taken some flak due to the languages inherent terseness, almost to the point of unreadability.  Upon reflection over a dinner at Crapplebee's concerning functional programming, the misuses of Python, and many other topics with one John Watson, he mentioned that the code was extremely difficult to unravel based upon its output.  Now if most people said this, I might snort slightly and point them politely towards grep, but Watson knows what's up.  He searched high and low for various strings output by the blog example (not the least of which was how the URL is generated), and came up empty.  Both of us agree that Paul's propensity towards three-letter commands may be hindering the readability of his code, but we are both tremendously excited to be among the first to use an interesting and powerful new functional programming variant.  Imagine being there when McCarthy produced the first variety of Lisp!  The ability to arrive on the ground floor is boundlessly exciting.

Not much else to report.  I added some links to my link page.  Some good sites to check,  I left uncov up there even though Ted has stopped updating, which is extremely sad.  That was one of my favorite sites to waste time on.  The archives are all still there, and all of them are worth reading.

This is the first of a series of journal entries for my AI class, taught by Wheeler Ruml at UNH.  Each entry is meant to be a retrospective of sorts about my reactions to the class, and to various interesting parts of artificial intelligence in general. 

I was interested to learn about A*, a search algorithm which I had heard much about but never actually investigated.  After reading a brief overview about in in Wikipedia, I became curious about some of the other state-space search algorithms that returned admissible results.  Some digging around revealed B*, which seems quite similar to A* except for the fact that it uses intervals for each node in the search tree as opposed to single values.  I would be curious to see if this is ever faster than A* for a common problem; obviously it must be faster for some cases, but which ones?  It would be interesting to run both algorithms on a variety of sets of data to benchmark one versus the other. 

I also discovered the Bellman-Ford algorithm, which piqued my interest when I noticed it solved a problem posed by Brad Larsen in class.  Brad had noted that negative edge weights often played havoc with some of the algorithms we discussed, so I was pleased to notice the BF algorithm, which is a variant of Dijkstra's shortest-path algorithm which accounts for the possibility of negative edge weights.  Instead of choosing the minimum edge weight path to expand, it expands all the paths and adjusts those that are negative until no negative edge weights remain.  It seems a little counter-intuitive the way it is described here, and I wonder if it could be better explained.  It seems to be used in some forms of routing in that all nodes in a network are constantly examining nodes they can reach, noting the shortest path, and propagating this information about the shortest path outward upon the network.  Interesting stuff!