[GitHub] [mahout] andrewpalumbo merged pull request #391: MAHOUT-2086: use consistent SBT resolvable jar naming scheme with the correct convention

2020-01-23 Thread GitBox
andrewpalumbo merged pull request #391: MAHOUT-2086: use consistent SBT resolvable jar naming scheme with the correct convention URL: https://github.com/apache/mahout/pull/391 This is an automated message from the Apache

[GitHub] [mahout] andrewpalumbo opened a new pull request #391: MAHOUT-2086: use consistent SBT resolvable jar naming scheme with the correct convention

2020-01-23 Thread GitBox
andrewpalumbo opened a new pull request #391: MAHOUT-2086: use consistent SBT resolvable jar naming scheme with the correct convention URL: https://github.com/apache/mahout/pull/391 ### Purpose of PR: Please give a short description of what this PR is for. Fix naming of release

[jira] [Created] (MAHOUT-2086) change jar naming scheme to the corredct convention

2020-01-23 Thread Andrew Palumbo (Jira)
Andrew Palumbo created MAHOUT-2086: -- Summary: change jar naming scheme to the corredct convention Key: MAHOUT-2086 URL: https://issues.apache.org/jira/browse/MAHOUT-2086 Project: Mahout

Re: [DISCUSS] Naming convention for multiple spark/scala combos

2017-07-09 Thread Trevor Grant
ich seems to be our use case (sort of). I entirely concede that I may be wrong here. [1] https://maven.apache.org/pom.html On Sat, Jul 8, 2017 at 4:30 PM, Andrew Palumbo <ap@outlook.com> wrote: > +1 if so (sbt naming re: pats comment). > > Also +1 on Zeppelin integration b

RE: [DISCUSS] Naming convention for multiple spark/scala combos

2017-07-08 Thread Andrew Palumbo
+1 if so (sbt naming re: pats comment). Also +1 on Zeppelin integration being non-trivial. Sent from my Verizon Wireless 4G LTE smartphone Original message From: Pat Ferrel <p...@occamsmachete.com> Date: 07/07/2017 10:35 PM (GMT-08:00) To: dev@mahout.apache.org Cc:

Re: [DISCUSS] Naming convention for multiple spark/scala combos

2017-07-07 Thread Pat Ferrel
rk2 is probably the right way (or > _spark_1 / _spark_2 is fine too). > > > On Fri, Jul 7, 2017 at 11:43 AM, Trevor Grant <trevor.d.gr...@gmail.com> > wrote: > >> >> -- Forwarded message -- >> From: Andrew Palumbo <ap@outlook.

Re: [DISCUSS] Naming convention for multiple spark/scala combos

2017-07-07 Thread Holden Karau
: 07/07/2017 1:24 PM (GMT-08:00) > To: dev@mahout.apache.org > Cc: Trevor Grant <trevor.d.gr...@gmail.com> > Subject: Re: [DISCUSS] Naming convention for multiple spark/scala combos > > Trevor looped me in on this since I hadn't had a chance to subscribe to the > list yet (on no

RE: [DISCUSS] Naming convention for multiple spark/scala combos

2017-07-07 Thread Andrew Palumbo
Welcome! Sent from my Verizon Wireless 4G LTE smartphone Original message From: Holden Karau <holden.ka...@gmail.com> Date: 07/07/2017 1:24 PM (GMT-08:00) To: dev@mahout.apache.org Cc: Trevor Grant <trevor.d.gr...@gmail.com> Subject: Re: [DISCUSS] Namin

Re: [DISCUSS] Naming convention for multiple spark/scala combos

2017-07-07 Thread Trevor Grant
ant <trevor.d.gr...@gmail.com> > wrote: > >> >> -- Forwarded message -- >> From: Andrew Palumbo <ap@outlook.com> >> Date: Fri, Jul 7, 2017 at 12:28 PM >> Subject: Re: [DISCUSS] Naming convention for multiple spark/scala combos >

Re: [DISCUSS] Naming convention for multiple spark/scala combos

2017-07-07 Thread Holden Karau
way (or _spark_1 / _spark_2 is fine too). On Fri, Jul 7, 2017 at 11:43 AM, Trevor Grant <trevor.d.gr...@gmail.com> wrote: > > -- Forwarded message -- > From: Andrew Palumbo <ap@outlook.com> > Date: Fri, Jul 7, 2017 at 12:28 PM > Subject:

Re: [DISCUSS] Naming convention for multiple spark/scala combos

2017-07-07 Thread Dmitriy Lyubimov
it would seem 2nd option is preferable if doable. Any option that has most desirable combinations prebuilt, is preferable i guess. Spark itself also releases tons of hadoop profile binary variations. so i don't have to build one myself. On Fri, Jul 7, 2017 at 8:57 AM, Trevor Grant

Re: naming

2015-03-24 Thread Dmitriy Lyubimov
Data structures supporting math are math. (i.e. openHashMap) On Tue, Mar 24, 2015 at 9:52 AM, Andrew Palumbo ap@outlook.com wrote: On 03/24/2015 11:24 AM, Pat Ferrel wrote: Lots of non-math in math-scala, Reader/Writer traits, options, option parsing, driver base classes,

Re: naming

2015-03-24 Thread Andrew Palumbo
On 03/24/2015 11:24 AM, Pat Ferrel wrote: Lots of non-math in math-scala, Reader/Writer traits, options, option parsing, driver base classes, IndexedDataset (mini-Dataframes), and there will always be more because there is no other engine-neutral module. So far the rules as I understand them

Re: naming

2015-03-23 Thread Dmitriy Lyubimov
I like math-*. And it is math only there. Or was last time i checked. it will be what R calls R-base, and I would welcome no other scope there. all environment things are math. all ML things are math. quasi-newton, bayesian optimizers, linear search are all math. Stats are math. als, (d)ssvd,

persistence function naming convnentions

2014-09-28 Thread Pat Ferrel
user visible intermediate files. Also simple CSV is the only currently supported format for IndexedDataset, there will be others as needs present themselves. Therefore following your train of thought and to fit the changes you suggest for DRM naming I’d change the IndexedDataset names to: Package

Re: persistence function naming convnentions

2014-09-28 Thread Dmitriy Lyubimov
of thought and to fit the changes you suggest for DRM naming I’d change the IndexedDataset names to: Package level indexedDatasetDfsRead(src: String, schema: Schema = DefaultSchema): IndexedDataset Method level indexedDataset.dfsWrite(dest: String, schema: Schema = DefaultSchema) Once read