[
https://issues.apache.org/jira/browse/MAHOUT-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743375#action_12743375
]
Sean Owen commented on MAHOUT-162:
----------------------------------
The interesting part might be the choice of hash function. I reversed myself
and went with MD5. The reason is that it is more portable since it is a well
known function implemented in many contexts and this could aid integration. For
example from a MySQL database table using string ids, once can simply select
'conv(substr(md5(id),1,16),16,10)' instead of 'id' from the table and that is
about it.
Good glad it looks pretty straightforward. My laptop died so it will be some
time before I can rebuild and commit from a new machine. Good thing I put out
the patch, that is about the only thing I hadn't saved.
> Added support for mapping String to long IDs in CF code
> -------------------------------------------------------
>
> Key: MAHOUT-162
> URL: https://issues.apache.org/jira/browse/MAHOUT-162
> Project: Mahout
> Issue Type: Improvement
> Components: Collaborative Filtering
> Affects Versions: 0.2
> Reporter: Sean Owen
> Assignee: Sean Owen
> Fix For: 0.2
>
> Attachments: MAHOUT-162.patch
>
>
> Since the framework now only allows long (64-bit integer) IDs, and no longer
> Strings, we need to provide some support for translating between the two. The
> basic proposal is this:
> - Define a one-way mapping from Strings to longs that is repeatable and easy
> to implement in many contexts. In particular I propose using the bottom 64
> bits of the MD5 hash of a string.
> - Define support for storing the reverse mapping (longs to Strings) in
> various ways, in an efficient way, that handles gracefully the very rare
> possibility of collision
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
