QuantEcon / QuantEcon/QuantEcon.py
Repeated logic in several modules
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2.4k
- Forks
- 2.3k
- Avg merge
- 3d 3h
- Merged PRs (30d)
- 3
Description
There are several existing classes that appear to be reproducing closely related functionalities, thus violating the "Don't Repeat Yourself" principle which is outlined in one of the lectures in one of the lectures. For instance, all the following modules include a form of a linear state transition equation
robustlq.pylss.pylqnash.pylqcontrol.pyarmy.pykalman.py
#476 introduces yet another class which falls into this group. The ARMA class has a simulation method, the LQ class has a compute_sequence method and the LinearStateSpace has a simulate method. Besides, both Kalman and LQ have stationary_values methods that use solve_discrete_riccati. Similarly, LinearStateSpace and ARMA have impulse_response methods.
Therefore, we might want to consider refactoring these classes, potentially into a sub-package. Besides avoiding repetition and making it easier to understand how these classes are connected, another benefit would be that features added to a base class would directly propagate to derived classes.
As @thomassargent30 pointed out, this refactoring is bound to take some time and require a person who is familiar with all of the lectures that use these classes. Considering that some new lectures which use these classes are currently in production, @jstac suggested that we hold off on a major reorganization and instead consider piecemeal improvements. Specifically, we could add a linear_gaussian module that contains:
-
a jitted function that simulates vector-valued Gaussian processes, and
-
a jitted function that returns the stationary mean and variance.
Does anyone have any additional thoughts or suggestions?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing the repeated methods in robustlq.py, lss.py, lqnash.py, lqcontrol.py, army.py, and kalman.py, along with the ARMA, LQ, and LinearStateSpace classes introduced in the issue. Review issue #476 and the proposed linear_gaussian module; done requires an agreed refactoring scope and changes that preserve the existing simulation, stationary-values, and impulse-response behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100