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
A normal usecase for the DDS SolveBoard() method is to:
Call SolveBoard() for the opening lead and play the suggested card for say West.
Have the user (North) play a card.
Call SolveBoard() again
etc.
As I see it, it must be possible to reuse the transposition table and the rel/aggr structures in all calls after 1).
To make this possible, the test for NewDeal should only validate that all cards in the current deal was in the same hand as when the transposition table was initiated.
I've actually got it working with very minimal changes to the code. That is when the new deal is a subset of the old one. But is now working on a superset version also. By this I mean situations where all cards in the deal stored in the transpositiontable are placed in the same hands in the new deal and none of the extra cards was present in the former deal. This can be handled by "filling in the blanks" in the rel and aggr structures.
There is also a number of small errors like indexing with an negative value when cards count is 4 and setting upperbound to 13 when there is fewer cards
The text was updated successfully, but these errors were encountered:
A normal usecase for the DDS SolveBoard() method is to:
etc.
As I see it, it must be possible to reuse the transposition table and the rel/aggr structures in all calls after 1).
To make this possible, the test for NewDeal should only validate that all cards in the current deal was in the same hand as when the transposition table was initiated.
I've actually got it working with very minimal changes to the code. That is when the new deal is a subset of the old one. But is now working on a superset version also. By this I mean situations where all cards in the deal stored in the transpositiontable are placed in the same hands in the new deal and none of the extra cards was present in the former deal. This can be handled by "filling in the blanks" in the rel and aggr structures.
There is also a number of small errors like indexing with an negative value when cards count is 4 and setting upperbound to 13 when there is fewer cards
The text was updated successfully, but these errors were encountered: