tag:blogger.com,1999:blog-1959142971479045512024-02-20T12:40:56.620-08:00The Foundations of StatisticsThis blog is intended to be a public forum for the textbook:
<a href="http://www.ling.uni-potsdam.de/~vasishth/book.html">Shravan Vasishth and Michael Broe. The Foundations of Statistics: A Simulation-based Approach. Springer, 2010. ISBN: 978-3-642-16312-8</a>.Shravan Vasishthhttp://www.blogger.com/profile/13453158922142934436noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-195914297147904551.post-52101515315890792532012-10-20T02:49:00.001-07:002012-10-20T02:49:42.130-07:00Lecture notes up<div dir="ltr" style="text-align: left;" trbidi="on">
I put up some lecture notes that I use in my statistics course. Usually in one semester I only manage notes 2-4 (over 15 90 minute meetings).<br />
<br />
They are located <a href="http://www.ling.uni-potsdam.de/~vasishth/VasishthBroeLectureNotes.zip">here</a>.</div>
Shravan Vasishthhttp://www.blogger.com/profile/05926656325558456592noreply@blogger.com1tag:blogger.com,1999:blog-195914297147904551.post-26343354131807728312011-10-31T07:27:00.000-07:002011-10-31T07:27:45.245-07:00Corrected pages in bookI've added a zip archive of corrected pages, where I corrected some of the errors that were pointed out to me by Christian Robert. You can access it here:<br />
<br />
<a href="http://www.ling.uni-potsdam.de/~vasishth/CorrectedPages.zip">http://www.ling.uni-potsdam.de/~vasishth/CorrectedPages.zip</a><br />
<br />
Some of the changes Christian suggests require rewriting parts of the text; I've started doing that, but publishing the whole book again will have to wait until the next corrected edition can come out (say the publishers---apparently they have to wait till the existing copies are sold). Until the corrected edition appears, I will keep updating this blog and the book's home page with corrections.<br />
<br />
Please tell me if you find more problems in the text.Shravan Vasishthhttp://www.blogger.com/profile/13453158922142934436noreply@blogger.com0tag:blogger.com,1999:blog-195914297147904551.post-8475928736473229472011-09-01T01:50:00.000-07:002011-09-01T01:54:58.311-07:00Lower p-values apparently give you more confidence in the alternative hypothesis<br />
<div class="p1">
"But an isolated finding, especially when embodied in a 2 X 2 design, at the .05 level or even the .01 level was frequently judged not sufficiently impressive to warrant archival publication." (p. 554)</div>
<div class="p1">
From: Melton, A. W. (1962). Editorial. <i>Journal of Experimental Psychology, 64, </i>553–557.</div>
<div class="p1">
</div>
<div class="p1">
<br /></div>
<div class="p1">
According to Gigerenzer et al (Published in: D. Kaplan (Ed.). (2004). <i>The Sage handbook of quantitative methodology for the social sciences </i>(pp. 391–408)), this quote is where the common convention comes from to use p-values as a measure of one's belief in a result.</div>
<div class="p1">
<br /></div>
<div class="p1">
Gigerenzer et al write: </div>
<div class="p1">
<br /></div>
<div class="p1">
"Editors of major journals such as A. W. Melton (1962) made null hypothesis testing a necessary</div>
<div class="p1">
condition for the acceptance of papers and made small <i>p</i>-values the hallmark of excellent</div>
<div class="p1">
experimentation."</div>
<br />Shravan Vasishthhttp://www.blogger.com/profile/13453158922142934436noreply@blogger.com0tag:blogger.com,1999:blog-195914297147904551.post-75525515259113134672011-07-17T09:12:00.001-07:002011-07-17T09:12:08.048-07:00Useful website for people interested in data analysis<span class="Apple-style-span" style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18px;">Here's a revolutionary website: all data and code accompanying papers.<br />
<br />
http://read.psych.uni-potsdam.de/pmr2/<br />
<br />
Imagine if it was mandatory to release data with your publication! It would make life so much easier.</span>Shravan Vasishthhttp://www.blogger.com/profile/13453158922142934436noreply@blogger.com1tag:blogger.com,1999:blog-195914297147904551.post-2740977315030052352011-07-16T09:30:00.000-07:002011-08-15T12:45:45.951-07:00Is this book for you?<span class="Apple-style-span" style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;">Here is a simple test to decide whether this book is aimed at your current ability level:<br />
<br />
<quote><i>Define odds as: odds=p/(1-p). Can you define p in terms of odds?</i> </quote></span><br />
<div><span class="Apple-style-span" style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><br />
</span></div><div><span class="Apple-style-span" style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><quote>If you couldn't solve it, don't feel dejected. That's a problem that can be fixed, and besides, I know a lot of people who are in the same boat as you. Our book is not designed to fix this problem (that would require more contact with mathematics, which is up to you), but our book </quote></span><span class="Apple-style-span" style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><i>is</i> designed to teach a little bit to people who're at this level.</span><br />
<span class="Apple-style-span" style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><br />
</span><br />
<span class="Apple-style-span" style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;">PS You may benefit from the book even if you could solve the above problem. Just take a look and decide for yourself.</span></div>Shravan Vasishthhttp://www.blogger.com/profile/13453158922142934436noreply@blogger.com0tag:blogger.com,1999:blog-195914297147904551.post-40160725478669988822011-07-13T13:54:00.000-07:002011-07-13T13:54:55.112-07:00ErrataThe semester is finally over, and I've started working on an errata for the book.<div><br />
</div><div>Here is the current list of errors (I'll update it as I get time): </div><div><br />
</div><div><a href="http://www.ling.uni-potsdam.de/ErrataVasishthBroe.pdf">http://www.ling.uni-potsdam.de/ErrataVasishthBroe.pdf</a></div><div><br />
</div><div>Please send me email if you find any other errors (including errors in the errata ;).</div>Shravan Vasishthhttp://www.blogger.com/profile/13453158922142934436noreply@blogger.com0tag:blogger.com,1999:blog-195914297147904551.post-84210483280095775892010-12-28T22:39:00.000-08:002010-12-28T22:39:04.388-08:00How to do Maximum Likelihood Estimation by hand<a href="http://www.johnmyleswhite.com/notebook/2010/04/21/doing-maximum-likelihood-estimation-by-hand-in-r/">http://www.johnmyleswhite.com/notebook/2010/04/21/doing-maximum-likelihood-estimation-by-hand-in-r/</a>Shravan Vasishthhttp://www.blogger.com/profile/13453158922142934436noreply@blogger.com0tag:blogger.com,1999:blog-195914297147904551.post-18863142316109484092010-12-09T11:54:00.000-08:002010-12-09T11:54:10.580-08:00The book is outYou can <a href="http://www.springerlink.com/content/978-3-642-16312-8#section=811438&page=1">read it online</a>.Shravan Vasishthhttp://www.blogger.com/profile/13453158922142934436noreply@blogger.com0tag:blogger.com,1999:blog-195914297147904551.post-48607330632488127282010-10-04T03:11:00.000-07:002010-10-04T22:29:11.814-07:00On fearlessnessOne of the first problems I encounter when teaching from this book is fear. So I'd like to inaugurate this blog with a comment which may serve as an antidote.<br />
<div><br />
</div><div>Here is an excerpt from a very useful email that a former colleague of mine wrote to a beginning programmer. The advice here will be useful to people who want to use our book but are afraid to because they have never programmed before, or are afraid of the idea of doing `computer programming.'<br />
<div><br />
How to become self-sufficient with everyday computing issues<br />
<br />
The author is a colleague who shall remain anonymous<br />
(Note: I made up the title) <br />
<br />
In my experience, both first and second hand, solving practical<br />
programming issues requires some combination of one or more of the<br />
following:<br />
<br />
1. "can do" attitude;<br />
2. tenacity;<br />
3. experience from reading existing programs;<br />
4. experience from programming;<br />
5. experience from reasoning about programs;<br />
6. domain knowledge about programming task (protocols, specifications). <br />
<br />
None of these can really be taught, except for the last one. You might<br />
get more experienced from taking a course and doing the assignments.<br />
<br />
It's a vicious circle: you need experience to write programs, but<br />
you'll only get it by writing programs. At some point you'll just<br />
have to make a decision that you can do it, and then get started by<br />
writing programs. There are many good books that you can read,<br />
depending on what exactly you want to learn. You can't go terribly<br />
wrong by reading anything published by O'Reilly (even the comic<br />
books). Avoid the "For Dummies" books unless they are written by John<br />
Levine, who has written at least one O'Reilly book. There is also<br />
very good on-line documentation available. For example, the user's<br />
guide for GNU Awk is perhaps the best book on Awk ever. If you want<br />
to learn C, do not under any circumstances read Kernighan & Ritchie;<br />
for C++, do not read Stroustrup.<br />
<br />
Do not expect any quick results. Programming is a craft that you have<br />
to practice. Depending on the language and task, it might take weeks,<br />
months, or years until you can write programs fluently without<br />
constantly pausing to consult documentation. And that's just for the<br />
syntax, semantics, idioms, and libraries for one language. So start<br />
with a small language. For text mangling, Awk is my first choice.<br />
It's a very small language and you'll outgrow it sooner or later.<br />
Scheme is a nice first general-purpose language, since it's small but<br />
can grow. Java, C++, Perl, Python are much bigger and come with<br />
extensive libraries, some of which you'd have to first know how to use<br />
in order to get anything done; avoid them for now, but start looking<br />
into Python when Awk is starting to get a bit tight under the arms.<br />
Avoid Perl, it's Pure Evil (or at least wait for version 6), as is the<br />
C-shell family. Avoid C++ whenever and wherever you can.<br />
<br />
Before you get started with anything, you have to pick your weapons<br />
carefully: what are your short-term and long-term goals? "Learning<br />
how to program" is a very vague concept that ranges from<br />
point-and-click assembly of components (Visual Basic) to spread sheets<br />
to shell scripts to writing C programs, and from hacking together a<br />
script that Does The Job to designing and documenting libraries and<br />
components. <br />
<br />
I'm assuming that you'll be writing mostly short programs that will be<br />
modified often and run only a few times. In that case you want<br />
simplicity. You want languages that hide the low-level details of the<br />
hardware from you as much as possible. So stick with sh, ksh, Awk,<br />
Python, Scheme, Caml, and Java. If you don't know Awk very well already,<br />
start with that. Find the documentation on Gawk (GNU Awk), called<br />
"Effective Awk Programming".<br />
<br />
That's part of another exercise: there is a *lot* of information<br />
available on the net, and plenty on your average Unix system,<br />
including ours. Find out how to use it. You have to be<br />
self-sufficient in that respect as much as possible, since you won't<br />
have the time to track down somebody who can help you nor can you<br />
afford to wait for email responses. Start with the documentation<br />
available via Emacs, the so-called "info" pages, in addition to the<br />
"man" pages. <br />
<br />
You have to be able to go from there on your own. Trial and error is<br />
another favorite strategy. I have a few "sandbox" directories whose sole<br />
purpose it is to be a safe spot where no important data reside and where I<br />
can try out and test things. Set aside plenty of time for this. This is<br />
not a nuisance, but an Important Step along The Way. Be prepared to set<br />
aside 4 hours or more for writing a 10-line script in the beginning. <br />
You'll be able to do it in 10 minutes later, but only if you know what<br />
you're doing. Play with it. Make sure you understand all its parts. <br />
Write documentation, in case you want to use it again and to make sure you<br />
know what everything is doing. Documentation is *part* of the program, it<br />
does not belong in lab notebooks etc. State assumptions clearly, e.g.,<br />
"expects input lines of the form <foo>:<bar>$" and write down what the<br />
program does.</div></div>Shravan Vasishthhttp://www.blogger.com/profile/13453158922142934436noreply@blogger.com0