public
Last active

  • Download Gist
gistfile1.rb
Ruby
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
I would start by running the test stuff.
 
test = euclidean(@people, 'Lisa Rose', 'Gene Seymour')
puts "#{test} should equal 0.148148148148"
 
Also note that the version in the book is wrong,
which is why i have the #errata comment there, since my version is the correct one, afaik.
 
so, both euclidean and pearson are meant to be interchangeable.
So, all that both of them do is take a hash in the following form:
 
 
{
:owner_object => {:owned_object => score, :owned_object => score,
:another_owner_object => {:owned_object => score}
}
 
Where score is an int. To try this for yourself, just construct some hash and
pass in two of the keys.
 
So, euclidean will just take a hash like that, plus two of the keys
for the owner objects and tell you how similar they are.
 
Does that make sense?
 
I wrote the method to be very clear for people / movies,
but it's unfortunaly kind of unclear if you want to abstract it.
However, it is abstract.
 
 
You can see all this at work in the delicious_recommendations.rb file.
 
So, when it calls super, in top matches in the class in that file, it's calling
the top_matches defined in recommendations.rb, (since it's defined on object it gets called
by super -- i was lazy).
 
So, looking here, we can see that peearson is getting called.
 
I think that you could just change this to euclidean and it would still work. So that's another example.
 
def top_matches(people, person, n=5)
scores = people.map do |critic, items|
unless person == critic
[(block_given? ? yield(people, person, critic) : pearson(people, person, critic)), critic]
end
end
scores.compact.sort.reverse[0..n]
end
 
Best,
 
M

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.