4 ms·
The Traveling Salesman with Simulated Annealing, R, and Shiny
- teps 11y agoI 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?
- spooningtamarin 11y agoSimulated 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.
- baldeagle 11y agoAnd 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.
- mcphage 11y ago> a simulated annealing for a seemingly so simple function Which are you referring to here as the "seemingly so simple function"?
- kruhft 11y agoI would assume so that this algorithm could be solved using a DWave with it's supposed 10^8 speedup if successful?
- sandGorgon 11y agoA 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.
- jmalicki 11y agoI'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.
- Hansi 11y agoWe 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/ http://rapache.net/) and then did some testing with OpenCPU (https://www.opencpu.org/ 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/ 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.
- sandGorgon 11y agodid 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).
- Hansi 11y agoYes, 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.