Most policy decisions these days are heavily influenced by proprietary forecasting models.
Just look at the fuss that was made because the House passed a health bill without a Congressional Budget Office score. The CBO score will certainly play a large part in the Senate's rewrite. The problem is that the CBO and other organizations like it are quite secretive about their modeling. Most of the time they only produce point estimates, and they don't publish many of the assumptions behind their modeling. When there is a bill that contains both taxes and spending, the Joint Committee on Taxation models the tax part, the CBO models the spending part, and they just smash the results together because even those two organizations aren't willing to share and integrate their models.
The NY Fed is serving as an important leader in this field. Policy analysis should be transparent and scientific, and that's what the NY Fed is moving the field towards.
The Open Source Policy Center, where I work, is focussed on this issue. www.ospc.org Most of OSPC's work is focussed on fiscal policy rather than monetary policy.
I was wondering why they specifically chose Julia for this (since I know little about Julia at all), and found an answer in a previous article:
> Julia has two main advantages from our perspective. First, as free software, Julia is more accessible to users from academic institutions or organizations without the resources for purchasing a license. Now anyone, from Kathmandu to Timbuktu, can run our code at no cost. Second, as the models that we use for forecasting and policy analysis grow more complicated, we need a language that can perform computations at a high speed. Julia boasts performance as fast as that of languages like C or Fortran, and is still simple to learn.
Julia boasts performance as fast as that of languages like C or Fortran, and is still simple to learn.
I think the greatest benefit is that Julia code is both high-performance and (mostly) high-level, which makes it easy to change. I don't mind implementing a completely-specified algorithm in C or Fortran, but making significant changes to these code bases is simply much more work than in languages like Python or Julia.
I agree in sentiment but lately keep finding Python fraudulent in that regard: folks write complex messes in it because of its deficiencies, or to just be dramatic.
However, Julia isn't Python - although I don't know enough about the latter to comment on what deficiencies you are referring to, nor do I know if Julia addresses these.
Yes; Julia isn't unique in being a modern high-level high-performance language. But it's the only one I know that explicitly targets numerical computing, and it chooses its trade-offs accordingly.
Agreed, that wasn't meant as a knock on julia. Just pointed out there is a long history behind the approach. Part of lisp's role in the "last AI bubble (TM)" was how natural it was to express certain types of problems in it. Julia is clearly targeting a similar advantage in other areas.
This is true - I once wrote something like that in a common lisp but never got it past the half-assed but useful.
Similarly (but painfully and never completely successful), see all the c++ expression template approaches to linear algebra. After 15 years or so some of them are quite usable but retain some of the pain.
Just look at the fuss that was made because the House passed a health bill without a Congressional Budget Office score. The CBO score will certainly play a large part in the Senate's rewrite. The problem is that the CBO and other organizations like it are quite secretive about their modeling. Most of the time they only produce point estimates, and they don't publish many of the assumptions behind their modeling. When there is a bill that contains both taxes and spending, the Joint Committee on Taxation models the tax part, the CBO models the spending part, and they just smash the results together because even those two organizations aren't willing to share and integrate their models.
The NY Fed is serving as an important leader in this field. Policy analysis should be transparent and scientific, and that's what the NY Fed is moving the field towards.