I understand hash functions can produce collisions, but they really shouldn't collide for something as trivial as [2, 3] and [4, 5].
Broken semantics for such simple things make me seriously distrust the language runtime completely. At the very least, this means that the much-touted Hash object in Ruby is untrustworthy and can easily lead to data loss or corruption.
> they really shouldn't collide for something as trivial as ...
Why not? Hashes produce collisions. If you don't want collisions don't use hashes. Or if you want a hash function that doesn't produce collisions for your specific data type, write one. It's not hard.
Relying on a generic hash function to never create a collision is just poor engineering on your part.
As you say yourself, 1.8.6 is slightly broken. But do you expect old releases to always be bug-free? 1.8.6 isn't even the newest version of the 1.8 branch, let alone that 1.9 is the current branch of Ruby.
And as for your distrust of the runtime, did you know that 1.9 is an entirely new one?
As I noted, 1.8.7 produces a hash collision for [2, 3] and [4, 5]. 1.9.1-p376 has exactly the same behavior. I reiterate: the Hash object is unreliable, regardless of the runtime version. Based on such nasty behavior in such a simple case, I distrust Ruby's runtime and standard library for more complicated uses.
Ruby 1.8.6:
Meaning, two identical objects are not equal. This is fixed in 1.8.7, but:Ruby 1.8.7:
I understand hash functions can produce collisions, but they really shouldn't collide for something as trivial as [2, 3] and [4, 5].Broken semantics for such simple things make me seriously distrust the language runtime completely. At the very least, this means that the much-touted Hash object in Ruby is untrustworthy and can easily lead to data loss or corruption.