Hi,
I was messing around with recursive arrays and I came across this:
mark@imac% cat hash.rb
a = []
a[0] = a
puts a.hash
mark@imac% ruby -v hash.rb
ruby 1.9.0 (2004-04-11) [powerpc-darwin]
hash.rb:3:in hash': stack level too deep (SystemStackError) from hash.rb:3:inhash’
from hash.rb:3:in hash' from hash.rb:3:inhash’
from hash.rb:3:in hash' from hash.rb:3:inhash’
from hash.rb:3:in hash' from hash.rb:3:inhash’
from hash.rb:3:in hash' ... 44888 levels... from hash.rb:3:inhash’
from hash.rb:3:in hash' from hash.rb:3:inhash’
from hash.rb:3
You might count this as a bug, but it is documented.
In ToDo of ruby-1.8.1, there is this line:
hash etc. should handle self referenceing array/hash
···
On Wed, Apr 28, 2004 at 02:14:31AM +0900, Mark Hubbart wrote:
Hi,
I was messing around with recursive arrays and I came across this:
mark@imac% cat hash.rb
a =
a[0] = a
puts a.hash
mark@imac% ruby -v hash.rb
ruby 1.9.0 (2004-04-11) [powerpc-darwin]
hash.rb:3:in hash': stack level too deep (SystemStackError) from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' ... 44888 levels... from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3
Hi,
I was messing around with recursive arrays and I came across this:
mark@imac% cat hash.rb
a =
a[0] = a
puts a.hash
mark@imac% ruby -v hash.rb
ruby 1.9.0 (2004-04-11) [powerpc-darwin]
hash.rb:3:in hash': stack level too deep (SystemStackError) from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' ... 44888 levels... from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3
… looks like a bug?
Hm, I’d say that for efficiency reasons loop detection in object graphs of
arrays is not done and thus it’s a bug you’ll have to live with. After
all, how often do you need self referencing containers?
Apparently if I do need self referencing arrays, I can’t use #hash on
them. Unless I redefine it so it works properly.
Anyway, I realized that the documentation for Array#hash is messed up.
It claims (or at least implies) that #eql? uses #hash to compare
values. I was assuming that a bug in #hash would make comparisons mess
up. I was wrong
Hi,
I was messing around with recursive arrays and I came across this:
mark@imac% cat hash.rb
a =
a[0] = a
puts a.hash
mark@imac% ruby -v hash.rb
ruby 1.9.0 (2004-04-11) [powerpc-darwin]
hash.rb:3:in hash': stack level too deep (SystemStackError) from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' ... 44888 levels... from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3
… looks like a bug?
Hm, I’d say that for efficiency reasons loop detection in object
graphs of
arrays is not done and thus it’s a bug you’ll have to live with. After
all, how often do you need self referencing containers?
Returns true if array and other are the same object,
or are both arrays with the same content.
Array#eql? does not use Array#hash at all for comparison. Hash
assumes hash values to be same when eql? is true (but not reverse).
matz.
···
In message “Re: Array#hash bug?” on 04/04/28, Mark Hubbart discord@mac.com writes:
Anyway, I realized that the documentation for Array#hash is messed up.
It claims (or at least implies) that #eql? uses #hash to compare
values. I was assuming that a bug in #hash would make comparisons mess
up. I was wrong
Hi,
I was messing around with recursive arrays and I came across this:
mark@imac% cat hash.rb
a =
a[0] = a
puts a.hash
mark@imac% ruby -v hash.rb
ruby 1.9.0 (2004-04-11) [powerpc-darwin]
hash.rb:3:in hash': stack level too deep (SystemStackError) from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3:in hash' ... 44888 levels... from hash.rb:3:in hash’
from hash.rb:3:in hash' from hash.rb:3:in hash’
from hash.rb:3
… looks like a bug?
Hm, I’d say that for efficiency reasons loop detection in object
graphs of
arrays is not done and thus it’s a bug you’ll have to live with.
After
all, how often do you need self referencing containers?
Apparently if I do need self referencing arrays, I can’t use #hash on
them. Unless I redefine it so it works properly.
Yes. But do you need them? And if so, to which end?
Anyway, I realized that the documentation for Array#hash is messed up.
It claims (or at least implies) that #eql? uses #hash to compare
values. I was assuming that a bug in #hash would make comparisons mess
up. I was wrong
I was just stupid I misinterpreted the ri entry for Array#hash:
Compute a hash-code for this array. Two arrays with the same
content will have the same hash code (and will compare using
+eql?+).
Actually, this entry is completely true, much to my surprise; I just
read it completely wrong.
–Mark
···
On Apr 28, 2004, at 2:01 AM, Yukihiro Matsumoto wrote:
In message “Re: Array#hash bug?” > on 04/04/28, Mark Hubbart discord@mac.com writes:
Anyway, I realized that the documentation for Array#hash is messed up.
It claims (or at least implies) that #eql? uses #hash to compare
values. I was assuming that a bug in #hash would make comparisons mess
up. I was wrong
Which document did you read? ri says:
call-seq:
array.eql?(other) => true or false
Returns true if array and other are the same object,
or are both arrays with the same content.
Array#eql? does not use Array#hash at all for comparison. Hash
assumes hash values to be same when eql? is true (but not reverse).
