> the main advantage it has over SPSS-like software is that you do not > need to explicitly create dummy variables. You only need to specify > your dependent variable and independent variables and R will fit it > (and create dummy variables automatically) for you.Does the audience know exactly what the creation of dummy variables in SPSS is and means? If not, they might consider this geek talk. Why don't you just go for a concrete example?: Show an SPSS operation sequence and the equivalent R expressions side-by-side. No need to explain much, then. Lutz
Hi Kevin,
I think your \begin{quote}...\end{quote} block covers it nicely. Some
generic remarks to consider:
* If the presenter is using slides, distill the description into 1 slide
(for the 1-2 minutes).
* Of course Edward Tufte would not approve, but I think three main bullet
points are useful, with some sub-items that could be explicit or described
verbally:
* R is free (as in beer, wine, etc.)
* There is a strong, growing R community
* Useful documentation, and
* Help is always a sincere, intelligent email posting away
* (Choose an authentic example, such as what you described with the
SPSS dummy coding)
By "authentic", I mean something you feel much of the audience will
relate
to. That could be specific to data analysis and/or interpretation in
Finance, or just a more convenient/efficient way to do tedious tasks, like
good computer software should do. The "plot" example I just now see
cited
by Barry Rowlingson is a good one, I think.
The first two items derive from the principle of open source software, and
it could be pointed out that the Earth now has several examples of where the
open-source model has been indisputably successful, based on the facts. And
such examples are not just for "geeks" anymore; note for example
OpenOffice
and KDE.
Hope that helps and good luck,
Bill
----------------------------------------
Bill Pikounis, Ph.D.
Biometrics Research Department
Merck Research Laboratories
PO Box 2000, MailDrop RY33-300
126 E. Lincoln Avenue
Rahway, New Jersey 07065-0900
USA
Phone: 732 594 3913
Fax: 732 594 1565
> -----Original Message-----
> From: r-help-bounces at stat.math.ethz.ch
> [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of
> Ko-Kang Kevin Wang
> Sent: Friday, June 04, 2004 7:51 AM
> To: r-help at stat.math.ethz.ch
> Subject: [R] How to Describe R to Finance People
>
>
> Hi,
>
> I've been doing a joint research with someone from the Property
> Department here and she is about to give a presentation on the
> results. The audience will include people from Property and Finance,
> and she is wondering how to describe R to these people (as I used R to
> do the analyses), since she has never even heard of R before our joint
> research (and has been using SPSS). The difficult part is she has
> only about 1 ~ 2 minutes to talk about R.
>
> The following is what I have in mind, any suggestions from people in
> Finance will be greatly appreciated! (From our research together I
> think it may be safe to assume the audience will know, or at least
> have heard of, basic statistical terminology such as multiple linear
> regression and dummy variables).
>
> \begin{quote}
> R was originally developed by Dr. Ross Ihaka and Dr. Robert Gentleman
> from the Department of Statistics at the University of Auckland in
> 1992. It is free and in the last decade it has evolved into one of
> the most powerful statistical software, with over 150 user-contributed
> add-on packages. It is not only used by statisticians or scientists,
> but also econometricians and people in finance due to its cost (FREE)
> and its powerfulness.
>
> Although it has a slightly higher learning curve than SPSS-like
> program, it gets easier to use once one is familiar with it. One of
> the main advantage it has over SPSS-like software is that you do not
> need to explicitly create dummy variables. You only need to specify
> your dependent variable and independent variables and R will fit it
> (and create dummy variables automatically) for you.
>
> It also has many state-of-art free resources, including manuals,
> contributed tutorials and documentations, online. A free mailing list
> is also available for people to ask questions and questions are
> usually answered by more experienced users around the world within a
> few hours (sometimes even within minutes).
> \end{quote}
>
> As mentioned above, she was rather impressed when I mention that one
> does not need to create dummy variables in R. Therefore I am thinking
> she might be interested in mentioning it in her talk.
>
> I have never had experience of trying to introduce R to
> non-Scientists, hence I would appreciate any comments!
>
> Cheers,
>
> Kevin
>
> --------------------------------------------
> Ko-Kang Kevin Wang, MSc(Hon)
> SLC Stats Workshops Co-ordinator
> The University of Auckland
> New Zealand
>
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide!
> http://www.R-project.org/posting-guide.html
>
>
well, it depends on who you call finance people. i am a finance professor, and i use R for my own work these days. two of my colleagues are using S on occasion, S being "close enough" IMHO. how about students? I am also writing an introductory finance text book, which is currently freely available from my website (http://welch.som.yale.edu/book/). all the figures will eventually be done in R (at the moment, some are still in gnuplot), the book will say so, and i will provide the code for it. the statistical analysis is done in R, but much of it is not shown (it is just an intro text book). hopefully, this will get more finance students asking "what is this program? how can i use it? etc." but R has also huge drawbacks. most importantly, there is no good *current* textbook for an intro R user. that is, not for the fancy statistical techniques, but lots about data manipulation, plots, linear regression, heteroskedasticity and related (white-like) corrections, programming, "cookbook" (ala perl cookbook---more about the simple stuff: how to delete or insert a row, how to delete or insert a column, typical problems, especially when doing IO). so, honestly, i cannot recommend R to my finance students right now. this mailing list---wonderful as it is [though sometimes "grumpy"]---cannot be a substitute for such an intro R textbook. i cannot ask 300 students to use it as their support hotline. i am afraid that if R becomes more successful, this mailing list will be overwhelmed. the 10-30 people in the know who donate their time to help here just cannot do it. we definitely do need this R textbook. and, though I love the first parts of Ripley&Venables, they want it to be a "stats book in R", not a book about R. (witness brian ripley's annoyed reaction everytime i tried to suggest elaborations on the first part, or them writing another book.) one more big problem: the name "R". I cannot easily specify to do a comprehensive google search on subject matter "insert and R". A single letter like R just does not connect well with google. this is of course steeped in too much history, but a name change would help---calling it some random 6-letter combination. regards, /ivo welch
On Sat, 05 Jun 2004 10:11:18 -0400, ivo welch <ivo.welch at yale.edu> wrote:>one more big problem: the name "R". I cannot easily specify to do a >comprehensive google search on subject matter "insert and R". A single >letter like R just does not connect well with google.I just did a search for the string "insert and R", and it was indeed useless. However, "R and insert" came up with 4 relevant hits in the first 10 and the usual warning about using "and"; when I leave it out and type "R insert" I got up to 6 relevant hits out of 10. So I think the name R is not so bad, but Google is a little more subtle in its searches than I would have guessed. Duncan Murdoch
Tamas Papp <tpapp at axelero.hu> wrote:
I would emphasize the following:
...
2. The programming language is really friendly and convenient to work
with. In finance, you often need to hack together special solutions
for problems that are not conventional (especially in term structure
models, but I think that the same applies to bi- and trinomial models
and their ilk). As an R newbie, it took me an afternoon to implement
a basic toolkit for the former, which I could use for interesting
explorations.
There are three perspectives on programming languages like the S/R family:
(1) The programming language perspective.
I am sorry to tell you that the only excuse for R is S.
R is *weird*. It combines error-prone C-like syntax with data structures
that are APL-like but not sufficiently* APL-like to have behaviour that
is easy to reason about. The scope rules (certainly the scope rules for
S) were obviously designed by someone who had a fanatical hatred of
compilers and wanted to ensure that the language could never be usefully
compiled. Thanks to 'with' the R scope rules are little better.
The
fact that (object)$name returns NULL instead of reporting an error when
the object doesn't _have_ a $name property means that errors can be
delayed to the point where debugging is harder than it needs to be.
The existence of two largely unrelated object-oriented extensions
further complicates the language.
APL, Xerox's Interactive Data-analysis Language (an extension of
Interlisp), and Lisp-Stat are *far* cleaner as programming languages.
(2) The Excel perspective.
Many people are using Excel as their statistics package.
(One of my students persists in using it for making his graphs.
I've talked another lecturer and his student into using R although
it's too late for a paper they've published. Dark backgrounds for
printed graphs don't work well. What persuaded them was a number
of relevant things available out-of-the-box in R.)
In Excel, there are at least three "languages":
- direct manipulation
- the formula language
- Visual Basic for Applications
What R offers is a *single* language that's used uniformly,
with a rich data model.
(3) The statistics package perspective.
I've used Minitab, GLIM, SPSS, Matlab, and Octave (and BASIS, if
anyone remembers that). I've owned and read manuals for GENSTAT.
Recently I had occasion to look at more SAS code than I ever wish to.
(No, I didn't understand it.) Several of these packages share a
common design feature: there is a language of built-in commands,
perhaps a data transformation language, and a separate macro language.
The macro language is typically very clumsy.
What R offers is a *single* language that's used uniformly,
with a rich data model. Analysis components you get off CRAN are
accessed using the *same* syntax as 'built-in' analyses.
R also offers something important for people who _do_ have the money
to buy commercial packages, and who might be reluctant to trust open
source: a very high degree of compatibility with an established
commercial product. R could almost be seen as an indefinite lifetime
'evaluation' version of S-Plus.
The fact that I can use 'contributed' code, or even my own code, exactly
the same way as 'built-in' stuff, even including access to on-line
documentation and examples, actually *improves* the learning curve for R
compared with many packages. At least it did for me.
In the words of an old Listerine commercial: 'I hate it. Twice a day.'
I wrote:
> The scope rules (certainly the scope rules for S) were obviously
> designed by someone who had a fanatical hatred of compilers and
> wanted to ensure that the language could never be usefully
> compiled.
Drat! I forgot the semi-smiley!
Tony Plate <tplate at blackmesacapital.com> wrote:
What in particular about the scope rules for S makes it tough
for compilers? The scope for ordinary variables seems pretty
straightforward -- either local or in one of several global
locations.
One of *several* global locations.
attach() is the big one.
I spent a couple of months trying to design a compiler that would
respect all the statements about variable access in "The (New) S
Programming Language" book.
(Or are you referring to the feature of the get()
function that it can access variables in any frame?)
That's part of it too. Worse still is that you can create and
delete variables dynamically in any frame. (Based on my reading of
the blue book, not on experiments with an S system.) And on one
fairly natural reading of the blue book,
f <- function (x) {
z <- y "this is a global reference"
y <- z + 1
g()
y/z "this is a local reference"
}
whether a reference inside a function is local or global would be
a dynamic* property even if the function g() couldn't zap the local
definition of y.
R has its own problems, like the fact than with(thingy, expression)
introduces local variables and you don't know WHICH local variables
until you look at the run-time value of thingy. Actual transcript:
> z <- 12
> f <- function (d) with(d, z)
> f(list())
[1] 12
> f(list(z=27))
[1] 27
Is that reference to z a reference to the global z or to a local copy
of d$z? We don't know until we find out whether d *has* a $z property.
How are you supposed to compile a language where you don't know which
variable references are global and which are local?
(Answer: it can be done, but it ain't pretty!)
In this trivial example, it's obvious that the intent is for z to come
from d, but (a) it isn't an error if it doesn't and (b) realistic
examples
have more variables, some of which are often visible without 'with'.