Sheffield | 25-SDC-Nov | Sheida Shabankari | Sprint 2 |improve with caches

[sheida-shab]

• I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
• My changes meet the requirements of the task
• I have tested my changes
• My changes follow the style guide

PR summary :

Add manual caching to speed up recursive Fibonacci and ways_to_make_change functions.

• Use dictionaries to store results of already computed subproblems.
• In Fibonacci, store fibonacci(n) values to avoid recalculating them.
• In ways_to_make_change, use a key (total, tuple(coins)) to remember results for each combination of total and remaining coins.
• All recursive calls share the same cache to reuse previous results, without using @cache.
• These changes reduce repeated calculations and make the functions much faster for large inputs.

[cjyuan]

Why not use {} as the default value for cache?

[sheida-shab]

If I use {} as the default value, the cache is shared between all function calls .
Not only between recursive calls, but between every call to the function in the whole program.

This happens because default arguments in Python are created once, when the function is defined.

If I use None instead, then every time ways_to_make_change is called,
a new cache dictionary is created.

At the same time, all recursive calls share that same cache,
which is exactly what we want for memoisation .

[cjyuan]

Thanks for clarification. I didn't know that.

Here are two alternatives,

1. Create the cache in ways_to_make_change() and then pass it to ways_to_make_change_helper(), or

2. Define ways_to_make_change_helper() as an inner function of ways_to_make_change(), and then have
   the inner function share the cache declared in ways_to_make_change().

[sheida-shab]

Thanks for the suggestions!

I’ve updated the code again based on your guidance. I now create the cache in
ways_to_make_change() and pass it into the helper function, so the cache is scoped
to a single top-level call but shared across all recursive calls.

[cjyuan]

Array creation is a relatively costly operation.

From line 34, we know coins can only be one of the following 9 arrays:

[200, 100, 50, 20, 10, 5, 2, 1]
[100, 50, 20, 10, 5, 2, 1]
[50, 20, 10, 5, 2, 1]
...
[1]

We could further improve the performance if we can

• avoid repeatedly creating the same sub-arrays at line 41 (e.g. use another cache), and
• create key as (total, a_unique_integer_identifying_the_subarray) instead of as (total, tuple of coins)
  • There are only a small number of different subarrays. We can easily assign each subarray a unique integer.

[sheida-shab]

Refactor memoisation to avoid repeated sub-array creation

Precompute all possible coin sub-arrays once and identify them by index.
Use (total, subarray_id) as the cache key instead of (total, tuple(coins)),
so recursive calls reuse the same sub-arrays and avoid unnecessary list
and tuple allocations.

[cjyuan]

Looks good. Well done.