miloshasan

These claims are false. We can get savings on a small number of "low-hanging fruit" problems, which are easy to approximate on practical instances - bin packing with many small items, scheduling with many short jobs, 2D Euclidean Hamiltonian cycles. What about, for example, the learning applications that Fortnow mentions? Try your C-PLEX on the problem "find the minimal size circuit that explains this big set of observations". You will not get anywhere. There are many other examples.

It makes sense for the industry to concentrate on making a buck out of the easy instances, and leaving the hard stuff to the academics. However, that is different from claiming that hard instances don't exist.

Umm... I thought it was a pretty good introductory article, listing well-known and uncontroversial stuff. Yes, a polynomial algorithm might not be actually practical. Everybody knows this, and pointing it out every time P=NP comes up is bordering on cliche. Yes, NP-hard combinatorial optimization problems can have easy instances in practice. Why is that a reason for outrage?

If an idea saves you a month of work, its value is exactly equal to the value of a month of work, right?

From what I could tell, the links you posted are no evidence to the contrary.

First, child abuse is beyond what most would call "parenting"; that term is mostly applied to things like strictness with respect to school homework, video games, pressure to choose certain careers, etc. My argument was that those of us that care about giving their children the best should not sweat too much over where precisely to draw the lines, because the effect of these decisions on the child's personality and life outcome is minimal.

Second, it is very possible that the same genes that increase the chance of a person being a child abuser also increase the chance of their child being, say, an alcoholic or criminal.

The author points out something he may not have even intended: that parenting might not matter at all, despite the raging discussions about which parenting style is better.

In fact, lots of research on twins and adopted children suggests that parenting matters very little in shaping a child's personality and skills, while biology and peer groups matter a lot. Identical twins turn out quite similar regardless of whether they grow up in the same family, while adopted siblings are as different as any random people. (Check "How the Mind Works" by Pinker for a great overview.) People have a hard time accepting this, since most would like to believe that they have a power to shape their children, but this does not make it any less true.

> the Immigration Act of 1965... didn't just abolish racial quotas, it also created preference categories for science, math and engineering-trained immigrants to come over.

Ah, so Asian immigrants to the US are far from an unbiased sample of their original populations! This explains a lot more than bitter fights over parenting.

You are comparing top startups to mediocre Ph.D.'s. Top academia is very high-risk and very competitive. You take on very difficult research problems in the hope of becoming famous (but you may never be able to solve them). The rewards are accordingly high - having a large impact on the world, getting tenure to do what you love for the rest of your life, being surrounded by the best people in your field.

The premise that Ph.D. degrees are supposed to be mainly training for academic careers is wrong, at least in technical/engineering fields.

It is very common for people to enter e.g. CS or EE programs with no intention of pursuing an academic career, and instead planning to find an industry job afterwards. Indeed, there were some people I met in grad school that left well-paying jobs at (say) Microsoft with the intention of getting a Ph.D. and going back to industry to work on more interesting stuff. As far as I know, they usually succeeded.

Does a Ph.D. increase your expected salary, if you get an industry job afterwards? Probably not enough to be worth it. Does it raise the level of problems you will be solving, and the quality of people you will be surrounded with? Absolutely.

I would expect that an oversupply of lawyers would make them cheaper to hire and nicer to deal with. If we instead have a small group of lawyers that are expensive and unpleasant, while a lot of younger graduates cannot find jobs, I'd expect there must be some powerful artificial barriers of entry created by the group of insiders, though I have no idea what they could be...

Of course... read my reply again please.

I am not disagreeing with you, I am saying that I would love to see a better data-parallel language than C (or CUDA to be precise), but it does not exist right now (at least not a practical one that would run on a real GPU with reasonable performance and allow non-trivial nested and hierarchical algorithms).

> It would make a lot of sense to have something like StarLisp or APL for CUDA right now. Trying to do data parallelism in C is about the most brain-damaged idea ever. I don't know if anyone is working or interested in that, though.

You may well be right, but I challenge you to prove it. I myself am very interested in whether this would work. I have spent many sleepless nights programming GPU algorithms, and wondered if ideas from other programming languages and paradigms (especially functional programming) could be applied to make it easier and more elegant.

The nested data-parallelism approach does look promising on paper, and many people are well aware of the theoretical possibility of this working on GPUs (including people at Nvidia itself), but so far nobody succeeded to make it practical.

So, doing data parallelism in CUDA may be brain-damaged, but the flexibility and performance it delivers is mind-blowing. If you can achieve something comparable using a higher-level functional approach, I will be among your first users, and I'll tell everyone I know.

MultiLisp (AFAIK) is traditional task-parallelism rather than data-parallelism, and would not work well on a GPU.

I suspect that the inability to bring down power isn't just "laziness" on Intel's part. Decreasing power consumption is (more or less) equivalent to increasing performance per watt - an area where Nvidia and ARM designs may simply be better.

Ah, OK... I thought he was comparing more "CPU-like" to "GPU-like" designs, rather than CISC to RISC.

The article does not contain the word "CISC"...

You'd be surprised how many people walk around with terrible vision, without knowing it. My guess is that computer-related jobs require good vision, so people in these jobs are more likely to discover and treat their vision problems.

Python is awfully close to being a superior (and free) replacement for Matlab, but there are a few annoyances that keep preventing me from switching forever. Unfortunately, these are mostly not bugs but bad design that is believed to be correct by the core developers, so it is unlikely to ever change:

- Matrices are a pain. The r_[] and c_[] operators could be a reasonable replacement for Matlab's elegant matrix construction syntax, but they do not work as expected (as smart hstack and vstack), instead doing something completely different and inconsistent for vectors and matrices.

- Tensors are a bigger pain. Matlab has a very well-defined semantics for operations like permute and reshape; in NumPy these operations sometimes create just a view, at other times they reshuffle the memory contents. I know the idea was to "protect" the user from having to know the memory layout of data, but this idea is bad.

- Ipython is great in every way except when it comes to reloading parts of your program. After any tiny change to your code, the only safe thing to do is to quit ipython and start it again. All the other options (run, reset, reload...) make some secret and wrong assumptions on what you want to reload. In contrast, this works flawlessly in Matlab.

So you're saying that the "language is a tool" metaphor breaks down because C is "complete" in a way that a hammer isn't. True, but that's taking the metaphor too far; it's original meaning is that the tool matters less than what you're building.

Well, describing oneself as a working programmer (as opposed to a computer scientist) is a valid position, but why does it invalidate the "programming language as tool" metaphor?

A basic message of CS is that most general-purpose programming languages are to a large extent isomorphic in their expressive power, and that many computing problems can be solved efficiently in the mathematical language of sets, matrices, or abstract nodes sending each other abstract messages. The translation to a real language is then the easier step (though it still can be time-consuming and error-prone, for sure).

If only we all worked this way - there would be fewer language wars, and less terrible code resulting from "thinking in the language" rather than "thinking about the problem".

Ah, yes - of course decorators do not fundamentally increase the expressive power of the language (and neither do lambdas, obviously). It's all just a matter of convenience and elegance, which are in the eye of the beholder anyway...

The decorator can do introspection on the function object. This project uses the idea to execute (some) Python code on the GPU:

http://code.google.com/p/copperhead/

Didn't downvote you, but the difference is that lambdas can only be executed (i.e. applied to something) while decorators let you analyze the code of the function and do something else other than just executing it.