Now that we have the architecture document out of our systems, we can
start working on the 2.9.x development branch. Here's what needs to be
done:
1. Map names to tests.
----------------------
At the time being pointers to the test functions are stored in an array,
and mapping the test letters to these functions is done by using offset
calculations. Thus, whenever a test is added, the indexes in the mapping
function have to be changed. A very unscalable solution.
What I thought was is to have an associative array of names to pointers to
test functions. Someting like that:
struct fcs_test_name_mapping_struct
{
/* A string representing the name */
char * name;
/* The test function ptr */
freecell_solver_solve_for_state_test_t test;
};
typedef struct fcs_test_name_mapping_struct fcs_test_name_mapping_t;
fcs_test_name_mapping_t test_by_names[20] =
{
{ "a", freecell_solver_sfs_move_top_stack_cards_to_founds },
{ "b", freecell_solver_sfs_move_freecell_cards_to_founds }.
.
.
.
};
and so forth - a sorted array that can be queried in time O(log(n)). Then
we can use it to lookup individual tests, and by extending the tests order
parser to accept a "{testname}" notation, we can have more verbose test
names.
2. Derived States Ordering
--------------------------
At the moment derived states when ordered are ordered randomly. What I'd
like to have is a generic way to order the derived way of any tests group
(or random group as it has been called so far). Something like that:
-to "[01234]=shlomif(0.2,0.3)[567]=tomholroyd(0,4,2,0.5,0.3)"
with ={function name} means associating the function with the
previous random group. and whatever comes inside the parenthesis are
parameters to it.
I already created an inheritable class to implemement a generic derived
state ordering mechanism but need to implement a random subclass and a
shlomif subclass of it. And then implement the code in the random-DFS scan
to use them.
3. Integrating Patsolve's prioritization
----------------------------------------
I took a look at Patsolve's source code and understood what are the 5
parameters that determine which state to follow next do. (I forgot it
since then, but I can easily trace them). Using the generic state ordering
mechanism, I can add an equivalent functionality to Freecell Solver. This
will allow running several of Patsolve's scan simultaneously and to
specify the exact behaviour from the command line.
Notice that I will not use the original Patsolve code, so the core code
of Freecell Solver will not be tainted with GPL code.
-------
I have some other items in my todo list, but they are more minor:
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/fc-solve/fc-solve/source/TODO?rev=1.57&content-type=text/vnd.viewcvs-markup
Another thing I'd like to do is to add a To-Do page to the FCS homepage.
This is in accordance to what I noticed the second time I read CatB and
"Homesteading the Noospher". What ESR sais there is that if you say "my
program is complete? No way! It cannot do x, y, and z", then patches to
implement x, y and z will soon follow.
I'd also like to add a HACKING file to the distribution in hope to attract
future contributors (I'll tell about the arch doc, the lecture, etc.). Of
course, I have other endeavours besides Freecell Solver at the moment
(check my Advogato diary for details), so I personally do not intend to
work on it full-time.
Regards,
Shlomi Fish
----------------------------------------------------------------------
Shlomi Fish shlomif_at_vipe.technion.ac.il
Home Page:
http://t2.technion.ac.il/~shlomif/
He who re-invents the wheel, understands much better how a wheel works.
Received on Sat Nov 30 2002 - 02:48:40 IST