You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, great library, clean approach! However, I have a couple of suggestions
Introduce memoization for find_all_solutions. While thinking about other problems, I've found that if next_state function can return the same result for two different inputs (that is if next_state is not bijection), a lot of solutions will be recomputed. It would be nice if this solver could store the %{state => next_state(state)} kind of map to avoid recomputations
find_all_solutions function is craving for parallelization.
Minor, it would be nice if you could remove examples from lib, so that they won't be loaded into runtime of the program which uses this dependency
The text was updated successfully, but these errors were encountered:
Thank you for the feedback. I've pushed a feat/memoization branch. Maybe you can try whether this approach speeds things up for you? I tried with the Hamiltonian Path and a relatively large graph, but it just made things slower:
Hi, great library, clean approach! However, I have a couple of suggestions
Introduce memoization for
find_all_solutions
. While thinking about other problems, I've found that ifnext_state
function can return the same result for two different inputs (that is ifnext_state
is not bijection), a lot of solutions will be recomputed. It would be nice if this solver could store the%{state => next_state(state)}
kind of map to avoid recomputationsfind_all_solutions
function is craving for parallelization.Minor, it would be nice if you could remove examples from
lib
, so that they won't be loaded into runtime of the program which uses this dependencyThe text was updated successfully, but these errors were encountered: