Hi all!
Here is what is new in the Freecell Solver version control repository, since
Freecell Solver version 2.36.0:
1. I updated the list of files under the Public Domain in the COPYING.txt file
There's only one left, "pqueue.h" - all the others were merged or removed.
2. AsciiDoc is now mentioned here:
http://fc-solve.berlios.de/links.html#technologies
The AsciiDoc developers were kind enough to mention Freecell Solver on their
homepage as a program that uses it:
http://www.methods.co.nz/asciidoc/
3. The --help-short-sol blurb was updated to:
<<<<<<<<<<<
The following configurations may produce shorter solutions:
fc-solve -l gooey-unknown-thing
fc-solve -l slick-rock
You may also try adding the "-opt" and/or "--reparent-states" optionswhich may
make things a little better.
Refer to the file 'USAGE' for more information.
>>>>>>>>>>>
(I'm correcting the long line with the typo as I speak).
4. I've been experimenting with a branch called
" reduce-the-size-of-the-internal-move-token-structs " (still in the
repository under /branches). The motivation for it was that the C tokens
representing the moves currently occupied 4 octets (one octet for each field)
while they could occupy only 2 octets.
Since the 4-octet move tokens were part of the Freecell Solver ABI I declared
another struct called fcs_internal_move_t which was a bit-struct that had four
4-bit fields, one for each field. This may have reduced the memory consumption
(hard to know if a little or a lot) but made the code slower. (a few seconds
for the MS-32,000 run of under 200 seconds). I believe most of the slowdown
was due to the bit fiddling being slower than assigning entire bytes, and
possibly there was was also a negative effect of the lack of memory alignment
in the 2-byte tokens.
I may still opt to incorporate this branch into the main line after enhancing
it to be a compile time option, in case someone could use saving the extra
memory.
5. make_pysol_freecell_board.py now have an undocumented -F flag that allows
it to generate boards of PySolFC (whose randomisation algorithm has changed
from the original PySol), and some tests were added.
6. I've done some work on the soft-threads presets generation. Most of it was
refactoring, but I also played with trying to graph the performance of a
series of constant soft-threads quotas (say [100,100,100,100...],
[150,150,150,150,150...], [205,205,205,205...], etc.). I found out that I got
a bumpy graph where the total number of iterations (where more iterations =~
slower performance) decreased relatively rapidly and then steadily increased
afterwards.
The top 10 lowest iteration counts were:
<<<<<<<<<<<<<<
309 18343963
391 18343388
319 18342457
341 18341339
310 18337826
390 18332992
378 18328836
377 18322322
375 18317338
376 18314246
>>>>>>>>>>>>>>
This is whereas 350 which is the default and what formed the basis of most of
the presets so far gives:
<<<<<<<<<<<<<
350 18382968
>>>>>>>>>>>>>
So it's not an earth-shaking difference.
In any case this eventually has given me an idea for an algorithm to
methodically optimise the sequence of iterations quotas (not a particularly
smart one and it requires a lot of brute force, but it may be good enough).
More about it in a later message.
------------------
Regards,
Shlomi Fish
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
"Star Trek: We, the Living Dead" - http://shlom.in/st-wtld
Bzr is slower than Subversion in combination with Sourceforge.
( By: http://dazjorz.com/ )
Received on Thu Dec 24 2009 - 08:07:08 IST