in reply to better algorithm: bitwise reordering

What is the actual real-world problem you're attempting to model with this data structure? I suspect there's already a CPAN module that would do most of this for you .......

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

  • Comment on Re: better algorithm: bitwise reordering

Replies are listed 'Best First'.
Re^2: better algorithm: bitwise reordering
by hv (Prior) on Aug 25, 2004 at 16:49 UTC

    It's one part of my attempt to write a reasonably efficient function to calculate f(a, b), the number of full-spectrum rook's walks on an a x b board. (The integer sequence A096121 handles the specific case of a = 2, but I wish to extend to the more general case.)

    I'd be kinda surprised if there were already a CPAN module for this, though I suspect an understanding of PDL might help.

    Hugo

      This sounds like a graph theory problem. (Though, given that I've been using Graph a bunch, and even submitted patches to it, recently, everything's been looking kinda like a nail right now.)

      Here's what I mean

      1. Create an undirected graph of X x Y vertices, presumably labeled a1, a2, b1, etc.
      2. Create edges between all the squares that are connected to one another by means of how a rook can move. So, a1 has an edge to both a2 and b1, but a2 and b1 don't have an edge between them.
      3. Put all the vertex names into a hash to mark if you've been there or not.
      4. Pick a starting point. Mark it as being seen.
      5. Find all the neighbors.
      6. Iterate through them, recursively calling this function until you have touched every square.

      The problem statement (as I read it) doesn't make mention of going back and forth between two squares (though it would be a valid variation upon a given walk), so you could probably prune a bunch of possibilities because you've already been there.

      I would look at writing a better problem statement. Basically, are you only counting walks that minimize the number of squares touched? I would add the stipulation that you can only touch any square a maximum of two times. (One could add the once-per-square stipulation, but that may eliminate desired outcomes. I don't know enough about the problem domain to say with any certainty.)

      The reason I suggest this option is because it sounds like you're not happy with your data structure which, in turn, is causing serious headaches with your algorithm.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

        The EIS reference is the best definition: "a rook must land on each square exactly once, but may start and end anywhere and may intersect it's own path". (For the non-chess players, the rook may move from a given square to any other square in the same row or the same column.)

        The data structure I'm using takes advantage of the fact that any given position is equivalent to one in which rows and/or columns are arbitrarily reordered, in an attempt to maximise the benefits of memoizing calculated values; the rearrange() function under discussion is trying to do precisely that reordering.

        I don't know enough graph theory to guess whether a graph-based approach would gain me anything; I think I'm happy with my data structure (though there may well be a better way), but I understand it rather better than I've been able to explain it so far.

        Hugo