in reply to Re^2: Travelling problem (Anyone better 86850?)
in thread Travelling problem

> First time I have tried this approach, seems very powerful.

Well not sure if this problem isn't too easy for a good test, considering that the naive approach already gives a solution of 95166, which is probably good enough in most cases.¹

I have the impression that a little branch and bound with just the 3 or 4 shortest edges per node (instead of just one) would quickly produce much better results.

Cheers Rolf

( addicted to the Perl Programming Language)

¹) at least for the OP.

  • Comment on Re^3: Travelling problem (Anyone better 86850?)

Replies are listed 'Best First'.
Re^4: Travelling problem (Anyone better 86850?)
by BrowserUk (Patriarch) on Dec 23, 2013 at 16:04 UTC
    I have the impression that a little branch and bound with just the 3 or 4 shortest edges per node (instead of just one) would quickly produce much better results.

    Prove it! (You've done a great job of quoting wikipedia; how about putting some of your reading into practice?)


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Branch & Bound with the two shortest edges finds the following in less than 30 seconds:

      95166 90498 90298 89653 88925 88838 86867 85294 84860

        There's thems that talk, and thems that do :)


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
      And what have you "proven" so far except dropping numbers and (most probably) miscalculating the lower bound?

      Cheers Rolf

      ( addicted to the Perl Programming Language)

        except dropping numbers

        Check it yourself:

        86850 [ 0 5 13 22 8 3 12 20 16 11 6 1 10 15 7 18 2 19 17 14 4 9 21 23 +]

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        Or even:
        85923 [1,2,11,16,7,8,12,17,21,6,13,4,9,23,14,10,22,15,5,18,20,3,19,24]
Re^4: Travelling problem (Anyone better 86850?)
by hdb (Monsignor) on Dec 23, 2013 at 16:58 UTC

    My branch and bound is running on the three shortest nodes for 27hrs now. Best so far 88491.

      Well, which is far better than 95166. =)

      Anyway both results are already within 20% from the optimum.

      May I ask, if you cache intermediate results?

      If you go from 1 to 24 and reach node X again via the same nodes (just other order) then the options for the rest of the way are identical.

      In my experience such memoizing helps to bound very efficiently.

      update

      This caching is maybe better applied in a "breadth first search" to reduce pathes.

      Cheers Rolf

      ( addicted to the Perl Programming Language)

        No caching, just brute force. I have now cleaned my code, you have to give the bound on the command line: