Hi all!
I previously wrote about it here and here:
*
http://tech.groups.yahoo.com/group/fc-solve-discuss/message/1026
*
http://tech.groups.yahoo.com/group/fc-solve-discuss/message/1027
I finished by saying that:
<<<<<<<<<<<<<
That was all nice and dandy, but when I fed the resultant meta-scan into the
solver it ran slightly slower than "-l cool-jives". Moreover, as I noticed it
resulted in a different number of iterations than what the meta-scan-
generating algorithm yielded as an estimate.
I tried using both --scans-synergy's and to increment the quotas by 1 in case
there's an off-by-one error, but while some of them improved the final
iterations count, they did not result in the same iterations numbers.
Therefore, I now need to investigate why the result is different by simulating
the scans and seeing where fc-solve deviates from that.
>>>>>>>>>>>>
So I wrote some code to simulate the boards through the quotas, and then a
Ruby program that ran the Freecell Solver range solver vis-á-vis with the
simulation, and realised it started deviating at board 36. After investigating
it yesterday I realised that the Best-First-Search (BeFS) algorithm traversed
different positions than the simulation. I ran it in the command line version
and it indeed resulted in different things.
After a lot of investigation, I realised that the problem was due to the Best-
First-Search weights being inconsistent, which in turn was due to the fact I
forgot to input the 5th one, which made it once 0 and once something else due
to a lack of bounds check in the string processing of the -asw's parameter's
command line argument.
This was fixed and then the BeFS scan ran consistently. However, I still
didn't get identical results. I investigated and it turned out it was caused
by the number of final iterations having an off-by-one error in reporting the
final iterations count. So if Iteration No. 500 was the final state it
reported it solved in 500 iterations instead of 501 (which should be the case
due to the fact that it starts from 0 iterations). So I had to correct the
output.
I realised that some of my tests in the
t/t/intermediate-iterations-are-in-order.t were lacking and omitted some bugs
and so had to fix them and then I had to update the checksums and lengths of
the tests in the identicality test, because the number of iterations reported
was higher.
After all that, I had to fix the scans' results to generate the same tests. I
decided to write a script that will increment the number of iterations it took
the scans to run in the input data by 1, and I rerun the scan for finding the
optimal quota allocation, and it yielded a new preset which I called "blue-
yonder". I timed it against "cool-jives", and it indeed took it two seconds
less to run (though even cool-jives was a bit slower than when I timed it last
time).
Since I have some bug fixes and other stuff, I'm considering to release a new
stable version.
Regards,
Shlomi Fish
P.S.: all hail my new signature.
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
Parody on "The Fountainhead" - http://shlom.in/towtf
Deletionists delete Wikipedia articles that they consider lame.
Chuck Norris deletes deletionists whom he considers lame.
Received on Sat Jan 16 2010 - 09:37:47 IST