You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by "Sean Owen (JIRA)" <ji...@apache.org> on 2009/09/07 09:26:57 UTC
[jira] Created: (MAHOUT-174) Unify Pair implementation
Unify Pair implementation
-------------------------
Key: MAHOUT-174
URL: https://issues.apache.org/jira/browse/MAHOUT-174
Project: Mahout
Issue Type: Task
Affects Versions: 0.2
Reporter: Sean Owen
Assignee: Sean Owen
Priority: Minor
Fix For: 0.2
Attachments: MAHOUT-174.patch
Per discussion on mahout-dev, starting a series of patches to unify code, starting with Pair. Simple enough, but, it snowballed a little bit:
- Now there is just org.apache.mahout.common.Pair
- I moved my LongPair implementation next to it for consistency
- But it depends on my RandomUtils, and doesn't make sense for a top-level package to depend downward like that, so moved it too -- since we discussed that this should probably get reused a little more too
- Then I saw that the LFUCache class needs a mutable Pair whereas the new variant is immutable. I judged it was better to actually modify LFUCache to not need mutability -- because in this case it ends up increasing performance as well: Rather than create and re-create Longs as counts, it uses a "mutable Long" -- AtomicLong. An array of one long would have done the trick too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAHOUT-174) Unify Pair implementation
Posted by "Sean Owen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sean Owen updated MAHOUT-174:
-----------------------------
Attachment: MAHOUT-174.patch
Another patch that adds random number generation unification around MersenneTwisterRNG
> Unify Pair implementation
> -------------------------
>
> Key: MAHOUT-174
> URL: https://issues.apache.org/jira/browse/MAHOUT-174
> Project: Mahout
> Issue Type: Task
> Affects Versions: 0.2
> Reporter: Sean Owen
> Assignee: Sean Owen
> Priority: Minor
> Fix For: 0.2
>
> Attachments: MAHOUT-174.patch, MAHOUT-174.patch
>
>
> Per discussion on mahout-dev, starting a series of patches to unify code, starting with Pair. Simple enough, but, it snowballed a little bit:
> - Now there is just org.apache.mahout.common.Pair
> - I moved my LongPair implementation next to it for consistency
> - But it depends on my RandomUtils, and doesn't make sense for a top-level package to depend downward like that, so moved it too -- since we discussed that this should probably get reused a little more too
> - Then I saw that the LFUCache class needs a mutable Pair whereas the new variant is immutable. I judged it was better to actually modify LFUCache to not need mutability -- because in this case it ends up increasing performance as well: Rather than create and re-create Longs as counts, it uses a "mutable Long" -- AtomicLong. An array of one long would have done the trick too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAHOUT-174) Unify Pair implementation
Posted by "Sean Owen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sean Owen updated MAHOUT-174:
-----------------------------
Attachment: MAHOUT-174.patch
> Unify Pair implementation
> -------------------------
>
> Key: MAHOUT-174
> URL: https://issues.apache.org/jira/browse/MAHOUT-174
> Project: Mahout
> Issue Type: Task
> Affects Versions: 0.2
> Reporter: Sean Owen
> Assignee: Sean Owen
> Priority: Minor
> Fix For: 0.2
>
> Attachments: MAHOUT-174.patch
>
>
> Per discussion on mahout-dev, starting a series of patches to unify code, starting with Pair. Simple enough, but, it snowballed a little bit:
> - Now there is just org.apache.mahout.common.Pair
> - I moved my LongPair implementation next to it for consistency
> - But it depends on my RandomUtils, and doesn't make sense for a top-level package to depend downward like that, so moved it too -- since we discussed that this should probably get reused a little more too
> - Then I saw that the LFUCache class needs a mutable Pair whereas the new variant is immutable. I judged it was better to actually modify LFUCache to not need mutability -- because in this case it ends up increasing performance as well: Rather than create and re-create Longs as counts, it uses a "mutable Long" -- AtomicLong. An array of one long would have done the trick too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAHOUT-174) Unify Pair implementation, Random
number generation
Posted by "Sean Owen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sean Owen updated MAHOUT-174:
-----------------------------
Description:
Per discussion on mahout-dev, starting a series of patches to unify code, starting with Pair. Simple enough, but, it snowballed a little bit:
- Now there is just org.apache.mahout.common.Pair
- I moved my LongPair implementation next to it for consistency
- But it depends on my RandomUtils, and doesn't make sense for a top-level package to depend downward like that, so moved it too -- since we discussed that this should probably get reused a little more too
- Then I saw that the LFUCache class needs a mutable Pair whereas the new variant is immutable. I judged it was better to actually modify LFUCache to not need mutability -- because in this case it ends up increasing performance as well: Rather than create and re-create Longs as counts, it uses a "mutable Long" -- AtomicLong. An array of one long would have done the trick too.
- Now, the patch also unifies random number generation around MersenneTwisterRNG, and ensures that all RNGs can be set to use a constant seed when in unit test mode.
was:
Per discussion on mahout-dev, starting a series of patches to unify code, starting with Pair. Simple enough, but, it snowballed a little bit:
- Now there is just org.apache.mahout.common.Pair
- I moved my LongPair implementation next to it for consistency
- But it depends on my RandomUtils, and doesn't make sense for a top-level package to depend downward like that, so moved it too -- since we discussed that this should probably get reused a little more too
- Then I saw that the LFUCache class needs a mutable Pair whereas the new variant is immutable. I judged it was better to actually modify LFUCache to not need mutability -- because in this case it ends up increasing performance as well: Rather than create and re-create Longs as counts, it uses a "mutable Long" -- AtomicLong. An array of one long would have done the trick too.
Summary: Unify Pair implementation, Random number generation (was: Unify Pair implementation)
> Unify Pair implementation, Random number generation
> ---------------------------------------------------
>
> Key: MAHOUT-174
> URL: https://issues.apache.org/jira/browse/MAHOUT-174
> Project: Mahout
> Issue Type: Task
> Affects Versions: 0.2
> Reporter: Sean Owen
> Assignee: Sean Owen
> Priority: Minor
> Fix For: 0.2
>
> Attachments: MAHOUT-174.patch, MAHOUT-174.patch
>
>
> Per discussion on mahout-dev, starting a series of patches to unify code, starting with Pair. Simple enough, but, it snowballed a little bit:
> - Now there is just org.apache.mahout.common.Pair
> - I moved my LongPair implementation next to it for consistency
> - But it depends on my RandomUtils, and doesn't make sense for a top-level package to depend downward like that, so moved it too -- since we discussed that this should probably get reused a little more too
> - Then I saw that the LFUCache class needs a mutable Pair whereas the new variant is immutable. I judged it was better to actually modify LFUCache to not need mutability -- because in this case it ends up increasing performance as well: Rather than create and re-create Longs as counts, it uses a "mutable Long" -- AtomicLong. An array of one long would have done the trick too.
> - Now, the patch also unifies random number generation around MersenneTwisterRNG, and ensures that all RNGs can be set to use a constant seed when in unit test mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MAHOUT-174) Unify Pair implementation, Random
number generation
Posted by "Sean Owen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAHOUT-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sean Owen resolved MAHOUT-174.
------------------------------
Resolution: Fixed
> Unify Pair implementation, Random number generation
> ---------------------------------------------------
>
> Key: MAHOUT-174
> URL: https://issues.apache.org/jira/browse/MAHOUT-174
> Project: Mahout
> Issue Type: Task
> Affects Versions: 0.2
> Reporter: Sean Owen
> Assignee: Sean Owen
> Priority: Minor
> Fix For: 0.2
>
> Attachments: MAHOUT-174.patch, MAHOUT-174.patch
>
>
> Per discussion on mahout-dev, starting a series of patches to unify code, starting with Pair. Simple enough, but, it snowballed a little bit:
> - Now there is just org.apache.mahout.common.Pair
> - I moved my LongPair implementation next to it for consistency
> - But it depends on my RandomUtils, and doesn't make sense for a top-level package to depend downward like that, so moved it too -- since we discussed that this should probably get reused a little more too
> - Then I saw that the LFUCache class needs a mutable Pair whereas the new variant is immutable. I judged it was better to actually modify LFUCache to not need mutability -- because in this case it ends up increasing performance as well: Rather than create and re-create Longs as counts, it uses a "mutable Long" -- AtomicLong. An array of one long would have done the trick too.
> - Now, the patch also unifies random number generation around MersenneTwisterRNG, and ensures that all RNGs can be set to use a constant seed when in unit test mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.