[
https://issues.apache.org/jira/browse/MAHOUT-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Anil updated MAHOUT-157:
--
Component/s: Frequent Itemset/Association Rule Mining
> Frequent Pattern Mining using Parallel FP-Growt
DistanceMeasure is broken: iteration is done over nonZeroElements of
v1.plus(v2), not v1.minus(v2)
--
Key: MAHOUT-181
URL: https://issues.apache.org/jira/browse/MAHOUT
[
https://issues.apache.org/jira/browse/MAHOUT-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Mannix updated MAHOUT-181:
---
Status: Patch Available (was: Open)
Fix for all but TanimotoDistanceMeasure, as well as (currently f
[
https://issues.apache.org/jira/browse/MAHOUT-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Mannix updated MAHOUT-181:
---
Attachment: MAHOUT-181.patch
Hmm... missed the patch the first time.
> DistanceMeasure is broken: it
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760879#action_12760879
]
Jake Mannix commented on MAHOUT-165:
Hey Ted, I tried bringing your patch up to current
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760886#action_12760886
]
Jake Mannix commented on MAHOUT-165:
One test which is failing is the basic VectorTest
[
https://issues.apache.org/jira/browse/MAHOUT-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760890#action_12760890
]
Robin Anil commented on MAHOUT-170:
---
A Quick Test, uses some parameters which i felt woul
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760893#action_12760893
]
Sean Owen commented on MAHOUT-165:
--
It's a good, important question and one I think needs
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760898#action_12760898
]
Grant Ingersoll commented on MAHOUT-165:
There are some thoughts on equals, etc. in
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760902#action_12760902
]
Grant Ingersoll commented on MAHOUT-165:
There are some thoughts on equals, etc. in
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760956#action_12760956
]
Sean Owen commented on MAHOUT-165:
--
Are my conclusions sound then:
We agree that equals()
Regarding having equals() effectively delegate to
getName().equals(other.getName()) && equivalent(other) means that we need to
be extra special careful about implementations of hashCode() :
If we are not going to break the contract between equals() and hashCode(),
and we're having equals() *only*
On Sep 30, 2009, at 4:03 PM, Jake Mannix wrote:
Regarding having equals() effectively delegate to
getName().equals(other.getName()) && equivalent(other) means that we
need to
be extra special careful about implementations of hashCode() :
If we are not going to break the contract between equ
No I don't hear anyone wanting to make equals() ignore the name.
(Otherwise, hashCode() would have to ignore it as well.)
JIRA also seems pretty laggy to me.
On Wed, Sep 30, 2009 at 9:03 PM, Jake Mannix wrote:
> If we are not going to break the contract between equals() and hashCode(),
> and we'
On Wed, Sep 30, 2009 at 1:16 PM, Grant Ingersoll wrote:
>
> On Sep 30, 2009, at 4:03 PM, Jake Mannix wrote:
>
> Regarding having equals() effectively delegate to
>> getName().equals(other.getName()) && equivalent(other) means that we need
>> to
>> be extra special careful about implementations of
I didn't say that equals() should ignore name, I said the opposite - equals
and
hashCode() should *only* take into account the contents and the name, and
not
implementation (which means that hashCode() needs to stay in one place and
not get monkeyed with in subclasses.
On Wed, Sep 30, 2009 at 1:18
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761002#action_12761002
]
Jake Mannix commented on MAHOUT-165:
Good luck with the "quick" part - there seem to be
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761000#action_12761000
]
Ted Dunning commented on MAHOUT-165:
I will take a quick look this evening at the patc
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Mannix updated MAHOUT-165:
---
Attachment: MAHOUT-165-updated.patch
> Using better primitives hash for sparse vector for performance
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761018#action_12761018
]
Jake Mannix commented on MAHOUT-165:
Ted, some notes on your patch:
* with the two
[
https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761021#action_12761021
]
Ted Dunning commented on MAHOUT-165:
THanks Jake, that could be very helpful.
The thr
New helper methods for Matrix: times(Vector), timesSquared(Vector), numRows()
and numCols()
---
Key: MAHOUT-182
URL: https://issues.apache.org/jira/browse/MAHOUT-182
[
https://issues.apache.org/jira/browse/MAHOUT-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Mannix updated MAHOUT-182:
---
Attachment: matrixTimes.patch
Patch to add these methods with unit tests.
> New helper methods for M
So what's the status on integration of commons-math-2.0 in Mahout?
Do we need that stuff? Some of their apis are pretty ugly (look at the
number
of methods you need to implement to qualify to be a "RealVector"), but
piggybacking on some of their functionality would be pretty useful
(especially
st
No motion. I was pushing that integration because it looked like MTJ was
integrating with them. That would give some pretty high performance linear
algebra to commons-math.
That hasn't gone anywhere lately as far as I know.
The only other integration point is that every time we have needed some
On Wed, Sep 30, 2009 at 8:26 PM, Ted Dunning wrote:
> No motion. I was pushing that integration because it looked like MTJ was
> integrating with them. That would give some pretty high performance linear
> algebra to commons-math.
>
MTJ is LGPL, how was that ever going anywhere?
Luc has been
26 matches
Mail list logo
