Optimal is a strong word. 12 trucks have to deliver 144 items and pick up 60 items, No truck can have more than 14 items at any given time. Do to a Quirk in what we are shipping let's say it is dogs and cats... You can never be hauling both a dog, and a cat at the same time, but you can be picking up a dog, at a location you just deposited a cat. Also if you travel with a Dog for more than 3 hours you explode, but you can trade dogs for ones that won't explode at any place that can swap dogs with you.
While I call this a traveling sales man, we also have an acceptable penalty for failed pickups and failed deliveries, so it is more chess engine than Traveling Salesman. Capture X pieces in Y moves and score as many points as possible. My piece was really just building the What are the valid moves at this point in time. I didn't have to solve all the rest. Also The items being shipped were not Dogs, They were something far more Fissile. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jeff Schnitzer Sent: Wednesday, December 14, 2011 8:23 PM To: [email protected] Subject: Re: [google-appengine] Re: Isn't .08/hr 1.92/day $59.52/month for a 600 MHZ CPU instance with 128 MB memory a LITTLE EXPENSIVE If you have a polynomial-time implementation of optimal traveling salesman, I'll buy that for $500k. Jeff On Wed, Dec 14, 2011 at 11:02 PM, Brandon Wirtz <[email protected]> wrote: > By the way the original use of the code was used for solving real life > traveling SalesMan routes for shipping and receiving for a VERY, VERY > large client, and GAE is not what the final product runs on but we > needed infrastructure to test the logic on which is what was sold, not > the actual source code. > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Brandon Wirtz > Sent: Wednesday, December 14, 2011 6:53 PM > To: [email protected] > Subject: RE: [google-appengine] Re: Isn't .08/hr 1.92/day $59.52/month > for a > 600 MHZ CPU instance with 128 MB memory a LITTLE EXPENSIVE > > I have very nice Teselation Code, uses concentric Hexagons in place of > Circles and works for nested families on a map, and even has a "Driving" > distance function rather than "As the crow flies" that requires there > be a road of a given size in the Hex to make the move. And While it > isn't well tested we have a "driving Time" function that allows for > City, Highway, and Rural, hexes so that you can specify a that you'd > like to find something with in a 30 minute radius instead of a 30 mile > radius, and if you can hop on i80, that will search 30 miles, and if > you are in LA it will search 7 miles. Currently only being used for US maps, but it can be used for Global. > > > Works really well and is blazing fast on GAE. Sell it to you for $500k. > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Jeff Schnitzer > Sent: Wednesday, December 14, 2011 6:33 PM > To: [email protected] > Subject: Re: [google-appengine] Re: Isn't .08/hr 1.92/day $59.52/month > for a > 600 MHZ CPU instance with 128 MB memory a LITTLE EXPENSIVE > > On Wed, Dec 14, 2011 at 8:08 PM, Brandon Wirtz <[email protected]> wrote: >> GAE FORCES you to think about your code. But it allows you to forget >> about everything else. > > Brandon, I humbly suggest you just haven't hit an edge case yet. > There are plenty of indexing problems which GAE simply doesn't offer a > solution to. When I am forced to think about "does polygon A overlap > with polygon B?", I look for R-tree indexes... which GAE doesn't > offer. There are a million spatial index functions which are > no-brainers in PostGIS but represent man-years of work on GAE. And of > course there's fulltext indexing. > > GAE gets more features every month, which is great. The magic > anti-exploding-index queries recently added are a godsend. Fulltext > indexing is on its way. And I'll be jumping up and down in happiness > when true spatial indexes show up. But let's not pretend that GAE is complete. > And let's make sure Google knows it when they make missteps like > pricing large instances unreasonably or offering halfway email > solutions that do little more than generate complaints on this list. > > Jeff > > -- > You received this message because you are subscribed to the Google > Groups "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > > -- > You received this message because you are subscribed to the Google > Groups "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]. > For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. > -- We are the 20% -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
