Update SymPy in Equalizing Differences Lecture

[HumphreyYang]

Hi @jstac and @mmcky,

This PR is a preview of using SymPy to solve equalizing differences model.

I put the code into the last section as a draft, which is a replicate of what has been done in NumPy. I feel the SymPy version of the implementation is more concise and intuitive.

I think this lecture may be better presented if we use the SymPy version to guide students through the equations and explore graphs and derivatives, and we put the NumPy version as an exercise to ask students to implement this model in NumPy. The benefit is that readers can see the code and derivation immediately after they see the formula, and it is light in terms of designing the code.

Could you please kindly let me know your thoughts on this?

Many thanks in advance.

[netlify]

✅ Deploy Preview for taupe-gaufre-c4e660 ready!

Name	Link
🔨 Latest commit	3afb4a3
🔍 Latest deploy log	https://app.netlify.com/sites/taupe-gaufre-c4e660/deploys/64ebfeef00389c0008a40512
😎 Deploy Preview	https://deploy-preview-284--taupe-gaufre-c4e660.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mmcky]

@HumphreyYang I am a bit confused. Is this migrating the sympy code from QuantEcon/lecture-python-programming.myst#284?

[HumphreyYang]

@HumphreyYang I am a bit confused. Is this migrating the sympy code from QuantEcon/lecture-python-programming.myst#284?

Hi @mmcky,

Yes, this is trying to apply the SymPy code to this lecture. While I am migrating, I find SymPy code might illustrate the concept better, so I put them into the last section of this lecture to ask for your opinion on this.

[github-actions]

🚀 Deployed on https://64ec0254c2bf4d402bbc5f02--taupe-gaufre-c4e660.netlify.app

[HumphreyYang]

Hi @shlff and @Smit-create.

I have written a SymPy version of equalizing differences model lecture. Our aim is to present this lecture better by giving the code immediately after the formula and using simpler code in SymPy. So I am selling this to you first for your review/opinions.

Please find the new SymPy version here:
https://64d2d007debf9d0099ab5c52--taupe-gaufre-c4e660.netlify.app/equalizing_difference

and the old version here:
https://intro.quantecon.org/equalizing_difference.html

Many thanks in advance.

[shlff]

Thanks @HumphreyYang . I will take a quick review soon.

[jstac]

@shlff and @mmcky please let me know your thoughts.

[mmcky]

@HumphreyYang I really like the sympy version of this lecture. One aspect of sympy I find tricky is the order of computation can lead to different outcome expressions (degree of simplification) which makes comparison a bit harder. Is that what is going on here (for example)?

[HumphreyYang]

@HumphreyYang I really like the sympy version of this lecture. One aspect of sympy I find tricky is the order of computation can lead to different outcome expressions (degree of simplification) which makes comparison a bit harder. Is that what is going on here (for example)?

Hi @mmcky,

That is right. I think it is a problem of symbolic programming in general. For simple expressions, they can present them pretty well, but for more complex cases (i.e. taking a derivative of a complex equation), it can look messy.

In defense of sympy, the solution for the derivative of pv -- derivative of a series of quotients with powers above and below the division line will be messy for human writers if we do not introduce new symbols : )

Nonetheless, I think the previous numpy version also has this derivative section as well. The main contribution of this PR mainly is to remove the long Python classes and functions in the main text to represent the present values more concisely in sympy.

[mmcky]

Nonetheless, I think the previous numpy version also has this derivative section as well. This PR mainly removes the long Python classes and functions to represent the present values more concisely in sympy.

@HumphreyYang so the variations in the values that are computed from the default values -- is that expected - or is there something stochastic going on in generating those values.

[HumphreyYang]

@HumphreyYang so the variations in the values that are computed from the default values -- is that expected - or is there something stochastic going on in generating those values.

Hi @mmcky,

Many thanks for raising this!

This is expected. My model was inherited from the previous section with an entrepreneur component, and thus with a $\pi$ terms and $\pi = 0.2$. If we set $\pi = 1$, then there is no entrepreneur component, which produces the same results as before (see replication here).

The rationale for this deviation is that, in the current version, the text does not flow well given the derivative is calculated based on the formula in the first model, instead of the second model (entrepreneur model), so there is a jump back to the first model in our derivative analysis. This PR fixes this issue by presenting the entrepreneur model, which is a generalization of the first model (the first model is just a special case of the entrepreneur model with $\pi = 1$)

[mmcky]

Thanks for explaining that @HumphreyYang that makes sense.

[HumphreyYang]

Thanks for explaining that @HumphreyYang that makes sense.

Did I successfully sell this to you @mmcky? If yes, we can pass it on to John I guess : )

[jstac]

Typo in original: "And doing that will let illustrate how good Python is at doing calculus!"

[jstac]

Hi @HumphreyYang (CC @mmcky). I reviewed this and, although the coding is very nice, I have mixed feelings about it.

Our core mission is quantitative economics, and working with NumPy is a simpler approach to basic quantitative analysis. So I think we should start with NumPy code. I suggest that we do a clean up of the NumPy code and then show how SymPy can add to the analysis in a separate section.

I propose that we

• close this PR (but @HumphreyYang keeps the md file)
• discuss our concerns about the NumPy code with @thomassargent30 and ask permission to improve it
• clean up the NumPy code in one PR (replace class with named tuple, eliminate all the functions in the code cell that starts with # ϕ_R, etc.)
• improve the SymPy code in a second PR.

Sound reasonable?

[HumphreyYang]

Many thanks @jstac,

Sounds great to me!