Travelling with Style Feedback Thread

@Alex: thanks for your guidance in regards to faster vs closer.
Have you posted new rankings yet?
I am using this URL:
http://www.beyond3d.com/B3D_AMP_CONTEST/Public_rankings.pdf
Is that the right one?
Also, would you mind putting a time stamp on the page so I know I have the latest?

Thanks!

- Bernd

 

@Veikko: thanks for offering your help! I have a day job, so I can only work in the evenings on ATSP. But I think I am close.

We'll see.

Cheers,

- Bernd

 

Sure. If you find a way to put daily jobs and babies on hold for a day or two, please do share your insight with me.

 

@Alex: thanks for updating the rankings!
So, who is leading the TSP category, now?

 

Hmm, indeed, I wonder the same as Bernd.

I introduced a much more dynamic interruption mechanism to the solver and with current settings on my computer (heh, the works on my computer argument) I get slightly worse tour quality as the previous ad-hocish submission, though clearly faster. Well, that's somewhat a degree of parameter setting.

I wonder what's the problem for my solver on one of the ATSP instances. Let's see if I can deduce something from the size...

 

@Alex: admit it, you can't really tell The costs for getting closer increase as you are getting closer to the optimum! The only way to tell which one is better is by normalizing the results.

@Veikko: Hey, I have a proposal for you.
Shall we normalize our results to, say 360 secs?
In other words I can set the maximum running time at 360 secs. That would allow is to compare apples with oranges.

 

@Alex: I just submitted a new version of my solver with fixes for ATSP.
I also let the solver time out at 360 secs in order to get results we can compare against Veikko's solver.
Also, can I assume that you build Release, x64?

Please let me know if you run into any problems.
I am looking forward to reading the new rankings!

Cheers,

- Bernd

 

@Alex: I think I accidentally zipped the binaries. The mail came back with a "rejected" note.
Either way, I resent the zip file.

 

I concur, the costs increase even dramatically so.

Which also mean, to some extent that neither of us would actually need 360 seconds especially on smaller instances to get within percentage points of the solutions we see, e.g. in your submission.

You see 360 seconds on my results because of a rather dumb stopping condition, it's much more dynamic now.

Apples to oranges indeed. It's all right for me. I don't have an objection (in fact, maybe even higher would be better since I know my solver does make visible progress in any case), but I hope you don't mind waiting for a while?


I still have a few tricks in the sleeve, but it takes at least 13 hours from now for me to get a computer and try crank some code and if I'm lucky/not too tired/etc., I can have something shippable (but it can take another evening too). Currently the tricks are just TODO comments in code, but I think I can pull-off at least one and it should have a (very) beneficial effect very early on in the processing time considering length and especially on the longer tours. Well, at least if we are to believe researchers and I can pull off this particular thing.

 

Hey Veikko, you can go higher than 360. I'll just try to use what you use as a stopper.
13 hours until you get access to a computer?
You must be in the middle of nowhere!

I have a few tricks in my tool chest, too.
Whit is fun!

- Bernd

 

I have a dynamic stopper now, which checks for change in tour length size in some window, and stops the solver when changes get too small. Though I still have a hard-coded limit too on 360 seconds. Currently especially on the smaller instances it's the "change window check" that stops the solver well before that.

So, you are matching the speed of my solver with quality, which carries more weight in the finald scoring?

At work in downtown Tampere, Finland. I'd rather much be implementing ideas to the solver, but can't run away from here now.

For my part, I just hope I get to the right performance/quality ballpark for what I think I should have after implementing some additions.

 

@Alex: are you seeing those errors for TSP, ATSP, or both?

 

Hmm, I'll send you another version.
When you say "assert" you mean validation errors?
All asserts melt away in release builds.

- Bernd

 

Hello, folks!

It looks like I managed to improve the quality of my tours and lessen the time needed to have them. This comes with a bit of a caution, since it looks like I broke my ATSP calculation in the process. Furthermore, I created a bit of a mess to the code. If I don't need to go to sleep )), I'll try to submit today/tomorrow (it's soon midnight here) so that the results should become visible sooner.