Federal Reserve Bank of NY converts major economic model to Julia

Cool, despite Julia replacing matlab here, it looks like the biggest loser to Julia's rise might be Octave.

Matlab will always have its proponents, that will use it no matter what, but if Julia keeps encroaching on this territory, I'm not sure where that leaves Ocatve.

To the model discussed in this paper, check out this series of blog posts for more information:

http://libertystreeteconomics.newyorkfed.org/2014/09/forecas...

Essentially the model is a work in progress that is continually updated each quarter. It attempts to model at a macro economic level, the interactions between Banks, consumers, Companies, Governments and households.

Once the model has solved for the general equilibrium of how those 5 agencies interact the model can then be used to "shock" a particular factor, such as interest rates, to determine how this might affect the interaction between these agents.

Its a fairly well respected model, and the fact that the US is one of the few countries to release such a large amount of financial data is one reason why the US is still a leader in economic theory.

Even more interesting is the document on Github with technical details about the port:

https://github.com/FRBNY-DSGE/DSGE.jl/blob/master/doc/Matlab...

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.

> 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.

> I honestly can't understand why

The answer is fairly obvious though, isn't it? For scientists or novice programmers wanting to do some numerically intensive work, Matlab has typically offered one of the quickest (in time-to-solution) prototyping platforms. One of the keys being that you can get started very quickly, with minimal setup (besides the expensive license and installation, something most academics need not worry about). As a former academic programmer and now a consultant that helps companies commercialize such prototypes, I understand your pain, but at the same time I completely understand why a physicist, imaging scientist, or finance major ends up using Matlab over something like C++ or Python. Same goes for LabView, and if you despise Matlab, I challenge you to give LabView a whirl. The gap between the Matlabs and Labviews of the world and the other programming languages is closing in terms of ease of use and setup time, but we're not there yet and also momentum shifts on this type of thing take a loooong time. If you come into a lab and are working on a research project that was started in Matlab, odds are, in the interest of finishing your thesis on time, you're unlikely to port it to another language, even if you have the skill to do so.