<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<?asciidoc-toc?>
<?asciidoc-numbered?>

<article lang="en">
<articleinfo>
    <title>Freecell Solver&#8217;s To-do list</title>
    <date>2009-08-14</date>
    <author>
        <firstname>Shlomi</firstname>
        <surname>Fish</surname>
        <email>shlomif@cpan.org</email>
    </author>
    <authorinitials>SF</authorinitials>
<revhistory><revision><revnumber>$Id$</revnumber><date>2009-08-14</date><authorinitials>SF</authorinitials></revision></revhistory>
</articleinfo>
<section id="_pressing">
<title>Pressing</title>
<itemizedlist>
<listitem>
<simpara>
Check for thread-safety of the meta_allocator construct in <literal>dbm_fc_solver.c</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Try to convert the core libfreecell-solver code to meta_alloc and see if
it makes a difference in speed.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_non_pressing">
<title>Non-pressing</title>
<itemizedlist>
<listitem>
<simpara>
Prune for variants whose empty columns cannot be filled at all: there is
no point in moving the last card in a column to a parent on a different
column, because then the column won&#8217;t be able to be filled and will be left
to disuse.
</simpara>
<itemizedlist>
<listitem>
<simpara>
See for example: Baker’s Dozen.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Trap one of the UNIX signals in fc-solve to quit prematurely with a valid
footer of "Iterations limit reached"/etc.
</simpara>
</listitem>
<listitem>
<simpara>
Create a displayer for fc-solve&#8217;s solutions which will allow seeing where a card
was moved from (using a colored →) and where it was placed.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Adapt it to dbm_fc_solve&#8217;s solutions.
</simpara>
</listitem>
<listitem>
<simpara>
Create a GUI version.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Create a more compact queue for <literal>dbm_solver.c</literal> which has a header of the
next pointer to the item, some integers for start and finish within
the queue, as well as a vector/array of items that are extracted. Then the
segment is recycled as a whole.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Possibly offload the queue segments to the hard disk.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Adapt the new balanced binary tree to store entire encoded_keys instead of
pointers (to save space).
</simpara>
</listitem>
<listitem>
<simpara>
Make sure that run_hard_thread runs the soft_thread up to the limit of the
instance&#8594;num_times or the soft_thread&#8217;s upper bound instead of entering
and exiting.
</simpara>
</listitem>
<listitem>
<simpara>
Unit-test <literal>fc_solve_compare_lru_cache_keys</literal> in <literal>scans.c</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Add an option to convert the stack_locs and fc_locs to a
MAX_NUM_STACKS-factorial permutation that can be stored compactly.
</simpara>
</listitem>
<listitem>
<simpara>
With the <literal>fc-solve</literal> command line program: add a flag to trigger different
notice on having reached <literal>FCS_SUSPEND_PROCESS</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Experiment with using "selection sort" instead of "insertion sort" when
sorting small data sets (columns, freecells, derived states, etc.).
</simpara>
</listitem>
<listitem>
<simpara>
Divide the scan type variable into two variables: super-scan
(DFS vs BeFS/BFS/Opt) and sub-scan (random_dfs, soft_dfs, etc.), to facilitate
multiplexing them.
</simpara>
</listitem>
<listitem>
<simpara>
If <literal>-opt</literal> is specified for the flare, then make sure that if the flares
loop stop it when it&#8217;s doing the optimization scan, then the optimization scan
goes on until it ends.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Not sure about it.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Inline fc_solve_free_instance().
</simpara>
</listitem>
<listitem>
<simpara>
Experiment with making fcs_move_t a bit-field with half-octets/etc. for
the various fields.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Make sure that the amount required can fit there using CMake and a log2
function.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Play with moving commonly accessed struct elements to the start of
the struct to fit within the processor&#8217;s cache line. Like the Linux kernel
where the most important elements are at the first 32 bytes of the struct.
</simpara>
</listitem>
<listitem>
<simpara>
See about getting rid of the unused context variable where appropriate.
</simpara>
</listitem>
<listitem>
<simpara>
Investigate a way to have positions_by_rank also index according to the
suit, and to traverse only the possible parents or children based on the
suit.
</simpara>
</listitem>
<listitem>
<simpara>
Do the test for <literal>SUSPEND_PROCESS</literal> (<literal>check_if_limits_exceeded()</literal> ) in only
one place. There isn&#8217;t a need for it to be done in several places.
</simpara>
</listitem>
<listitem>
<simpara>
Experiment with using a union in the soft_thread to unify common elements
that are used only by one of the scans.
</simpara>
</listitem>
<listitem>
<simpara>
Move the trunk, branches, tags, etc. to under /fc-solve. (?)
</simpara>
</listitem>
<listitem>
<simpara>
Re-organize the source code to be more sensibly organized.
</simpara>
</listitem>
<listitem>
<simpara>
Experiment with using bit members for cards:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://en.wikipedia.org/wiki/Bit_field">http://en.wikipedia.org/wiki/Bit_field</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Abstract away the move of a single card from one column to another
in freecell.c.
</simpara>
</listitem>
<listitem>
<simpara>
Interactive mode? Continue a scan that reached its limit.
</simpara>
</listitem>
<listitem>
<simpara>
Investigate ways to perform more pointer arithematics and
(ptr &lt; end_ptr) ; ptr++ . A lot of code is under-optimized this way.
</simpara>
</listitem>
<listitem>
<simpara>
In the states handling, there&#8217;s still some room for pointer arithmetics.
</simpara>
</listitem>
<listitem>
<simpara>
Implement more of Kevin Atkinson&#8217;s Common Lisp solver&#8217;s atomic move types,
and try to contruct good heuristics out of them.
</simpara>
</listitem>
<listitem>
<simpara>
Play with writing a memory-re-cycling Soft-DFS scan: if a sub-tree was
marked as a dead-end, then its states might be able to be placed on a linked
list of states that can be reused.
</simpara>
</listitem>
<listitem>
<simpara>
Add a FCS_2FC_FREECELL_ONLY macro for quickly solving 2 freecell games.
</simpara>
</listitem>
<listitem>
<simpara>
PySolFC Deal No. 48007594292403677907 :
</simpara>
</listitem>
</itemizedlist>
<screen>shlomif:~$ make_pysol_freecell_board.py -t -F 48007594292403677907 | fc-solve -l cpb -sam | grep ^Move | wc -l
106
shlomif:~$ make_pysol_freecell_board.py -t -F 48007594292403677907 | fc-solve --method a-star -to 01234675 -asw 300,1500,0,2,50000 -sam | grep ^Move | wc -l
105
shlomif:~$ make_pysol_freecell_board.py -t -F 48007594292403677907 | fc-solve --method a-star -to 01234675 -asw 40,2,40,0,40 -sam | grep ^Move | wc -l
121
shlomif:~$ make_pysol_freecell_board.py -t -F 48007594292403677907 | fc-solve --method a-star -to 0123467589 -asw 300,1500,0,2,50000 -sam | grep ^Move | wc -l
100
shlomif:~$ make_pysol_freecell_board.py -t -F 48007594292403677907 | fc-solve --method a-star -to 0123467589 -asw 300,1500,0,2,40000 -sam | grep ^Move | wc -l
106
shlomif:~$ make_pysol_freecell_board.py -t -F 48007594292403677907 | fc-solve --method a-star -to 0123467589 -asw 300,1500,0,2,60000 -sam | grep ^Move | wc -l
91</screen>
<screen>shlomif:~$ make_pysol_freecell_board.py -F -t 91151234961275807905 | ~/apps/test/fcs/bin/fc-solve  -p -t -sam --method a-star -to 0123467589 -asw 300,1000,0,2,90000 | grep ^Move | wc -l
84</screen>
<simpara>However this scan generates takes too much time for most boards (over 100K
iterations).</simpara>
<itemizedlist>
<listitem>
<simpara>
PySolFC deal No. 03620802041832966472:
</simpara>
</listitem>
</itemizedlist>
<screen>shlomif[fcs]:$trunk/fc-solve/source$ make_pysol_freecell_board.py -t -F 03620802041832966472  | ./scripts/summarize-fc-solve -- --method a-star -to 0123467589 -asw 300,1500,99,2,65000
Verdict: Solved ; Iters: 156 ; Length: 87</screen>
<itemizedlist>
<listitem>
<simpara>
I solved it at length 87.
</simpara>
<itemizedlist>
<listitem>
<simpara>
PySolFC deal No. 54369539487824719321:
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<screen>shlomif[fcs]:$trunk/fc-solve/source$ make_pysol_freecell_board.py -F -t 54369539487824719321 | ./scripts/summarize-fc-solve --method a-star -to 0123456789 -asw 3000,100,60,0,500
Verdict: Solved ; Iters: 1325 ; Length: 115</screen>
<itemizedlist>
<listitem>
<simpara>
Shlomi Fish solved it in under 110 moves.
</simpara>
<itemizedlist>
<listitem>
<simpara>
PySolFC deal 96166640969002647853:
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<screen>shlomif[fcs]:$trunk/fc-solve/source$ make_pysol_freecell_board.py -F -t 96166640969002647853 | ./scripts/summarize-fc-solve --method a-star -to 0123467589 -asw 370,0,0,2,90000
Verdict: Solved ; Iters: 615 ; Length: 77</screen>
<itemizedlist>
<listitem>
<simpara>
Shlomi Fish solved it in 77 moves.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Add the new Freecell Solver-copmatible game variants of PySolFC.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_long_term">
<title>Long-term</title>
<itemizedlist>
<listitem>
<simpara>
Code a generic tests grouping.
</simpara>
</listitem>
<listitem>
<simpara>
Integrate the patsolve&#8217;s prioritization and mixed BFS/DFS scan.
</simpara>
</listitem>
<listitem>
<simpara>
Update the architecture document.
</simpara>
</listitem>
<listitem>
<simpara>
Make a super-strict parsable-output without all the quirks of
-p -t (see Games-Solitaire-Verify for why).
</simpara>
</listitem>
<listitem>
<simpara>
Write a multi-threaded version.
</simpara>
</listitem>
<listitem>
<simpara>
Port to Java (?)
</simpara>
</listitem>
<listitem>
<simpara>
Add a switch to ask the user if he wants to continue and enter a bigger
iterations limit.
</simpara>
</listitem>
<listitem>
<simpara>
Check for unmalloced data and if so gracefully exit.
</simpara>
</listitem>
<listitem>
<simpara>
Experiment with a delta-based state storage.
</simpara>
</listitem>
<listitem>
<simpara>
Add a way to build the various libavl2 trees to be used as
positions/columns collections.
</simpara>
</listitem>
<listitem>
<simpara>
Adapt the scans based on the parameters of the initial board.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Try to find a correlation between various parameters of the initial board
(such as those calculated in the A* scan or the number of steps required to
sort the cards in each column by rank), and the performance of various scans
and then:
</simpara>
<orderedlist numeration="arabic">
<listitem>
<simpara>
Calculate the initial parameters on startup.
</simpara>
</listitem>
<listitem>
<simpara>
See what would be a good meta-scan based on them.
</simpara>
</listitem>
<listitem>
<simpara>
Use it.
</simpara>
</listitem>
</orderedlist>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_to_be_considered">
<title>To be considered</title>
<itemizedlist>
<listitem>
<simpara>
Make the code <ulink url="https://sourceforge.net/projects/splint/">splint</ulink>-clean.
</simpara>
</listitem>
<listitem>
<simpara>
Write a multi-process client/server program.
</simpara>
</listitem>
<listitem>
<simpara>
Add a limit to stacks number (in the case of Indirect Stack States),
number of states that are stored anywhere, etc.
</simpara>
</listitem>
</itemizedlist>
</section>
</article>