[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

compare two identically hashes fails

Simon Strandgaard

10/6/2003 12:53:00 PM

failure 1).. I compare 2 hashes with assert_equal.
If I inspect the hashes they appear to be identical.
But the == operator tells me they are different???
I only use Ruby's native types for the things stored in
the hash. Question: Why does this assertion fail ?



server> ruby test_all.rb
Loaded suite Unnamed TestSuite
Started
........................false
FF
Finished in 0.049179 seconds.

1) Failure!!!
test_one_letter(TestRegex) [./test_regex.rb:29]:
<{1=>[["a", 2]], 2=>[]}> expected but was
<{1=>[["a", 2]], 2=>[]}>

2) Failure!!!
test_sequence(TestRegex) [./test_regex.rb:36]:
<#<Nfa:0x81d2194 @nfa_hash={1=>[["a", 2]], 2=>[["b", 3]], 3=>[]}>> expected but was
<#<Nfa:0x81d225c @nfa_hash={1=>[["a", 2]], 2=>[["b", 3]], 3=>[]}>>

25 tests, 25 assertions, 2 failures, 0 errors
server>



In order to reproduce the problem, you can do a cvs-checkout of
these files.

cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/aeditor login

press enter when promped for a password

cvs -z3 -d:pserver:anonymous@rubyforge.org:/var/cvs/aeditor co projects/experimental/nfa_to_dfa

cd projects/experimental/nfa_to_dfa

cvs up -r 1.2 nfa.rb
cvs up -r 1.2 regex.rb
cvs up -r 1.3 test_regex.rb


in order to execute it then do:

ruby test_regex.rb

--
Simon Strandgaard
6 Answers

Simon Strandgaard

10/6/2003 1:00:00 PM

0

On Mon, 06 Oct 2003 15:52:59 +0200, Simon Strandgaard wrote:

> failure 1).. I compare 2 hashes with assert_equal.
> If I inspect the hashes they appear to be identical.
> But the == operator tells me they are different???
> I only use Ruby's native types for the things stored in
> the hash. Question: Why does this assertion fail ?


I have found a simplification of my problem:

def test_hash_compare
on_new = proc {|h, k| h[k] = []}
h1 = Hash.new(&on_new)
h1[1] = [["a", 2]]
h1[2] = []
h2 = {1=>[["a", 2]], 2=>[]}
assert_equal(h1, h2)
end

How should I compare these 2 hashes, so it yields true ?

--
Simon Strandgaard

Simon Strandgaard

10/6/2003 1:17:00 PM

0

On Mon, 06 Oct 2003 15:59:59 +0200, Simon Strandgaard wrote:

> On Mon, 06 Oct 2003 15:52:59 +0200, Simon Strandgaard wrote:
>
>> failure 1).. I compare 2 hashes with assert_equal.
>> If I inspect the hashes they appear to be identical.
>> But the == operator tells me they are different???
>> I only use Ruby's native types for the things stored in
>> the hash. Question: Why does this assertion fail ?
>
>
> I have found a simplification of my problem:
>
> def test_hash_compare
> on_new = proc {|h, k| h[k] = []}
> h1 = Hash.new(&on_new)
> h1[1] = [["a", 2]]
> h1[2] = []
> h2 = {1=>[["a", 2]], 2=>[]}

h1.default = nil
h2.default = nil


> assert_equal(h1, h2)
> end
>
> How should I compare these 2 hashes, so it yields true ?

Now it yields true.. thanks comp.lang.ruby :-)

--
Simon Strandgaard

Robert Klemme

10/6/2003 1:20:00 PM

0


"Simon Strandgaard" <qj5nd7l02@sneakemail.com> schrieb im Newsbeitrag
news:pan.2003.10.06.13.17.01.151417@sneakemail.com...
> On Mon, 06 Oct 2003 15:59:59 +0200, Simon Strandgaard wrote:
>
> > On Mon, 06 Oct 2003 15:52:59 +0200, Simon Strandgaard wrote:
> >
> >> failure 1).. I compare 2 hashes with assert_equal.
> >> If I inspect the hashes they appear to be identical.
> >> But the == operator tells me they are different???
> >> I only use Ruby's native types for the things stored in
> >> the hash. Question: Why does this assertion fail ?
> >
> >
> > I have found a simplification of my problem:
> >
> > def test_hash_compare
> > on_new = proc {|h, k| h[k] = []}
> > h1 = Hash.new(&on_new)
> > h1[1] = [["a", 2]]
> > h1[2] = []
> > h2 = {1=>[["a", 2]], 2=>[]}
>
> h1.default = nil
> h2.default = nil
>
>
> > assert_equal(h1, h2)
> > end
> >
> > How should I compare these 2 hashes, so it yields true ?
>
> Now it yields true.. thanks comp.lang.ruby :-)

You're welcome. Sometimes expressing one's thoughts is already enough to
find the answer. :-)

Have fun

robert

Simon Strandgaard

10/6/2003 1:38:00 PM

0

On Mon, 06 Oct 2003 16:19:55 +0200, Robert Klemme wrote:
>
> You're welcome. Sometimes expressing one's thoughts is already enough to
> find the answer. :-)

Yes.

Some more thoughs about Hash#default... here we go:


Why does Hash#inspect not output the content of Hash#default ?
It would make sense, because Ruby already compare Hash#default.




Why does Ruby not reset Hash#default when you issues a #to_hash ?
I think it would give a better behaiver? What does others thinks?

def test_hash_compare
on_new = proc {|h, k| h[k] = []}
h1 = Hash.new(&on_new)
h1[1] = [["a", 2]]
h1[2] = []
h2 = {1=>[["a", 2]], 2=>[]}
h1.default = nil # this is annoying!!
h2.default = nil # this is annoying!!
assert_equal(h1, h2)
end

If one instead could write it like following:

def test_hash_compare
on_new = proc {|h, k| h[k] = []}
h1 = Hash.new(&on_new)
h1[1] = [["a", 2]]
h1[2] = []
h2 = {1=>[["a", 2]], 2=>[]}
assert_equal(h1.to_hash, h2.to_hash)
end


--
Simon Strandgaard

Robert Klemme

10/6/2003 1:47:00 PM

0


"Simon Strandgaard" <qj5nd7l02@sneakemail.com> schrieb im Newsbeitrag
news:pan.2003.10.06.13.38.12.369148@sneakemail.com...
> On Mon, 06 Oct 2003 16:19:55 +0200, Robert Klemme wrote:
> >
> > You're welcome. Sometimes expressing one's thoughts is already enough
to
> > find the answer. :-)
>
> Yes.
>
> Some more thoughs about Hash#default... here we go:
>
>
> Why does Hash#inspect not output the content of Hash#default ?
> It would make sense, because Ruby already compare Hash#default.

In a way it would make sense. On the other hand, the inspect method
yields something that can be reconverted to a Hash using eval; although
this is likely to work only for standard types (String, Integer, Hash,
Array) the feature is quite useful. It would then be reasonable to change
the Hash creation syntax, maybe by allowing a single element in front:

a = {1=>2, 3=>4}
b = {nil 1=>2, 3=>4}
c = {"Foo" 1=>2, 3=>4}

a == b but a != c

> Why does Ruby not reset Hash#default when you issues a #to_hash ?

Short answer: why should it?

Long answer: Because it returns self. That method is rather meant for
other types that can convert themselves to a hash. This method is not
expected to generate a side effect and the reset thus would violate POLS.

Kind regards

robert

Kent Dahl

10/6/2003 1:50:00 PM

0

Simon Strandgaard wrote:
> Why does Hash#inspect not output the content of Hash#default ?
> It would make sense, because Ruby already compare Hash#default.

Calling Hash#default may modify the Hash, such as with the proc you use.
(Try calling h1.default before assert_equal)

There are two values underlying the default, both a value default and a
proc default. Outputting them both would be ugly and visually
cluttering, IMHO.

> Why does Ruby not reset Hash#default when you issues a #to_hash ?
> I think it would give a better behaiver? What does others thinks?

I think it would break the protocol of the to_hash as a type conversion
method and result in information loss. What if someone calls to_hash
just to ensure they have a Hash or hash-like object? Why should the
default value or proc be tossed out?

> def test_hash_compare
> on_new = proc {|h, k| h[k] = []}
> h1 = Hash.new(&on_new)
> h1[1] = [["a", 2]]
> h1[2] = []
> h2 = {1=>[["a", 2]], 2=>[]}
> h1.default = nil # this is annoying!!
> h2.default = nil # this is annoying!!

That last line is not necessary, since the literal hash has nil as
default value anyway. So it is only half as annoying. :-)

> assert_equal(h1, h2)
> end
>
> If one instead could write it like following:
>
> def test_hash_compare
> on_new = proc {|h, k| h[k] = []}
> h1 = Hash.new(&on_new)
> h1[1] = [["a", 2]]
> h1[2] = []

Just a tangential nitpick, but shouldn't the above line only be
h1[2]
if you're trying to exercise the on_new proc in the test?

> h2 = {1=>[["a", 2]], 2=>[]}
> assert_equal(h1.to_hash, h2.to_hash)
> end

What I realized I missed upon seeing your question, was a
Hash#default_proc= method. It seems a bit restrictive to only be able to
set it on object construction. Does anyone know if there is a rationale
behind this decision?

--
(\[ Kent Dahl ]/)_ _~_ _____[ http://www.pvv.or... ]_____/~
))\_student_/(( \__d L b__/ Master of Science in Technology )
( \__\_õ|õ_/__/ ) _)Industrial economics and technological management(
\____/_ö_\____/ (____engineering.discipline_=_Computer::Technology___)