search

QuantEcon / book-dp1-public-companion

Dynamic Programming Volume 1
https://quantecon.github.io/book-dp1-public-companion/
BSD 3-Clause "New" or "Revised" License
109 stars 23 forks source link

Chapter 5: Python Code #3

Closed Smit-create closed 2 years ago

Smit-create commented 2 years ago

Results from firm exit: firm_exit_1 firm_exit_2

Smit-create commented 2 years ago

I modified the code slightly ( fixed some minor bugs) to make it jit compile and got the following results: american_option_1 american_option_2

Smit-create commented 2 years ago

@jstac Does this look good now?

jstac commented 2 years ago

Thanks @Smit-create , please see my comments above.

jstac commented 2 years ago

Thanks @Smit-create . I wonder if we should modify cartesian to be jit-aware --- otherwise we will need to repeat your product function in quite a few files for this project. It's just a suggestion and I'm open to other ideas.

Regarding the figures, I notice that the font size for "in the money" and "out of the money" is too large in the Python code (please see above).

Finally, for successive approximation, perhaps we should use https://quanteconpy.readthedocs.io/en/latest/tools/compute_fp.html

Smit-create commented 2 years ago

Finally, for successive approximation, perhaps we should use https://quanteconpy.readthedocs.io/en/latest/tools/compute_fp.html

I was trying to avoid using direct library functions so that if anyone tries to compare python and Julia code, it would be easy to relate the things easily.

Smit-create commented 2 years ago

Fixed the plot american_option_2

Smit-create commented 2 years ago

I wonder if we should modify cartesian to be jit-aware

We can try to make that change in the quantecon itself? I mean we can try to make the functions/classes jit-aware as much as we can?

Smit-create commented 2 years ago

Thanks, @jstac. I have addressed your comments. If we replace successive_approx with compute_fp then we will need to do that in all the previous code to maintain uniformity and that will make it differ slightly from Julia code. Should I change that? Or keep the current version?

jstac commented 2 years ago

Thanks for the fixes @Smit-create

If we replace successive_approx with compute_fp then we will need to do that in all the previous code to maintain uniformity and that will make it differ slightly from Julia code. Should I change that? Or keep the current version?

I hadn't thought about this carefully enough. How about this policy: we don't worry about matching Python and Julia code, as long as we reproduce the figures.

As a general rule, let's write the Python code as efficiently as possible, and with minimal repetition.

Following this rule, let's use compute_fp here. But there's no need to go back and change the earlier ones --- it might be good for people who are starting out to see all the details.

Smit-create commented 2 years ago

As a general rule, let's write the Python code as efficiently as possible, with minimal repetition.

Thanks, @jstac. I just replaced the product and instead used loops with prange and also used compute_fp from quantecon. This works very fast now.

jstac commented 2 years ago

Very nice work @Smit-create . I'll merge this now.