5 ms·
You're focussing a lot on whether they an algorithm can say that it "wins" and trying to find a way for them to say that fairly. I don't think that's important
by ketralnis 11y ago
You're focussing a lot on whether they an algorithm can say that it "wins" and trying to find a way for them to say that fairly. I don't think that's important at all.
It seems like it's probably better for some problems and not others, like where some precomputation is both practical and helpful. So if you want to see if that's possible for a particular problem, try it and see.
- idunning 11y ago"Try it and see" will be pretty definitive (assuming you can implement it correctly, which is nontrivial), but it has scaling problems. I'd argue thats exactly what this talk is about: the presenter claims to have a new method that "wins", i.e. beats something else (A* and some variants on it). So the presenter at least thinks its important, as does the competition he mentions in the talk. He thinks you should try it, because he is saying its better. I'm claiming that without more care, its hard for me to take action on that claim because "better" is not a single dimensional thing, its a rich trade off between at least run time, precomputation time, precomputation memory, and arguably implementation difficulty. It'd be nice to not have to try everything yourself for your particular problem, don't you think?
- darkmighty 11y agoYou're missing the point here: this is a practical application. He's saying in the context that most people currently use A* his approach is much faster (and he does explain it uses more memory) -- the title is completely justified. You're nitpicking, really.