Add a generate_cutting_experiments function

[caleb-johnson]

This should be the first PR to be merged into main based on #352 .

This creates a public function generate_cutting_experiments which largely mimics the current private function of the same name in cutting_evaluation. This function is being moved to cutting_decomposition, as subexperiments will be created in that module starting in 0.4.0.

This PR should not be merged prior to 0.3.1, so I am putting it on hold.

The private _generate_cutting_experiments will be removed along with the module cutting_evaluation in a following PR.

[coveralls]

Pull Request Test Coverage Report for Build 5932193014

• 101 of 101 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.2%) to 92.088%

---

Totals
Change from base Build 5918830797:	0.2%
Covered Lines:	3026
Relevant Lines:	3286

---

💛 - Coveralls

[garrison]

This PR should not be merged prior to 0.3.1, so I am putting it on hold.

I'll just comment on this part, which is: once finalized and approved, we can merge this to main anytime, as backport-able changes can be backported to the stable/0.3 branch, and 0.3.1 will be tagged (if we tag such a release) from this branch too.

[caleb-johnson]

"samples to draw from the quasi-distribution representing the cuts." maybe? hmm

[caleb-johnson]

@garrison , this should be ready to be looked at. It's just moving a function and exposing it to the public API. It also adds unit tests, since this function isn't covered by the e2e tests. This function isn't used anywhere in the software or tutorials. It will be used in a later PR when we remove execute_experiments

[garrison]

Thanks!

Attached are my comments at the moment, though I am going to have to work with this a bit to tell which of the remaining code (if any) is new, or rather the few details that have been modified. In general, it's easier to review if the pull requests that change code/interfaces are distinct from the ones that purely move code. This is fine -- I can definitely work with this -- but ideally it would have been

1. Remove the underscore to make the function public, add docstring(s), and add tests in the location appropriate for the code after the move (first PR). In the PR's rationale, mention which functions/classes/etc. you plan to move (and where) in a subsequent PR. This will minimize the diff in this stage to actual code changes.
2. Actually move the code itself, without changing anything other than import lines (second PR)

This would also have avoided the brief period in which the function is duplicated (public & private versions in the repo at once).

will be removed along with the module cutting_evaluation in a following PR.

I wonder if we can/should keep execute_experiments only as a deprecated function? (and remove it in a subsequent release)

[caleb-johnson]

I wonder if we can/should keep execute_experiments only as a deprecated function? (and remove it in a subsequent release)

We could do that, but it would no longer consume the output of partition_problem. Users would have to pack up the 1D list into that 3D list themselves.

[caleb-johnson]

Closing in favor of #385