Fixes to Monte Carlo chapter

[leios]

Feature Request

As described in #658, the Monte Carlo (MC) chapter is in a somewhat dire need of a rework

Description

Right now, several implementations in the MC chapter have been written with the specific intent of integrating pi, not for general-purpose MC integration.

This is because the text is somewhat ambiguous. It should clearly state that calculating the area of the circle is the same as finding an approximation for pi. It should also highlight that MC is general-purpose and can be used for more than calculating the area of a circle (this was why we had an in_circle() function that could be abstracted into an shape).

Right now, it seems like we need to do the following:

• [ ] Fix the example code so it can integrate arbitrary shapes. This simply means that implementations should not have the circle changing with grid-size to always return pi.
• [ ] Show another shape. A square, maybe? Batman logo (http://leios.github.io/Batman_Montecarlo)?
• [ ] Fix the text (specifically in the example code section) so it highlights the fact that integrating the area of the circle is the same as finding an approximation for pi, and that we are using this fact to make sure we are integrating correctly.
• [ ] Modify the code to integrate a full circle, not just a quarter.

For Algorithm Archive Developers

• [ ] This feature can be added to the Master Overview (if it cannot be, explain why in a comment below -- lack of technical expertise, not relevant to the scope of this project, too ambitious)
• [ ] There is a timeline for when this feature can be implemented
• [ ] The feature has been added to the Master Overview
• [ ] The feature has been implemented (Please link the PR)

[thecnoNSMB]

I just checked all the implementations, and as of now only the Factor implementation has a general Monte Carlo integrator that outside code uses to approximate pi. All other implementations combine both of those steps in the same function or code block intended to return pi.

[leios]

I think all implementations are fine as long as the radius is set at the in_circle() level and not the monte_carlo() level. So Julia is fine, but Python is not.

I still need to look into it a bit more

[Amaras]

The Python version (and Coconut one, for that matter) simply define a keyword argument radius that can possibly be changed, if you really want to change it. You could make it more difficult to change the radius in monte_carlo by changing the signature to def monte_carlo(n_samples, *, radius=1), but the complexity increases a bit. Or you could just change the call to in_circle inside monte_carlo from in_circle(point, radius) to in_circle(point, 1). However, I think that it loses the clarity of saying which circle you are talking about, and losing the generality of in_circle.

The choice is on you, but I'm ready to change the codes if needed.

[Krzmbrzl]

Just throwing in a note: It seems that the Monte-Carlo algorithm as described here only discusses simple sampling which works for these easy examples. However for more complicated examples (e.g. used in simulations) simple sampling is just not feasible (doesn't explore the space well enough) and therefore importance sampling is needed. With that the algorithm gets quite a bit more complicated.

I think it should at least be mentioned that such a thing exists and that therefore Monte-Carlo is not always that simple :point_up:

[leios]

Yeah, I agree with this. There are a bunch of monte carlo methods, but I haven't gotten around to them yet... Sorry!

[Krzmbrzl]

Absolutely no need to apologize. I was not meaning to critize anyone. I merely wanted to bring up that these kind of things exist and might be worth mentioning :)