Re: (Bi-)Weekly/Monthly Dev Sessions

2013-06-14 Thread Grant Ingersoll
It seems to be that 6 pm ET is the consensus time for the majority of people, 
although my having screwed up the poll didn't help.

Bi-weekly is the other consensus.  It also looks like Tuesday or Thursday are 
the preferred dates.

I can't make next week, so I'm going to propose we kick off on Tuesday, June 25 
at 6 pm.  That will give us time to dry-run the Google Hangouts, etc.

Again, just to be clear, the goal here is to work on the development of Mahout, 
not to answer questions about how to run Mahout (we could do that separately if 
there is a desire.)

I'll send out a reminder as we get closer.

-Grant


On Jun 12, 2013, at 3:04 PM, Suneel Marthi suneel_mar...@yahoo.com wrote:

 I am from Northern Virginia, how many of us here are from the Washington DC 
 Metro area?
 
 
 
 
 
 From: Jake Mannix jake.man...@gmail.com
 To: dev@mahout.apache.org dev@mahout.apache.org 
 Sent: Wednesday, June 12, 2013 1:56 PM
 Subject: Re: (Bi-)Weekly/Monthly Dev Sessions
 
 
 Wow, a lot of Seattleites, I should organize a Mahout MeetUp / Hackathon
 when I get back from europe at the end of the summer!
 
 
 On Wed, Jun 12, 2013 at 10:44 AM, Andrew Musselman 
 andrew.mussel...@gmail.com wrote:
 
 Bi-weekly is good for me; I'm in Seattle and just filled out the poll.
 
 Great idea!
 
 
 On Wed, Jun 12, 2013 at 10:22 AM, Saikat Kanjilal sxk1...@hotmail.com
 wrote:
 
 +1, am in Seattle as well and would love to attend and be involved.
 
 Sent from my iPhone
 
 On Jun 12, 2013, at 10:18 AM, Ravi Mummulla ravi.mummu...@gmail.com
 wrote:
 
 Good idea on recurring meetings. Im very interested in participating.
 Biweekly works for me. I'm in Seattle (pacific) timezone - GMT-8.
 
 An agenda for the meetings ahead of time will help us get the most of
 our
 time at the meetings.
 
 Thanks.
 On Jun 12, 2013 6:23 AM, Grant Ingersoll gsing...@apache.org
 wrote:
 
 
 On Jun 12, 2013, at 8:41 AM, Shannon Quinn squ...@gatech.edu wrote:
 
 Angel and Suneel, you may want to re-fill out the new doodle.
 
 FYI, this week won't be representative of my schedule; I'm in the
 last
 few weeks of a job at ORNL where I travel every weekend. Normally I'll
 have
 more flexibility than just 6pm on weeknights.
 
 Yeah, Doodle makes you pick dates, but I just want it to be
 representative
 a week long period of time and not tied to a specific set of dates.
   So,
 just put in what your ideal times are in general and ignore the fact
 that
 it is set to next week.
 
 
 On 6/12/13 8:26 AM, Grant Ingersoll wrote:
 On Jun 12, 2013, at 7:29 AM, Shannon Quinn squ...@gatech.edu
 wrote:
 
 +1, awesome idea
 
 One question: the poll, while set to GMT -5, does say it's in
 Central
 Time. Is this a daylight savings thing?
 I turned on Time Zone support, so not sure how it will look to
 others,
 but it sounds like it adjusts based on your location...  I see: 8 am,
 10,
 1, so on.
 
 I also realize, that I messed it up.  I meant 9 pm, not 9 am.
 
 Here is the correct one: http://doodle.com/ymqaiwbh7khisnyv
 
 
 Grant Ingersoll | @gsingers
 http://www.lucidworks.com
 
 
 
 
 
 
 
 
 
 
 
 -- 
 
   -jake


Grant Ingersoll | @gsingers
http://www.lucidworks.com







[jira] [Commented] (MAHOUT-879) Remove all graph algorithms with the exception of PageRank

2013-06-14 Thread Abbas Gadhia (JIRA)

[ 
https://issues.apache.org/jira/browse/MAHOUT-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683298#comment-13683298
 ] 

Abbas Gadhia commented on MAHOUT-879:
-

There's an interesting project out there called reco4j that does Euclidean, 
Jaccard and Cosine on top of Neo4j.
Just thought i'd call it out.

 Remove all graph algorithms with the exception of PageRank
 --

 Key: MAHOUT-879
 URL: https://issues.apache.org/jira/browse/MAHOUT-879
 Project: Mahout
  Issue Type: Task
  Components: Graph
Affects Versions: 0.6
Reporter: Sebastian Schelter
Assignee: Sebastian Schelter
 Fix For: 0.6

 Attachments: graph-processing.tar.gz, MAHOUT-879.patch


 As discussed on the mailinglist we will remove the graph algorithms from 
 Mahout (except PageRank). It has become pretty clear that the Map/Reduce is 
 not suitable for most classic graph algorithms.
 I will attach a file containing the code of all algorithms that will be 
 removed so that they don't get lost.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (MAHOUT-1263) Serialise/Deserialise Lambda value for OnlineLogisticRegression

2013-06-14 Thread Mike Davy (JIRA)
Mike Davy created MAHOUT-1263:
-

 Summary: Serialise/Deserialise Lambda value for 
OnlineLogisticRegression 
 Key: MAHOUT-1263
 URL: https://issues.apache.org/jira/browse/MAHOUT-1263
 Project: Mahout
  Issue Type: Bug
  Components: Classification
Affects Versions: 0.7
Reporter: Mike Davy


The value for Lambda in OnlineLogisticRegression seems not the be 
serialised/deserialised correctly. 

If I train a model with a specific lambda value, serialise it, then read it 
back in, the value of Lambda goes back to the default value (1.0e-5). 

I've created a patch that adds the lambda value into the write/readFields 
(org.apache.hadoop.io.Writable). Patch includes a unit test that checks the 
values after serialising/deserialising to/from a ByteArray. 

I think this is correct, unless I'm missing something obvious?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (MAHOUT-1263) Serialise/Deserialise Lambda value for OnlineLogisticRegression

2013-06-14 Thread Mike Davy (JIRA)

 [ 
https://issues.apache.org/jira/browse/MAHOUT-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Davy updated MAHOUT-1263:
--

Attachment: MAHOUT-1263.patch

 Serialise/Deserialise Lambda value for OnlineLogisticRegression 
 

 Key: MAHOUT-1263
 URL: https://issues.apache.org/jira/browse/MAHOUT-1263
 Project: Mahout
  Issue Type: Bug
  Components: Classification
Affects Versions: 0.7
Reporter: Mike Davy
  Labels: patch
 Attachments: MAHOUT-1263.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The value for Lambda in OnlineLogisticRegression seems not the be 
 serialised/deserialised correctly. 
 If I train a model with a specific lambda value, serialise it, then read it 
 back in, the value of Lambda goes back to the default value (1.0e-5). 
 I've created a patch that adds the lambda value into the write/readFields 
 (org.apache.hadoop.io.Writable). Patch includes a unit test that checks the 
 values after serialising/deserialising to/from a ByteArray. 
 I think this is correct, unless I'm missing something obvious?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (MAHOUT-1263) Serialise/Deserialise Lambda value for OnlineLogisticRegression

2013-06-14 Thread Mike Davy (JIRA)

 [ 
https://issues.apache.org/jira/browse/MAHOUT-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Davy updated MAHOUT-1263:
--

Status: Patch Available  (was: Open)

 Serialise/Deserialise Lambda value for OnlineLogisticRegression 
 

 Key: MAHOUT-1263
 URL: https://issues.apache.org/jira/browse/MAHOUT-1263
 Project: Mahout
  Issue Type: Bug
  Components: Classification
Affects Versions: 0.7
Reporter: Mike Davy
  Labels: patch
 Attachments: MAHOUT-1263.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The value for Lambda in OnlineLogisticRegression seems not the be 
 serialised/deserialised correctly. 
 If I train a model with a specific lambda value, serialise it, then read it 
 back in, the value of Lambda goes back to the default value (1.0e-5). 
 I've created a patch that adds the lambda value into the write/readFields 
 (org.apache.hadoop.io.Writable). Patch includes a unit test that checks the 
 values after serialising/deserialising to/from a ByteArray. 
 I think this is correct, unless I'm missing something obvious?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (MAHOUT-1263) Serialise/Deserialise Lambda value for OnlineLogisticRegression

2013-06-14 Thread Mike Davy (JIRA)

 [ 
https://issues.apache.org/jira/browse/MAHOUT-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Davy updated MAHOUT-1263:
--

Description: 
The value for Lambda in OnlineLogisticRegression seems not the be 
serialised/deserialised correctly. 

If I train a model with a specific lambda value, serialise it, then read it 
back in, the value of Lambda goes back to the default value (1.0e-5). 

I've created a patch that adds the lambda value into the write/readFields 
(org.apache.hadoop.io.Writable). Patch includes a unit test that checks the 
values after serialising/deserialising to/from a ByteArray. 

I think this is correct, unless I'm missing something obvious?

Note: this patch is not backwards compatible - can easily adapt to be more 
backwards compatible if required. 

  was:
The value for Lambda in OnlineLogisticRegression seems not the be 
serialised/deserialised correctly. 

If I train a model with a specific lambda value, serialise it, then read it 
back in, the value of Lambda goes back to the default value (1.0e-5). 

I've created a patch that adds the lambda value into the write/readFields 
(org.apache.hadoop.io.Writable). Patch includes a unit test that checks the 
values after serialising/deserialising to/from a ByteArray. 

I think this is correct, unless I'm missing something obvious?


 Serialise/Deserialise Lambda value for OnlineLogisticRegression 
 

 Key: MAHOUT-1263
 URL: https://issues.apache.org/jira/browse/MAHOUT-1263
 Project: Mahout
  Issue Type: Bug
  Components: Classification
Affects Versions: 0.7
Reporter: Mike Davy
  Labels: patch
 Attachments: MAHOUT-1263.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The value for Lambda in OnlineLogisticRegression seems not the be 
 serialised/deserialised correctly. 
 If I train a model with a specific lambda value, serialise it, then read it 
 back in, the value of Lambda goes back to the default value (1.0e-5). 
 I've created a patch that adds the lambda value into the write/readFields 
 (org.apache.hadoop.io.Writable). Patch includes a unit test that checks the 
 values after serialising/deserialising to/from a ByteArray. 
 I think this is correct, unless I'm missing something obvious?
 Note: this patch is not backwards compatible - can easily adapt to be more 
 backwards compatible if required. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Assigned] (MAHOUT-1263) Serialise/Deserialise Lambda value for OnlineLogisticRegression

2013-06-14 Thread Suneel Marthi (JIRA)

 [ 
https://issues.apache.org/jira/browse/MAHOUT-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suneel Marthi reassigned MAHOUT-1263:
-

Assignee: Suneel Marthi

 Serialise/Deserialise Lambda value for OnlineLogisticRegression 
 

 Key: MAHOUT-1263
 URL: https://issues.apache.org/jira/browse/MAHOUT-1263
 Project: Mahout
  Issue Type: Bug
  Components: Classification
Affects Versions: 0.7
Reporter: Mike Davy
Assignee: Suneel Marthi
  Labels: patch
 Attachments: MAHOUT-1263.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The value for Lambda in OnlineLogisticRegression seems not the be 
 serialised/deserialised correctly. 
 If I train a model with a specific lambda value, serialise it, then read it 
 back in, the value of Lambda goes back to the default value (1.0e-5). 
 I've created a patch that adds the lambda value into the write/readFields 
 (org.apache.hadoop.io.Writable). Patch includes a unit test that checks the 
 values after serialising/deserialising to/from a ByteArray. 
 I think this is correct, unless I'm missing something obvious?
 Note: this patch is not backwards compatible - can easily adapt to be more 
 backwards compatible if required. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (MAHOUT-1263) Serialise/Deserialise Lambda value for OnlineLogisticRegression

2013-06-14 Thread Suneel Marthi (JIRA)

 [ 
https://issues.apache.org/jira/browse/MAHOUT-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suneel Marthi updated MAHOUT-1263:
--

   Resolution: Fixed
Fix Version/s: 0.8
   Status: Resolved  (was: Patch Available)

Patch committed to trunk.

 Serialise/Deserialise Lambda value for OnlineLogisticRegression 
 

 Key: MAHOUT-1263
 URL: https://issues.apache.org/jira/browse/MAHOUT-1263
 Project: Mahout
  Issue Type: Bug
  Components: Classification
Affects Versions: 0.7
Reporter: Mike Davy
Assignee: Suneel Marthi
  Labels: patch
 Fix For: 0.8

 Attachments: MAHOUT-1263.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The value for Lambda in OnlineLogisticRegression seems not the be 
 serialised/deserialised correctly. 
 If I train a model with a specific lambda value, serialise it, then read it 
 back in, the value of Lambda goes back to the default value (1.0e-5). 
 I've created a patch that adds the lambda value into the write/readFields 
 (org.apache.hadoop.io.Writable). Patch includes a unit test that checks the 
 values after serialising/deserialising to/from a ByteArray. 
 I think this is correct, unless I'm missing something obvious?
 Note: this patch is not backwards compatible - can easily adapt to be more 
 backwards compatible if required. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (MAHOUT-1263) Serialise/Deserialise Lambda value for OnlineLogisticRegression

2013-06-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/MAHOUT-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684085#comment-13684085
 ] 

Hudson commented on MAHOUT-1263:


Integrated in Mahout-Quality #2083 (See 
[https://builds.apache.org/job/Mahout-Quality/2083/])
MAHOUT-1263:Serialise/Deserialise Lambda value for OnlineLogisticRegression 
(Revision 1493313)

 Result = SUCCESS
smarthi : 
Files : 
* /mahout/trunk/CHANGELOG
* 
/mahout/trunk/core/src/main/java/org/apache/mahout/classifier/sgd/OnlineLogisticRegression.java
* 
/mahout/trunk/core/src/test/java/org/apache/mahout/classifier/sgd/OnlineLogisticRegressionTest.java


 Serialise/Deserialise Lambda value for OnlineLogisticRegression 
 

 Key: MAHOUT-1263
 URL: https://issues.apache.org/jira/browse/MAHOUT-1263
 Project: Mahout
  Issue Type: Bug
  Components: Classification
Affects Versions: 0.7
Reporter: Mike Davy
Assignee: Suneel Marthi
  Labels: patch
 Fix For: 0.8

 Attachments: MAHOUT-1263.patch

   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 The value for Lambda in OnlineLogisticRegression seems not the be 
 serialised/deserialised correctly. 
 If I train a model with a specific lambda value, serialise it, then read it 
 back in, the value of Lambda goes back to the default value (1.0e-5). 
 I've created a patch that adds the lambda value into the write/readFields 
 (org.apache.hadoop.io.Writable). Patch includes a unit test that checks the 
 values after serialising/deserialising to/from a ByteArray. 
 I think this is correct, unless I'm missing something obvious?
 Note: this patch is not backwards compatible - can easily adapt to be more 
 backwards compatible if required. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira