Introductions

[Spencer Lyon]

I would like to get to know more about the people interested in this group, so I figured I would start off the introductions. I'll post a brief sketch of my background and interests. I invite you to do the same as comments in this thread.

I am a first year PhD student in economics at New York University (NYU). My background is a BS in Physics and BS in Economics from Brigham Young University (BYU). 

The most recent open-source project I have spent substantial time on is xdress (http://xdress.org/). xdress is an automatic wrapper generator to take C/C++ projects into Python via a Cython bridge. The main idea is that you can describe describe C-based source and (optionally) the desired structure of the python interface and xdress will generate the necessary Cython code required to create the interface for you. All the user then has to do is incorporate the Cython in a build system and have fun in Python!

Another project with which I have had some, albeit small, involvement with is the new website quant-econ.com managed by Tom Sargent and John Stachurski. 

As I am in my first year, my main goal is to survive coursework and pass qualifying exams in June 2014! Also due to my relative lack of experience I would say that my computational interests at this point are just computation in general! I expect that these interests will be fine-tuned over time as I gain experience and am exposed to more things.

[Spencer Lyon]

And a quick typo-correction: it is quant-econ.net, not quant-econ.com!! (this shows how "small" my involvement has been!)

[Pablo Winant]

What a pity we didn't know the `.com` extension was available ! That would have been another good option...

I had never heard of the XDress project. Clearly, knowing how to wrap low-level code will be very valuable, and possibly unavoidable until JIT compilation schemes catch up. If I understand well, the main selling point of XDress, is its abillity to wrap C++ classes transparently. Maybe it would be one way to actually use C++ classes from Julia, via pycall, since I don't know how c++ classes would map into Julia objects. Or maybe having C interfaces is a better way to go since we have the robust ccall/cffi functions. Can you use your HSF library to solve economic models ?

Pablo

--
You received this message because you are subscribed to the Google Groups "econforge" group.
To unsubscribe from this group and stop receiving emails from it, send an email to econforge+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Pablo Winant]

To follow up on this introduction thread, here are some computational issues I am currently involved with:

- I am currently funded by the IMF to develop a toolbox for global models. This one is available as a python library ( https://albop.github.com/dolo/ ), which already includes many tools to solve economic models.

It consists in some low-level compiled routines (for instance interpolation routines), as well as higher-level ones aka. solution algorithms. In a long equilibrium, the low-level routines could be moved where they would benefit more people, possibly in scipy or in a common library, if somebody else wants to work on them.

- I take it as a strong delusion that some people want to work on economic modelling without ever learning to program, so that I didn't take it as a priority to create a completely integrated user-interface (but that will come in due time). On the other hand, I would like to lower the entry cost into it as much as possible, using documentation, tutorials, examples and so on. It is actually a good summary of what I believe we could achieve by providing a good and robust economic library. There would be no need to write an "economic modelling language" since we can leverage existing user-friendly languages and a whole opensource stack.

- Speaking of which I became recently interested in cloud computing technologies. Again, it looks like that by using (almost) existing free technologies, we can rather easily setup a computing environment for our students/end-users. That would solve many infrastructure at once, and I am very curious to gather some early feedback on that aspect.

- I find the recent developments in JIT compiling very exciting, both in the python world (with numba) or in the new Julia community. This is excellent since it removes the big performance penalty that was associated with naive iterative programming in user-friendly (interpreted) languages. At this point of time it is not clear to me which is the better option between the two languages, or how they will eventually specialize, but as for now, the scientific communities behind them seem to have some kind of a parallel evolution with many exchanges. They have even begun to share a standard format for interactive computations (the IPython notebook). That's one of the reasons why I think it's a good idea to have the current mailing list subjects span over many languages. In particular I am eager to have comparative feedbacks on how young economists react when being taught to program in Python, or in Julia. I also made somewhere a mental note, that I would like to have all the dolo functions to have some kind of julia equivalent (possibly to extend the prototype here: https://github.com/albop/jolo/ )

- One key issue that I have been working in the past years, with respect to economic modelling, was to look for some standardized representation of economic models. This has been the subject of many informal discussions so far and should probably be one of our top priorities. There are two sides of it. First, there is the user-side, where one writes a model, by declaring symbols first, and listing a list of equations, and possibly other informations. The Dynare modfiles have proven that it is indeed a very healthy discipline (even for skilled programmer) to be able to focus on the model definition, independently from its numeric outcomes. Christophe and I have had the same experience for global models: it may even be more important in that case since, there are more variables types to take care of and it is very easy to make subtle timing errors. There is also the developer side where having a standard representation of "a" generic model makes it possible to develop efficient generic algorithms. It would save everybody a lot of time if we were able to coordinate on both aspects. This is not an easy task, since we want to be simultaneously universal, elegant and future-proof, but it's certainly worth it. Or course we will probably return to that matter in a separate thread.

Best,

Pablo

To unsubscribe from this group and stop receiving emails from it, send an email to econforge+unsubscribe@googlegroups.com.

[Spencer Lyon]

That is pretty much the main purpose of xdress. Beyond just wrapping C++ classes it can also wrap C/C++ functions. \

I believe that we would be able to use xdress + pycall to get quick access to C++ classes in Julia. I haven‘t tried it before, but believe that it would work. If you have some C++ code you would like to try wrapping let me know and we’ll get it working from Python and Julia.

Because HSF is so new, only the original authors have used it in their fields: Physics and engineering. I believe that it should work for economic modeling as well, if not better, than other types of spline. Some highlights of HSF are:

• As it is written in C++ it is quite fast and efficient.
• Boundary conditions (some constraints) can be built directly into the splines rather than imposed after their creation
• With HSF it is possible to have localized refinement, which is certainly not true of other splines.
• The basis functions have a compact support and can be made into a partition of unity.
• Curves constructed from using HSF are smooth and accurate.
• HSF curves can be made between knots and at knots (p is the degree of the spline and k is the multiplicity of the knot). This gives us control over the continuity of the spline.

[Sébastien Villemot]

Hi,

Now it's my turn to present myself.

I am originally from a math and computer science background (I have an
MSc in computer science), and it’s only later that I switched to
economics (got my PhD one year ago).

A brief overview of my activities:

- I am one of the core developers of Dynare. I am mainly involved with
the development of the preprocessor and with the overall coordination of
the project.

- I am interested in research on solution methods for economic models,
on which I (co-)authored a few papers. In addition to DSGE models, I
also work on sovereign debt models with endogenous decision to default,
which are challenging from a computational point of view

- I am a free software enthusiast, having been using GNU/Linux since
1995. I am a regular contributor to the free software community, mainly
through my involvement in Debian (one of the most influential GNU/Linux
distribution, on top of which many other distributions, including
Ubuntu, are based). Within Debian, I maintain essential components of
the numerical stack (BLAS/LAPACK, Octave, Julia, some R stuff…), and I
am trying to push forward the use of Debian by economists (see
http://blends.alioth.debian.org/science/tasks/economics )

- I am very interested in Julia, and within EconForge I intend to mainly
contribute around that language. I already wrote a prototype code for
DSGE solving à la Dynare using Julia, some parts of which can probably
reused for EconForge. See https://github.com/DynareTeam/Dynare.jl .

Looking forward to hear from the others!

--
Sébastien Villemot
Researcher in Economics
Dynare developer
http://www.dynare.org/sebastien

[Chase Coleman]

I didn't want to post my introduction too close to Spencer's because they are a little bit alike.

I started my PhD this month at New York University (NYU).  I graduated from Brigham Young University (BYU) with a double major in Mathematics and Economics.

My work in open-source projects has been a little bit limited, but I am very interested in providing more contributions (probably starting after I make it through my first year of my PhD).  I also had some small involvement with Tom and John's quant-econ.net.

My current research interests are in growth theory/macroeconomics in general.  I'm hoping to narrow that down a little bit as the year goes on.  I'm also very interested in establishing viable solution methods for models.

Thanks for all the introductions so far and those that are forthcoming.

[Christophe Gouel]

Hi,

I am a junior researcher at INRA, the French National Institute for Agronomic Research. As such, my work revolves around issues of agricultural economics.

My interest in computational economics is mainly instrumental. I am interested in solving nonlinear models of commodity pricing, mostly rational expectations storage models. Since at the time of my PhD no solver was able to solve conveniently the models I was interested in, I have started developing a dedicated MATLAB solver. I am convinced that we have to make our research papers as replicable as possible, so I have made this solver publicly available at https://github.com/christophe-gouel/recs.

Currently my work relies mostly on MATLAB for two main reasons. Firstly, because the best solver for mixed complementarity problems, PATH (http://pages.cs.wisc.edu/~ferris/path.html), is freely available for MATLAB and this solver is a must-have when problems with complicated occasionally binding constraints have to be solved. Secondly, the CompEcon toolbox provides well designed functions for interpolation with splines or Chebyshev polynomials.

Now that I know more about computing, I could contemplate switching to other, more open, languages. There are also C and Fortran libraries for PATH. With a bit of work, we should be able to call them from Python or Julia. Interpolation will probably require a bit of additional work, as in many libraries of interpolation I have always missed what makes CompEcon so useful: a proper handling of derivatives.

Before starting my PhD, I worked on CGE modeling. In this field, the development of GAMS and GEMPACK has really changed the game by allowing the standardization of models' development. For stochastic rational expectations models, Dynare has started this process, but many types of model are left outside of Dynare's framework. Moving further on the issue of standardized representation of economic models appears to be crucial for me. I have occasionally collaborated a few lines of Python with Pablo to help on this part of dolo.

Christophe

--
You received this message because you are subscribed to the Google Groups "econforge" group.
To unsubscribe from this group and stop receiving emails from it, send an email to econforge+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
Christophe Gouel

INRA - Economie publique
AgroParisTech
16 rue Claude Bernard
75005 PARIS - FRANCE
Tel +33 (0)1 44 08 72 77
www.christophegouel.com

[Pablo Winant]

Le mercredi 25 septembre 2013 14:08:51 UTC+2, Christophe Gouel a écrit :

Hi,

I am a junior researcher at INRA, the French National Institute for Agronomic Research. As such, my work revolves around issues of agricultural economics.

My interest in computational economics is mainly instrumental. I am interested in solving nonlinear models of commodity pricing, mostly rational expectations storage models. Since at the time of my PhD no solver was able to solve conveniently the models I was interested in, I have started developing a dedicated MATLAB solver. I am convinced that we have to make our research papers as replicable as possible, so I have made this solver publicly available at https://github.com/christophe-gouel/recs.

Currently my work relies mostly on MATLAB for two main reasons. Firstly, because the best solver for mixed complementarity problems, PATH (http://pages.cs.wisc.edu/~ferris/path.html), is freely available for MATLAB and this solver is a must-have when problems with complicated occasionally binding constraints have to be solved. Secondly, the CompEcon toolbox provides well designed functions for interpolation with splines or Chebyshev polynomials.

Now that I know more about computing, I could contemplate switching to other, more open, languages. There are also C and Fortran libraries for PATH. With a bit of work, we should be able to call them from Python or Julia. Interpolation will probably require a bit of additional work, as in many libraries of interpolation I have always missed what makes CompEcon so useful: a proper handling of derivatives.

It should be relatively easy to produce bindings to PATH since it appears to have a simple C interface. But since its licensing is problematic (it is neither opensource nor really free to use or distribute) we should certainly also aim at having a simple standalone complementarity solver made available. Here it would be great if the relevant part of the compecon toolbox could be relicensed so that we could use them. Otherwise, we will need to write something from scratch, following published papers.

Having good interpolation routines would clearly be very beneficial in the short run. I'll start a new thread now to discuss it.

[Tom Holden]

Hi all,

Pablo mentioned the existence of this group to me. Quite a few of you know me already, but for those who don't, I'm an assistant professor at the university of Surrey in the UK. My PhD was from Oxford. Prior to that, I was a professional programmer for EA games.

I have tended to make my code open source when I can, and you can find me on GitHub here: https://github.com/tholden/

My most widely used repository is DynareOBC from here: https://github.com/tholden/dynareOBC

It is mostly designed for simulating DSGE models with occasionally binding constraints, but also handles exact simulation of IRFs without Monte Carlo, non-linear simulation of "model local variables" including integration to calculate the expectation of ones including future dated variables (making calculating Euler equation errors very easy), and can also do estimation of models solved to a third order via the cubature Kalman filter.

Best,

Tom