=== is not commutative petrik. That's by design, since its main use is for the case... when statement. brian, [1,2] and [2,1] are obviously not equal. Order is meaningful in arrays.
One of them is a *by value* comparison, and one of them is a *by reference* comparison; Matz's ripped this straight out of Lisp (but Java/C# has this too).
'==' is saying "Do these objects have the same value?", and 'equal?' is saying "Are these two the same object in memory". Since they were created in separate parts of the expression, and they aren't memoized, the latter is False (internally, these two arrays are stored in different places).
If you picked non-integral types, '==' will always be the same as 'equal?'.
Are you a hacker who likes to make music? You know how you feel precise control when you write code you understand, but you have to filter your understanding of your music through oversimplified GUIs which sometimes have terrible UX? I made a series of videos which teaches you how to write music sequencing software in Node.js and CoffeeScript. When I do it, I experience a clarity which makes it easy for me to make more exciting sounds. You may have the same experience. Upcoming episodes will also teach you how to use simple probabilistic artificial intelligence to write code which writes its own music (which I've already done in Ruby).
And, also:
ReplyDelete>> [1,2].eql? [1,2]
=> true
WTF, mate?
How about this one:
ReplyDelete>> 'a' === String
=> false
>> String === 'a'
=> true
.eql? is an .equal? only relevant to numeric comparison.
ReplyDelete[1,2] == [2,1] #=> false on my machine
ReplyDelete=== is not commutative petrik. That's by design, since its main use is for the case... when statement.
ReplyDeletebrian, [1,2] and [2,1] are obviously not equal. Order is meaningful in arrays.
One of them is a *by value* comparison, and one of them is a *by reference* comparison; Matz's ripped this straight out of Lisp (but Java/C# has this too).
ReplyDelete'==' is saying "Do these objects have the same value?", and 'equal?' is saying "Are these two the same object in memory". Since they were created in separate parts of the expression, and they aren't memoized, the latter is False (internally, these two arrays are stored in different places).
If you picked non-integral types, '==' will always be the same as 'equal?'.
Ah ok that makes sense. Thanks!
ReplyDeleteHere is nice catch:
ReplyDeleterequire 'ostruct'
[1, 2].to_set == [2, 1].to_set
=> true