From e314023bf6616e90bcdaeee3b404e000cf35fc37 Mon Sep 17 00:00:00 2001 From: Matt McKay Date: Tue, 5 May 2026 13:33:17 +1000 Subject: [PATCH] maint: remove developer instruction pages, link to project repos (#126) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Developer instructions for QuantEcon.py and QuantEcon.jl have been migrated to the respective project repositories (see QuantEcon.py#740). This removes the now-redundant pages from the website and updates the 'Contribute' buttons to link directly to the CONTRIBUTING.md in each project repo. Deleted pages (all had menu_item: false, none in nav): - pages/python-developers.md (/python-developers/) - pages/julia-developers.md (/julia-developers/) - pages/developer-resources.md (/developer-resources/) - pages/wiki.md (/wiki/) - pages/wiki-py-conda-dev-env.md - pages/wiki-py-docstrings.md - pages/wiki-py-unit-testing.md Updated inbound links: - quantecon-py.md: Contribute button → QuantEcon.py CONTRIBUTING.md - quantecon-jl.md: Contribute button → QuantEcon.jl CONTRIBUTING.md Closes #126 --- pages/developer-resources.md | 36 ----- pages/julia-developers.md | 20 --- pages/python-developers.md | 47 ------ pages/quantecon-jl.md | 4 +- pages/quantecon-py.md | 4 +- pages/wiki-py-conda-dev-env.md | 64 -------- pages/wiki-py-docstrings.md | 286 --------------------------------- pages/wiki-py-unit-testing.md | 134 --------------- pages/wiki.md | 17 -- 9 files changed, 4 insertions(+), 608 deletions(-) delete mode 100644 pages/developer-resources.md delete mode 100644 pages/julia-developers.md delete mode 100644 pages/python-developers.md delete mode 100644 pages/wiki-py-conda-dev-env.md delete mode 100644 pages/wiki-py-docstrings.md delete mode 100644 pages/wiki-py-unit-testing.md delete mode 100644 pages/wiki.md diff --git a/pages/developer-resources.md b/pages/developer-resources.md deleted file mode 100644 index b10db014..00000000 --- a/pages/developer-resources.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Resources for Developers -permalink: /developer-resources/ -menu_item: false ---- -# Resources for Developers - -## Introduction - -If you are new to open source development, here is some information to help you get started. - -Contributions to QuantEcon should follow the canonical open source pattern, via forking the code libraries and sending pull requests. If you’re not familiar with this kind of development there are many useful tutorials lying around, including - -1. [The GitHub Guides](https://guides.github.com/) - -2. [GitHub Help](https://help.github.com/) - -3. [Pull request ettiquette](http://readwrite.com/2014/07/02/github-pull-request-etiquette) - -QuantEcon follows standard best practice coding protocols, such as unit testing and continuous integration. Read on for specific information on development protocols for each language. - -## Other Topics - -### Python Resources - -1. [General Instructions and Style Guide](/python-developers) - -2. [Creating a conda development environment](/wiki-py-conda-dev-env) - -3. [Docstrings and Documentation](/wiki-py-docstrings) - -4. [Unit Testing in QuantEcon](/wiki-py-unit-testing) - -### Julia Resources - -1. [General Instructions and Style Guide](/julia-developers) \ No newline at end of file diff --git a/pages/julia-developers.md b/pages/julia-developers.md deleted file mode 100644 index a542d7a2..00000000 --- a/pages/julia-developers.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Contribute to QuantEcon.jl" -permalink: /julia-developers/ -menu_item: false ---- -# Contribute to QuantEcon.jl - -If you’d like to contribute to [QuantEcon.jl](quantecon-jl.md), a good place to start is the [project issue tracker](http://github.com/QuantEcon/QuantEcon.jl/issues). Those who are new to Julia programming should look out for the [![](https://lh4.googleusercontent.com/ZiAerphdsw1ervUgUhpq_Tbd74tUuogdLP6PL8vGROA3lvW-32fPi8B1OyVtM2Y-mlDM2vubywzz5H_OeqhszHV0Eg31_fX1Bauhox_2R5v4FER7aDg0Egstncbmk82uqJp4qt9X)](https://github.com/QuantEcon/QuantEcon.jl/labels/beginner) tag, indicating [tasks](https://github.com/QuantEcon/QuantEcon.jl/labels/beginner) that are a good entry point to contributing. - -## General Information - -As a programming language, Julia is still new and thus some aspects of the language are still evolving. As a result there may be some changes from time to time in styles and conventions. The upside is that it is fast and quickly being adopted by the broader scientific computing community. The [Julia style guide](https://docs.julialang.org/en/v1/manual/style-guide/index.html) is a good starting point for Julia programming conventions. - -## Writing Documentation - -Julia is currently undergoing a decision process for standardization with regards to documentation. [This issue](https://github.com/JuliaLang/julia/pull/8791) is tracking this discussion. Once a decision has been made and formalized a QuantEcon style guide will be updated to assist Julia contributions. - -## Writing Tests - -One prerequisite for contributions to QuantEcon.jl is that all functions and methods should be paired with [unit tests](https://en.wikipedia.org/wiki/Unit_testing) to verify that they are functioning correctly. A guide to writing tests in Julia is currently in work. diff --git a/pages/python-developers.md b/pages/python-developers.md deleted file mode 100644 index 2339c2f6..00000000 --- a/pages/python-developers.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Contribute to QuantEcon.py" -permalink: /python-developers/ -menu_item: false ---- -# Contribute to QuantEcon.py - - -If you’d like to contribute to [QuantEcon.py](quantecon-py.md), a good place to start is the [project issue tracker](http://github.com/QuantEcon/QuantEcon.py/issues). Those who are new to Python programming should look out for the [![](https://lh6.googleusercontent.com/f5iu-YzQUQJrRiq7Fznofq_Xikw_QvuGYZ8FaZYN9jnE9QR7zvh7QUbYB0K3GdrFtleaY_OAjWC-yMipbVls7loByc7Ea6FErfSHGgL0PRjyFW7866Wp7VZWDGiov4Liytot4HXX)](https://github.com/QuantEcon/QuantEcon.py/labels/beginner) tag, indicating [tasks](https://github.com/QuantEcon/QuantEcon.py/labels/beginner) that are a good entry point to contributing. - -## Set up a Conda development environment - -One of the advantages of the [Anaconda Python environment](https://www.anaconda.com/distribution/) is that it is cheap to set up (and discard) Python environments for development versions of packages and populate them with your favorite scientific tools. For example, if you’re working on QuantEcon.py you might find it useful to set up an environment (containing NumPy, SciPy, etc.) that uses your development version rather than the default ones. This facilitates contributing to QuantEcon.py without worrying about corrupting the Python environment on which your other work depends. - -See [creating a Conda development environment](/wiki-py-conda-dev-env/) - -## Write tests - -All functions and methods contributed to QuantEcon.py should be paired with tests to verify that they are functioning correctly. - -See [unit testing in QuantEcon](/wiki-py-unit-testing/) - -## Write documentation - -We try to maintain a simple and consistent format for inline documentation, known in the Python world as docstrings. The format we use is known as [numpydoc](https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt). It was developed by the numpy and scipy teams and is used in many popular packages. Adhering to this standard helps us - -* Provide a sense of consistency throughout the library - -* Give users instant access to necessary information at the interpreter prompt (either via the built-in Python function help(object_name) or the Jupyter object_name?) - -* Easily generate a reference manual using sphinx’s autodoc and apidoc - -See [docstrings and documentation](/wiki-py-docstrings/) - -Instructions to compile a local version of the documentation can be found [here](https://github.com/QuantEcon/QuantEcon.py/tree/master/docs). This can be useful if you would like to check how your docstrings render in html prior to submitting a pull request. - -## Package structure - -The current structure of QuantEcon.py is relatively flat. The majority of methods are available at the top level namespace for easy access. The Python API is defined by the __init__.py files within the quantecon package. - -## The QuantEcon.py API - -As QuantEcon.py evolves, the structure will naturally move towards having more sub-packages. Every effort should be made to maintain the current API, however if you are submitting a pull request (PR) that results in a necessary change to the current API, this should be highlighted and discussed in the PR on GitHub. - -## Further questions - -We encourage you to reach out to the [QuantEcon team](https://quantecon.org/team) via [contact@quantecon.org](mailto:contact@quantecon.org) or open an issue on [GitHub](https://github.com/QuantEcon/QuantEcon.py/issues) if you have any further questions. diff --git a/pages/quantecon-jl.md b/pages/quantecon-jl.md index e203d51c..d822948e 100644 --- a/pages/quantecon-jl.md +++ b/pages/quantecon-jl.md @@ -21,8 +21,8 @@ A high performance, open source Julia code library for economics

Documentation

  • -

    -

    Contribute

    +

    +

    Contribute

  • diff --git a/pages/quantecon-py.md b/pages/quantecon-py.md index 6c248472..40830420 100644 --- a/pages/quantecon-py.md +++ b/pages/quantecon-py.md @@ -21,8 +21,8 @@ A high performance, open source Python code library for economics

    Documentation

  • -

    -

    Contribute

    +

    +

    Contribute

  • diff --git a/pages/wiki-py-conda-dev-env.md b/pages/wiki-py-conda-dev-env.md deleted file mode 100644 index 2e04a482..00000000 --- a/pages/wiki-py-conda-dev-env.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Creating a Conda development environment -permalink: /wiki-py-conda-dev-env/ -menu_item: false ---- -# Creating a Conda development environment - -One of the advantages of the Anaconda Python environment is that it is cheap to set up (and discard) Python environments for development versions of packages and populate them with your favorite scientific tools. For example, if you’re working on `QuantEcon.py` you might find it useful to set up an environment (containing NumPy, SciPy, etc.) that uses your development version rather than the default one. This facilitates contributing to `QuantEcon.py` without worrying about corrupting the Python environment on which your other work depends. - -Googling will locate plenty of tutorials on setting up Conda environments but here’s a quick start. It assumes that you’ve already installed Anaconda. - -## Step 1: - -[Fork and clone](https://help.github.com/articles/fork-a-repo) a copy of the `QuantEcon.py` repository on to your local machine. - -## Step 2: - -Create a `conda` environment called `quantecon-dev` (say) by opening a terminal and typing - - conda create -n quantecon-dev python=3.11 - -## Step 3: - -Activate the `quantecon-dev` environment: - - conda activate quantecon-dev - -## Step 4: - -Change into your local copy of the `quantecon` repo. For example, on a UNIX-like system, type - - cd /PATH/TO/LOCAL/CLONE/ - -## Step 5: - -Install the required build tool and your local version of `quantecon`: - - pip install flit - -Then install in development mode (editable install), which allows changes to take effect immediately: - - flit install --symlink - -Alternatively, for a non-editable install: - - flit install - -## Other useful commands - -To switch into the `quantecon-dev` Conda environment: - - conda activate quantecon-dev - -To shift back to your default Python environment type - - conda activate base - -To delete the environment type - - conda remove -n quantecon-dev --all - -To list all environments try - - conda info -e diff --git a/pages/wiki-py-docstrings.md b/pages/wiki-py-docstrings.md deleted file mode 100644 index 98c6d905..00000000 --- a/pages/wiki-py-docstrings.md +++ /dev/null @@ -1,286 +0,0 @@ ---- -title: Docstrings and Documentations -permalink: /wiki-py-docstrings/ -menu_item: false ---- -# Docstrings and Documentations - -## Summary - -For a detailed description of the `numpydoc` standard, see [numpy’s actual description](https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt#user-content-documenting-classes) of the style. This should be read by each developer to make sure we understand exactly what is required and what other options we have while documenting. Here is a summary of the key components of that document: - -`numpydoc` style docstrings are written in [restructured text](http://docutils.sourceforge.net/rst.html). They are composed of a short description of the object followed by a few required and optional sections. For functions and methods, these sections are: - -**Required** - -1. Parameters -2. Returns - -**Optional** - -1. Raises -2. See Also -3. Notes -4. References -5. Examples - -The sections for a class are the same, except instead of a `Returns` section there is an `Attribute` section that defines all attributes of the class. - -## What is a docstring? - -A _docstring_ is a string that starts on the first new line immediately after the declaration of a function or a class. Like the body of the function or class, the docstring must be indented 4 spaces. Typically, a docstring is contained within a block string, set off by tripe quotes “”” as shown below: - - def func(a, b): - """ - This is a docstring for a function - """" - - class MyNewClass(object): - """ - This is a docstring for this class. - """ - -## What are docstrings used for? - -Docstrings provide a way for developers to document their code inline. This is very useful for many reasons, among which are: - -1. Writing “”” docstrings (where “”” means following the numpydoc standard desribed below) force developers to provide a concise explanation of what the code is supposed to do. This leads to code that is more focused, efficient, and clear. -2. A good docstring serves as the starting point for other developers who work on code someone else has written (or for the original author who comes back to the code after initially writing it). If the intent of the code is clearly defined in the docstring, then all who work on this code later know exactly what the purpose of the code is. -3. As hinted at above, docstrings are the code printed at the interpreter when users ask for `help` on a particular object. - -## `numpydoc` style docstrings - -`numpydoc` style docstrings are written using [restructured text](http://docutils.sourceforge.net/rst.html) (aka rst: the markup used in sphinx documents), using a special structure. While any restructured text is valid in a numpydoc style docstring, the only required restructured text element is knowing how to define a section. In our docstrings, we will denote sections using the following syntax: - - Section name - ------------ - -The key elements are a line containing only the name of the section followed be another line containing only minus signs (`-`) underneath each character of the section name. - -### Documenting functions and methods - -Using this syntax, a `numpydoc` style docstring for a **function** or **method** is made up of the following elements: - -1. A short description of what the function or class does -2. A section named `Parameters` that explains the object’s input parameters -3. A section named `Returns` that explains that function’s output -4. Any of the following “optional sections”; (in any order): - 1. `Examples`: This section is optional, but strongly recommended and encouraged within QuantEcon (it may be required at some time in the future). Within the section we would include one or more examples for how to use the obejct. - 2. `Notes`: This section provides additional details that help the user or fellow developer understand the function, but were not included in the short description at the beginning. This might include a description of the algorithm or mathematics underlying the function. - 3. `References`: If any journal articles, books, or other publications _or_ 3rd party code were consulted when writing the function, this should be documented in this section. - 4. `Raises`: if the function/class might raise an exception when called, the exception along with cases under which the exception is raised should be documented. - 5. `See Also`: if the function/class is related to another object, we should specify this relation in a `See Also` section. - -Below is an example of such a docstring - - def func(a, b, c=3): - """ - Short description of what the function accomplishes - - Parameters - ---------- - a : scalar(float) - Explanation of what a is used for within the function - - b : array_like(float) - Explanation of what a is used for within the function - - c : scalar(int), optional(default=3) - Explanation of what c is used for within the function - - Returns - ------- - ret1 : type of ret1 - Explanation of the first object returned - - ret2 : type of ret2 - Explanation of the second object returned - - Notes - ----- - Any implementation notes that help understand how/why the function - was written the way it was. This section is optional. - - References - ---------- - In this section we include any references to papers/articles/other - reading material or other code that we referenced when writing the - function - - Examples - -------- - >>> a = 130; b = [10, 20, 30] - >>> func(a, b) - <function output copied and pasted> - - Raises - ------ - ValueError - If any parameters are equal to `None.` - - """ - -There are a few additional points to mention here: - -* When listing parameters and return types, we start by providing the variable name, then space-colon-space, then the type of the object. Additionaly, if the parameter is optional, we say this. I also like to give the default value in parenthsis after the word optional (see the line for the parameter `c` above) -* We should make sure that each line in a docstring is no longer than 72 characters (as specified in the official python style guide, [PEP8](http://legacy.python.org/dev/peps/pep-0008/)) -* The examples section should feel just like a copy/paste from an interactive python session where the example’s code was executed. -* There should be a blank line at the end of the docstring. -* When documenting a method, do not include `self` in the list of parameters. - -### Documenting classes - -The `numpydoc` standard for documenting classes is very similar. The key components are (this all goes the first line of the docstring that is below the line containing the `class` keyword) - -1. A short description of what the class does -2. A `Parameters` section that describes the parameters for the class’s `__init__` function -3. An `Attributes` section that describes all the attributes of the class. This replaces the `Returns` section we saw above for functions and methods. -4. Any of the optional sections outlined above in addition to an optional section describing the `Methods`that are implemented specifically for this class. - -**Remark** There is often overlap between the parameter list and the attribute list. To avoid repetition attributes already discussed in the parameter list can be entered in the attributes list in the form `a, b, c : seeParameters`. An example is given below. - -## Examples - -Below I will provide some examples. These are copied and pasted from the source of some code we are already using, or will soon be using from within QuantEcon. For additional examples, see these two references: - -* [Example 1](http://sphinxcontrib-napoleon.readthedocs.org/en/latest/example_numpy.html) -* [Example 2](https://github.com/numpy/numpy/blob/master/doc/example.py) - -### Function example - - def poly_inds(d, mu, inds=None): - """ - Build indices specifying all the Cartesian products of Chebychev - polynomials needed to build Smolyak polynomial - - Parameters - ---------- - d : scalar(int) - The number of dimensions in grid / polynomial - - mu : scalar(int) - The parameter mu defining the density of the grid - - inds : list(list(int)), optional(default=None) - The Smolyak indices for parameters d and mu. Should be computed - by calling `smol_inds(d, mu)`. If None is given, the indices - are computed using this function call - - Returns - ------- - phi_inds : array_like(int, ndim=2) - A two dimensional array of integers where each row specifies a - new set of indices needed to define a Smolyak basis polynomial - - Notes - ----- - This function uses smol_inds and phi_chain. The output of this - function is used by build_B to construct the B matrix - - """ - -### Class example - - class SmolyakGrid(object): - """ - This class currently takes a dimension and a degree of polynomial - and builds the Smolyak Sparse grid. We base this on the work by - Judd, Maliar, Maliar, and Valero (2013). - - Parameters - ---------- - d : scalar(int) - The number of dimensions in the grid - - mu : scalar(int) or array_like(int, ndim=1, length=d) - The "density" parameter for the grid - - Attributes - ---------- - d, mu : see Parameters - - lb : array_like(float, ndim=2) - This is an array of the lower bounds for each dimension - - ub : array_like(float, ndim=2) - This is an array of the upper bounds for each dimension - - cube_grid : array_like(float, ndim=2) - The Smolyak sparse grid on the domain :math:`[-1, 1]^d` - - grid: : array_like(float, ndim=2) - The sparse grid, transformed to the user-specified bounds for - the domain - - inds : list(list(int)) - This is a lists of lists that contains all of the indices - - B : array_like(float, ndim=2) - This is the B matrix that is used to do lagrange interpolation - - B_L : array_like(float, ndim=2) - Lower triangle matrix of the decomposition of B - - B_U : array_like(float, ndim=2) - Upper triangle matrix of the decomposition of B - - Examples - -------- - >>> s = SmolyakGrid(3, 2) - >>> s - Smolyak Grid: - d: 3 - mu: 2 - npoints: 25 - B: 0.65% non-zero - >>> ag = SmolyakGrid(3, [1, 2, 3]) - >>> ag - Anisotropic Smolyak Grid: - d: 3 - mu: 1 x 2 x 3 - npoints: 51 - B: 0.68% non-zero - - """ - - Method example - -------------- - def interpolate(self, pts, interp=True, deriv=False): - """ - Basic Lagrange interpolation, with optional first derivatives - (gradient) - - Parameters - ---------- - pts : array_like(float, ndim=2) - A 2d array of points on which to evaluate the function. Each - row is assumed to be a new d-dimensional point. Therefore, pts - must have the same number of columns as ``si.SGrid.d`` - - interp : bool, optional(default=false) - Whether or not to compute the actual interpolation values at pts - - deriv : bool, optional(default=false) - Whether or not to compute the gradient of the function at each - of the points. This will have the same dimensions as pts, where - each column represents the partial derivative with respect to - a new dimension. - - Returns - ------- - rets : list(array(float)) - A list of arrays containing the objects asked for. There are 2 - possible objects that can be computed in this function. They will, - if they are called for, always be in the following order: - - 1\. Interpolation values at pts - 2\. Gradient at pts - - If the user only asks for one of these objects, it is returned - directly as an array and not in a list. - - References - ---------- - This is a stripped down port of ``dolo.SmolyakBasic.interpolate`` - - """ diff --git a/pages/wiki-py-unit-testing.md b/pages/wiki-py-unit-testing.md deleted file mode 100644 index 5bd0749b..00000000 --- a/pages/wiki-py-unit-testing.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: Unit Testing in QuantEcon -permalink: /wiki-py-unit-testing/ -menu_item: false ---- -# Unit Testing in QuantEcon - -## Summary - -The QuantEcon package uses [pytest](https://docs.pytest.org/) to manage tests. We adhere to some conventions to facilitate ease of maintenance and management of test cases. The main conventions are as follows: - -* Tests live in Python files, which in turn live in `quantecon/tests/` -* These test files should be prepended with `test_` followed by module name (e.g., tests for `asset_pricing.py` should be found in `quantecon/tests/test_asset_pricing.py`). -* Test files should contain test functions prefixed with `test_`. - -## Test Fundamentals - -The basic premise of testing in Python is to write functions that make assertions. An assertion checks a given logical condition. If the condition is met, then the program continues onto the next line. If not, the assertion will trigger an Exception and issue an `AssertionError`. Here's a simple example: - -```python -def test_equal(a, b): - """ - This tests for equality between two arguments a and b - """ - assert a == b, "Test failed: Arguments are not equal." -``` - -If `a=2` and `b=1` then this test would fail and raise an `AssertionError` with the message string after the comma. - -pytest parses Python files in the QuantEcon repository and collects all tests (i.e., all functions that satisfy the test naming convention discussed below). It then runs them one by one and provides you with a report of which passed and which failed. - -To run the test suite, you need to type `pytest` at the command line, or `pytest -v` for a more verbose report. - -### Test Function Names - -When `pytest` parses the repository looking for tests, it will search for functions prefixed with `test_`. Examples: - -* `test_somethinghere` -* `test_my_function_returns_correct_value` - -When naming your test function, remember to use PEP8 convention. Also make sure you clearly indicate what part of a module (be it a function or class etc.) that your test is testing. - -### Assertion Methods - -While it's fine to construct your own logic and messaging using `assert` statements as above, note that there are also many helpful pre-existing assertion methods available in other packages, such as - -1. [numpy.testing](https://numpy.org/doc/stable/reference/routines.testing.html) -2. [pandas.testing](https://pandas.pydata.org/docs/reference/testing.html) - -These packages are used throughout QuantEcon, so it is safe to use functions and methods from them directly using import statements such as: - -```python -from numpy.testing import assert_allclose -``` - -This particular function is useful in testing if an array matches a known solution, allowing for a degree of tolerance through the `rtol=` relative tolerance or `atol=` absolute tolerance keyword arguments. - -To learn more, you can browse some of the files in `quantecon/tests/` and learn from these examples. - -### Example: A Basic Test - -Let's look at an example, concerning a basic test for the `mc_compute_stationary` function from the `mc_tools.py` module. - -We will use a known matrix and compute its stationary distribution. - -$$ P := \left( \begin{array}{cc} 0.4 & 0.6 \\ 0.2 & 0.8 \end{array} \right) $$ - -We know that the unique stationary distribution should be (0.25, 0.75) - -Now let's write a test case in the file: `tests/test_mc_tools.py`: - -```python -import numpy as np -from numpy.testing import assert_allclose -from quantecon import mc_compute_stationary - -def test_mc_compute_stationary_pmatrix(): - """ - Test mc_compute_stationary for a Known Solution of Matrix P - """ - P = np.array([[0.4, 0.6], [0.2, 0.8]]) - P_known = np.array([0.25, 0.75]) - computed = mc_compute_stationary(P) - assert_allclose(computed, P_known) -``` - -Note: We use `assert_allclose` rather than exact equality because computed results and perfect analytical results are often very close but not quite equal due to floating point precision. - -### Making Tests More General - -You can use pytest's parametrize decorator to run the same test with multiple inputs: - -```python -import pytest -import numpy as np -from numpy.testing import assert_allclose -from quantecon import mc_compute_stationary - -@pytest.mark.parametrize("P,expected", [ - (np.array([[0.4, 0.6], [0.2, 0.8]]), np.array([0.25, 0.75])), - (np.array([[1.0, 0.0], [0.0, 1.0]]), np.array([0.5, 0.5])), -]) -def test_mc_compute_stationary_pmatrix(P, expected): - """ - Test mc_compute_stationary for known solutions - """ - computed = mc_compute_stationary(P) - assert_allclose(computed, expected) -``` - -## Running Tests - -To run all tests: - -```bash -pytest -``` - -To run tests in a specific file: - -```bash -pytest quantecon/tests/test_mc_tools.py -``` - -To run a specific test: - -```bash -pytest quantecon/tests/test_mc_tools.py::test_mc_compute_stationary_pmatrix -``` - -## Resources - -* [pytest Documentation](https://docs.pytest.org/) -* [NumPy Testing Guide](https://numpy.org/doc/stable/reference/routines.testing.html) diff --git a/pages/wiki.md b/pages/wiki.md deleted file mode 100644 index cc44a903..00000000 --- a/pages/wiki.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Wiki -permalink: /wiki/ -menu_item: false ---- -# Wiki - - -This wiki contains information for developers writing code for QuantEcon. - -All contributions to QuantEcon should follow the conventions described here on docstrings, coding style, testing, etc. - -### Python instructions - -* [Creating a Conda development environment](/wiki-py-conda-dev-env) -* [Docstrings and Documentation](/wiki-py-docstrings) -* [Unit Testing in QuantEcon](/wiki-py-unit-testing) \ No newline at end of file