4 ms·

It's invalid because the paper was presented to solve a problem which does not exist. Maybe it can be applied to some other problem using similar theory, but t

by palish 16y ago

It's invalid because the paper was presented to solve a problem which does not exist. Maybe it can be applied to some other problem using similar theory, but the problem it presents would basically never have to be solved in linear time. Try to think of an application where realtime triangulation of dynamic (changes every frame, negates the possibility of caching) concave polygons is an such a bottleneck that it not only requires hand-optimizing your triangulation routine, but also requires you re-architect it to run in linear time. In Google's words, it is a "solution in search of a problem". Memoization is not panacea. This is like telling someone to sort every possible group of numbers and saving it to disk so you don't have to implement something faster than bubble-sort. I really am not trying to be mean, I'm just stating the facts -- your statement is so full of ignorance that it's kind of disturbing that you believe it. Programming is generally an exercise in caching. There was a good article posted a long time ago called It's caches, all the way down. If you think about it, memoization (a.k.a. 'caching') has been the primary solution to a large percentage of past problems. The examples off the top of my head: - GPU memory is a cache of system memory - system memory is a cache of the hard drive - the operating system presents a file I/O interface which heavily utilizes caching - John Carmack developed Quake which revolutionized the realtime graphics industry primarily because of his innovative "potential visibility set" algorithm, which is just a cache of computing visibility on-the-fly So for all intents and purposes, memoization (caching) IS the magical panacea that you deny it to be.

codexon 16y ago
How do you know the problem doesn't exist? Even if you are pre-computing it, wouldn't you like it to go faster, like encoding a video or rendering a ray-traced scene? There are an infinite number of polygons. Of course caches are important. But it isn't the only thing. That's why programs aren't all giant databases. Memoization != better caching either. That is simply naive. If your algorithm can fit in L1-L2 cache, it can be better than loading a giant hash table or tree from disk. I'm not trying to be mean either, but you have all the signs of a junior developer who thinks there is nothing left in CS to challenge him as he churns out enterprise crud where caching is the only thing he can think of that matters.
- palish 16y ago
  How do you know the problem doesn't exist? Because the problem applies primarily to realtime 3D / 2D graphics, of which I have spent the last 7 years learning about. That is of course not a guarantee the problem does not exist, but it is very likely. Otherwise, it would be one of the significant known problems in realtime graphics. Even if you are pre-computing it, wouldn't you like it to go faster, like encoding a video or rendering a ray-traced scene? What I want is irrelevant. All that matters is what the application needs to do. It is a senseless waste of time to optimize a sufficiently fast algorithm. There are an infinite number of polygons. There are an infinite number of numbers. This has no bearing on the problem, on the effectiveness of caching, or on any other of my points. In other words, this is yet another completely irrelevant statement by you. You have all the signs of a junior developer who thinks there is nothing left in CS to challenge him as he churns out enterprise crud where caching is the only thing he can think of that matters. Oh, really? I did you the courtesy of explaining exactly why your earlier statement was so full of ignorance. You merely insult without reason or basis. Congrats, you are a troll and have been trolling this entire time. This means you have not only completely discredited yourself, but are also no longer worth trying to disprove, because your statements are without reason or merit. Which is quite sad, since I personally was interested in an opposing viewpoint; but not if it's completely insane. Have you even solved any problems related to "polygons" in your programming career? Also, how long exactly have you been programming for? I have been programming for ten years. I'm trying to find one good reason to take any of your statements seriously. Unless you have any graphics experience, or more experience in general, I see no reason to. And since you have neither logic nor tact, I see no reason to continue this conversation.
  - codexon 16y ago
    I just explained to you the reasons why you are wrong which you have conveniently disregarded. Instead of rising up to the challenge or admitting failure, you make broad sweeping generalizations like you could learn 99% of any CS concept in less than a day, and that any challenge that you are not willing to do (or likely cannot), is because the challenge has no "real-life" application. Not only did you read the paper incorrectly, trying desperately to find holes in it, but you try to change the subject by calling me naive in my refusal to allow you to just say "memoize" as the answer to any algorithmic challenge. I think it is clear to anyone else reading this that you are in the wrong here.

by palish 16y ago

codexon 16y ago

How do you know the problem doesn't exist? Even if you are pre-computing it, wouldn't you like it to go faster, like encoding a video or rendering a ray-traced scene? There are an infinite number of polygons. Of course caches are important. But it isn't the only thing. That's why programs aren't all giant databases. Memoization != better caching either. That is simply naive. If your algorithm can fit in L1-L2 cache, it can be better than loading a giant hash table or tree from disk. I'm not trying to be mean either, but you have all the signs of a junior developer who thinks there is nothing left in CS to challenge him as he churns out enterprise crud where caching is the only thing he can think of that matters.

palish 16y ago
How do you know the problem doesn't exist? Because the problem applies primarily to realtime 3D / 2D graphics, of which I have spent the last 7 years learning about. That is of course not a guarantee the problem does not exist, but it is very likely. Otherwise, it would be one of the significant known problems in realtime graphics. Even if you are pre-computing it, wouldn't you like it to go faster, like encoding a video or rendering a ray-traced scene? What I want is irrelevant. All that matters is what the application needs to do. It is a senseless waste of time to optimize a sufficiently fast algorithm. There are an infinite number of polygons. There are an infinite number of numbers. This has no bearing on the problem, on the effectiveness of caching, or on any other of my points. In other words, this is yet another completely irrelevant statement by you. You have all the signs of a junior developer who thinks there is nothing left in CS to challenge him as he churns out enterprise crud where caching is the only thing he can think of that matters. Oh, really? I did you the courtesy of explaining exactly why your earlier statement was so full of ignorance. You merely insult without reason or basis. Congrats, you are a troll and have been trolling this entire time. This means you have not only completely discredited yourself, but are also no longer worth trying to disprove, because your statements are without reason or merit. Which is quite sad, since I personally was interested in an opposing viewpoint; but not if it's completely insane. Have you even solved any problems related to "polygons" in your programming career? Also, how long exactly have you been programming for? I have been programming for ten years. I'm trying to find one good reason to take any of your statements seriously. Unless you have any graphics experience, or more experience in general, I see no reason to. And since you have neither logic nor tact, I see no reason to continue this conversation.
- codexon 16y ago
  I just explained to you the reasons why you are wrong which you have conveniently disregarded. Instead of rising up to the challenge or admitting failure, you make broad sweeping generalizations like you could learn 99% of any CS concept in less than a day, and that any challenge that you are not willing to do (or likely cannot), is because the challenge has no "real-life" application. Not only did you read the paper incorrectly, trying desperately to find holes in it, but you try to change the subject by calling me naive in my refusal to allow you to just say "memoize" as the answer to any algorithmic challenge. I think it is clear to anyone else reading this that you are in the wrong here.