4 ms·
Yep, it's the same thing every time. "We propose this new thing with optimal time complexity blah blah blah" - don't care. Show benchmark. What do you mean it's
by andersa 3y ago
Yep, it's the same thing every time. "We propose this new thing with optimal time complexity blah blah blah" - don't care. Show benchmark. What do you mean it's slower than this basic but cache efficient hash table implemented in 100 lines of c++?
- vlovich123 3y agoThis is a totally different result. It’s providing a proof of an algorithmic complexity. So let’s say you have 10^18 items, it’s likely you’d be using this even if certain algorithms are faster at smaller numbers. It’s also important to note the particularly interesting result is how the mathematicians proved that the earlier design was optimal (upper and lower bound). The technique is the valuable part as it adds to the mathematician tool kit of how to prove such results. This article is about math papers / functional theoretic math, not about applies CS ideas.
- Dylan16807 3y ago> let’s say you have 10^18 items You won't. Not on a single node. > The technique is the valuable part as it adds to the mathematician tool kit of how to prove such results. Agreed.
- andersa 3y agoI'm struggling to think of any possible application that would need anywhere remotely close to 10^18 items. Do you have an example?
- vlovich123 3y agoI pulled that specific number out of the air and it was intentionally an over exaggeration. We don’t know the crossover point.