Federal Reserve Bank of NY converts major economic model to Julia (opens in new tab)

> it looks like the biggest loser to Julia's rise might be Octave.

It's not a competition. Julia is our friend, not a rival to Octave. We're on good terms with their developers. Occasionally we share ideas and patches back and forth when it makes sense. They've asked me for help with their Octave benchmark and I've gladly provided it.

Octave being unnecessary is Octave's ultimate goal. When nobody cares about Matlab, probably nobody will care about Octave either. But as long as people care about Matlab, Octave will be relevant. Or perhaps, in a perfect world, enough people will stop caring about Matlab that Octave can start leading in fixing the biggest stupidities in the programming language (we already do this to some degree, but keep relenting and replicating Matlab's bugs because code depends on those bugs).

If Julia is gaining the minds of people in scientific computing, great. It's going to take them away from Matlab and Octave to equal degree. If we can all do our computing unfettered by proprietary licenses, I don't care if it means we end up using Octave or Julia as long as we stop using Matlab.

And many of Matlab's alleged proponents keep turning to Octave. Octave still fills a niche that Julia does not: being able to use Matlab code freely.

This is an anecdote about a big Matlab proponent who switched sides.

I learned Matlab from my Econ 101 professor 8 years ago. He was a big Matlab proponent, and he knew all the econ tools inside out.

We kept in touch, since he has been one of the best professors I've ever had. So, fast forward to 2 years ago, I sent him an email asking about this [1] Quantitative Economics course by Sargent and Stachurski based on python. He told me that it looked interesting and that he would give it a try and tell me what he thought. This was his first approach to Python.

Two months later he sends me an email telling me that he's ditched Matlab for good, he's taken a couple MOOC python courses and that he is having a lot of fun with Python. He also praised the community and all the open source tools. He also told me to get away from the Sargent and Stachurski course, that they add too much complexity to the explanations just for the sake of looking more Nobel-prize-winner like.

[1] http://quant-econ.net/

> Matlab will always have its proponents

I honestly can't understand why. I'm currently in a computer vision class that uses Matlab, and it's literally the worst language I've ever used in my life. The design is nonsensical, bordering on malicious

I've always thought that the biggest problem with python was that as programs get bigger, you're likely to run into some confusion due to the lack of static typing and substantial use of implicit conversion (e.g. "Truthy" and "falsy" values), but python has nothing at all on Matlab.

Just last night, a matrix I constructed using the expression "[x, y, (x+scale), (y+scale)]" inexplicably had dimensions 1x8 instead of the visually obvious 1x4, but only after a few hours of matlab slowly evaluating this expression thousands of times without any trouble. I suspect this has something to do with matlab's horrible ambiguous matrix concatenation syntax.

Improvements to our LuaJIT benchmarking are currently being discussed in https://github.com/JuliaLang/julia/issues/14222. LuaJIT 2.1 is significantly faster than LuaJIT 2.0, but until now I haven't had a convenient way to get an installation of LuaJIT 2.1 on our test machine. LuaSci was easy to install and we would be amenable to switching over to LuaSci instead of vanilla gsl-shell. See https://github.com/JuliaLang/julia/issues/14222#issuecomment... for a timing comparison.

Julia in contrast to most languages can run very fast or very slow for roughly the same program because of type information and garbage collection.

I would be willing to bet there is a lot of fat to be trimmed if you can't get close to LuaJIT unless SIMD is involved. Have you tried profiling your Julia code to see where the problem is?

I think it would be really interesting to understand exactly why Julia underperforms LuaJIT on some benchmarks. I'm pretty skeptical that Julia loses to LuaJIT uniformly; I suspect it depends on the benchmark taking advantage of LuaJIT's superior discovery of run-time type information.

I find benchmarking to be of little value when the percentages are small. The differences are tiny when I see them don.

Very interesting, particularly the Challenges section:

"Differences between the behavior of MATLAB and Julia’s core linear algebra libraries led to many roadblocks in the development of DSGE.jl. Julia uses multithreaded BLAS functions for some linear algebra functions. Using a different number of threads can change the results of matrix decomposition when the matrix is singular. This indeterminacy caused significant problems for our testing suite, both in comparing output matrices to MATLAB results and in testing for reproducibility among Julia outputs."

Kudos to them for taking this on, I think.

No. A central bank moving at all to Julia is absolutely fucking huge.

As far as votes of confidence go, Julia landing successfully at any of the 12 Federal Reserve Banks is a strong one. They all do a whole mess of complex modeling. The NY Fed in particular is a "first among equals" in the Federal Reserve system, so it's always good to be there.

That said, I have no idea if this will be that influential on economists changing their tools, or the tools that they teach to their students. People tend to stick with tools that they know and like. But it's very possible that this will help Julia in the eyes of people getting into the field choosing their first programming language.

The DSGE models are influential up until somebody comes up with a valid alternative, at which point they will be dropped at somewhat over the speed of light :)

To be brutally honest, this is not a big achievement. You should be able to rapidly speed up any matlab model by porting it into pretty much any other language due to well known issues with matlab. Being able to run DSGE models more quickly is important to economists because it allows them to be better 'callibrated' - which is to say that the economists essentially tweak the models for the country they are looking at, until they fit the known data over an acceptable time period. (They don't try to hide this btw. there are scores of papers on model calibration approaches.)

A good example of what this leads to is the one for Iceland:

http://www.sedlabanki.is/lisalib/getfile.aspx?itemid=8077

Notice that this is published in 2010, but for some strange reason the charts (p57 onwards) all stop in 2005.

It's over fitting to the curve on computer assisted steroids.

I work on research close to this area -- time series w/ macro applications, but not on these specific models. These specific models are very very important for estimating the effects of monetary policy decisions, forecasting, etc. because they embed a fair bit of economic theory with a decent amount of estimation theory so that the models can address questions about "causality" in a meaningful way: if I intervene by changing the interest rate, what is the distribution of outcomes that will result. (The stuff I work on uses less economic theory so it can't address those questions.)

That's not to say that the NY Fed takes the model's recommendations uncritically and assumes that the models are perfect or the recommendations are the truth, because that would be nuts. Just that this class of models is one of the few ways to use "the data" to provide guidance about policy decisions.

The people who've developed the NY Fed's DSGE model are some of the absolute top people working on these models. It's based on a lot of academic research and a lot of research published in top journals by people at the NY Fed involved in building the model. Other banks have their own models, but I suspect this one is the highest profile. (Again, not precisely my field of research, so I could be missing one or two.)

So, to get around to answering your question. For academic research in economics, this is as "production level" as it gets. Is this the same as using Julia for algorithmic trading? No. The NY Fed's not running this model in real time, and if something crashes then they can restart it. But I think this is huge for Julia's adoption in economic research.

(For a pdf with more about the modeling strategy itself: https://www.newyorkfed.org/medialibrary/media/research/staff... but that is 2 years old now.)

To be honest, it will have very little influence. Economists don't like to change their tools.

I'm not sure how the comparison stacks up for you. Drupal nabbing the whitehouse site was pretty huge in enabling it to land a bunch of other government and higher ed sites/mindshare. I'm not sure which end of the order of magnitude scale you place that though.

The Fed isn't a government agency. It has private share holders. It was named The Federal Reserve specifically to breed the confusion that most people have - it was supposed to sound like a federal agency while it is not.

Doesn't this make the code more difficult to work with, sine these characters require uncommon sequences of keystrokes?

Single character Greek variables don't seem better than single character ASCII for readability.

Whoa that's awesome, are there any other languages that allow that?

I haven't either, but they just start with a #, right? What's the problem?

EDIT: Oh, I see there are multiline comments.