thanks for the correction, that’s what I thought, too.
From: dannyjones183
Sent: Saturday, December 01, 2012 8:06 PM
To: fc-solve-discuss_at_yahoogroups.com
Subject: Re: Pruning Examples -- Correction
Correction:
All of the solveable deals in the first 1,000,000 deals were solved in Pass_1 or Pass_2 by my solver. This means that it reduced every card's suit to red/black when creating layout checksums. It wasn't until my solver processed the first 25,000,000 deals that it used Pass_3 and needed all four suits when creating layout checksums. Deals #24515390 and #94717719 come to mind.
--- In mailto:fc-solve-discuss%40yahoogroups.com, "dannyjones183" <dannyjones183_at_...> wrote:
>
> <snip>
>
> I didn't get into specifics because I doubted if anyone would be interested. My mistake. Here comes the judge ... I mean specifics.
>
> I have two trees that store data. The first tree stores layout information exactly as generated. A "priority value" and "sequence number" dictate the order in which entries are extracted from the tree. By initially forcing the priority value to zero, I can use BFS logic to traverse N levels of entries at the start. After N levels, I can generate non-zero priority values to enable my general "priority search" logic. By splitting the logic this way, I have a nice sample space from which to choose my first prioritized layout. If I use N=0, then I'm running in prioritized mode from the start.
>
> The second tree is the accumulation of checksum calculations for the layouts encountered. I create the checksums based on which Pass is being performed and an orderly method of gathering information from a layout so that an equivalent layout will result in the same checksum. For Pass_1 and Pass_2, I only extract red/black information from the cards. Only four deals in the first 1,000,000 deals return a false-negative after Pass_1 and Pass_2. Pass_3 uses the full card information and returns these four deals as solveable.
>
> Regards, Danny
>
Received on Sun Dec 02 2012 - 07:21:22 IST