I care about reproducible research. Anyone who has ever been a research assistant or tried to follow the path set by other researchers also cares. Sometimes, reproducing others’ results is a frustrating task; sometimes, it is outright impossible. Yet sometimes, it is satisfyingly simple. In my experience, reproducing results is easy when it involves a Stata do-file. I believe this is true even beyond my personal bias (I work for Stata and used the software regularly before that). A recent article published by the American Economic Association (AEA), Vilhuber, Turrito, and Welch (2020), shows that Stata is the preferred package among economists, and I believe reproducibility is a big reason why. Read more…
I saw a tweet the other day where someone claimed that StataCorp ensures that the dataset format in Stata X is always different from Stata X-1.
This reminded me of an email I wrote a few years ago to a user who had questions about backward compatibility and reproducibility. I’m going to use large parts of that email in this blog post to share my thoughts on those topics.
I understand the frustration of incompatibilities between software versions. While it may not ease the inevitable difficulties that arise, I would like to explain our efforts in this regard. Read more…
Automating common tasks is crucial to effective data analysis. Automation saves you lots of time from repeating the same sets of operations, and it reduces errors by reducing what you have to repeat.
Let’s automate something using Stata. The task we are automating doesn’t much matter. What matters is that we get comfortable with how to automate tasks.
We will automate the simple task of normalizing a variable. That is to say, subtracting the variable’s mean and dividing by its standard deviation.
Just so you know, there are already community-contributed commands to do this and to do it more flexibly than we will. Type search normalize variable in Stata, and you will see one of those commands. (You will see things about other types of normalization that have nothing to do with normalizing a variable, but the command of interest is easy to pick out.) You can also normalize a single variable using Stata’s egen command, but we are going to do more than that.
As with all the articles in this series, I assume the reader is new to automating tasks in Stata. So, if you are already an expert, these articles may hold little interest for you. Or perhaps you will still find something novel. Read more…
“The book that Stata programmers have been waiting for” is how the Stata Press describes my new book on Mata, the full title of which is
The Mata Book: A Book for Serious Programmers and Those Who Want to Be
The Stata Press took its cue from me in claiming that it this the book you have been waiting for, although I was less presumptuous in the introduction:
This book is for you if you have tried to learn Mata by reading the Mata Reference Manual and failed. You are not alone. Though the manual describes the parts of Mata, it never gets around to telling you what Mata is, what is special about Mata, what you might do with Mata, or even how Mata’s parts fit together. This book does that.
I’m excited about the book, but for a while I despaired of ever completing it. I started and stopped four times. I stopped because the drafts were boring. Read more…
This post is the fourth in a series that illustrates how to plug code written in another language (like C, C++, or Java) into Stata. This technique is known as writing a plugin or as writing a dynamic-link library (DLL) for Stata.
In this post, I write a plugin in Java that implements the calculations performed by mymean_work() in mymean11.ado, discussed in Programming an estimation command in Stata: Preparing to write a plugin, and I assume that you are familiar with that material.
This post is analogous to Programming an estimation command in Stata: Writing a C plugin and to Programming an estimation command in Stata: Writing a C++ plugin. The differences are due to the plugin code being in Java instead of C or C++. I do not assume that you are familiar with the material in those posts, and much of that material is repeated here.
This is the 32nd post in the series Programming an estimation command in Stata. See Programming an estimation command in Stata: A map to posted entries for a map to all the posts in this series. Read more…
This post is the third in a series that illustrates how to plug code written in another language (like C, C++, or Java) into Stata. This technique is known as writing a plugin or as writing a dynamic-link library (DLL) for Stata.
In this post, I write a plugin in C++ that implements the calculations performed by mymean_work() in mymean11.ado, discussed in Programming an estimation command in Stata: Preparing to write a plugin. I assume that you are familiar with the material in that post.
This post is analogous to Programming an estimation command in Stata: Writing a C plugin. The differences are due to the plugin code being in C++ instead of C. I do not assume that you are familiar with the material in that post, and you will find much of it repeated here.
This is the 31st post in the series Programming an estimation command in Stata. I recommend that you start at the beginning. See Programming an estimation command in Stata: A map to posted entries for a map to all the posts in this series. Read more…
This post is the second in a series that illustrates how to plug code written in another language (like C, C++, or Java) into Stata. This technique is known as writing a plugin or as writing a dynamic-link library (DLL) for Stata.
In this post, I write a plugin in C that implements the calculations performed by mymean_work() in mymean11.ado, discussed in Programming an estimation command in Stata: Preparing to write a plugin. I assume that you are familiar with the material in that post.
This is the 30th post in the series Programming an estimation command in Stata. See Programming an estimation command in Stata: A map to posted entries for a map to all the posts in this series. Read more…
This post is the first in a series that illustrates how to plug code written in another language (like C, C++, or Java) into Stata. This technique is known as writing a plugin or as writing a dynamic-link library (DLL) for Stata.
Plugins can be written for any task, including data management, graphical analysis, or statistical estimation. Per the theme of this series, I discuss plugins for estimation commands.
In this post, I discuss the tradeoffs of writing a plugin, and I discuss a simple program whose calculations I will replace with plugins in subsequent posts.
This is the 29th post in the series Programming an estimation command in Stata. See Programming an estimation command in Stata: A map to posted entries for a map to all the posts in this series. Read more…
In my previous post, I talked about how to combine the Java library Twitter4J and Stata’s Java function Interface using Eclipse to create a helloWorld plugin. Now, I want to talk about how to call Twitter4j member functions to connect to Twitter REST API, return Twitter data, and load that data into Stata using the Stata SFI. Read more…
Introduction
Three months ago, I wrote about a new command, twitter2stata, that imports data from Twitter’s REST API into Stata. Today, I will show you the tools we used to develop this command. Writing this command from scratch solely in Mata or ado-code would have taken several months. Fortunately, we can significantly speed up our development using an existing Java library (Twitter4J) and Stata’s Java plugins. In this post, I will discuss the basic steps of how to leverage a Java library and the Stata Java API.
Java is the most popular programming language in the world, so there are many libraries to support your development. A quick Google search should tell you if a Java library exists for what you are trying to do; this is how we found the library Twitter4J. For the rest of this blog entry, a basic understanding of programming in Java is helpful, but not necessary. Read more…