I probably wouldn't renew at $119. And without free shipping, I would order less stuff from Amazon. That doesn't sound too good for the shareholders.
Not going to get into all the arguments here. Yes, it is more complicated in detail than the simple model Walker lays out. But in practice, *if* you count calories as prescribed, *then* the model is good enough.
I'd like to provide an update here. I read about the Hacker's Diet first on Slashdot, in fall 1999. I followed it, and during 2000 I lost 50 pounds. I've kept it off for 13 years now. A few years later I started running. I've now run 96 marathons and ultramarathons, heading towards my 10th consecutive Boston Marathon, I've broken 3 hours four times, and I've run three 100 milers, including Western States. Couldn't be happier with that part of my life.
The running has been a bigger life change than losing weight. But I couldn't have done it, no way, without losing the weight first. And I have the Hacker's Diet to thank for that.
And yes, running 60-70 miles / week, I *still* have to count calories.
I would guess that you've never entered one of these competitions. To do well, it is not sufficient to come up with quick and dirty solutions; these will generally fail. You have to be able to find a good algorithm, quickly, and implement it, catching all the edge cases. These are certainly valuable real-world skills.
Disclaimer -- I was on the Rice team that took 3rd in 1986 (before there were any international teams at all).
... sort of. And it is established physics. See Swimming in Spacetime: Motion by Cyclic Changes in Body Shape, Science, 2/27/2003, by Jack Wisdom.
But this mechanism relies on general relativistic effects, and only works in curved spacetime. Momentum conservation is not violated, because while the location of the object changes, its momentum (thus velocity) does not -- it simply cyclicly translates itself through space.
My first thought reading about the EmDrive was that Shaywer had found a way to reproduce this effect using a microwave cavity. But unless I'm mistaken, this does not appear to be the case, and I don't follow the arguments that Shaywer's drive should work.
Grover's search algorithm gives only a quadratic speedup.
Exactly. That was the big problem I had with the book: it's written for Java programmers. I am intrigued by the language, but I would much prefer a book that treats the language on its own terms.
It's on my list...
I'll mention it to my publisher, but honestly it would lose a lot without all the color figures.
The book is based on my Ph.D. thesis, which you can download for free:
The reason that fun games tend to be NP-hard (or harder) is that if a game's "physics" supports interesting constructions requiring complex reasoning to solve, then probably that same physics can be used to build computational gadgets, which is how you show hardness of the generalized version. This quality expresses itself even on small, fixed-size board.
Ah, it doesn't mean that either.
If a problem is NP-hard, it means it is at least as hard as any other problem that can be solved in polynomial time on a nondeterministic computer.
It is an open question (P=NP) whether this is equivalent to saying that there is no deterministic polynomial-time algorithm.
Chess and Go are actually EXPTIME-complete, even harder than NP-complete problems and PSPACE-complete problems.
In general, one-player games of bounded length (like Flood-It, or Sudoku) tend to be NP-complete; one-player unbounded games (like sliding-block puzzles, or Sokoban) tend to be PSPACE-complete; two-player bounded-length games (like Hex, or Amazons) also tend to be PSPACE-complete, and two-player unbounded games (like Chess, Checkers, and Go) tend to be EXPTIME-complete.
I can't resist here a plug for my book (with Erik Demaine), Games, Puzzles, and Computation, which discusses all these issues in detail. A theme running throughout the book is the same as the view expressed in this paper: most interesting games and puzzles seem to be as hard as their "natural" complexity class, outlined above.