quantecon / quantecon.jl Goto Github PK

This will make sure code that website readers use or read at least runs.

A next step would be to verify accuracy of the results, but that would be more time consuming.

• People Link
• Lead Developers Link

And as both link to the same url, one can be removed.

Found this while combing through deprecation warnings:

julia> using QuantEcon

julia> P1 = [1 0 0; .2 .5 .3; 0 0 1];

julia> d1 = MarkovChain(P1);

julia> QuantEcon.irreducible_subsets(d1)
3-element Array{Array{Int64,1},1}:
 [1]
 [2]
 [3]

julia> QuantEcon.irreducible_subsets(d1)
1-element Array{Array{Int64,1},1}:
 [1,2]

julia> QuantEcon.irreducible_subsets(d1)
1-element Array{Array{Int64,1},1}:
 [1]

julia> QuantEcon.irreducible_subsets(d1)
1-element Array{Array{Int64,1},1}:
 [2]

julia> QuantEcon.irreducible_subsets(d1)
2-element Array{Array{Int64,1},1}:
 [2]
 [3]

Shouldn't the irreducible_subsets of a given stochastic matrix be constant?

@ZacCranko any ideas what's going on here?

update the mc_tools file to match the new changes to that file in the python version

Julia Version 0.4.0-dev+7018
Commit b6a0241* (2015-08-27 00:03 UTC)
Platform Info:
System: Darwin (x86_64-apple-darwin14.4.0)
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
LAPACK: libopenblas
LIBM: libopenlibm
LLVM: libLLVM-3.3

julia> using QuantEcon
ERROR: LoadError: LoadError: Invalid doc expression [eigen_solve,lu_solve,gth_solve]
in include at ./boot.jl:259
in include_from_node1 at ./loading.jl:271
in include at ./boot.jl:259
in include_from_node1 at ./loading.jl:271
in require at ./loading.jl:210
while loading /Users/djb/.julia/v0.4/QuantEcon/src/mc_tools.jl, in expression starting on line 143
while loading /Users/djb/.julia/v0.4/QuantEcon/src/QuantEcon.jl, in expression starting on line 115

• ASCIIPlots 0.0.3
• AnsiColor 0.0.2
• ArgParse 0.2.11
• AudioIO 0.1.1
• Benchmark 0.1.0
• Blink 0.1.4
• CPUTime 0.0.4
• Calendar 0.4.3
• Clang 0.0.5
• DataFrames 0.6.9
• DataStructures 0.3.12
• Dates 0.4.4
• Debug 0.1.4
• Distributions 0.8.3
• Escher 0.1.0
• FileFind 0.0.0
• Gadfly 0.3.14
• GeoIP 0.2.1
• GraphViz 0.0.4
• Graphs 0.5.5
• IJulia 0.2.5
• Jewel 1.0.5
• LogParser 0.1.0
• Logging 0.1.1
• MarketData 0.2.4
• Memoize 0.0.0
• ODBC 0.3.10
• Pandas 0.2.0
• ProfileView 0.0.12
• ProtoBuf 0.1.1
• PyCall 0.8.2
• PyPlot 2.0.1
• QuantEcon 0.2.0
• RDatasets 0.1.2
• TimeData 0.6.1
• Timestamps 0.0.2
• WAV 0.5.1
• Winston 0.11.12
• ZMQ 0.2.0

Don't have a julia version of the gth_solve module

Thoughts started by: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/quantecon/AQzUAsLFxFA

Often when I (and probably others) am calling meshgrid, the arguments that I would like to pass in are LinSpace types. I typically just use collect and pass them in. Would it make sense for us to write an additional method that takes arguments that are linspaces and simply converts them to arrays before calling out to the final function?

I came across this due to a broken link in the lecture site.

Should src/markov_approx.jl be located in the markov folder?

I had a rough start at implementing the quadrature routines.

There is still a lot of work to do on this.

It should be quite fast -- we can copy/paste relevant portions from both matlab/python.

Hello,

I am trying to learn Julia through the lecture notes by Prof. Sargent and Stachurski. In the manuscript , when QuantEcon is utilized they use specific packages (routines) like tauchen.

Where one can find the full list of the routines used plus, maybe, a short description of them?

Some topics that are available to be worked on

Code Library

• Improve DiscreteDP code by porting State-Action Pair Formulation of Python code to Julia
• Improve DiscreteDP code by porting Sparse Matrix Support from Python to Julia
• CompEcon merge (see #45)

Notebooks

• Fix up errors in 2 x DiscreteDP Julia notebooks
• Port python notebooks to julia equivalents in QuantEcon.notebooks() (ref #113)

Infrastructure

• Improve testing infrastructure by running Julia notebooks and checking for any runtime errors. QuantEcon.applications contains some starting code which is used to run python notebooks using the runipy project

Don't have a julia version of the graph_tools module

I receive an error message on using mc_sample_path()

julia> using QuantEcon

julia> P = [0.4 0.6; 0.8 0.2]
2x2 Array{Float64,2}:
0.4 0.6
0.8 0.2

julia> P = MarkovChain(P)
Discrete Markov Chain
stochastic matrix:
2x2 Array{Float64,2}:
0.4 0.6
0.8 0.2

julia> mc_sample_path(P, [0.5, 0.5], 100000)
ERROR: type cannot be constructed
in map at abstractarray.jl:1328

I'm using Julia version 0.3.9 on Mac OS X 10.10.3

I think that #64 is hitting JuliaLang/julia#12586 and can be avoided if we simply don't use the name src/distributions.jl for holding the BetaBinomial type.

Right now we have plotting functions included in arma.jl -- this makes us dependent on PyPlot.jl. I don't want to do this for a few reasons:

• I would prefer to have no non Julia hard dependencies.
• This adds 5-6 seconds to the loading time for QuantEcon. Not a huge deal, but annoying.

Does anyone have any ideas for what we can do? I have tried figuring out a way of only importing PyPlot if it is not defined and one of the plotting functions is called, but conditional importing within a function is harder than it should be.

One thing that I think would work would be to move the plotting functions to a file in the examples directory and then having a "helper" function in src/arma.jl that uses include to execute the contents of the plotting file in the Main module so users can use them. We could easily call using PyPlot or import PyPlot.plt from the file in examples without making it a QuantEcon dependency.

We need a style guide so that contributors know what conventions they should follow. We should be sure to include at least:

• spaces after all commas (in indexing expressions, tuples, function declarations, function calls)
• Docstring conventions
• No trailing whitespace
• 4 space indentation (no tabs, not 2 or 8 spaces)
• Either 80 or 92 column limit per line (I've always done 80 -- official Julia contributor guide recommends 92. We need to make a decision here. Any comments?)
• All keyword arguments must be typed
• Function arguments that go onto new lines should be indented all the way to the column where the first function argument begins (note that despite what I have in the example below, function arguments should be put on the same line unless they will violate the max column rule):

# bad
function foo(x::Int,
    y::Float64)
    x + y
end

# good
function foo(x::Int,
             y::Float64
    x + y
end

• All new functionality must be tested before it will be merged
• Types and module names should be UpperCamelCase
• Function names should be lowercase, words separated by underscore (_) as needed
• Functions should be separated by ecactly 1 line of whitespace
• One line functions should be one line:

# bad
function foo(x::Int, y::Float64)
    x + y
end

# good
foo(x::Int, y::Float64) = x + y

• If one line function exceeds max column limit on single line, use the trailing = and 4 space rule:

Basis(p::AnyParam, ps::AnyParam...) =
    Basis(Basis(p), Basis[Basis(p) for p in ps]...)::Basis{length(ps) + 1}

• No whitespace around default function arguments

# bad
foo(x::Int, y::Float64 = 1.0) = x + y

# good
foo(x::Int, y::Float64=1.0) = x + y

• Make sure code runs on latest release and dev version of Julia (utilize Compat.jl as necessary).

There are probably others. Please comment and let me know if I left anything out. Or feel free to propose alternatives to what I have here.

I ran into this issue today while trying to run some code in 0.4. I don't really have an idea what's going on, and unfortunately no time to look into it now, but I still thought I'd mention it here.

I was looking over our coverage results and noticed that we don't test lu_solve or eigen_solve at all.

Is the gth_solve algorithm strictly better? If so, I would vote to remove the other two algorithms entirely.

cc: @oyamad @ZacCranko

We don't have a Julia version of the ivp module

Right now the main performance bottleneck in the library is linear interpolation.

We are currently using Grid.jl, which has by its authors been described as flexible, but slow.

There is a new package Dierckx.jl that wraps a fortran library that is supposed to feel like the routines in spicy.interpolate, but run at Fortran speeds.

We should look in to it.

We don't have a direct representation of the cartesian module from the python side.

I think the function in the python library is actually somewhat like the repeat function from the Julia standard library. @albop, can you confirm that?

new stuff in python version for this too

We don't have a Julia version of the robustlq module

Don't have a julia version of the matrix_eqn module

On the Python side lqcontrol.py has been updated to handle cross-product terms

http://quant-econ.net/py/lqcontrol.html#adding-a-cross-product-term

Same functionality required on Julia side.

Right now we are using FactCheck.jl mainly to group tests.

On 0.5-dev we can now use @testset to accomplish this.

On 0.4 we can use the BaseTestNext.jl library to use the new 0.5 Base.Test module.

See here for an example of how to do this

this line specifically.

I think there may be more in the get_greedy! methods too

We have a lot of old branches. Not sure which ones can be deleted, but would love to clean it out. Any branches that we should leave alone (besides any that are in a PR)?

Right now these live in a different repo: https://github.com/spencerlyon2/CompEcon.jl

Before they are merged a few things need to happen:

• Tests
• Docstrings
• Decide on API. Do we want to expose the original API and a more Julian type-based API? That is kinda how it works right now, and it might help new users familiar with the Matlab tool box ease into using this package and Julia. However, the Julian interface should be the first class member here.
• Make sure there are no legal/copyright issues here. Need to revisit old email conversations from last summer and make sure we have permission to do this.

The brent method for Optim.jl's optimize function seems to be more fickle than brentq from scipy.

The solution for exercise 4 didn't work because optimize kept complaining that the lower bound of the search region was not less than the upper bound (an annoying, albeit reasonable complaint).

I just noticed that:

On the Python side the routine for Tauchen style discretization of an AR(1) is called approx_markov and lives in a file called tauchen.py

On the Julia side the same routine is called tauchen and lives in a file called markov_approx.jl

I guess we should unify. In fact I suggest we call both routines tauchen and put them in mc_tools.py and mc_tools.jl respectively.

The Julai versions of the files in this module are both contained in the standard library.

The rank_est function from our python library is named rank in the Julia standard library

The nullspace function from our python library is named null in the Julia standard library

This is simply a note to make devs aware of the difference and perhaps a reminder to make a note about this difference in the Julia documentation when it comes out.

(RFAC is short for refactor)

When using QuantEcon in my current 0.4.0 build, I'm getting

LoadError: LoadErrror: LoadError: Invalid doc exprression [eigen_solve,lu_solve,gth_solve]

This seems to be caused by line 145 in mc_tools.jl, simply commenting out this line fixes it for me (but probably breaks part of the documentation).

I've never written any documentation in Julia, so I don't have any idea what the problem is and how to fix it unfortunately, but it looks like an easy fix.

This algorithm is easily parallelizable.

As a first shot we might want to implement this using the DArray type. We can refer to this implementation of the game of life to see how it works. If that doesn't give us what we want, we could easily just distribute indices/chunks of the array, have each process update their chunk, then have the master process organize them back into the original array in preparation for the next iteration.

This really doesn't need to be its own issue, but there are enough open PRs that do different things that I wanted to make sure we noted to close those before implementing anything new.

On Julia 0.4.0-dev master branch which I built right now,

"using QuantEcon" results in the following error

Warning: could not import Base.@math_const into Distributions
ERROR: LoadError: LoadError: LoadError: UndefVarError: @math_const not defined
in include at ./boot.jl:254
in include_from_node1 at ./loading.jl:133
in include at ./boot.jl:254
in include_from_node1 at ./loading.jl:133
in reload_path at ./loading.jl:157
in _require at ./loading.jl:69
in require at ./loading.jl:55
in include at ./boot.jl:254
in include_from_node1 at ./loading.jl:133
in reload_path at ./loading.jl:157
in _require at ./loading.jl:69
in require at ./loading.jl:52
while loading /Users/ranjan/.julia/v0.4/Distributions/src/constants.jl, in expression starting on line 6
while loading /Users/ranjan/.julia/v0.4/Distributions/src/Distributions.jl, in expression starting on line 252
while loading /Users/ranjan/.julia/v0.4/QuantEcon/src/QuantEcon.jl, in expression starting on line 6

I think they changed @math_const on master to something else (Irrational{:symbol} I think).

We really don't need to define this distribution here.

It would be far better to have this in Distributions.jl

Before this can be down we need to fill in these methods.

It is highly likely that we only need to define a subset of them and the rest will be filled in via dispatch on an abstract type.

We should consult the source of Distributions.jl and construct a list of which methods we actually need to implement ourselves before submitting the PR.

Anyone know why this is happening with the master branch on v0.4?

julia> using QuantEcon
WARNING: requiring "Distributions" did not define a corresponding module.
WARNING: requiring "Distributions" did not define a corresponding module.
WARNING: requiring "Distributions" did not define a corresponding module.
WARNING: module Util should explicitly import * from Base
WARNING: module Filters should explicitly import * from Base
WARNING: requiring "Distributions" did not define a corresponding module.
WARNING: requiring "Distributions" did not define a corresponding module.
ERROR: LoadError: LoadError: UndefVarError: MultivariateNormal not defined
 in include at /usr/local/Cellar/julia/HEAD/lib/julia/sys.dylib
 in include_from_node1 at /usr/local/Cellar/julia/HEAD/lib/julia/sys.dylib
 in include at /usr/local/Cellar/julia/HEAD/lib/julia/sys.dylib
 in include_from_node1 at /usr/local/Cellar/julia/HEAD/lib/julia/sys.dylib
 in require at /usr/local/Cellar/julia/HEAD/lib/julia/sys.dylib
while loading /Users/zaccranko/.julia/v0.4/QuantEcon/src/lss.jl, in expression starting on line 41
while loading /Users/zaccranko/.julia/v0.4/QuantEcon/src/QuantEcon.jl, in expression starting on line 120

The line

s = mc_sample_path(P, [0.5, 0.5], 100000)

in the code box at the end of the Simulation section has to be written as

mc = MarkovChain(P)
s = mc_sample_path(mc, [0.5, 0.5], 100000)

(following the change by adbd0db).

In [3]:

s = mc_sample_path(P, [0.5, 0.5], 100000)
LoadError: MethodError: `mc_sample_path` has no method matching mc_sample_path(::Array{Float64,2}, ::Array{Float64,1}, ::Int64)
Closest candidates are:
  mc_sample_path(!Matched::QuantEcon.MarkovChain{T<:Real}, ::Array{T,1}, ::Int64)
  mc_sample_path(!Matched::QuantEcon.MarkovChain{T<:Real}, !Matched::Int64, ::Int64)
  mc_sample_path(!Matched::QuantEcon.MarkovChain{T<:Real}, ::Array{T,1})
while loading In[3], in expression starting on line 1

Docs are pretty old.

They still talk about the models

This might look like this:

random_markov_chain{T}(n::Int, k::Int=n, ::Type{Matrix{T}})  # ==> return dense array
random_markov_chain{T}(n::Int, k::Int=n, ::Type{SparseMatrixCSC{Int,T}})  # ==> return sparse array

Also, having Union{Int,Void} shouldn't be necessary here as it is in python because default arguments can depend on one another. (e.g. def f(n, k=n): is n't possible in python but function f(n, k=n) is possible in Julia)

Now that the doctoring mechanism in 0.4 is stable, we should start adding them to all of our routines.

Most of the text can be borrowed from the python docstrings, but we would want to do heavy reformatting to match the conventions established in the docs for methods in Base

This should address #24

I don't believe, but would have to verify, that we use either Grid or Optim anymore.

I've been browsing through QuantEcon code for income fluctuations problem, and noticed probable typo in definition of get_greedy! operator at src/models/ifp.jl, line 96:

function get_greedy!(cp::ConsumerProblem, V::Matrix, out::Matrix)
    bellman_operator!(cp, v, out, ret_policy=true)
end

The input array with value function values is denoted V, but bellman_operator! is then called with lowercase v (although it looks like that the inplace version of get_greedy is not called in examples or tests, so this hasn't caused problems).