Skip to content

recursion exercises: simplify example solution logic #670

Description

@damon314159

Prerequisites

  • I have thoroughly read and understand The Odin Project Contributing Guide
  • I have searched the existing issues to ensure this improvement hasn't been suggested before (please have a look through our open issues list to make sure)
  • The title of this issue follows the <Location of the improvement>: <Brief description of the improvement> format, e.g. Exercises: Add exercise on XYZ
  • (Optional) I am interested in working on this issue and would like to be assigned to it

Improvement Description

The current recursion exercises 4_permutations and 5_pascal have (imo) overly complicated solutions that make it harder to understand them.

For permutations, the current example solution uses a tail call optimised structure with optional parameters that are passed down into recursive calls, and then the result is built up piece by piece with a series of element swaps. This is generally considered to be a more efficient approach (particularly in languages that can take advantage of TCO, which JS isn't).
But since the objective of these exercises is a learning tool, I think we should make the recursive step as simple and easy to understand as possible.
To that end I suggest we remove the optional parameters, have the base case clearly isolated, and then make the recursive call as the 2nd step. Following that you can construct the next set of permutations and return them without muddying the waters with element swapping and other techniques that complicate the logic.

Similarly, for pascal, the current approach defines at the beginning an array, which either gets returned immediately in the base case, or sticks around to be mutated later on for non-base cases. And the usage of a forEach and nullish coalescing operator are also unnecessarily distracting to the learner who is trying to understand the concept, not the syntax.
I suggest we do not use the same array for base case and mutations, and cut the nullish coalescing in favour of explicitly adding zeros before computing the pairwise sums. And finally a standard for-loop will make it obvious why you need one extra iteration compared to the previous row.

I have taken the liberty of writing up a PR with my suggested edits, since describing the changes I propose in enough detail is equivalent to just writing them. Feel free to close it if this issue gets closed.

Acceptance Criteria

  • recursion exercise 4_permutations example solution refactored
  • recursion exercise 5_pascal example solution refactored

(Optional) Additional Comments

No response

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Status: In ProgressThis issue/PR has ongoing work being done

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions