Some simplifications may actually be harmful to understanding if they throw away key points or introduce logical contradictions.
For a hash table, the general "promise" is that you map a very large space of keys (e.g. all strings) to a very small space of indexes using a simple function. Common sense might tell you that this shouldn't be possible ("how can you put something big into something small?") - and of course actual hash tables solve the conundrum by acknowledging collisions and defining ways to deal with them.
But by saying "let's assume no collisions" the reader is asked to just ignore the logical contradiction instead of solving it. That can lead to frustration in the best case or to serious misconceptions in the worst case.
Of course there is nothing wrong with saying "let's ignore those points for now, I'll explain later". Also I guess it depends very much on the learning style of the reader. But bad simplification can be very annoying for some learners.
>For a hash table, the general "promise" is that you map a very large space of keys (e.g. all strings) to a very small space of indexes using a simple function
Well, AFAICT there is no mention of any of this in the document. No "promise" or any such thing has been said or implied. Please stick to what the author has actually said rather than what you imagine people are thinking about when reading the document.
>. Common sense might tell you that this shouldn't be possible ("how can you put something big into something small?")
No, it doesn't tell me that at all, because that point is not brought up in the document. But is that how you think most people learn? Using common sense?
>But by saying "let's assume no collisions" the reader is asked to just ignore the logical contradiction instead of solving it.
Sure, you think those are the logical contradictions in the readers' minds. Can you actually establish that?
> But bad simplification can be very annoying for some learners.
A list of what is annoying for "some" learners is quite possibly very very large. Lets not....
--
Anyway, we can go down this rabbit hole, but it isn't actually productive, and quite boring to be honest. My point is that every-time someone tries simplify something for beginners, people seem to relish that opportunity to show everyone how "smart" they are about trivial data-structures. Yes, if you want somebody to make an expository article for beginners with the detail of something like TAOCP, then yeah, you're going to be disappointed. But, you can and should learn Newtonian physics, even if its "wrong", before you move on to Einstein.
>Well, AFAICT there is no mention of any of this in the document. No "promise" or any such thing has been said or implied.
I'm not sure you got the parent's comment. What you wrote about is true -- and that's what's wrong with the document. That it doesn't mention such a promise, not it describe an actual hash table implementation (where collisions are inevitable and should be dealt with).
>Please stick to what the author has actually said rather than what you imagine people are thinking about when reading the document.
Again, the problem is that people sticking with "what the author has actually said" will not learn how hash tables actually work.
>No, it doesn't tell me that at all, because that point is not brought up in the document. But is that how you think most people learn? Using common sense?
Now you're just being contradictory to be contradictory. Or trolling.
Yes, people use common sense to learn -- and to understand what they are learning. How is this not obvious?
>Sure, you think those are the logical contradictions in the readers' minds. Can you actually establish that?
I'm a reader, and immediately jumped to see the same logical contradiction.
Not even sure what you're trying to defend exactly. Sloppy examples?
>Again, the problem is that people sticking with "what the author has actually said" will not learn how hash tables actually work.
Huh? People are complaining about the implementation not having collision detection. The author clearly lays out what collisions are, why they are required and also that they need to be dealt with. Did you read the article?
>Yes, people use common sense to learn -- and to understand what they are learning. How is this not obvious?
It would help if you didn't change the context and scope of what I have said. I am not talking about some random topic that you can derive through first principles or common sense or other logical means. To me its obvious you didn't understand what I meant or what I was replying to. Its pointless to argue further and derail the thread.
>Not even sure what you're trying to defend exactly. Sloppy examples?
Not to sound gratuitously rude, but if you don't know what my point is, why not ask me first?
How hard is it to introduce the idea of slots or pidgeonholes that the elements are stuck in, and if there is more than one item there, it is added to a list/collection?
For a hash table, the general "promise" is that you map a very large space of keys (e.g. all strings) to a very small space of indexes using a simple function. Common sense might tell you that this shouldn't be possible ("how can you put something big into something small?") - and of course actual hash tables solve the conundrum by acknowledging collisions and defining ways to deal with them.
But by saying "let's assume no collisions" the reader is asked to just ignore the logical contradiction instead of solving it. That can lead to frustration in the best case or to serious misconceptions in the worst case.
Of course there is nothing wrong with saying "let's ignore those points for now, I'll explain later". Also I guess it depends very much on the learning style of the reader. But bad simplification can be very annoying for some learners.