In the article, x is not the size of the hash table, it is the inverse of the table’s filling fraction. A 1000-element table that is 90% full has x=10, N=1000.
Since they’re not discussing scaling of data sizes, would be confusing to use O(N) notation or people would make that assumption.
If you use a hash table, you search every time you retrieve an object.
If you didn’t retrieve, why would you be storing the data in the first place?
Hash tables are used in literally everything and they always need to minimize resizing because it’s a very expensive operation.
I suspect this will silently trickle into lots of things once it gets picked up by standard Python and JavaScript platforms, but that will take years.
That’s just another monopoly. How much do you trust your government?
Reminder that the Nokia the smart phone company was spun off/renamed HMD and this Nokia sells cell network equipment to telecoms.
I don’t need wireless 1Gbps around town.
I need reliable 100kbps when I’m out in the boonies.
Fixing coverage gaps is not sexy but is way more useful.
Isn’t it a chariot?
Downvoting is not harassment.
Don’t be so sensitive.
That’s only the shareware version. Full DOOM took like 8 floppies.
Downvoting is harmless disagreement and I won’t interact with any place than bans them because it’s a sure sign of an authoritarian echo chamber.
What’s the exposure surface of this if I have remote access disabled?
Swasticar
A bad pickup truck is still just a pickup truck.
The article is discussing how to reduce the constant time factor which depends on the filling fraction, which is a speed-memory tradeoff when creating the hash table.
The innovation described allows for the use of fuller tables which are resized less frequently, or faster insertion/retrieval for the existing filling fraction.