wildanimal

But if you look at Emacs-as-IDE route taken by EDE/CEDET suite, it's a kludgy beast... (I don't know how large the EDE/CEDET user community is, but most people I know forsake it in favor of the simpler facilities in Emacs).

I thought the plan was to rebase in Guile Scheme?

Can you get it through a host like sourceforge/github, or through a package manager like macports/homebrew? I can only find a zipped file on the web...

The original statement could be interpreted in this way: the former operation 'returns a function' and in the latter, it 'bind[s] [...] arguments' - suggesting a form of destructive updating of the original function. But I agree with you that in this context, since both return functions it's an implementation detail.

I wouldn't discourage them uniquivocally - for instance, 'subset' is an idiom often used in the context of data/relational tables. That matters a little bit (enough to pay a little penalty in raw performance), I would think.

I couldn't tell from the first chapter, but are there a lot of equations? If so, would be a big plus for me.

How is this better than attaching data to objects and operating on them with its methods? (Seriously, I would like to know). The syntax does not look all that different and with classes you can additionally have inheritance by which you can "get" a lot of relevant methods for free...

That sounds great -- I only recently learned of pandas (I normally don't use much of NumPy/SciPy), but I will keep an eye out on this.

I entirely agree though my personal preference is for lattice over ggplot as it is faster and more flexible at the present time (the "limitations" of ggplot reflect the preference of the creator; e.g. not being able to have two axes for the same plot). But reshape and also plyr are quite useful.

R does have surprising capability for shell scripting and text processing, albeit slower than Python. I also use Python for the rapid text-processing necessary (possibly populating an SQL database) for R to eventually use.

I've been keeping an eye on SciPy, but there still seems to be a lot of "the source code is the documentation", whereas in R the documentation is usually superb and well-structured. And Matplotlib, while beautiful, seems to be more verbose than Matlab or R when it comes to customizing details of the graphics (e.g., axes, etc.). That's just my impression, but I wouldn't mind being shown otherwise.

can use virtualbox+windows. not ideal, but one way.

Agreed -- the author of the post is talking about writing or debugging algorithms; coding is the stuff you need your computer for.

When I tried to use easy_install with the EPD it tried to take me to their repository, for which we don't have appropriate permissions? So I sucked it up and installed some from .dmg's and others from source (matplotlib was difficult). And I found out just because it's Python doesn't mean it's portable - for instance NumPy/SciPy is hardly ever installed on other machines (it's not trivial, as is written here many times), and I find that administrators won't update their Python installation so I've had to re-write bits of my code to accommodate Python 2.3-2.4 at times! But all said, it's a nice tool and hopefully these installation/ version issues will work itself out.

Agreed. I use Python for heavy shell-scripting and text-processing (though R surprisingly does have respectable facilities for all but the most overwhelming of these tasks) and R for the rest of the analysis. I've thought about switching to NumPy/SciPy as it's part of Python to integrate everything, but R's data frame, factors, and reshape, plyr, and lattice packages makes you think very differently about how to approach the data - and hard to go back to lower-level manipulation of arrays; not to mention all the stats/graphics packages which are very easy to install and apply. And documentation of its functions is superb.

I see - yes, most of the masters whose .emacs.d file I've had the privilege to look have been from the old guard.

Sorry, meant "from my limited observation it seems that everyone"... but what you suggest makes sense.

I wonder why everyone writes out the function invocations to add each directory they're adding, rather than doing something like

(labels ((add-path (p) (add-to-list 'load-path (path-join emacs-root p)))) (let ((paths '("foo" "bar"))) (mapc 'add-path paths)))

Is there an advantage to writing it out?

When do you decide to use some directory like ~/emacs or ~/elisp or whatever instead of your ~/.emacs.d/ directory for your packages? A lot of emacs sites say to use ~/.emacs.d, but then I see a lot of masters putting them in a directory of their choosing...

Google apparently runs R on desktops (http://dataspora.com/blog/predictive-analytics-using-r/) and ports it to Python or C++ once their ideas are tested (for production code). Having said that if your list of functions are growing, try packaging up in a library - there are many tutorials available on the web. If your data is becoming big, try using RHIPE (Hadoop integration), bigmemory, snow, or a number of other packages: http://cran.r-project.org/web/views/HighPerformanceComputing...

You can check out the lattice, ggplot2, scatterplot3d and rgl libraries to see how R handles multivariate data - R is especially well suited for analyzing panel (longitudinal) data with multiple variables.

S-PLUS objects reside on the hard drive whereas R's are stored entirely in memory. So R is faster for smaller computations but runs against limitations when the data sets are large, though you can use the bigmemory library or store your data in external databases - e.g., SQLite or PostgreSQL and pull off chunks as you need them. R also had a much more extensive library but I heard that S-PLUS (as of version 8) made their program compatible with R so that R's libraries could be used in S-PLUS. Also, R has lexical scoping; I think S-PLUS only has global and local like Matlab. I personally like lexical scoping so can't think of cases when you'd find S-PLUS's scope definition advantageous.

I'm having the same problem. R is slow; yet R's plyr, reshape, and lattice packages are indispensable (ggplot2 wasn't quite mature enough when I wanted to learn it). Maybe something could be written around record/structured arrays. (I'm halfway inclined to try...)