...and that's how political scientists became redundant

From here:

Upload a data set, and the automatic statistician will attempt to describe the final column of your data in terms of the rest of the data. After constructing a model of your data, it will then attempt to falsify its claims to see if there is any aspect of the data that has not been well captured by its model.

competition

So, I’m no longer the only one using machine learning in order to measure democracy - I just found out about this initiative. It looks interesting and it made me regret not going to APSA this year. We differ in tools (they use SVM, I use a combination of LSA, LDA, decision trees, and Wordscores) and texts (they use human rights reports and Freedom House reports, I use 6,043 newspapers and magazines), but the spirit is the same: producing measures that are more transparent and reproducible (and eventually maybe real-time).

Project Jupyter - the great convergence?

“Why is it called IPython if it can do Julia, R, Haskell, Ruby, …?”

a comparison of programming languages in economics

Here.

Highlights:

1. C++ and Fortran are still considerably faster than any other alternative, although one needs to be careful with the choice of compiler.

1. C++ compilers have advanced enough that, contrary to the situation in the 1990s and some folk wisdom, C++ code runs slightly faster (5-7 percent) than Fortran code.

1. Julia, with its just-in-time compiler, delivers outstanding performance. Execution speed is only between 2.64 and 2.70 times the execution speed of the best C++ compiler.

1. Baseline Python was slow. Using the Pypy implementation, it runs around 44 times slower than in C++. Using the default CPython interpreter, the code runs between 155 and 269 times slower than in C++.

1. However, a relatively small rewriting of the code and the use of Numba (a just-in-time compiler for Python that uses decorators) dramatically improves Python’s performance: the decorated code runs only between 1.57 and 1.62 times slower than the best C++ executable.

1. Matlab is between 9 to 11 times slower than the best C++ executable. When combined with Mex files, though, the difference is only 1.24 to 1.64 times.

1. R runs between 500 to 700 times slower than C++. If the code is compiled, the code is between 240 to 340 times slower.

1. Mathematica can deliver excellent speed, about four times slower than C++, but only after a considerable rewriting of the code to take advantage of the peculiarities of the language. The baseline version our algorithm in Mathematica is much slower, even after taking advantage of Mathematica compilation.

rise of the machines - part 3

In part 2 we saw how to use C++ and bytecodes to program LEGO Mindstorms EV3 bricks. Now, bytecodes don’t make for human-readable scripts. And C++ scripts take ~4 times longer to write than equivalent Python or Perl scripts. So, I’ve started writing a Python module that should make life easier - I’ve called it ev3py.

Here’s the GitHub repo. For now the module is still inchoate; it only covers three basic functions (starting motors, stopping motors, and reading data from sensors) and it only works on Macs, and only via Bluetooth. But it’s a start.

Let’s see a concrete example. Say you want to start the motor on port A with power 20. If you’re using bytecodes and C++ you need to write something like this:

#include <unistd.h>
#include <fcntl.h>
#include "ev3sources/lms2012/c_com/source/c_com.h"

int main()
{    
    unsigned const char start_motor[] {13, 0, 0, 0,
        DIRECT_COMMAND_NO_REPLY,
        0, 0,
        opOUTPUT_POWER, LC0(0), LC0(1), LC1(20),
        opOUTPUT_START, LC0(0), LC0(1)};

    int bt = open("/dev/tty.EV3-SerialPort", O_RDWR);
    write(bt, start_motor, 15);
 }

With ev3py here’s how you do it:

from ev3py import ev3

mybrick = ev3()
mybrick.connect('bt')
mybrick.start_motor(port = 'a', power = 20)

So, with ev3py the code becomes human-readable and intuitive. It also becomes much faster to write. You no longer need to set message size, message counter, command type, etc.

Unlike other EV3 modules ev3py interacts with the EV3’s native firmware, so there’s no need to make the EV3 boot to a different operating system; just turn the brick on and you’re ready.

The goal is to eventually cover all EV3 capability and make ev3py work with USB and WiFi and also with Linux and Windows. I.e., something along the lines of the QUT-EV3 toolkit and the Microsoft EV3 API. If you’d like to contribute your help is much appreciated - just fork the GitHub repo and add capabilities, fix bugs, or suggest changes to the overall structure of the module.