jgershen

That's almost exactly the opposite of what this article says. To summarize it briefly, Vardi reminds us that the importance of proving P!=NP is to enhance our understanding of the underlying issues. Also, he devotes a significant fraction of the article to reiterating that worst-case complexity is not the same thing as tractability.

I'm not really familiar with protein structure prediction, but I don't think that it involves solving NP-complete problems. Scouring Wikipedia articles about protein structure prediction suggests that the techniques used are broad, varied, and distinct from the classical set of problems in NP. If someone's doing work in this area and is attempting to solve a problem in NP I'd love to hear it.

Actually, I think that with the possible exception of #2 (which can be debated extensively) these are not "things that Paul Graham is wrong about". They are "places where Paul Graham used hyperbole to make a point."

I disagree with PG on a number of issues, but this post completely missed the point.

Except that's not something that PG says, in general. I think that in this case, he was pretty clearly saying "the talk will be online" in an idiomatic manner.

In my experience PG errs toward the side of putting too much emphasis on taking notes, honestly. (This is probably because he works better when he takes notes, and he's seen a lot of YC founders forget/ignore his advice when they don't write it down.)

I interpreted Qz's comment as "this professor is deserving of the allocated credit." As a recent CMU CS grad (and student of Professor Miller) I would agree and say that this is also generally the case.

Sorry about the Google cache; HN won't let you submit FTP links.

This was written by Warren S. Sarle from 1997-2002. I ran into it while trying to look for papers on benchmarking neural networks. I highly recommend it for its frank and accessible style.

It seems like this would be a reasonable introduction to neural network programming (while PyBrain contains code for other classifiers, the site also suggests that this is mainly for comparative purposes). If you were more concerned about performance, it seems like it might be better to check out libfann.

I couldn't easily find comparative benchmarks, so this opinion is just based on the documentation of the two libraries and what they say about themselves. If I have some free time this week (hah!) I'll throw together a quick and dirty performance comparison.

I pointed at some of the general techniques we use on Quora: http://www.quora.com/GazeHawk/What-broad-computer-vision-tec...

> for an engineer it was an ultimate challenge

You won't find any argument from me; eye-tracking is extremely hard stuff to do correctly and reliably. There are many things that I still want to do to improve our implementation, but can't find the time to write.

(Insert a shameless request for interested readers to send me their resumes here!)

Also worth a look is FutureAdvisor (disclaimer: YC S10). Bo and Jon are working on helping people answer these questions - they're both very smart guys who really know what they're talking about (the latter is a surprisingly rare quality in both the financial and startup communities, in my experience).

I did the Fifth Year Masters program at CMU because I was in exactly this position. I recommend talking to Stehlik about it.

I understand that point and I agree. What I'm saying is that upon reading the article closely, I noticed he was primarily promoting the "view infinite as arbitrarily large" technique for dealing with the appearance of infinity.

Example quote from article: "Interpret the problem as saying that the width of the capacitor is so large relative to its thickness that you don’t have to worry about edge effects."

What he's saying is that by "infinite," people usually mean "arbitrarily large". I've found that if you just say "arbitrarily large" when that's what you mean, it eliminates a lot of these misunderstandings.

Of course, I talk to a lot of engineers and mathematicians. You run the risk of sounding unnecessarily pedantic.

Yes. I told him the following in person earlier tonight, at the last YCS10 dinner, and I think it's the consensus among the other founders I've talked to from our batch.

For the first month of Y Combinator, Paul Graham will tear you and your startup apart on a weekly basis (when you meet with him during office hours). If you're doing your job as a founder, though, you are the world expert in your particular field. So there should be times when you are right, and he's wrong, and you know that this is the case because of specific domain knowledge. There may even be times when you try to explain this to him and are unable to communicate it successfully.

However! There are also times when you think you have a problem specific to your startup that is actually a problem most startups have. In this case, PG is the domain expert, and you should probably listen to him.

The hard thing to do, obviously, is to distinguish the two cases. I have some thoughts on that, too, but they basically boil down to "you should appropriately mix cautious thought with bullheaded stubbornness", and you already knew that if you read anything anyone wrote about startups ever.

Edit: Didn't mean to speak for the rest of the founders. Feel free to disagree.

Good point, I didn't see that. I have to believe, though, that this suggests Google views Rapportive favorably in general.

A version of Rapportive is featured (free) in the Google marketplace. See http://www.google.com/enterprise/marketplace/.

If that doesn't settle the fairness aspect for you, take a look at http://code.google.com/apis/gmail/gadgets/contextual/ - improving Gmail is something Google is interested in.

Edit: Rapportive's listing specifically can be found at http://www.google.com/enterprise/marketplace/viewListing?pro...

Is anyone else a fan of the reporting Wade has been doing on this batch of YC companies? I've really enjoyed the in-depth articles - a nice contrast to the typical ADD of the Internet echo chamber.

The loss in accuracy between us and a custom hardware setup for eye-tracking is primarily due to the fact that we're using a very different eye-tracking method. The "gold standard" for eye-tracking involves shining an infrared LED at the user's eye and measuring the reflection.

Since we're trying to use no custom hardware at all, we have to use machine learning techniques to extract features from the visible-light image of the user's eye. This is a lot more difficult than locating the bright spot in a reflection, so there's a lot more that can go wrong.

Just some information about the accuracy of our eye-tracking software - people have been curious, so I thought I'd share it with the community.

Feedback appreciated, as always!

People typically hold the iPhone closer to their face than they hold their laptop. Since accuracy in eye tracking depends on the angle between the calculated gaze vector and the true gaze vector, this means that error will be reduced.

The amazingly high pixel density on the iPhone 4 means that that the calculated gaze focus may be more pixels away from the real point - but we're working on some ways to compensate for that.

Yes. Very yes. I can't upvote this comment enough.

Advertising pricing with cost-per-glance (or eyeball, or something) is a big dream of ours. Front-facing cameras on mobile devices excite us no end.

Props for linking to OpenGazer and Dasher. AEGIS is absolutely a terrific project, and I've been inspired by the work that Emli-Mari Nel and others are doing on exactly this problem.

Something to keep in mind when you're thinking about eye tracking for accessibility is how much custom hardware can greatly enhance the experience. Even if you're just mounting a webcam on a head bracket and removing the IR filter, some inexpensive work can really improve the user interface. (Of course, mounting a camera on your face isn't necessarily conducive to unbiased usability testing!)

One of my greatest hopes, personally, is that our approach to webcam-based eye tracking will yield algorithms and methods that we can give back to the community. Eye tracking has its shortcomings, to be sure, but the potential benefit is too great to be ignored.

Looks like you beat us to the punch with the article!

Questions and comments are welcome. Thanks everyone!

I just finished my thesis about cellular automata. Specifically, I worked on the automatic verification of logical formulas about the behavior of a given automaton.

Here's what that means. Suppose that you have some cellular automaton p, and you're interested in knowing whether p returns to its original state when you run it for a while. For finite grids and specific opening patterns this is an easy question to answer -- in theory -- you just simulate the automaton for long enough. But what about infinite grids? Or what if we wanted to answer a question like "does there exist a configuration of p which returns to its original state after 3 steps?" Or what if the automaton is just too big and too complicated to simulate for a long period of time? The majority of my work was in implementing a way of answering questions such as these (link for the really, really interested reader: http://carnegie-mellon.academia.edu/documents/0107/1998/thes...).

Cellular automata are surprisingly deep, for how simple they are. However, they aren't "a new kind of science" - like most constructs in computer science they are amenable to mathematical treatment.

If you already know a fair amount about CA, here's another good question for you to think about. How can we better classify different types of cellular automata based on their behavior? The usual classification system essentially boils down to choosing one of "it is obvious what this CA does", "you can prove what it does", "you can sort of guess what it does", and "no one has any idea so maybe this is universal". This is clearly unsatisfactory -- any suggestions?

What about Larry Page and Sergey Brin? Or Steve Jobs and Steve Wozniak?

Motivation, more workers, and new ideas are all valuable contributions, but I feel like you might have missed the biggest benefit of all.

Co-founders can be good at the things you, personally, can't do. This is most visible in the business/technical co-founder division, but it can generalize to all kinds of tasks. If you're terrific at engineering large-scale filesystems (or whatever), but you can't build a web interface (or whatever), you might really need a technical co-founder with a different skill set. Every day or so, my co-founder cranks out something that would have taken me a week or more in a few hours.

Don't underestimate the value of teaming up with someone who's as good as you are at different things!

What I really enjoyed about this article was hearing how difficult his experience really was -- and you can tell he A) actually knows what he's talking about and B) is still understating the difficulty. I've always assumed that I would "know how to survive off the land" -- my outdoor self-confidence pretty much comes from time backpacking in the Scouts as a kid, and from reading a lot of Heinlein. And I have power tool experience, and I can do physical labor. How hard could it be?

So at the beginning of the article, I was thinking "this seems incredible, I would love to do something like that." In the middle, I was beginning to appreciate how horribly difficult and unpleasant it would actually be. And by the end, I was realizing that if I absolutely had to live off the land on my own, without society to bail me out, I would almost certainly screw something up and starve. I think almost all of us would.

Anyway, you might have already known that. But for some reason this article hit just the right note to make me aware of the arrogance I've always had about how hard surviving via subsistence farming would really be. I'm going to go eat some cereal now and get back to work on the startup in the morning.

Terrific stuff, you can do a lot with OpenCV right out of the box. The Python bindings are pretty poorly documented, though (they change a lot). As much as I'd rather write Python than C++, if you're not already familiar with OpenCV it can be a lot easier to learn with the C++ version. There's a great introduction and API rooted here: http://opencv.willowgarage.com/documentation/cpp/index.html

Shameless self-promotion: If you're interested in face / eye tracking, email me or keep tabs on http://www.gazehawk.com.

I definitely agree with the argument that historical perspective is important - but I think the author's pessimistic assessment of the American public school system, and its approach, is inaccurate.

For example, he references a poll by Strategic Vision LLC that purports to show the ignorance of students in Oklahoma - the poll in question was pretty thoroughly debunked here, three weeks before the blog post was published:

http://www.fivethirtyeight.com/2009/11/real-oklahoma-student...