| I'm sorry for coming across harsh. I tried to stick to commentary about your words, not you as a person. That's why I said "your comments are." I legitimately find your commenting here rather frustrating. It feels to me like you're posting zingers instead of trying to come to a mutual understanding. I'll try one last time. I personally feel like this answer[1] very clearly refutes the criticism leveled in the top-level comment[2]. Specifically, the opening parts of the answer: > It depends on the computational model you choose. It is obviously not true that two numbers can be added together in constant time regardless of their size. If you think about it in terms of the most elementary operations, those on individual bits, adding two n-bit numbers would require O(n) elementary operations. And multiplying two n-bit numbers would use O(n2) elementary operations if you do it using long multiplication. You can easily try this out for yourself using pen and paper. > The problem with this viewpoint is that it makes analyzing algorithms very tedious. Any time we would add two numbers a and b we would have to figure out that they would have loga and logb bits respectively and that the addition would take O(loga+logb) time. This would make the analysis much more tedious, and result in running time with lots of logs in them. And thus, by convention, big-O notation typically uses an `n` that is defined in terms of units of bits and not just bits themselves. This is why it can make sense to declare something O(1) even when it might actually be O(logn) where n is the number of bits in the input. [1]: https://cs.stackexchange.com/a/140646 [2]: https://news.ycombinator.com/item?id=38511259 |
I don't disagree with this at all, now the question is: what is n in the case we are talking about? That goes to infinity as we evaluate the cost of this cache system, allowing us to use *asymptotic O notation*?