tl;dr Dynamic programming is often better than greedy.
More like hill climbing is often better than depth-first search.
Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
31–40 of 60 posts
Re: Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
#32Well, viva human brain versions of Monte Carlo Search Tree algorithms. Your game was at least solvable deductively in practice. If you were talking about solving something like the game of Go, i.e. high branching factor and deep tree, then Monte Carlo algorithms would be your first guess instead of trying to do deductive reasoning. Upper Confidence bound on Trees (UCT) algorithm is a good one to read about and understand if you have a spare evening.
Re: Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
#33Erm.. isn't this actually called 'trial and error' fairly common method.. No?
Re: Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
#34Linear variation method in QM + an SCF cycle ;)
Re: Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
#35> It turns out to be easier and faster to iterate from an existing but wrong solution, than to deduce a correct solution from scratch.
Indeed, many things in real life follow this pattern.
Re: Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
#36> "It turns out to be easier and faster to iterate from an existing but wrong solution, than to deduce a correct solution from scratch. "
It is if you have no additional cost in building/destroying something, as in this game. If you had a pot of money and every piece you placed/destroyed cost you money (or even more than a fraction of a second in time) - as is often the case in real life - then the picture could well be very different.
Re: Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
#37"No, they had discovered a superior strategy." I had a similar experience when I published an iOS game in 2011. I was still in high school, so publishing a game available on the App Store was quite a big deal to the other people at school. I became known by a bunch of people for making this game. One day, someone I'd never spoken to comes up to me and shows me 'a bug'. It turns out this guy had developed an optimal s…
"When I played my own game, I had the technical knowledge of how the game functioned"
I have this same problem when I test my own software.
Re: Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
#38> "It turns out to be easier and faster to iterate from an existing but wrong solution, than to deduce a correct solution from scratch. " It is if you have no additional cost in building/destroying something, as in this game. If you had a pot of money and every piece you placed/destroyed cost you money (or even more than a fraction of a second in time) - as is often the case in real life - then the picture could well…
That's true if you are building something tangible. You can't simply start building something (like a bridge) and fix the mistakes you make while you are making them.
But for programming ? You don't have those kind of costs.
Re: Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
#39> "It turns out to be easier and faster to iterate from an existing but wrong solution, than to deduce a correct solution from scratch. " It is if you have no additional cost in building/destroying something, as in this game. If you had a pot of money and every piece you placed/destroyed cost you money (or even more than a fraction of a second in time) - as is often the case in real life - then the picture could well…
That's true if you are building something tangible. You can't simply start building something (like a bridge) and fix the mistakes you make while you are making them. But for programming ? You don't have those kind of costs.
>But for programming ? You don't have those kind of costs.
Where did you get this strange idea from? You have customers, backwards compatibility, programmers time, and tons of other "cost" stuff.
Re: Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
#40Earlier quoted context omitted.
That's true if you are building something tangible. You can't simply start building something (like a bridge) and fix the mistakes you make while you are making them. But for programming ? You don't have those kind of costs.
> But for programming ? You don't have those kind of costs. Where did you get this strange idea from? You have customers, backwards compatibility, programmers time, and tons of other "cost" stuff.
You don't have to ship until you have actually solved whatever problem you are working on, though. It still might be faster to get to the point of shipping code by this method, in some instances.