The Traveling Salesman with Simulated Annealing, R, and Shiny | Hacker News Reader

The Traveling Salesman with Simulated Annealing, R, and Shiny

toddwschneider.com

74 pointssebg12 comments

I don't understand how the simulated annealing is helping.

I quote the explanation of step 4:

  If the candidate tour is worse than the existing tour, still maybe accept it, according to some probability. 
  The probability of accepting an inferior tour is a function of how much longer the candidate is compared to the current tour, and the temperature of the annealing process. 
  A higher temperature makes you more likely to accept an inferior tour

Why would you need a simulated annealing for a seemingly so simple function?

Simulated annealing is simple. It's just the acceptance criterion of simulated annealing that you are using.

You take the previous solution, and the current one, the difference of the cost (up or down) and plug it into the formula.

Simulated annealing allows some jumps up and jumps down, hill climbing goes only up.

And the purpose of the down jumps is to move you away from a local maxima. For example, if you were wanting to climb [any large mountain] and could only gain elevation, then you would fairly easily get stuck in the stairwell of the hotel in the valley.

> a simulated annealing for a seemingly so simple function

Which are you referring to here as the "seemingly so simple function"?

I would assume so that this algorithm could be solved using a DWave with it's supposed 10^8 speedup if successful?

A little bit off topic, but has anyone run a r based api in production? What do you guys use - something like renjin...or do you put up reserve behind a connection pool ?

It's really hard to find something around this.

I've used rpy to have the web-api side done in python, then make a call to the R code. That way R can do the math it's good at, and python can do the logging/API/etc. stuff it's good at.

We have a C# WebAPI in front of R for our use. Each application can either do ad-hoc requests or register itself with the api, reserve N instances of R and a set of packages to be loaded on each and they get enacted as a queue for the app to handle incoming requests. I built the first version using rApache (http://rapache.net/) and then did some testing with OpenCPU (https://www.opencpu.org/) but we had to make it run on Windows and IIS so we built our own in the end. http://deployr.revolutionanalytics.com/ could be a ready made option and seems to be pretty solid but we deemed it to complicated for our needs when we looked at it.

did you evaluate Renjin ? it seems that Java would have been a good fit for you . Also - what do you mean by "reserving N instances of R". I'm not sure what that means (coming from a Python/Java background).

Yes, we looked at Renjin and it's just not what we want, they re-implemented R based off 2.14 and don't do feature parity with that version or newer versions and since the actual analytics code is developed in vanilla R it didn't seem attractive. Also this was a few years back and Renjin as is has sparse documentation and seemingly not too many users and back then the situation on those fronts was worse. To the instance question, I simply mean spinning up a N-amount (usually 4-6) of R processes (there are multiple apps and hundreds of users so we couldn't make it a single linear queue for processing). We mainly use it for optimization calls so we prime the optimization engine in R with the required packages etc and then the R processes just lingers around ready to do an optimization when required.

YHat and Domino Data Labs both have commercial solutions for exactly this.

On the open-source front, OpenCPU (https://www.opencpu.org/), Jug (http://bart6114.github.io/jug/) or plumber (http://plumber.trestletech.com/) are all built for this. Plumber has a page to guide you through setting it up on a server using PM2 here: http://plumber.trestletech.com/docs/hosting/

(Conflict of interest warning: I wrote plumber.)

I've been running an API on plumber (with admittedly low volumes of traffic) for months now unattended using a strategy similar to the guide mentioned above. Haven't had any issues yet.

Very cool! How do you manage this in production? We use supervisors for other services. Is plumber aware of USR1, SIGHUP,etc signals to trigger restarts,etc

Reply on news.ycombinator.com