aposteriori

Regarding who submitted it, PNAS works differently from other journals. Weissman is a member of the National Academy of Sciences, and as such he gets to contribute a paper X times a year. It still gets peer reviewed. The question of how well things are reviewed applies to other journals as well.

Fink/ports work enough, but like I said it doesn't integrate with the OS like on Debian/Ubuntu. I've already mentioned the issue of clashing versions (gcc from Fink vs from Apple, etc.)

But OS X is nice, if only Ubuntu and Linux in general had the drivers, the overall polish, better menus (System Preferences on OS X are nice, on gnome they are a dog's breakfast) and dropped the ugly brown theme...

I think I'll stick to Mac laptops and Linux desktops and enjoy the best of both worlds :)

Thanks, wasn't aware of this name.

Let's not forget that it's only the expected return, i.e., the return as the number of trials goes to infinity. But, you don't have infinite money to spend, so there's a good chance you'll go broke before you win (depending on the variance). Another way of looking at it, it's a random walk with a bottom barrier --- once it hits zero, you're out of the game.

I've been a long time Linux user and recently got a macbook, partly because it just works and I don't have to read 1001 web forums trying to decide whether the specific NVidia chipset is compatible with the latest Xorg driver.

So it's really easy to set up and easy to use, once you get used to the oddities (command Q...). It's basically a BSD, so you get Bash and Python and gcc and Vim etc.

However, I'm starting to discover while it is Unix, it's got its problems. On Ubuntu, everything is just an apt-get away. I can check out bug reports on launchpad and get unstable fixes, and not have to wait for an update from the Apple gods. On OSX, you need to use fink or darwinports, which isn't integrated with the OS (anyone said Apple gcc vs fink gcc?). Apple just likes doing things its own way, like rewriting config files for you (even though you edited them manually), having obscure config options (.MacOSX/environment.plist???).

So as much as I enjoy the interface, I think my next machine will be some sort of Thinkpad + Ubuntu, for all that brown themed ugliness :)

(oh, and I swear the white macbook scratches and scuffs the second you take it out of the box, get a black one or a pro.)

I think that's true of all technical books. Before I part with my hard earned money on some technical tome, I ask myself whether it's a classic (Knuth springs to mind, K&R C), or at least I'll get some value out of it for the next few years. Otherwise, there's tons of good online resources that don't require you to kill a tree.

Some people say double-blind reviews make things better since reviewers aren't (theoretically) influenced by the identity of the authors, and authors can't tailor their paper to suit the reviewers (or try to get back at them later for negative reviews).

How about completely open reviewing, like in some of the BiomedCentral medical journals (e.g., http://www.biomedcentral.com/bmcmed)?

If done properly, all the cards are on the table. A paper cannot (should not) be rejected or accepted without legitimate reasons. Reviewers and authors can be made to account (through tarnished reputation and risk of embarrassment, at least) for their actions.

As earl said, it's free! But that's not the most important aspect (although nice for a student).

It's an actual programming language. Like Python, you can use both non-OOP and OOP styles. You can define your own packages and namespaces (unlike MATLAB where there's just one big namespace). There are hundreds of contributed packages, you don't need to buy separate toolboxes. Not to forget, it's GPL, you can look at the source and learn a few things from people who know what they're doing (to name a few: Brian Ripley, Terry Therneau, Douglas Bates, Bill Venables).

On the other hand, it can be a bit of a steep learning curve at the beginning, but I feel it's definitely worth it. It's not perfect, I stub my toe on obscure language features from time to time, but to paraphrase Winston Churchill, R is the worst form of statistical languages except all those other forms that have been tried from time to time...

I think that Andrew Robinson's introduction is pretty decent (http://cran.r-project.org/doc/contrib/Robinson-icebreaker.pd...), but there are many others at http://cran.r-project.org/other-docs.html

Well, I don't how NumPy can be significantly faster than R, as R basically passes most linear algebra down to BLAS and LAPACK. NumPy does the same, no?

R is not at all like Excel, in form or function. R is actually a complete programming language, much more similar to Python in that respect. It supports two types of OOP (S3 and S4), has hundreds (if not more) of contributed packages that do things like survival analysis, 2D/3D plotting, bioinformatics, machine learning, Bayesian statistics, econometrics, numerical integration, spatial statistics, and more (http://cran.r-project.org/web/packages/)

One major advantage over Python is that it's vectorised, so you can say things like A + 1 when A is a vector (or matrix). A bit like Matlab in that regard, only that it doesn't suck as much as the Matlab ``language''.