Re: [RNG] Pending issues

[Artem Barger]

​Hi,

Can you please take a look on PRs which suppose to handle both issues?
​

On Fri, Jun 23, 2017 at 1:35 AM, Gilles 
wrote:

> Github and Maven experts, please have a look at the
> following issues:
>   https://issues.apache.org/jira/browse/RNG-38
>

​PR #1: ​
https://github.com/apache/commons-rng/pull/3


>
>   https://issues.apache.org/jira/browse/RNG-31
>

​PR #
​2​
: https://github.com/apache/commons-rng/pull/4


>
> Regards,
> Gilles
>



Best regards,
  Artem Barger.

Re: [VOTE][RC6] Release Commons RNG 1.0 (reminder)

[Artem Barger]

I am voting +1

Отправлено с iPhone

> 11 дек. 2016 г., в 8:11, Gilles  написал(а):
> 
>> On Wed, 07 Dec 2016 00:22:30 +0100, Gilles wrote:
>> Hi.
>> 
>> This is a [VOTE] for releasing Apache Commons RNG 1.0 (from RC6).
>> 
>> 
>> Tag name:
>>  RNG_1_0_RC6 (signature can be checked from git using 'git tag -v')
>> 
>> Tag URL:
>> 
>> https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=commit;h=4581a4520315657a4219b37c81f5db80e4a4e43c
>> 
>> Commit ID the tag points at:
>>  4581a4520315657a4219b37c81f5db80e4a4e43c
>> 
>> Site:
>>  http://home.apache.org/~erans/commons-rng-1.0-RC6-site
>> 
>> Distribution files (committed at revision 17284):
>>  https://dist.apache.org/repos/dist/dev/commons/rng/
>> 
>> Distribution files hashes (SHA1):
>>  c5e70a523160ed848194eeba0efa2b14d23c7a61 commons-rng-1.0-bin.tar.gz.sha1
>>  66d7701afc90aafa4c4b6e033b8df6cd84365161 commons-rng-1.0-bin.zip.sha1
>>  ef56543c8882a0e4771de83ecf8b3be190f122cf commons-rng-1.0-src.tar.gz.sha1
>>  3dc56b0793d8bbd703a4efa68547eb58f6fb5b35 commons-rng-1.0-src.zip.sha1
>> 
>> KEYS file to check signatures:
>>  http://www.apache.org/dist/commons/KEYS
>> 
>> Maven artifacts:
>>  https://repository.apache.org/content/repositories/orgapachecommons-1229/
>> 
>> Please select one of the following options[1]:
>> [ ] +1 Release it.
>> [ ] +0 Go ahead; I don't care.
>> [ ] -0 There are a few minor glitches: ...
>> [ ] -1 No, do not release it because ...
>> 
>> This vote will be open at least 72 hours, i.e. until 2016-12-10T00:00:00Z
>> (this is UTC time).
>> --
> 
> Ping?
> 
> Unless I'm mistaken, after 100 hours have elapsed, there are only
> 2 votes for RC6.
> The only change wrt RC5 is that the (single) problem, reported by
> Oliver, has been fixed.
> 
> Please share your opinion about releasing[1] this new component,
> especially since RC6 has gone a long way to satisfy requests[2]
> that were not part of my initial plan.[3]
> 
> 
> Thanks,
> Gilles
> 
> [1] RC1, 2 and 5 each had more than the three required votes...
>[For RC3 and 4, I stopped the RM process before getting to
>the vote.]
> [2] Cf. long discussion(s) threads about modularization, utilities
>(sampling and shuffling), versioning.
> [3] In a RERO view, the stated scope should have been sufficient
>to release the actual code at least 3 months ago (even much
>earlier, given that the development occurred under public
>scrutiny for more than a year now).
> 
>> 
>> Regards,
>> Gilles
>> 
>> [1] http://apache.org/foundation/voting.html
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE][RC5] Release "Apache Commons RNG" version 1.0

[Artem Barger]

My vote: +1

Best regards,
  Artem Barger.

On Thu, Dec 1, 2016 at 2:01 PM, Stian Soiland-Reyes 
wrote:

> My vote: +1 (binding)
>
> Looking good!
>
>
> Checked:
>
> +1 commit matches tag (even signed tag, yay!)
> +0 commit matches src (git tag is missing
> "true" -- why?)
> +0 src matches staging repo -sources (hard to check as *-src.tar.gz
> was not staged :-( )
> +1 bin JARs matches staging repo hashes
> +1 zip vs tar.gz
> +1 .asc signatures of dist and repo
> +1 md5/sha1 hashes (email's hash filenames says .sha1, but match
> correctly the zip/tar.gz)
> +0 mvn apache-rat:check (exceptions are already excluded for )
> +1 no unexpected binaries
> +1 mvn clean install
>   +1 .. and afterwards in commons-rng-examples
> +0 binary vs source (binary adds commons-rng-examples-1.0.jar, built
> separately in source)
> +1 RELEASE-NOTES
> +1 LICENSE, NOTICE
> +1 site (minor markdown highlight bug "64 bits" at
> http://home.apache.org/~erans/commons-rng-1.0-RC5-site/userguide/rng.html)
> +1 javadoc
>
> On 30 November 2016 at 00:08, Gilles  wrote:
> > Hi.
> >
> > This is a [VOTE] for releasing Apache Commons RNG 1.0 (from RC5).
> >
> > Main changes wrt the preceding vote (RC2, on September 16) are:
> >   * Modularization
> >   * Non-uniform deviates (in module "commons-rng-sampling")
> >
> >
> > Tag name:
> >   RNG_1_0_RC5 (signature can be checked from git using 'git tag -v')
> >
> > Tag URL:
> >
> > https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=commit;h=
> f9de6401e981554c3f44936c2272429e290fdbec
> >
> > Commit ID the tag points at:
> >   f9de6401e981554c3f44936c2272429e290fdbec
> >
> > Site:
> >   http://home.apache.org/~erans/commons-rng-1.0-RC5-site
> >
> > Distribution files:
> >   https://dist.apache.org/repos/dist/dev/commons/rng/
> >
> > Distribution files hashes (SHA1):
> >   de2a54518a0ef10ba5a2be1c3b060a441f4466e2  commons-rng-1.0-bin.tar.gz.
> sha1
> >   cfcfde1f65dec9c30be1273ff2237d551eb87933  commons-rng-1.0-bin.zip.sha1
> >   6d529de9418314066727a7d5ada88dd87dc0163d  commons-rng-1.0-src.tar.gz.
> sha1
> >   561dd3e5ebf53d60e883d5c04e543f58374c45b6  commons-rng-1.0-src.zip.sha1
> >
> > KEYS file to check signatures:
> >   http://www.apache.org/dist/commons/KEYS
> >
> > Maven artifacts:
> >   https://repository.apache.org/content/repositories/
> orgapachecommons-1225/
> >
> >
> > [ ] +1 Release it.
> > [ ] +0 Go ahead; I don't care.
> > [ ] -0 There are a few minor glitches: ...
> > [ ] -1 No, do not release it because ...
> >
> > This vote will close in 72 hours, at 2016-12-03T00:00:00Z (this is UTC
> > time).
> > --
> >
> >
> > Thanks,
> > Gilles
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [RNG] More grunt work... (Was: [ALL] Maven plugins common configuration)

[Artem Barger]

On Wed, Nov 2, 2016 at 1:25 AM, Gilles  wrote:

> Hello.
>
> Could you please have a look at the changes in "multimodule"
> branch?
>

​Sure.​


> I created an issue:
>   https://issues.apache.org/jira/browse/RNG-23
>
> You are most welcome to create the corresponding sub-tasks, and
> tackle some of them.  Top-priority is IMO:
>  * the web site duplication issue,
>  * how to now run the JMH benchmarks,
>  * how to run the examples
>
>
​Ok, I will start with 3 of these, while some of the items from the list is
pretty straight forward :)​



Best regards,
  Artem Barger.

Re: [ALL] Maven plugins common configuration.

[Artem Barger]

​Hi Gilles,​

On Wed, Oct 26, 2016 at 7:42 PM, Gilles 
wrote:

>
> $ mvn clean install site site:stage
>
> succeeds. :-)
>
> But the modules link are still dead.
> [E.g. there is no "apidocs".]


​Did you have chance to work that javadoc aggregation serves your need and
now
links are not broken anymore?
​


Best regards,
      Artem Barger.

Re: [ALL] Maven plugins common configuration.

[Artem Barger]

On Wed, Oct 26, 2016 at 7:42 PM, Gilles 
wrote:

>
> But the modules link are still dead.
> [E.g. there is no "apidocs".]


​Added aggregation of javadocs for parent project.​

Best regards,
          Artem Barger.

Re: [ALL] Maven plugins common configuration.

[Artem Barger]

On Wed, Oct 26, 2016 at 7:14 PM, Gilles 
wrote:

> ​Try "mvn install site"
>>>
>>
> That works but does not build the complete site, for which I'd
> invoke
>
> $ mvn site:stage


​Can you try now? I've pushed some changes.​


Best regards,
  Artem Barger.

Re: [ALL] Maven plugins common configuration.

[Artem Barger]

On Wed, Oct 26, 2016 at 7:14 PM, Gilles 
wrote:

> could not find "commons-rng-build-tools" (posted a question in maven ML
>>> list).
>>>
>>
>> The reactor of Maven does not consider plugins itself or dependencies to
>> plugins for its build order (by design). To support something like this,
>> you
>> will have to produce a released artifact first.
>>
>
> As maven-ignoramus, I do not follow.
> Does it mean that Artem's proposal is not feasible (according to
> Commons policy)?


​If only we could have build-tools as stand-alone component, that might
solve
all the problems.​ :/


Best regards,
  Artem Barger.

Re: [ALL] Maven plugins common configuration.

[Artem Barger]

On Wed, Oct 26, 2016 at 6:30 PM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

>
> The reactor of Maven does not consider plugins itself or dependencies to
> plugins for its build order (by design). To support something like this,
> you
> will have to produce a released artifact first.


​In that case I guess following tutorial has a bug:
https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
​


Best regards,
      Artem Barger.

Re: [ALL] Maven plugins common configuration.

[Artem Barger]

​Hi,
​


On Wed, Oct 26, 2016 at 5:53 PM, Gilles 
wrote:

> What is the command to "build everything"?
>
>

> I tried
>  $ mvn site
>

​Try "mvn install site"
​ instead.  For some reason dependencies between is not sorted out and
maven
could not find "commons-rng-build-tools" (posted a question in maven ML
list).

​


> Apart from that, the setup looks nice although I have no idea if
> it can fit the "Commons" way of handling each of its sub-project.
>
>
​Well, IMO this is fits into "Commons" pretty good, since it
provide common basic set of configs for maven plugins which
used by almost every common component.​



> Please let me know whether this can be sorted out so that a
> release of "Commons RNG" will not be invalidated because of an
> "unusual" project build layout or other incompatibility with the
> release policy.
>
>
​Working on it.



> When this is settled, we must review the
>   doc/release/release.howto.txt
> document and update according to the new layout.
>

​Sure thing.​



Best regards,
  Artem Barger.

Re: [ALL] Maven plugins common configuration.

[Artem Barger]

On Wed, Oct 26, 2016 at 10:36 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Because you must have a mechanism to trigger the e.g. the PMD plugin
> individually, if you put the declarationsof it into the commons parent
> (pluginManagement as well as report).
>
>
​Ok, I see, I didn't mean to put these into commons parent though.​



> > I just wanted to put all these configurations for build plugins which
> > executed during
> > "mvn site" into some common place and reuse them later.
>
> So you've put all those configuration *files* into this new artifact? Can
> those plugins access their configuration files when provided as resource?
>

​Yes, and yes, you can see how it works in "commons-rng", there is
a branch "multimodule" I have added my POC there.​



Best regards,
  Artem Barger.

Re: [ALL] Maven plugins common configuration.

[Artem Barger]

On Wed, Oct 26, 2016 at 10:08 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> You may put both parts into an own profile that is activated automatically
> at the extistence of pmd/pmd-ruleset.xml. Each component has then a chance
> to use it or not simply by providing that file.
>

​Not sure I follow you in the given context. I mean why one would create a
profile for
pmd plugin activated on presence of​ rule set xml?

I just wanted to put all these configurations for build plugins which
executed during
"mvn site" into some common place and reuse them later.


Best regards,
  Artem Barger.

Re: [ALL] Maven plugins common configuration.

[Artem Barger]

On Wed, Oct 26, 2016 at 3:20 AM, sebb  wrote:

> Why not include it in commons parent?
>

Because than it will introduce cyclic dependencies I guess. You will
declare "commons-parent"
is parent module and later add it as dependency for maven plugin config.​


Best regards,
      Artem Barger.

[ALL] Maven plugins common configuration.

[Artem Barger]

Hi,

While working on creating multi module configuration for commons-rng
component I've extracted all configurations for maven plugins such as: pmd,
findbugs, checkstyle into separate module "commons-rng-build-tools". Such
that parent project can now refer to it within build plugins section and
will imply it for all modules reducing the need to repeat it for each
module again (or copy same files into new modules).

Now I think that it could be beneficial to have this "build-tools" common
component across all Apache Commons, so it will provide same configurations
for checkstyle, pmd and etc at once.

For example configuration of pmd could look something like:




  maven-pmd-plugin
  ${pmd.version}
  
${maven.compiler.target}
false

  pmd/pmd-ruleset.xml

  
  

  org.apache.commons
  commons-build-tools
  1.0-SNAPSHOT

  




And reporting section:




  maven-pmd-plugin
  ${pmd.version}
  
${maven.compiler.target}
false

  pmd/pmd-ruleset.xml

  
  

  
pmd
cpd
  

  




At some sense this will be similar to "commons-parent", while keeping only
configuration resources for report generating plugins and for static
analysis tools.

WDYT?

PS. There is temporal example within "commons-rng" git repo inside
"multimodule" branch.

Best regards,
  Artem Barger.

Re: [01/51] [partial] commons-rng git commit: Multimodule support

[Artem Barger]

On Sat, Oct 22, 2016 at 5:24 PM, Gilles 
wrote:

> I don't think that's what caused all those files to be tracked:
>

Removing​ "/" from "/site-content" will make git to ignore this folder
within modules folders as well.



> ---CUT---
> $ git check-ignore site-content
> site-content
> ---CUT---
> [Meaning that "/site-content" in ".gitignore" effectively ignores
> that directory.]
>
> $ git ls-tree -r master --name-only
> ... output skipped ...
> [Shows that the files were not tracked on "master".]
>
> I think that it would be better to delete that branch and create
> a clean one (to avoid having those spurious files in the history).
>

​Done.​


Best regards,
  Artem Barger.

Re: [01/51] [partial] commons-rng git commit: Multimodule support

[Artem Barger]

​Hi,​

On Fri, Oct 21, 2016 at 2:10 PM, Gilles 
wrote:

> Hi.
>
> On Thu, 20 Oct 2016 23:29:08 -, bar...@apache.org wrote:
>
>> Repository: commons-rng
>> Updated Branches:
>>   refs/heads/multimodule [created] d1b3113ae
>>
>>
>>
>> http://git-wip-us.apache.org/repos/asf/commons-rng/blob/d1b3
>> 113a/commons-rng-core/site-content/.svn/pristine/61/61020
>> 2008fbfaca197f91798f2c9be651dd041b2.svn-base
>>
>> --
>> diff --git
>>
>> a/commons-rng-core/site-content/.svn/pristine/61/610202008fb
>> faca197f91798f2c9be651dd041b2.svn-base
>>
>> b/commons-rng-core/site-content/.svn/pristine/61/610202008fb
>> faca197f91798f2c9be651dd041b2.svn-base
>> new file mode 100644
>> index 000..0ba6567
>> Binary files /dev/null and
>>
>> b/commons-rng-core/site-content/.svn/pristine/61/610202008fb
>> faca197f91798f2c9be651dd041b2.svn-base
>> differ
>>
>
> Shouldn't the "site-content" directory have been "ignore"d (by git)?
>

​Yes it should, but I think "back slash" in .gitignore prevents that. ​


Best regards,
  Artem Barger.

Re: [RNG] Evaluating work required for a multi-module project

[Artem Barger]

On Fri, Oct 21, 2016 at 6:25 PM, Ralph Goers 
wrote:

> Please read the documentation on the maven site plugin -
> https://maven.apache.org/plugins/maven-site-plugin/
> examples/multimodule.html <https://maven.apache.org/
> plugins/maven-site-plugin/examples/multimodule.html>. “mvn site” builds
> the sites for all the individual modules but it does not put them together.
> That happens when you do site:stage-deploy or site:deploy.
>

​Yeah, as I thought just "mvn site" for multimodule is not enough. ​


Best regards,
  Artem Barger.

Re: [RNG] Evaluating work required for a multi-module project

[Artem Barger]

On Fri, Oct 21, 2016 at 2:07 PM, Gilles 
wrote:

> As I feared:
>  $ mvn clean site
> does not produce everything...
>
> ​I think that in case of multi model project simple "mvn site" won't be
enough,
​not sure but I think that "mvn site:deploy" should do the work in that
case.



> Is there an alternative command for a multi-module project?
>
> The
>  * userguide [1]
>  * apidocs
>  * jacoco
>  * clirr
>  * rat
> and others, are missing (or partial).
>
> The "About" page provides a link to "Apache Commons RNG Core", but it
> is dead ("File not found").
>
> The "Dependencies" page refers to packages that shouldn't be there
> ("jopt-simple", "commons-math3").
>

Well as I said I'm still have a few things to add, also I'd like to take
all build related
plugins config files (pmd, findbug, checkstyle and etc) into separate
module.​




Best regards,
  Artem Barger.

Re: [RNG] Evaluating work required for a multi-module project (Was: [ALL] Component with multiple modules?)

[Artem Barger]

​Hi Gilles,​

On Thu, Oct 20, 2016 at 4:47 PM, Gilles 
wrote:

> Hi Artem.
>
> Would you be willing to create a branch containing actual
> files?
>
> If so, since the break-down into modules I'm thinking of is
> not the one you've taken below,[1] I suggest that you create
> an "all-example" module, into which you'd move _all_ the code.
>
> I'd think that you should start from
>   https://svn.apache.org/repos/asf/commons/proper/weaver/trunk/pom.xml
> as suggested by Matt.
>
> Then, I expect that
>  $ mvn clean site
> will run smoothly, and produce everything which the current
> config does.[2]
>
> Please let me know if you don't have the time to do it, or if
> you run into any problem that would prevent this goal to be
> achieved quickly.[3]
>


​I've create a new branch where restructured project folders to add support
for multi modules. I still need to work on some configurations. Would be
glad if you can take a look and provide comments.



Best regards,
  Artem Barger.

Re: [RNG] Evaluating work required for a multi-module project (Was: [ALL] Component with multiple modules?)

[Artem Barger]

On Thu, Oct 20, 2016 at 4:47 PM, Gilles 
wrote:

> Hi Artem.
>
> Would you be willing to create a branch containing actual
> files?
>

​Yes, will do it today.​


>
> If so, since the break-down into modules I'm thinking of is
> not the one you've taken below,[1] I suggest that you create
> an "all-example" module, into which you'd move _all_ the code.
>
> I'd think that you should start from
>   https://svn.apache.org/repos/asf/commons/proper/weaver/trunk/pom.xml
> as suggested by Matt.
>

​Going to take a look into it.​


>
> Then, I expect that
>  $ mvn clean site
> will run smoothly, and produce everything which the current
> config does.[2]
>
> Please let me know if you don't have the time to do it, or if
> you run into any problem that would prevent this goal to be
> achieved quickly.[3]
>
>
I should be able to do it soon.
​


>
> Thanks,
> Gilles
>
> [1] I'm still convinced that the "utils" (referred to in the
> other thread) should be a separate component.  But we could
> nevertheless create modules in "Commons RNG" that would
> clearly stress the separation between the low-level RNG
> algorithms, the high-level interfaces and the "simple API".
> Then later on, the "utils" component could choose to only
> depend on the "core" algorithms and provide its own API.
> [2] In that case, I'll give a try at splitting the codebase.
> [3] In that case, I'll start the release process tomorrow, with
> what we have now.
>



Best regards,
  Artem Barger.

Re: [ALL] Component with multiple modules?

[Artem Barger]

On Thu, Oct 20, 2016 at 2:55 PM, Gilles 
wrote:

>
> Can you point me at a component that has a config supporting
> multiple modules?


​I cannot point you to the multi module project within ASF commons, while
it's not that
hard to create one. First of all you can use "mvn archetype:generate" to
create base
skeleton to play with, for example:

1. mvn archetype:generate -DgroupId=org.apache.commons \
-DartifactId=commons-rng \

-DarchetypeArtifactId=org.codehaus.mojo.archetypes

2. Enter commons-rng folder and run:
mvn archetype:generate -DgroupId=org.apache.commons \
-DartifactId=commons-rng-core \

-DarchetypeArtifactId=maven-archetype-quickstart

mvn archetype:generate -DgroupId=org.apache.commons \
 -DartifactId=commons-rng-utility \

-DarchetypeArtifactId=maven-archetype-quickstart

This will create parent muti-module project "commons-rng" with two modules
"utility" and "core".

Here is the example of pom.xml for possible multi module RNG component,
assuming
you have one main module with all core logic which is "commons-rng-core"
and another
utility one "commong-rng-utility" both of these are wrapped into pom
packaged module
"commons-rng":


http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
  4.0.0

  
org.apache.commons
commons-parent
41
  

  org.apache.commons
  commons-rng
  1.0-SNAPSHOT
  pom

  rng
  http://maven.apache.org

  
UTF-8
  

  
commons-rng-core
commons-rng-utils
  

  2016
  The Apache Commons RNG project provides implementations of
random numbers generators.

  http://commons.apache.org/proper/commons-rng/

  
jira
http://issues.apache.org/jira/browse/RNG
  

  
scm:git:
http://git-wip-us.apache.org/repos/asf/commons-rng.git
scm:git:
https://git-wip-us.apache.org/repos/asf/commons-rng.git

https://git-wip-us.apache.org/repos/asf?p=commons-rng.git
  

  

  apache.website
  Apache Commons Site
  scm:svn:
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-rng/


  

  

  junit
  junit
  4.11
  test

  


​
​Hope this helps you.​


Best regards,
  Artem Barger.

[RNG] RNG-17 - LFG

[Artem Barger]

Hi,


I was considering​ to give a try and implement RNG-17
<https://issues.apache.org/jira/browse/RNG-17> (LFG),  while I'm complete a
newbie in RNG topic. So I've read a couple of tutorials and IMO I've got an
idea behind the LFG (which doesn't seem that complex).

I haven't found in the literature the explanation of how to seed the LFG
though,
e.g. I have to create first "m" slots using the seed. However I've read in
some article, that Mersenne Twister could be used to seed the LFG. And here
comes my first question for you, is that  correct? And second question I
was trying to understand how to reuse state initialization within current
Mersenne Twister for LFG?

Also I was thinking whenever it's could be beneficial to de-couple seeding
abstraction from actual number generation?

Best regards,
  Artem Barger.

Re: [RNG] modules vs projects

[Artem Barger]

On Thu, Sep 29, 2016 at 1:48 PM, Stian Soiland-Reyes 
wrote:

> A good question is - if rng-core changes - would the other modules
> need to change as well? If not, then there's not a big reason why they
> need to be together in the same project (but we would end up with
> Commons Commons Components..)
>

​I think other modules will be somehow dependent on rng-core, so change
in core will require additional release of the module.​


Best regards,
      Artem Barger.

Re: [RNG] modules vs projects

[Artem Barger]

​Hi,

​

On Thu, Sep 29, 2016 at 1:06 PM, Emmanuel Bourg  wrote:

>
> >> Multi-module projects are quite common and the case you mention isn't
> >> unusual.
> >
> > Please show an example.
>
> Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
> There is no lack of examples. Multi-module projects routinely publish
> new releases with some of their modules unmodified.


I think that I'd agree w/ Emmanuel here. It will be very strange where
on change in rng-core from v1 to v2 one will have to update rng-module1
from v1 to v2 (since I believe that rng-module1 will depend on rng-core),
while
version update of rng-module1 will not cause reciprocal effect.

IMO it's much easier when user will be able to use one version for all
rng-* modules,
rather than starting to struggle what version need to be taken for what
module.



  org.apache.commons
  rng-core
  ${rng.version}



  org.apache.commons
  rng-tools
  ${rng.version}


Looks better than


  org.apache.commons
  rng-core
  v1



  org.apache.commons
  rng-tools
  v99


And it's much easier to support.

Best regards,
  Artem Barger.

Re: [VOTE][RC2] Release "Apache Commons RNG" version 1.0

[Artem Barger]

+1

Отправлено с iPhone

> 17 сент. 2016 г., в 6:10, Dave Brosius  написал(а):
> 
> +1
> 
> 
>> On 09/16/2016 05:46 PM, Gilles wrote:
>> Hi.
>> 
>> This is a [VOTE] for releasing Apache Commons RNG 1.0 (from RC2).
>> 
>> Tag name:
>>  RNG_1_0_RC2 (signature can be checked from git using 'git tag -v')
>> 
>> Tag URL:
>> https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=commit;h=412ffb37932c45d7664eb83bd540f81d27a02b84
>> 
>> Commit ID the tag points at:
>>  412ffb37932c45d7664eb83bd540f81d27a02b84
>> 
>> Site:
>>  http://home.apache.org/~erans/commons-rng-1.0-RC2-site
>> 
>> Distribution files:
>>  https://dist.apache.org/repos/dist/dev/commons/rng/
>> 
>> Distribution files hashes (SHA1):
>>   eb947802b687835983803147cfc0e51be97ae521 commons-rng-1.0-bin.tar.gz.sha1
>>   200840fb29abd126ce9b046549cff04fda4f151a commons-rng-1.0-bin.zip.sha1
>>   b872f12f68de7d9f929299badf0d0ddcc835bbf3 commons-rng-1.0-src.tar.gz.sha1
>>   31e6d6a5973b37904e2646675bd0c9beaa6c301f commons-rng-1.0-src.zip.sha1
>> 
>> KEYS file to check signatures:
>>  http://www.apache.org/dist/commons/KEYS
>> 
>> Maven artifacts:
>> https://repository.apache.org/content/repositories/orgapachecommons-1201/org/apache/commons/commons-rng/1.0/
>> 
>> [ ] +1 Release it.
>> [ ] +0 Go ahead; I don't care.
>> [ ] -0 There are a few minor glitches: ...
>> [ ] -1 No, do not release it because ...
>> 
>> This vote will close in 72 hours, at 2016-09-20T00:00:00Z (this is UTC
>> time).
>> --
>> 
>> Thanks,
>> Gilles
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

Re: [rng] Cleanup of "topic" branches

[Artem Barger]

I've deleted these branches.

Best regards,
  Artem Barger.

On Sun, Sep 11, 2016 at 11:13 PM, Dave Brosius  wrote:

> i'm not sure what the value of dead branch labels hanging around is. They
> just clutter things up and confuse new people coming it as to what to use.
> I'm +1 for deleting them.
>
>
>
>
> On 09/11/2016 02:26 PM, Jochen Wiedmann wrote:
>
>> On Sun, Sep 11, 2016 at 5:32 PM, Gary Gregory 
>> wrote:
>>
>>> Once a branch has been merged into master, I think it is OK to remove it.
>>> Otherwise, IMO it's on a case by case basis: Does the author of the
>>> branch
>>> need it?
>>>
>> Whats the point? I'd rather see us create something like
>> branches/archived and move such branches below.
>>
>> Basically same effect, but provides accessibility.
>>
>> Jochen
>>
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [rng] Cleanup of "topic" branches

[Artem Barger]

Yes, these can branches can be removed, actually I can take care of it.

Отправлено с iPhone

> 11 сент. 2016 г., в 18:32, Gary Gregory  написал(а):
> 
> Once a branch has been merged into master, I think it is OK to remove it.
> Otherwise, IMO it's on a case by case basis: Does the author of the branch
> need it?
> 
> Gary
> 
> On Sun, Sep 11, 2016 at 4:23 AM, Gilles 
> wrote:
> 
>> Hi.
>> 
>> If they are not used anymore, can we remove the following
>> branches:
>>  RNG-7
>>  RNG-7a
>>  checkstyle
>> ?
>> 
>> Thanks,
>> Gilles
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE][RC1] Release Commons Rng 1.0

[Artem Barger]

+1 from me

Отправлено с iPhone

> 11 сент. 2016 г., в 17:55, Gilles  написал(а):
> 
> Hi.
> 
> This is a [VOTE] for releasing Apache Commons Rng 1.0 (from RC1).
> 
> Tag name:
>  RNG_1_0_RC1 (signature can be checked from git using 'git tag -v')
> 
> Tag URL:
>  
> https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=commit;h=f8d23082607b9f2c7be7f489eb09627722440ee5
> 
> Commit ID the tag points at:
>  f8d23082607b9f2c7be7f489eb09627722440ee5
> 
> Site:
>  http://home.apache.org/~erans/commons-rng-1.0-RC1-site
> 
> Distribution files:
>  https://dist.apache.org/repos/dist/dev/commons/rng/
> 
> Distribution files hashes (SHA1):
>  a221e862c8ff970a9ca3e7fbd86c3200d1f8780a commons-rng-1.0-bin.tar.gz
>  689b2bfbdb1856d4f47851d75762aab42057805a commons-rng-1.0-bin.zip
>  40b7b1639eedf91b5fad5d38e6ebec01e659048f commons-rng-1.0-src.tar.gz
>  6296dbabde10169d6365bda99f2af6dcc191e515 commons-rng-1.0-src.zip
> 
> KEYS file to check signatures:
>  http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
>  
> https://repository.apache.org/content/repositories/orgapachecommons-1199/org/apache/commons/commons-rng/1.0/
> 
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
> 
> This vote will close in 72 hours, at 2016-09-14T15:10:00Z (this is UTC
> time).
> --
> 
> Thanks,
> Gilles
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [rng] Usefulness of benchmarks

[Artem Barger]

On Sun, Sep 4, 2016 at 3:01 PM, Gilles  wrote:

> "RandomStressTester" is in Commons _Rng_ "src/userguide" example
> code, while I've just committed "RandomNumberGeneratorBenchmark"
> in Commons _Math_ userguide examples (branch "develop").
>
> There is a README in "src/userguide"; basically, you'd run with a
> command similar to:
>
>   $ mvn -q exec:java \
>
> -Dexec.mainClass=org.apache.commons.math4.userguide.rng.RandomNumberGeneratorBenchmark
> \
>-Dexec.args="MT ISAAC JDK"
>
> where the "exec.args" contains a list of "RandomSource" identifiers.
>
>
​I've ​got following results and they look similar to ones you have in the
table :/

Java 1.8.0_101
Runtime 1.8.0_101-b13
JVM Java HotSpot(TM) 64-Bit Server VM 25.101-b13
nextInt() (calls per timed block: 100, timed blocks: 500, time unit: ms)
   name time/call std dev total time ratio   cv
difference
 j.u.Random 1.390e-05 4.2e-06 6.9486e+03 1.000 0.30
0.e+00
o.a.c.r.i.s.MersenneTwister 1.129e-05 3.9e-06 5.6437e+03 0.812 0.34
-1.3049e+03
o.a.c.r.i.s.ISAACRandom 1.611e-05 3.7e-06 8.0537e+03 1.159 0.23
1.1052e+03
  o.a.c.r.i.s.JDKRandom 1.634e-05 3.4e-06 8.1704e+03 1.176 0.21
1.2218e+03
nextDouble() (calls per timed block: 100, timed blocks: 500, time unit:
ms)
   name time/call std dev total time ratio   cv
difference
 j.u.Random 2.608e-05 4.3e-06 1.3042e+04 1.000 0.17
0.e+00
o.a.c.r.i.s.MersenneTwister 2.099e-05 3.9e-06 1.0497e+04 0.805 0.19
-2.5450e+03
o.a.c.r.i.s.ISAACRandom 2.381e-05 3.8e-06 1.1905e+04 0.913 0.16
-1.1367e+03
  o.a.c.r.i.s.JDKRandom 2.922e-05 4.5e-06 1.4612e+04 1.120 0.15
1.5705e+03
nextLong() (calls per timed block: 100, timed blocks: 500, time unit:
ms)
   name time/call std dev total time ratio   cv
difference
 j.u.Random 2.436e-05 3.9e-06 1.2180e+04 1.000 0.16
0.e+00
o.a.c.r.i.s.MersenneTwister 1.890e-05 3.4e-06 9.4501e+03 0.776 0.18
-2.7297e+03
o.a.c.r.i.s.ISAACRandom 2.169e-05 4.1e-06 1.0845e+04 0.890 0.19
-1.3352e+03
  o.a.c.r.i.s.JDKRandom 2.743e-05 4.7e-06 1.3713e+04 1.126 0.17
1.5330e+03


Best regards,
  Artem Barger.

Re: [rng] Usefulness of benchmarks

[Artem Barger]

On Sun, Sep 4, 2016 at 2:06 PM, Gilles  wrote:

> A few quick runs seems to produce numbers that are now much
> closer to what JMH produces.[1]
>
> What do you think?
>

​How I can produce results with PerfTestUtils? Is there any script to run
RandomStressTester?
It possible that previous results were produced on loaded computer, hence
the bias.​


Best regards,
          Artem Barger.

Re: [rng] Usefulness of benchmarks

[Artem Barger]

On Sat, Sep 3, 2016 at 1:36 AM, Gilles  wrote:

> The discrepancy between "PerfTestUtils" and JMH could be a bug (in
> "PerfTestUtils" of course!) or ... measuring different use-cases:
> Use of several RNGs at the same time vs using a single one; the
> latter could allow for more aggressive optimizations.
>

​I'm not really familiar with the PerfTestUtils, while I know that JMH is
doing a great
job to avoid different pitfalls while building microbenchmarks for
measuring a performance.
Also it looks a bit suspicious where comparing JDK random generator against
itself it's not
showing ration of 1.0 for PerfTestUtils.


> Lacking input as to what the benchmarks purport to demonstrate, I'm
> about to simply delete the "PerfTestUtils" column.
> The result will be a simplified (maybe simplistic) view of the
> relative performance of the RNGs in the "single use" use-case.
>
>
​I can try to take a look on PerfTestUtils to understand what is the main
cause of such difference.​



> Any comment, objection, explanation, suggestion?
> [E.g. set up JMH to benchmark the other use case, or a reason why
> this is in fact not necessary.]
>

​We can play with different amount of warm up rounds in JMH to see whenever
there is a degradation
to results similar to PerfTestUtils for example.​



Best regards,
  Artem Barger.

Re: [rng] Travis ?

[Artem Barger]

> 22 авг. 2016 г., в 20:45, Rob Tompkins  написал(а):
> 
> Gotcha. I suppose then that I should just add "pmd:pmd findbugs:findbugs 
> checkstyle:checkstyle" in the Travis mvn command?

I guess so.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [rng] Travis ?

[Artem Barger]

> 22 авг. 2016 г., в 20:08, Rob Tompkins  написал(а):
> 
> Sure. That’s not a problem at all. Currently we have in the pom.xml, 
> checkstyle’s “failOnViolation" set to false. I can add the validate maven 
> target to the .travis.yml, but we might at least want minimally to switch 
> “logViolationsToConsole” to true.
> 
> Thoughts?

Setting "logViolationsToConsole" to true will make Jenkins to fail, since 
plugin outputs these violations with status exit different than zero.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [rng] New "checkstyle" config is checking "src/test"

[Artem Barger]

On Thu, Aug 18, 2016 at 3:48 PM, sebb  wrote:

> > will never take the configuration for the checkstyle report into account.
> > Maven behaviour calling goals directly ...
>
> For this reason some POMs include both report and build entries for
> tools such as RAT, Checkstyle, Findbugs.


​And this is exactly what I did :)​


Best regards,
      Artem Barger.

Re: [rng] New "checkstyle" config is checking "src/test"

[Artem Barger]

On Thu, Aug 18, 2016 at 2:20 AM, Gilles 
wrote:

> It's something related to the plain
>>>  checkstyle:checkstyle
>>> target.
>>>
>>
>>
>> ​Added a rule to skip these files, looks better now.​
>>
>
> But why was it working fine with "mvn site"?


​Still reading about this.​


Best regards,
  Artem Barger.

Re: [rng] New "checkstyle" config is checking "src/test"

[Artem Barger]

On Thu, Aug 18, 2016 at 1:45 AM, Gilles 
wrote:

>
> It's something related to the plain
>  checkstyle:checkstyle
> target.


​Added a rule to skip these files, looks better now.​


Best regards,
      Artem Barger.

Re: [rng] Checkstyle on Jenkins

[Artem Barger]

On Thu, Aug 18, 2016 at 1:36 AM, Gilles 
wrote:

>
>> /Users/bartem/sandbox/commons-rng/LICENSE.txt:1: error: Line does not
>> match
>> expected header line of '/*'.
>> /Users/bartem/sandbox/commons-rng/NOTICE.txt:1: error: Missing a header -
>> not enough lines in file.
>>
>
> This happens on Jenkins too... :-/


​Yeap, need to digg into it, doesn't suppose to happen.​


Best regards,
  Artem Barger.

Re: [rng] New "checkstyle" config is checking "src/test"

[Artem Barger]

On Thu, Aug 18, 2016 at 1:30 AM, Gilles 
wrote:

> They are not the "src/main/java" directory; why would they be scanned?
>
> Looks like a Mac problem...
> Perhaps ask in a new ML thread.
>

​Look at Jenkins, not sure why these files scanned, but on Jenkins there is
same report as on my​ laptop.


Best regards,
      Artem Barger.

Re: [rng] New "checkstyle" config is checking "src/test"

[Artem Barger]

On Thu, Aug 18, 2016 at 1:12 AM, Gilles 
wrote:

>
> I have zero here.
> What are the errors you get?


/Users/bartem/sandbox/commons-rng/LICENSE.txt:1: error: Line does not match
expected header line of '/*'.
/Users/bartem/sandbox/commons-rng/NOTICE.txt:1: error: Missing a header -
not enough lines in file.

Best regards,
          Artem Barger.

Re: [rng] New "checkstyle" config is checking "src/test"

[Artem Barger]

On Thu, Aug 18, 2016 at 12:51 AM, Artem Barger  wrote:

> he "test" part of the source code need not have the same level
>> of cleanliness as the "main" part.
>> It was not usually scanned by checkstyle, which now outputs
>> many spurious errors.
>>
>
> ​Well, test code is also a code one need to support, but I'm fine to relax
> it
> to the previous configuration, a matter of setting one property.
>
> I've addressed all your recent comments and pushed into separate branch
> "checkstyle". Will wait
> for your confirmation before merging it into master.
>

​After removing test folder from checkstyle scan getting following report:

*"There are 2 errors reported by Checkstyle 6.11.2 with checkstyle.xml
ruleset.*​"


Best regards,
  Artem Barger.

Re: [rng] New "checkstyle" config is checking "src/test"

[Artem Barger]

On Thu, Aug 18, 2016 at 12:48 AM, Gilles 
wrote:

> The "test" part of the source code need not have the same level
> of cleanliness as the "main" part.
> It was not usually scanned by checkstyle, which now outputs
> many spurious errors.
>

​Well, test code is also a code one need to support, but I'm fine to relax
it
to the previous configuration, a matter of setting one property.

I've addressed all your recent comments and pushed into separate branch
"checkstyle". Will wait
for your confirmation before merging it into master.


Best regards,
  Artem Barger.

Re: [rng] Re: commons-rng git commit: Do not output checkstyle error to the console.

[Artem Barger]

On Thu, Aug 18, 2016 at 12:38 AM, Gilles 
wrote:

>
>> Artem,
>>>
>>> You have introduced spurious blank spaces.
>>>
>>>
>> ​Actually I've removed them.​
>>
>
> Ah, OK. Sorry; I had the "diff" arguments in revers order.
>
> Anyways, when you do that, do it in a separate commit.
> We should avoid mixing formatting changes with contents change.
>

​Yes, you are right.​


>
>
>>
>>
>>
>>> You should perform
>>> $ git diff --check
>>>
>>> You committed a file ("checkstyle.xml") unrelated to the
>>> commit message...
>>>
>>>
>> ​My IDE by default removing trailing whitespaces. Will ​adjust my configs
>> to not doing this next time.
>>
>
> Removing spurious space is fine.
>
> But you should perhaps adjust the config to not automatically commit
> every changed file.


​Already did it, will make sure next time I'm not committing unrelated
things.​




Best regards,
  Artem Barger.

Re: [rng] Re: commons-rng git commit: Add checkstyle plugin configuration, to read project checkstyle.xml

[Artem Barger]

On Thu, Aug 18, 2016 at 12:21 AM, Gilles 
wrote:

> Please check that you do not introduce unwanted formatting changes.
> In this commit, the tabulation setting is different from the rest
> of the file.
>

​Committed fixes into "checkstyle" branch, can you please verify that it's
correct now?​


Best regards,
      Artem Barger.

Re: [rng] Re: commons-rng git commit: Do not output checkstyle error to the console.

[Artem Barger]

On Thu, Aug 18, 2016 at 12:17 AM, Gilles 
wrote:

> Artem,
>
> You have introduced spurious blank spaces.
>

​Actually I've removed them.​



>
> You should perform
> $ git diff --check
>
> You committed a file ("checkstyle.xml") unrelated to the
> commit message...
>

​My IDE by default removing trailing whitespaces. Will ​adjust my configs
to not doing this next time.


Best regards,
  Artem Barger.

Re: [rng] Re: commons-rng git commit: Add checkstyle plugin configuration, to read project checkstyle.xml

[Artem Barger]

On Thu, Aug 18, 2016 at 12:21 AM, Gilles 
wrote:

> Artem,
>
> Please check that you do not introduce unwanted formatting changes.
> In this commit, the tabulation setting is different from the rest
> of the file.
>

​Thanks, will fix it.​


Best regards,
      Artem Barger.

Re: [RNG] Checkstyle

[Artem Barger]

On Wed, Aug 17, 2016 at 3:55 PM, Brent Worden 
wrote:

> It appears is it not using the correct checkstyle ruleset.  From the build
> output:
>
> [INFO] *--- maven-checkstyle-plugin:2.17:checkstyle (default-cli) @
> commons-rng ---
> *[INFO] There are 702 errors reported by Checkstyle 6.11.2 with
> sun_checks.xml ruleset.
>

​Thanks, will take a look to fix it.​


Best regards,
      Artem Barger.

[RNG] Checkstyle

[Artem Barger]

Hi,

I've enabled checkstyle Jenkins plugin and executed checkstyle plugin on
the current code base and it resulted in a lot of high priority warning see
here:
https://builds.apache.org/view/Apache%20Commons/job/Commons_Rng/14/checkstyleResult/HIGH/

Now, I'm wondering whenever it gets a wrong checkstyle.xml file or there
are indeed that many warnings or checkstyle.xml has to be adjusted?

Best regards,
  Artem Barger.

Re: [rng] JARs with different dependencies within the same component?

[Artem Barger]

On Tue, Aug 16, 2016 at 6:49 PM, Gilles 
wrote:

>
> The restriction, as Jörg wrote, is that a single component can only
> release artifacts with the same version.


​Ok, I think this is very common practice, as far as I recall correctly
same
thing also happens in many other open source projects, Spring could be an
example out of head. So even if you haven't changes in rng-core it make
sense to align its release cycle w/ rng-tools.


Best regards,
      Artem Barger.

Re: [rng] JARs with different dependencies within the same component?

[Artem Barger]

On Tue, Aug 16, 2016 at 3:00 PM, Gilles 
wrote:

> That's what I was afraid of; in this case, it would defeat the purpose:
> We shouldn't have to release "core-2.0" (thus a with change of the
> top-level package name), just because we want to fix something in the
> "utils" code.
>
> Given this situation, would it be possible to consider a separate
> component: "commons-rng-utils"?
>

I think following layout should actually work:

commons-rng-parent (pom) v1.0
|commons-rng-core (jar) v1.0
|commons-rng-tools (jar) v1.0​

​And suppose you want to update commong-rng-tools from v1.0 to v2.0 it will
look like:​

commons-rng-parent (pom) v1.1
|commons-rng-core (jar) v1.0
|commons-rng-tools (jar) v2.0​

​where you do not really have to touch version of core component. Unless
this is somehow
restricted by ASF commons coding standards or something.​

Or, do you have something else in your mind?

Best regards,
  Artem Barger.

Re: [rng] JARs with different dependencies within the same component?

[Artem Barger]

On Mon, Aug 15, 2016 at 5:32 PM, Gilles 
wrote:

>
> Suppose that
>   commons-rng-core-1.0.jar
> depends on JDK 1.6.
>
> And that we wish to offer utilities (e.g. random strings) and other
> syntactic sugar (such as Java 8 streams) in
>   commons-rng-utils-1.0.jar
> that would depend on JDK 1.8.
>
> Is it possible?


​If these are two separate JAR modules, this should be possible in fact
many people already doing it. While not sure how this will work for
muti-module ​pom project (I will be able to check it a bit latter).


Best regards,
  Artem Barger.

[RNG] User guide demo apps.

[Artem Barger]

Hi,

I was thinking of adding a few additional demo application for user guide
page:

1. Seeding algorithm for kmeans++ (sampling centers based on the distances).
2. Non uniform coreset for kmeans clustering (importance sampling),
reducing big data into small based on random algorithm.

What is the reasonable amount of demo applications for user guide which
should be enough to start with?

Best regards,
  Artem Barger.

[lang] LANG-1110

[Artem Barger]

Hi,


I'm planning to work on LANG-1110, since it's pretty related to my other
work I did for RNG project lately. Because this issue assumes adding JMH
benchmark instead of the  test which practically implements benchmarking, I
though it will be reasonable to start form adding JMH dependency. Therefore
created LANG-1256 and provided a PR:
https://github.com/apache/commons-lang/pull/182 (will be glad to hear
comments).

So my main question, whenever LANG-1110 requires to literally replace
"HashSetvBitSetTest" with JMH benchmark or just add a benchmark based on
JMH and leaving original test as is, since it check different assumption
and asserts the code. Or is there was an additional purpose?


PS. Also it looks like many common projects either already using JMH or
considering to add it to the arsenal of tools. Isn't better to add it to
parent pom.xml so everyone will have it?

Best regards,
      Artem Barger.

RNG component release

[Artem Barger]

Hi,

I'm looking on the project and since I'm pretty unfamiliar w/ inner ASF
processing, was wondering what currently missing to be able to release
first version of commons-rng?

Just trying to understand the process and probably to fill up the JIRA with
appropriate tasks which are necessary to successfully release the project
and to have a sense of progress.


Best regards,
  Artem Barger.

Re: commons-rng git commit: CheckStyle.

[Artem Barger]

How do you differ between core and tools? What should be included in each? Do 
you mean to further split up current commons-rng?

Sounds possible once decided how you'd like to divide it.

Отправлено с iPhone

> 11 авг. 2016 г., в 20:44, Gilles  написал(а):
> 
> On Thu, 11 Aug 2016 09:02:34 +0300, Artem Barger wrote:
>>> 11 авг. 2016 г., в 2:08, Rob Tompkins  написал(а):
>>> 
>>> I would guess that we would want to be compatible with the oldest version 
>>> of Java possible dictated out of necessity. By that I mean if there's 
>>> something of considerable substance that a newer version affords us, then 
>>> we should upgrade. But that's only really the thought that runs through my 
>>> head. I'm not really tied to it.
>> 
>> I think it could make sense to provide support to something similar
>> to SplittableRandom while releasing a new PRNG components within
>> commons. Which available from JDK 1.8.
> 
> Excerpt from the commit log:
> ---CUT---
> commit ed083eaf22c4c8403660c48bee7945d40edee6d9
> Author: Gilles 
> Date:   Tue Aug 9 19:03:39 2016 +0200
> 
>Bumped JDK dependency to Java 6 (due to "Arrays.copyOf").
> 
>Unlikely to loose many potential users w.r.t. Java 5.
> 
> commit bb0886f84ba23032306c6376987f92ce653f181d
> Author: Gilles 
> Date:   Tue Aug 9 16:02:08 2016 +0200
> 
>Make codebase Java 5 compatible.
> 
>The public API is comprised of 1 enum (with factory methods) and 2 
> interfaces.
>The "internal" classes would not gain tremendously from more recent 
> programming constructs (cf. changes in this commit).
>Additional RNG implementations would be mostly low-level code (e.g. bit 
> manipulation) also unlikely to be dependent on a modern JDK.
> 
>If and when considered, higher level utilities (e.g. "Stream"-based) could 
> be implemented in another module, with more stringent requirements.
> ---CUT---
> 
> 
> So, we could readily experiment with a multi-modules project.
> I guess that the pom.xml needs further adjustment to generate
> several JARs (say "commons-rng-core" and "commons-rng-tools").
> 
> First question: is it possible?
> 
> Regards,
> Gilles
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-rng git commit: CheckStyle.

[Artem Barger]

> 11 авг. 2016 г., в 2:08, Rob Tompkins  написал(а):
> 
> I would guess that we would want to be compatible with the oldest version of 
> Java possible dictated out of necessity. By that I mean if there's something 
> of considerable substance that a newer version affords us, then we should 
> upgrade. But that's only really the thought that runs through my head. I'm 
> not really tied to it.

I think it could make sense to provide support to something similar to 
SplittableRandom while releasing a new PRNG components within commons. Which 
available from JDK 1.8.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-rng git commit: CheckStyle.

[Artem Barger]

On Wed, Aug 10, 2016 at 11:58 PM, Gilles 
wrote:

> But if all are happy to require Java 7, I wouldn't certainly
> oppose it!
>

​And what about going forward and switching to Java 8? Or this sort of
decision
should be received broadly across ​all commons projects?


Best regards,
      Artem Barger.

Re: [rng] Update .gitignore to ignore MacOS related files.

[Artem Barger]

On Thu, Aug 11, 2016 at 1:12 AM, Gilles 
wrote:

> Hi,
>>
>> Will it be possible to apply patch for .gitignore file to skip Mac related
>> files?
>>
>
> Done.


​Thanks.​


Best regards,
  Artem Barger.

[rng] Update .gitignore to ignore MacOS related files.

[Artem Barger]

Hi,

Will it be possible to apply patch for .gitignore file to skip Mac related
files?

>From 30356710069fa340323485e5a10ee7fcb489617e Mon Sep 17 00:00:00 2001
From: Artem Barger 
Date: Thu, 11 Aug 2016 01:10:51 +0300
Subject: [PATCH] Update .gitignore to skip MacOs related folders

---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 46859ad..c76b190 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,7 @@ target
 *.ipr
 *.iws
 .idea
+.DS_Store
 *~
 /.externalToolBuilders/
 /maven-eclipse.xml
-- 
2.8.2


Best regards,
      Artem Barger.

Re: [MATH]: Current state of project?

[Artem Barger]

On Fri, Aug 5, 2016 at 2:47 PM, Rob Tompkins  wrote:

> So based upon all of the conversation here, I’ve concluded that the best
> path forward is to attempt to grow the community inside commons. That’s why
> I’m sticking with attempts to make contributions elsewhere in commons to
> gain the requisite rapport for committer status. Once I’ve accomplished
> that, then we’ll have two sets of hands to help here.
>

​While I can imagine myself contributing to other commons projects, it
still sounds a bit weird to me, contributing in one place just to
eventually get a mandate to be able to make the contribution in ​different
place.


> Further it seems that we’ve gotten ourselves into a vicious cycle sort of
> place, in that to gain a community we need a mechanism to quickly get
> commits into the component, but to do that we need more devoted committers
> (i.e. a larger community).
>
> Any thoughts here?
>

​I still full of hope to make my way directly into math without seeking for
alternatives. :)))​



Best regards,
  Artem Barger.

[rng] Adding JMH dependency, RNG-2.

[Artem Barger]

Hi,

I've created a following JIRA task, to add JMH dependency and allow
execution of microbenchmarks based on JMH framework. I've added maven
profile to separate compilation of benchmark related jar from the main
stream. My proposed changes attached to the JIRA issue, any comments or
suggestions are welcomed.


Also it will be interesting to hear ideas where to actually write and
implement the benchmarks once such change will be added. Moreover it's
important to note, that using JMH it only allows to compare algorithms and
different implementations performance wise rather than comparing the
actually accuracy of result produced. For example if I'll add a benchmark
to compare different random source providers, I will receive results which
show me what is the most performant provider for given workload, while
nothing regarding the actually accuracy of the algorithm I've implemented
to run the comparison.

More particularly I've added a benchmark to estimate value of PI add this
is the results I've got out of JMH:

# Run complete. Total time: 00:01:35

Benchmark (pairsToGenerate)  (randomSourceName)
Mode  Cnt  Score   Error  Units
PiComputationBenchmark.computePi100 JDK
avgt5  44076.310 ±  2794.888  us/op
PiComputationBenchmark.computePi100  WELL_512_A
avgt5  19374.112 ±  4973.542  us/op
PiComputationBenchmark.computePi100 WELL_1024_A
avgt5  20575.240 ±  4298.444  us/op
PiComputationBenchmark.computePi100WELL_19937_A
avgt5  42208.136 ±  2062.648  us/op
PiComputationBenchmark.computePi100WELL_19937_C
avgt5  45105.231 ±  2752.918  us/op
PiComputationBenchmark.computePi100WELL_44497_A
avgt5  49710.663 ± 15786.830  us/op
PiComputationBenchmark.computePi100WELL_44497_B
avgt5  48984.700 ±  2449.719  us/op
PiComputationBenchmark.computePi100  MT
avgt5  22466.565 ±  1377.585  us/op
PiComputationBenchmark.computePi100   ISAAC
avgt5  21615.283 ±  1080.331  us/op

Note, there is nothing here that shows how actually computed PI results is
close to real value.

Best regards,
  Artem Barger.

Re: [rng] Web site (Was: [rng] JIRA is up)

[Artem Barger]

On Tue, Aug 9, 2016 at 1:25 PM, Gilles  wrote:

> In short, you might try this:
>
>   
> 
>   org.apache.maven.plugins
>   maven-javadoc-plugin
>   
> -Xdoclint:none
>   
> 
>   
>
> If it fixes your problem, I'll commit the change.
>

​Yeah, now it's better. Based on this created a patch and attached to the
issue report, since the change wasn't exactly the same.​


Best regards,
  Artem Barger.

Re: [rng] Web site (Was: [rng] JIRA is up)

[Artem Barger]

On Tue, Aug 9, 2016 at 12:45 PM, Gilles 
wrote:

> Congrats! And here the first issue: RNG-1
>> <https://issues.apache.org/jira/browse/RNG-1>, not able to produce site
>> web
>> pages ("mvn clean site"), looks like there is a link missing.
>>
>
> I also encountered this problem.
> I suspect that it is a one time issue because a directory named
>   site-content
> is missing.
> Creating it manually allows "mvn site" to run to completion, creating
> the site inside the "target/site" directory.


​Made some progress, but still fails with errors:



[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
project commons-rng: Error generating maven-javadoc-plugin:2.10.3:javadoc:
[ERROR] Exit code: 1 -
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/internal/source32/MersenneTwister.java:52:
warning: attribute obsolete, use CSS instead: align
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/internal/source32/MersenneTwister.java:52:
warning: attribute obsolete, use CSS instead: bgcolor
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/internal/source32/MersenneTwister.java:83:
error: no summary or caption for table
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/internal/source64/MersenneTwister64.java:38:
warning: attribute obsolete, use CSS instead: align
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/internal/source64/MersenneTwister64.java:38:
warning: attribute obsolete, use CSS instead: bgcolor
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/internal/source64/MersenneTwister64.java:69:
error: no summary or caption for table
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/internal/source64/TwoCmres.java:32:
error: unexpected end tag: 
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/internal/util/NumberFactory.java:122:
error: unexpected end tag: 
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/internal/util/NumberFactory.java:141:
error: unexpected end tag: 
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/RandomSource.java:257:
error: unexpected end tag: 
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/RandomSource.java:274:
error: unexpected end tag: 
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/RandomSource.java:284:
error: unexpected end tag: 
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/RandomSource.java:304:
error: unexpected end tag: 
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/RandomSource.java:306:
error: text not allowed in  element
[ERROR] * @param source RNG type.
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/RandomSource.java:288:
error: element not closed: ul
[ERROR] * 
[ERROR] ^
[ERROR]
/Users/bartem/sandbox/commons-rng/src/main/java/org/apache/commons/rng/RandomSource.java:48:
error: unexpected end tag: 
[ERROR] * 
[ERROR] ^
[ERROR]
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/../bin/javadoc
@options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/Users/bartem/sandbox/commons-rng/target/site/apidocs' dir.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
​


Best regards,
  Artem Barger.

Re: [rng] JIRA is up

[Artem Barger]

Congrats! And here the first issue: RNG-1
<https://issues.apache.org/jira/browse/RNG-1>, not able to produce site web
pages ("mvn clean site"), looks like there is a link missing.

Best regards,
      Artem Barger.

On Tue, Aug 9, 2016 at 1:13 AM, Gilles  wrote:

>
> https://issues.apache.org/jira/browse/RNG
>
>
> Regards,
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [rng] Setting up Jenkins

[Artem Barger]

Eh... Feels like I'm trying to move rocks here. Is there anything I can help 
with here as a non-committer?

Отправлено с iPhone

> 8 авг. 2016 г., в 18:41, Stefan Bodewig  написал(а):
> 
>> On 2016-08-08, Artem Barger wrote:
>> 
>> What is the process of getting an ASF account?
> 
> Sorry, I wasn't clear. "you need an ASF account" really means "you need
> to be a committer".
> 
> Configuring Jenkins builds is one of the - few - areas non-committers ar
> unable to help out with, unfortunately.
> 
> Sorry
> 
>Stefan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [rng] Setting up Jenkins

[Artem Barger]

What is the process of getting an ASF account?

Отправлено с iPhone

> 8 авг. 2016 г., в 18:25, Stefan Bodewig  написал(а):
> 
>> On 2016-08-08, Artem Barger wrote:
>> 
>> Do I need to write them directly? Or Posting here will be enough?
> 
> Posting here should be enough.
> 
> If https://wiki.apache.org/general/Jenkins?action=show&redirect=Hudson
> is current I should be one of the folks who can grant you access but you
> need an ASF account to start with.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [rng] Setting up Jenkins (Was: [rng] New repository for "Commons Rng")

[Artem Barger]

Do I need to write them directly? Or Posting here will be enough?

Отправлено с iPhone

> 8 авг. 2016 г., в 18:02, Matt Sicker  написал(а):
> 
> You need the necessary karma to configure Jenkins stuff. One of the PMCs
> (or Gary) should be able to give that to you.
> 
>> On 8 August 2016 at 09:35, Artem Barger  wrote:
>> 
>> On Mon, Aug 8, 2016 at 5:33 PM, Gilles 
>> wrote:
>> 
>>> Help is welcome in order to set up the various tools (JIRA,
>>>>> Jenkins, etc.) for a Commons component.
>>>> ​I can help w/ Jenkins, while not sure I have access rights to do it :/​
>>> 
>>> Does configuring a Jenkins instance require an INFRA request?
>> 
>> 
>> ​I would expect so, while not familiar w/ how things work within "commons".
>> I'm not even sure
>> where to find the link to jenkins server to give it a try.​
>> 
>> 
>> Best regards,
>>  Artem Barger.
> 
> 
> 
> -- 
> Matt Sicker 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [rng] Setting up Jenkins (Was: [rng] New repository for "Commons Rng")

[Artem Barger]

On Mon, Aug 8, 2016 at 5:33 PM, Gilles  wrote:

> Help is welcome in order to set up the various tools (JIRA,
>>> Jenkins, etc.) for a Commons component.
>>>
>>>
>> ​I can help w/ Jenkins, while not sure I have access rights to do it :/​
>>
>
> Does configuring a Jenkins instance require an INFRA request?


​I would expect so, while not familiar w/ how things work within "commons".
I'm not even sure
where to find the link to jenkins server to give it a try.​


Best regards,
  Artem Barger.

Re: [rng] New repository for "Commons Rng"

[Artem Barger]

On Mon, Aug 8, 2016 at 1:16 PM, Julien Aymé  wrote:

> IMHO, it would be simpler to add JDKSecureRandom and
> JDKThreadLocalRandom classes, so that you know what you have in a
> single glance.
> WDYT?
>

IMO make sense, since it will allow to preserve inheritance relationships
similar
to those of JDK w/ Random, SecureRandom and ThreadLocalRandom classes.

Of course it's interesting to hear Gilles opinion since he is an author of
the changes.

Best regards,
      Artem Barger.

Re: [rng] New repository for "Commons Rng"

[Artem Barger]

​Hi,​

On Mon, Aug 8, 2016 at 4:10 AM, Gilles  wrote:

> A new git repository has been populated with the relevant
> codes, unit tests and documentation extracted from Commons
> Math ("o.a.c.math4.rng" package).
>

​I was looking on implementation of JDKRandom and it turns to use Random
implementation
from java.utils and actually delegates methods calls ​to it. Now I was
expect one to be able to
choose between Random, SecureRandom and ThreadLocalRandom and not solely
relying on
Random only implementation.

Does it make a sense to introduce a construct which will allow to override
the default of Random
instance w/ other possible JDK implementations?


Best regards,
      Artem Barger.

Re: [rng] New repository for "Commons Rng"

[Artem Barger]

On Mon, Aug 8, 2016 at 4:10 AM, Gilles  wrote:

> Help is welcome in order to set up the various tools (JIRA,
> Jenkins, etc.) for a Commons component.
>

​I can help w/ Jenkins, while not sure I have access rights to do it :/​


Best regards,
      Artem Barger.

Re: [MATH]: Current state of project?

[Artem Barger]

On Thu, Aug 4, 2016 at 9:50 AM, Ralph Goers 
wrote:

> > All I'm saying this is one of the problems within CM, ​which IMO only a
> > symptom for more acute problem of missing community. Also as you can see
> in
> > ML archive I've tried several times to rise discussion around work I'm
> > doing and also asked for PR review.
> > And to be precise, right now the someone to apply is Gilles only, as far
> as
> > I'm getting situation correctly.
>
> Any Commons committer can apply the patch. But to be honest, unless the
> patch is somewhat obvious or is in a part of the code Gilles isn’t familiar
> with, I would expect most everyone would wait for Gilles blessing.


​So if almost everyone supposed to wait until Gilles will accept it, why
Gilles initiatives of how project should be divided into separate
independent modules could not be accepted? I mean what should happen
effectively, to move things forward?  I was using CM for implementation of
different parts of my thesis work and I couldn't imagine to myself that
proposing improvements or new things related to CM base code will be so
hard.


Best regards,
  Artem Barger.

Re: [MATH]: Current state of project?

[Artem Barger]

On Thu, Aug 4, 2016 at 9:30 AM, Ralph Goers 
wrote:

> So you are saying that the real problem is that no one involved with
> Commons Math is acting on the work you are doing. In other projects PRs
> don’t always get acted upon immediately, but 3 months is a bit long.
> Pinging on the list to get someone to apply them is always a good idea.


All I'm saying this is one of the problems within CM, ​which IMO only a
symptom for more acute problem of missing community. Also as you can see in
ML archive I've tried several times to rise discussion around work I'm
doing and also asked for PR review.
And to be precise, right now the someone to apply is Gilles only, as far as
I'm getting situation correctly.


Best regards,
  Artem Barger.

Re: [MATH]: Current state of project?

[Artem Barger]

On Wed, Aug 3, 2016 at 2:30 PM, Ralph Goers 
wrote:

> > 1. My understanding is that any ASF committer has commit rights to
> Commons.  That is one case for a low barrier to entry. Of course, any
> committer will want to learn the way-of-working at Commons and any
> interesting subprojects, but commit rights is not itself an issue in this
> case, yes?
> >Has that changed?
>
> That has not changed, but I am of the impression that the folks expressing
> interest in Commons Math don’t have commit rights to any ASF project.


​Well, I'm not speak about commit rights, let's start from the point where
PR and JIRA reports got reviewed and accepted/rejected/commented. My three
PRs has been there for couple of months, but nothing effectively has happen
since when. And this is why I've initiated this thread to try to get clear
picture of where things are currently standing and understand whenever I
should continue ti investing my time proposing changes and improvements
here or shall I just skip and try something else. ​


Best regards,
  Artem Barger.

Re: [MATH]: Current state of project?

[Artem Barger]

On Wed, Aug 3, 2016 at 11:41 AM, Ralph Goers 
wrote:

> > If that were true, you could have said that the newcomers who
> > want to work on a revised CM are welcome to do so, and the
> > output of that work would normally be adopted by Commons
> > (unless it's proven crappy of course).
>
> OK. Newcomers are free to work on whatever they want, whether it is fixing
> new bugs, refactoring code, creating new components. Whatever. And that
> doesn’t apply to just Commons Math but pretty much every project at the
> ASF. No one should have to tell you that that is allowed.  As you have said
> a million times, you are currently the only one committing to CM so it is
> only going to be pretty much you who blocks commits.
>

​That being said, I'm trying to find my way on the CM project, proposed
several PR, opened a couple of issues in JIRA, however nothing seems to
happen with it, here I'm asking the question about the productivity and
actual need to continue and contribute my work to the project. I'd say this
is pretty weird situation where one would start contributing to other
common project to eventually be able to contribute to CM.​


Best regards,
  Artem Barger.

Re: [MATH]: Current state of project?

[Artem Barger]

On Tue, Aug 2, 2016 at 11:55 AM, Rob Tompkins  wrote:

> Hey Artem,
>
> I agree. I've decided to make some contributions in commons more generally
> to gain report as to become a committer. Until I can do that, I'm guessing
> that it'll just be Gilles accepting pill requests.
>
> Cheers,
> -Rob
>

​Yeah, I was also thinking of that, however sounds a bit awkward, since I'm
mostly interested in contributing to the math rather to other projects. ​


Best regards,
  Artem Barger.

[MATH]: Current state of project?

[Artem Barger]

Hello everyone,

It's been a while since there was a lot of hot discussion regarding the
future of the CM project, however I do not think that clear agreement was
reached. The reason I'm wondering is because I'd like to contribute to the
project and in fact already did, but doesn't looks like it gonna be
accepted/checked any soon.

I have reported following issues and provided PR with proposed fixes:

1. [MATH-1374] - https://github.com/apache/commons-math/pull/37
2. [MATH-1372] - https://github.com/apache/commons-math/pull/36
3. [MATH-1371] - https://github.com/apache/commons-math/pull/35

Reported and attached small improvement [MATH-1378].

Also I have some work in progress related to [MATH-1330].

I've been asking couple of times here in ML to review or suggest any
improvements for bugs I've reported and PR proposed, but apparently things
is not moving forward I guess due to the fact that there didn't remained
any active committers/contributes.

Is there any decision has been made? Is Math project could be considered as
"dead" and no more future development is going to happen?

I'm still willing to contribute to the project, but I'm really concern of
current "frozen" state, since it feels that any submition of changes or
reporting bugs to the project goes directly to "/dev/null".

Best regards,
  Artem Barger.

Re: [VOTE] New component: Standard math functions

[Artem Barger]

+1 [contributor]

Best regards,
  Artem Barger.

On Fri, Jul 1, 2016 at 3:34 PM, Rob Tompkins  wrote:

> +1 [contributor, not committer]
>
> > On Jun 27, 2016, at 6:23 AM, Gilles 
> wrote:
> >
> > On Mon, 27 Jun 2016 03:55:35 + (UTC), venkatesha m wrote:
> >> Does this use Java 8?
> >
> > What is "this"?
> >
> > If you want to discuss (rather than vote), please start a new
> > thread.
> >
> > Thank you,
> > Gilles
> >
> >
> >>On Monday, 27 June 2016 2:20 AM, Gilles
> >>  wrote:
> >>
> >>
> >> On Sun, 26 Jun 2016 16:13:06 -0400, Rob Tompkins wrote:
> >>>> On Jun 26, 2016, at 11:21 AM, Gilles 
> >>>> wrote:
> >>>>
> >>>>> On Sun, 26 Jun 2016 12:35:38 +0200, Jochen Wiedmann wrote:
> >>>>>> On Sat, Jun 25, 2016 at 9:00 PM, Gary Gregory
> >>>>>>  wrote:
> >>>>>> One could argue that since Java has java.util.Random, Commons Lang
> >>>>>> could
> >>>>>> include a random package.
> >>>
> >>> Yes, and it feels like an even more appropriate place for
> >>> org.apache.commons.math3.util.FastMath (and maybe associated classes)
> >>> due to the location of java.lang.Math.
> >>
> >> I don't think so.
> >> I'm in favour of "small" components.
> >>
> >> Take into account that Commons Lang is probably less stable
> >> than "FastMath": CL's top-level package name is now "lang3"
> >> whereas this functionality would be located in a package whose
> >> name would never change.
> >>
> >> Also, since the JDK itself is going to be "modular", it is a
> >> bit odd to go in the opposite direction.
> >>
> >>
> >> Gilles
> >>
> >>> -Rob
> >>>
> >>>>>
> >>>>> For the same reason, [io] might be moved to [lang], too.
> >>>>
> >>>> And [compress], [crypto], [imaging], [dbutils], [logging], [net].
> >>>> ;-}
> >>>>
> >>>> Gilles
> >>>>
> >>>>
> >>>>>
> >>>>> Jochen
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] New component: Random number generators

[Artem Barger]

On Sat, Jun 25, 2016 at 9:48 AM, Stian Soiland-Reyes 
wrote:

> On 21 Jun 2016 8:31 p.m., "Gilles"  wrote:
>
> > Hello.
> >
> > This is one of several votes for establishing new Commons components
> > out of functionality developed inside the "Commons Math" component.
> >
> > This vote is dedicated to the following functionality:
> >   Uniform (pseudo-)random number generators
> >
> > The concerned code is the contents of the following classes and packages:
> >   org.apache.commons.math4.rng
> > located in the "develop" branch of Commons Math:
> >
> >
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/rng;h=3f7313a705b1f517dc11f3d2b3983434852f4c02;hb=refs/heads/develop
> >
> > Notes:
> >  * Code in the above package was never released.
> >  * This component will have no dependency.
> >  * Code size: ~1800 lines of code (unit tests not included).
> >  * API: stable (probably).
> >  * Estimated minimum Java version: 6
> >
> > All are welcome to vote, especially potential users of the candidate
> > component and people who'd like to contribute to it, through user
> support,
> > bug-fixes and enhancements, documentation, release management.
> >
> > [ ] +1, this would be a valid Commons component.
> > [ ] -1, this won't be a good Commons component because ...
> >
> >
> > Thanks,
> > Gilles
>

​I believe that RNG is well separated and self contained component, hence
I'd like to express my 0.02$ and add:

+1​


Best regards,
  Artem Barger.

Re: [MATH] MATH-1378: KMeansPlusPlusClusterer optimize seeding procedure.

[Artem Barger]

Thanks, now then I've looked on it again, I think I can improve it more,
since I currently at each iteration
of the seed each points sampled with worst case complexity of O(n) (n is
number of points) I think it's possible
to reduce it to O(log(n)), while using O(n) of additional space.

Best regards,
  Artem Barger.

On Thu, Jun 23, 2016 at 4:37 PM, Eric Barnhill 
wrote:

> I use kmeans a bit and I will look at it.
>
> On Thu, Jun 23, 2016 at 2:10 PM, Artem Barger  wrote:
>
> > Hi all,
> >
> > While I understand there is a project decision threads are going on ML,
> > however I'd like to suggest and provide some improvements of CM kmeans++
> > implementation in the seeding procedure. Currently sum of squared
> distances
> > computed each iteration during initial centers seeding, which is
> redundant
> > since sum can be computed once and updated within the cycle.
> >
> >
> > Subjected JIRA item explains the optimization and I've also provided
> patch
> > with suggested fix. Would be glad to hear any comments or reviews.
> >
> >
> > Best regards,
> >   Artem Barger.
> >
>

[MATH] MATH-1378: KMeansPlusPlusClusterer optimize seeding procedure.

[Artem Barger]

Hi all,

While I understand there is a project decision threads are going on ML,
however I'd like to suggest and provide some improvements of CM kmeans++
implementation in the seeding procedure. Currently sum of squared distances
computed each iteration during initial centers seeding, which is redundant
since sum can be computed once and updated within the cycle.


Subjected JIRA item explains the optimization and I've also provided patch
with suggested fix. Would be glad to hear any comments or reviews.


Best regards,
  Artem Barger.

Re: [VOTE] New component: Random number generators

[Artem Barger]

On Tue, Jun 21, 2016 at 10:31 PM, Gilles 
wrote:

> Hello.
>
> This is one of several votes for establishing new Commons components
> out of functionality developed inside the "Commons Math" component.
>
> This vote is dedicated to the following functionality:
>   Uniform (pseudo-)random number generators
>
> The concerned code is the contents of the following classes and packages:
>   org.apache.commons.math4.rng
> located in the "develop" branch of Commons Math:
>
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/rng;h=3f7313a705b1f517dc11f3d2b3983434852f4c02;hb=refs/heads/develop
>
> Notes:
>  * Code in the above package was never released.
>  * This component will have no dependency.
>  * Code size: ~1800 lines of code (unit tests not included).
>  * API: stable (probably).
>  * Estimated minimum Java version: 6
>
> All are welcome to vote, especially potential users of the candidate
> component and people who'd like to contribute to it, through user support,
> bug-fixes and enhancements, documentation, release management.
>
> [ ] +1, this would be a valid Commons component.
> [ ] -1, this won't be a good Commons component because ...
>
>
​Why you do not want to make it a part of standard math function component?​

Re: [VOTE] New component: Standard math functions

[Artem Barger]

On Tue, Jun 21, 2016 at 10:30 PM, Gilles 
wrote:

> Hello.
>
> This is one of several votes for establishing new Commons components
> out of functionality developed inside the "Commons Math" component.
>
> This vote is dedicated to the following functionality:
>   Standard mathematical functions (either missing from "java.lang.Math",
>   or faster or more accurate than their counterpart in the JDK) and
>   floating point utilities.
>
> The concerned code is the contents of the following classes and packages:
>   org.apache.commons.math4.Field
>   org.apache.commons.math4.FieldElement
>   org.apache.commons.math4.RealFieldElement
>   org.apache.commons.math4.util.FastMath (and helper classes)
>   org.apache.commons.math4.util.Precision
>   org.apache.commons.math4.util.MathUtils
>   org.apache.commons.math4.util.ArithmeticUtils
>   org.apache.commons.math4.util.Combinations
>   org.apache.commons.math4.util.CombinatoricsUtils
>   org.apache.commons.math4.util.ContinuedFraction
>   org.apache.commons.math4.dfp
>   org.apache.commons.math4.special
> located in the "develop" branch of Commons Math:
>
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/util;h=c54f99f943f758e43ebeb54d8771a6ef6516d283;hb=refs/heads/develop
>
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/special;h=b8fb8b1f6e29a549d0716c866939e074525246a1;hb=refs/heads/develop


​What about o.a.c.m.fraction package? IMO it fits well into the list above.​


>
> Notes:
>  * This component will have no dependency.
>  * Code size: ~13000 lines of code (unit tests not included).
>[Out of which ~6000 lines are literal numbers defined in
>class "FastMathLiteralArrays".]
>  * API: stable.  [But some of it should probably be moved into
>an "internal" package.]
>  * Estimated minimum Java version: 5
>
> All are welcome to vote, especially potential users of the candidate
> component and people who'd like to contribute to it, through user support,
> bug-fixes and enhancements, documentation, release management.
>
> [ ] +1, this would be a valid Commons component.
> [ ] -1, this won't be a good Commons component because ...
>
>
​Not sure whenever my voice can be counted here.

+1.

Best regrads,
Artem Barger.​

Re: [Math] Commons Math (r)evolution

[Artem Barger]

 On Thu, Jun 9, 2016 at 1:54 AM, Gilles 
wrote:

> ​I guess someone need to prioritize them​ according to they importance for
>
>> release.
>>
>
> Importance is relative... :-}
>

​Indeed it's very objective function,  however someone has to decide
where to focus.​



> IMO, it is important to not release unsupported code.
> So the priority would be higher for issues that would be included
> in the release of the new Commons components.
> Hence the need to figure out what these components will be.
>

​Not clear whenever you really mean by not releasing unsupported code is
to exclude already existing parts which doesn't anyone who will be capable
to maintain the functionality and solve possible bugs?​



>
>>> Which ones?
>>>
>>> ​I will look into JIRA and provide the issue numbers, and of course I
>> can cover and assist with ML part and particular clustering.​
>>
>
> Thanks.
>

​You are welcome :)
So I looked through some of the open issues and I have a couple of
questions them​:

1. Which affected version do I really need to consider as an important to
be
released in the next version?
2. I've looked into affected versions: 3.5, 3.6, 3.6.1, 3.7 and 4.0.
Overall found
something like ~25 open bugs/issues. What about issues opened for lower
releases?

For example while I'm looking into MATH-1329
, it sounds not really
hard to have it fixed,
but looking on it not sure whenever it was accepted and approved as
something that need
to be done.

Next MATH-1315  seems like
reported has provided the patch and the only thing
missing is unit test, will addition of unit tests help to make that one
resolved?

MATH-1284  here is not
clear what is the final decision, according to comments look
like it can be resolved.

Here MATH-1262  according
to the comments editing current javadoc to explain the limitation
should also rest this case, am I missing something?

I think I can help to handle MATH-1281
, right after I will
finish the refactoring and
optimizations for kmeans clustering.

​Listed issues/tickets where I can help to provide support or fix, most
likely missed something
but can start with these.​


> with additional functionality, since I think I can provide my code for
>> several classification
>> algorithms​.
>>
>
> That sounds nice.
> Which algorithms?
>
>
​Naive Bayes, kNN, Decision Trees, Random Forest. I guess adding these into
the project will require
serious redesign of ML package​.

Re: [Math] Commons Math (r)evolution

[Artem Barger]

On Wed, Jun 8, 2016 at 12:25 AM, Gilles 
wrote:

>
> According to JIRA, among 180 issues currently targeted for the
>>> next major release (v4.0), 139 have been resolved (75 of which
>>> were not in v3.6.1).
>>>
>>>
>> ​Huh, it's above of 75% completion :)​
>>
>
> Everybody is welcome to review the "open" issues and comment
> about them.
>
>
​I guess someone need to prioritize them​ according to they importance for
release.


Of course, anyone who wishes to maintain some of these codes
>
>> (answer user questions, fix bugs, create enhancements, etc.)
>>> is most welcome to step forward.
>>>
>>>
>> ​I can try to cover some of these and maintain relevant code parts.​
>>
>
> Which ones?
>
> ​I will look into JIRA and provide the issue numbers, and of course I
can cover and assist with ML part and particular clustering.​




>
> IMO, a maintainer is someone who is able to respond to user
> questions and to figure out whether a bug report is valid.
>

​I'm subscribed for mailing list for quite a while and haven't seen a lot of
questions coming from user​s.



>>> ​I think that clustering part could be generalized to ML package as a
>> whole.​
>>
>
> Fine I guess, since currently the "neuralnet" sub-package's only
> concrete functionality is also a clustering method.
>
>
​I was also wondering whenever ML package meant to be extended in the future
with additional functionality, since I think I can provide my code for
several classification
algorithms​.

Re: [Math] Commons Math (r)evolution

[Artem Barger]

On Mon, Jun 6, 2016 at 3:49 AM, Gilles  wrote:

>
> According to JIRA, among 180 issues currently targeted for the
> next major release (v4.0), 139 have been resolved (75 of which
> were not in v3.6.1).
>

​Huh, it's above of 75% completion :)​


> So, on the one hand, a lot of work has been done already, but
> on the other, a lot remains.
> Some issues have been pending for several years, in particular
> those that required a major refactoring (e.g. in the packages
> "o.a.c.m.linear" and "o.a.c.m.optim").
>
> The remaining work is unlikely to be completed soon since the
> fork of Commons Math has drastically reduced the development
> capacity.
>
> Moreover, as whole areas of the codebase have become in effect
> unsupported, it would be deceiving to release a version 4.0 of
> Commons Math that would include all of it.
>
> Of course, anyone who wishes to maintain some of these codes
> (answer user questions, fix bugs, create enhancements, etc.)
> is most welcome to step forward.
>

​I can try to cover some of these and maintain relevant code parts.​



>
> But I'm not optimistic that the necessary level of support can
> be achieved in the near future for all the codebase.
> Waiting for that to happen would entail that code that could
> be in a releasable state soon will be on hold for an indefinite
> time.
>
> What exactly missing to provide reasonable support, apart of
course of people who left?​



> The purpose of this post is to initiate a discussion about
> splitting Commons Math, along the following lines:
> 1. Identify independent functionality that can be maintained
>even by a small (even a 1-person) team within Commons and
>make it a new component.
> 2. Identify functionality that cannot be maintained anymore
>inside Commons and try to reach out to users of this
>functionality, asking whether they would be willing to
>give a helping hand.
>If there is sufficient interest, and a new development
>team can form, that code would then be transferred to the
>Apache "incubator".
>
> According to the most recent development activity, the likely
> candidates for becoming a new component are:
>  * Pseudo-random numbers generators (package "o.a.c.m.rng")
>  * Complex numbers (package "o.a.c.m.complex")
>  * Clustering algorithms (package "o.a.c.m.ml.clustering")
>
>
​I think that clustering part could be generalized to ML package as a
whole.​

​Best regrads,
Artem Barger.​

Re: [Math] kmeans++: decouple EM LLoyd's iterations and initial seeding of clustering centers.

[Artem Barger]

On Wed, Jun 1, 2016 at 5:46 PM, Gilles  wrote:

> On Wed, 1 Jun 2016 17:24:47 +0300, Artem Barger wrote:
>
>> ​
>> On Tue, May 31, 2016 at 4:04 PM, Artem Barger  wrote:
>>
>> Hi,
>>>
>>> Current implementation of kmeans within CM framework, inherently uses
>>> algorithm published by  Arthur, David, and Sergei Vassilvitskii.
>>> "k-means++: The advantages of careful seeding." *Proceedings of the
>>> eighteenth annual ACM-SIAM symposium on Discrete algorithms*. Society for
>>> Industrial and Applied Mathematics, 2007. While there other alternative
>>> algorithms for initial seeding is available, for instance:
>>>
>>> 1. Random initialization (each center picked uniformly at random).
>>> 2. Canopy https://en.wikipedia.org/wiki/Canopy_clustering_algorithm
>>> 3. Bicriteria  Feldman, Dan, et al. "Bi-criteria linear-time
>>> approximations for generalized k-mean/median/center." *Proceedings of the
>>> twenty-third annual symposium on Computational geometry*. ACM, 2007.
>>>
>>> While I understand that kmeans++ is preferable option, others could be
>>> also used for testing, trials and evaluations as well.
>>>
>>> I'd like to propose to separate logic of seeding and clustering to
>>> increase flexibility for kmeans clustering. Would be glad to hear your
>>> comments, pros/cons or rejections...
>>>
>>>
>>> I've found "Scalable KMeans" or kmeans|| as referred in the
>> http://theory.stanford.edu/~sergei/papers/vldb12-kmpar.pdf, which
>> provides
>> parallelizable seeding procedure.
>> ​I guess this might serve as additional +1 vote for doing separation
>> between seeding and LLoyd's iterations in current implementations of
>> kmeans.
>>
>
> I guess that, around here, you are the expert about these algorithms...
>

​Thanks for providing me a credit, while I'm still not an expert :)
I'd say "have reasonable knowledge"...​

So go ahead and (re)write the code as you see fit, while still taking into
> account that the code should be self-documenting as much as possible.
> And OO (since this is Java).
>

​Will do my best.​


> If you are up for a major refactoring (e.g. for sparse data), I'd suggest
> to do it in a new package, so that we can easily compare the old and new
> codes (e.g. run the tests).
>

​I'm working on it, this is not as trivial as I initially though, described
several concerns
in other threads, one of them for example the usage of generic parameter​ T
and some
assumption which enforced by Clusterable interface.

And if you contemplate parallelization, I wonder whether the issue of
> switching to Java 8 might not have to be resolved first.
>

​I'm absolutely positive switching to Java 8, as I can see many benefits
both API and
performance ​

​wise. What it is the proper process to move for Java 8?


Best,
Artem Barger.​

Re: [Math] kmeans++: decouple EM LLoyd's iterations and initial seeding of clustering centers.

[Artem Barger]

​
On Tue, May 31, 2016 at 4:04 PM, Artem Barger  wrote:

> Hi,
>
> Current implementation of kmeans within CM framework, inherently uses
> algorithm published by  Arthur, David, and Sergei Vassilvitskii.
> "k-means++: The advantages of careful seeding." *Proceedings of the
> eighteenth annual ACM-SIAM symposium on Discrete algorithms*. Society for
> Industrial and Applied Mathematics, 2007. While there other alternative
> algorithms for initial seeding is available, for instance:
>
> 1. Random initialization (each center picked uniformly at random).
> 2. Canopy https://en.wikipedia.org/wiki/Canopy_clustering_algorithm
> 3. Bicriteria  Feldman, Dan, et al. "Bi-criteria linear-time
> approximations for generalized k-mean/median/center." *Proceedings of the
> twenty-third annual symposium on Computational geometry*. ACM, 2007.
>
> While I understand that kmeans++ is preferable option, others could be
> also used for testing, trials and evaluations as well.
>
> I'd like to propose to separate logic of seeding and clustering to
> increase flexibility for kmeans clustering. Would be glad to hear your
> comments, pros/cons or rejections...
>
>
I've found "Scalable KMeans" or kmeans|| as referred in the
http://theory.stanford.edu/~sergei/papers/vldb12-kmpar.pdf, which provides
parallelizable seeding procedure.
​I guess this might serve as additional +1 vote for doing separation
between seeding and LLoyd's iterations in current implementations of kmeans.

​Best,
Artem Barger.​

Re: [Math] Adding min/max and argmin/argmax values for an arrays of double/int (Comparable).

[Artem Barger]

Hi,


I've create a JIRA ticket MATH-1372 and attached a patch to it, also
submitted PR on GitHub: https://github.com/apache/commons-math/pull/36.

Best regards,
  Artem Barger.

On Tue, May 31, 2016 at 3:32 AM, Artem Barger  wrote:

>
> On Tue, May 31, 2016 at 3:17 AM, Gilles 
> wrote:
>
>> On Tue, 31 May 2016 02:58:27 +0300, Artem Barger wrote:
>>
>>> Methods "getMinValue()", "getMinIndex()".
>>>>
>>>> Important note: any contribution should be based on the contents of
>>>> the "develop" branch, not "master". See file
>>>>   doc/development/development.howto.txt
>>>> in the source tree.
>>>>
>>>>
>>>> ​So in order to use them I need to instantiate a RealVector, right?
>>>
>>
>> Yes.
>> And the iteration is probably not efficient since it use the
>> high-level API.
>>
>> Hence I think the question whenever to add static method w/
>>> similar functionality to MathArrays class is still valid, especially if
>>> I can enhance it to accept array or list of Comparables or to accept
>>> Comparator as an additional parameter​.
>>>
>>
>> Yes.
>> But perhaps a more general functionality would be useful.
>>
>
> ​General? Could you give an example?
> Aren't these​ enough?
>
> public static > T min(T...array);
>
> public static > T max(T...array);
>
> public static > int argmin(T...array);
>
> public static > int argmax(T...array);
>
>
>
>> Especially with the new Java 8 function types.
>>
>
> ​It's easy to implement having Java 8 function types, not sure I'm
> following you
> w/ how it could affect the API's of proposed methods.​
>
> I think I will submit a JIRA ticket w/ these and submit a patch, reviewing
> it we will
> be able to eventually come to some reasonable solution.
>
> Anyway ​if such functionality is already exist in "RealVector", I guess
>>>>
>>>>> there is no point of adding
>>>>> it to MathArrays, unless RealVector should be refactored and
>>>>> functionality
>>>>> should be removed from
>>>>> there.
>>>>>
>>>>>
>>>> Yes, refactored it should be:
>>>>  https://issues.apache.org/jira/browse/MATH-765
>>>>
>>>>
>>>> ​It says that these methods to be removed from RealVector.​
>>>
>>
>> A pity that what it says did not occur. :-}
>>
>
> ​:)))​
>
> ​Best,
>   Artem Barger.​
>
>

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

[Artem Barger]

On Tue, May 31, 2016 at 5:43 PM, Rob Tompkins  wrote:

> On May 31, 2016, at 10:21 AM, Matt Sicker  wrote:
> >
> > Why not just rename master to something like stable, then rename develop
> to
> > master? Less confusing to people who don't know about git-flow.
>
> Generally when I think about an arbitrary github project I would think
> that the “master” branch reflects the latest released code, and the
> “develop” branch should reflect the inflight development. Assuming that the
> history of the branches is properly maintained, a topic branch based in
> master should be able to be worked on and then PR’d into develop (assuming
> that the individual doing the work has accommodated for the merge conflicts
> in migrating it to develop).
>
> If the project is mirrored in git, then I would argue that the semantics
> of the version control system should be used as opposed to using our own
> semantics because then the arbitrary developer coming from another git
> project can quickly figure out how to work with the codebase.
> ​
>

​Well, IMO an average GutHub project usually uses a master branch as
ongoing branch for development and has "release" branch or even several
branches​ in case there are a couple of versions for release. Of course
working w/ feature branch for separate tasks merging/rebasing them later
into the master. But I think this is a matter of project policies and
agreements, important branches usually protected from accepting direct
commits into them.

BR,
- Artem.

Re: [Math] MATH-1371: Provide accelerated kmeans++ implementation

[Artem Barger]

On Tue, May 31, 2016 at 4:45 PM, Gilles 
wrote:

> Sorry, hit wrong key...
>
> On Tue, 31 May 2016 15:41:21 +0200, Gilles wrote:
>
>> On Tue, 31 May 2016 15:28:54 +0300, Artem Barger wrote:
>>
>>> Hi,
>>>
>>> Just finished the updated of the sources to address all comments from
>>> MATH-1371,
>>> attached updated sources.
>>>
>>> BTW, tried to commit feature branch directly to the remote, looks like I
>>> need a user or
>>> write access in order to being able to do it.
>>>
>>
>> Indeed, the Apache repositories are not world-writable. ;-)
>>
>>
> But you can paste the pull request command (not the "numbered"
> URL which I do not know how to handle) here or in a comment on
> JIRA.
>
>
​Are you refering to this?​

git fetch origin pull/*35*/head:

*feature-MATH-1371*

Anyway here is the link to PR itself

*: https://github.com/apache/commons-math/pull/35
<https://github.com/apache/commons-math/pull/35>*

Also please note that updated sources attached to JIRA tracker as well.


Best,

   Artem.





> Thanks,
> Gilles
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[Math] kmeans++: decouple EM LLoyd's iterations and initial seeding of clustering centers.

[Artem Barger]

Hi,

Current implementation of kmeans within CM framework, inherently uses
algorithm published by  Arthur, David, and Sergei Vassilvitskii.
"k-means++: The advantages of careful seeding." *Proceedings of the
eighteenth annual ACM-SIAM symposium on Discrete algorithms*. Society for
Industrial and Applied Mathematics, 2007. While there other alternative
algorithms for initial seeding is available, for instance:

1. Random initialization (each center picked uniformly at random).
2. Canopy https://en.wikipedia.org/wiki/Canopy_clustering_algorithm
3. Bicriteria  Feldman, Dan, et al. "Bi-criteria linear-time approximations
for generalized k-mean/median/center." *Proceedings of the twenty-third
annual symposium on Computational geometry*. ACM, 2007.

While I understand that kmeans++ is preferable option, others could be also
used for testing, trials and evaluations as well.

I'd like to propose to separate logic of seeding and clustering to increase
flexibility for kmeans clustering. Would be glad to hear your comments,
pros/cons or rejections...

​Thanks,
      Artem Barger.

Re: [math]: [MATH-1330] - KMeans clustering algorithm, doesn't support clustering of sparse input data.

[Artem Barger]

Hi,

I'm working on providing a solution for MATH-1330 and facing several design
related issues which I'd like to share, since I'd like my solution to fit
with the project road map and integrity. So, I'm looking on Clusterable
interface and looks like automatically impose the way internal
representation of data should look like, since getPoint() method signature
indirectly assumes that it has to be an array of doubles. And this might
not be a true for certain cases. IMO replacing of getPoint() with
getDistanceTo(Clusterable a) could be a better solution, since it doesn't
assumes anything about internal representation. From other side that means
what Clusterable instances need to be aware which DistanceMeasure
implementation used for clustering.

Therefore I'm not completely sure how to move on with it. Moreover suppose
I'll replace getPoint to return RealVector, then next issue will be to
decide how should I define/create cluster centers. Whenever do I need to
use sparse or dense implementation?

One of the possible solutions I'm thinking of is to decouple the process of
seeding the initial cluster centers and the Lloyd's iterations. That way I
can actually seed initial centers, provide them as a parameter into
clustering algorithm, which will move centers during the iteration instead
of creating each time new centroid instance. While it will work for center
based clustering algorithm that will not be the case for others, hence not
sure how I can fit this solution into the current design.

Any thoughts or suggestions?

BR,
Artem.

[Math] Is generic parameter T is really needed for KMeansPlusPlusClusterer.

[Artem Barger]

Hi,

I'm just wondering whenever generic parameter for class
KMeansPlusPlusClusterer is really needed? I mean, I do understand the
initial intent of declaring it and trying to provide generic solution,
however in really after all current implementation heavily relies on T
being actually a DoublePoint, since it required to provide an ability to
define new centers while running Lloyd's iteration.


Could it be better to remove T and change the declaration of the class from

*extends Clusterer *
into
*extends Clusterer*

to avoid confusions?

Best regards,
  Artem Barger.

Re: [Math] MATH-1371: Provide accelerated kmeans++ implementation

[Artem Barger]

Hi,

Just finished the updated of the sources to address all comments from
MATH-1371,
attached updated sources.

BTW, tried to commit feature branch directly to the remote, looks like I
need a user or
write access in order to being able to do it.

Best regards,
  Artem Barger.

Re: [Math] MATH-1371: Provide accelerated kmeans++ implementation

[Artem Barger]

On Tue, May 31, 2016 at 3:31 AM, Gilles 
wrote:

> On Tue, 31 May 2016 03:10:20 +0300, Artem Barger wrote:
>
>>
>>>
>>>>> ​Yes, you can parallelize it, though it will cancel several
>>>>> optimizations
>>>>>
>>>> I've added.
>>>> In fact you can partition the input according to number of threads you'd
>>>> like to use
>>>> and make each thread to take care of relevant data chunk.
>>>>
>>>> I guess it will increase performance, not sure why current
>>>> implementation
>>>> wasn't
>>>> parallelized.​
>>>>
>>>>
>>>> You are most welcome to enhance it. ;-)
>>>
>>>
>> Well, already did it ;-)
>> And if you mean to parallelize my current implementation for Elkan
>> algorithm,
>> I think that it should be handled as a separate task.​
>>
>>
> What I mean is that algorithms that can perform their computation
> on multiple threads should be implemented in such a way that the
> feature can be used.
>
> Of course, that means a more complex code, to ensure thread-safety.
> So, for sure, your code could be added now (modulo the remarks)
> if you don't want to handle that now.v And as you pointed out the
> other implementations are not multi-thread either.
>
> But it's a direction worth exploring I think.



​I totally agree w/ you, simply suggesting to go incremental, first to have
work done on
all comments provided, then having it committed and accepted I can
multi-threaded
support either.

Also I think that multi-threading support might impose some API changes and
should be
added carefully :)))​

Re: [Math] Adding min/max and argmin/argmax values for an arrays of double/int (Comparable).

[Artem Barger]

On Tue, May 31, 2016 at 3:17 AM, Gilles 
wrote:

> On Tue, 31 May 2016 02:58:27 +0300, Artem Barger wrote:
>
>> Methods "getMinValue()", "getMinIndex()".
>>>
>>> Important note: any contribution should be based on the contents of
>>> the "develop" branch, not "master". See file
>>>   doc/development/development.howto.txt
>>> in the source tree.
>>>
>>>
>>> ​So in order to use them I need to instantiate a RealVector, right?
>>
>
> Yes.
> And the iteration is probably not efficient since it use the
> high-level API.
>
> Hence I think the question whenever to add static method w/
>> similar functionality to MathArrays class is still valid, especially if
>> I can enhance it to accept array or list of Comparables or to accept
>> Comparator as an additional parameter​.
>>
>
> Yes.
> But perhaps a more general functionality would be useful.
>

​General? Could you give an example?
Aren't these​ enough?

public static > T min(T...array);

public static > T max(T...array);

public static > int argmin(T...array);

public static > int argmax(T...array);



> Especially with the new Java 8 function types.
>

​It's easy to implement having Java 8 function types, not sure I'm
following you
w/ how it could affect the API's of proposed methods.​

I think I will submit a JIRA ticket w/ these and submit a patch, reviewing
it we will
be able to eventually come to some reasonable solution.

Anyway ​if such functionality is already exist in "RealVector", I guess
>>>
>>>> there is no point of adding
>>>> it to MathArrays, unless RealVector should be refactored and
>>>> functionality
>>>> should be removed from
>>>> there.
>>>>
>>>>
>>> Yes, refactored it should be:
>>>  https://issues.apache.org/jira/browse/MATH-765
>>>
>>>
>>> ​It says that these methods to be removed from RealVector.​
>>
>
> A pity that what it says did not occur. :-}
>

​:)))​

​Best,
  Artem Barger.​

Re: [Math] MATH-1371: Provide accelerated kmeans++ implementation

[Artem Barger]

>
>>>
>>> ​Yes, you can parallelize it, though it will cancel several optimizations
>> I've added.
>> In fact you can partition the input according to number of threads you'd
>> like to use
>> and make each thread to take care of relevant data chunk.
>>
>> I guess it will increase performance, not sure why current implementation
>> wasn't
>> parallelized.​
>>
>>
> You are most welcome to enhance it. ;-)
>

Well, already did it ;-)
And if you mean to parallelize my current implementation for Elkan
algorithm,
I think that it should be handled as a separate task.​



>
> Gilles
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Adding min/max and argmin/argmax values for an arrays of double/int (Comparable).

[Artem Barger]

> Methods "getMinValue()", "getMinIndex()".
>
> Important note: any contribution should be based on the contents of
> the "develop" branch, not "master". See file
>   doc/development/development.howto.txt
> in the source tree.
>
>
​So in order to use them I need to instantiate a RealVector, right?
Hence I think the question whenever to add static method w/
similar functionality to MathArrays class is still valid, especially if
I can enhance it to accept array or list of Comparables or to accept
Comparator as an additional parameter​.



> Anyway ​if such functionality is already exist in "RealVector", I guess
>> there is no point of adding
>> it to MathArrays, unless RealVector should be refactored and functionality
>> should be removed from
>> there.
>>
>
> Yes, refactored it should be:
>  https://issues.apache.org/jira/browse/MATH-765
>
>
​It says that these methods to be removed from RealVector.​



> [Also, I think that the functionality which you proposed might be
> available or fairly easily achievable in Java 8.]
>
>
​What is the minimal Java version currently officially supported by CM​?
I just wondering in context of MATH-1371, since assuming it's Java 8 I can
add some more improvements.



>
> Gilles
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] MATH-1371: Provide accelerated kmeans++ implementation

[Artem Barger]

On Tue, May 31, 2016 at 2:20 AM, Gilles 
wrote:

> On Tue, 31 May 2016 01:28:48 +0300, Artem Barger wrote:
>
>> Hi,
>>
>> I've used out of the box current KMeansPlusPlusClusterer implementation
>> provided by CM, however saw that it doesn't scales well on large data
>> volumes. One of the proposals to improve current implementation was
>> submitted in JIRA-1330 is to provide support for sparse big data, i.e.
>> make
>> clustering algorithm to work w/ SparseVectors.
>>
>> While working on 1330, I've bumped into: Elkan, Charles. "Using the
>> triangle inequality to accelerate k-means." ICML. Vol. 3. 2003. paper
>> which
>> described additional possibility of scaling up performance of kmeans
>> algorithm. Method based on usage of triangle inequality to avoid
>> unnecessary distance computations cause by small movement of the cluster
>> center which doesn't affect assignment of given point to the cluster.
>>
>> Simply tests using PerfTestUtils shows that using Elkan's algorithm over
>> the standard provided currently in CM could achieve performance boost in
>> order of magnitude for significantly large inputs.
>>
>
> Impressive. :-)
>
> I've opened MATH-1371 "Provide accelerated kmeans++ implementation"
>> https://issues.apache.org/jira/browse/MATH-1371 and attached my
>> implementation there. Will be glad to receive review and comments about
>> it.
>>
>> I believe that switching to this algorithm instead of regular one could
>> improve quality of CM provided solution for kmeans.
>>
>
> Are these algorithms parallelizable?
> Wouldn't such an implementation increase performance even more?
>
>
​Yes, you can parallelize it, though it will cancel several optimizations
I've added.
In fact you can partition the input according to number of threads you'd
like to use
and make each thread to take care of relevant data chunk.

I guess it will increase performance, not sure why current implementation
wasn't
parallelized.​



> Regards,
> Gilles
>
>
>> Best regards,
>>   Artem Barger.
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Adding min/max and argmin/argmax values for an arrays of double/int (Comparable).

[Artem Barger]

Hi

On Tue, May 31, 2016 at 1:19 AM, Gilles 
wrote:

> Hi.
>
> On Tue, 31 May 2016 00:05:55 +0300, Artem Barger wrote:
>
>> Hi.
>>
>> Lately working w/ Apache Commons Math, library I've found myself
>> implementing functions which given an array of either doubles of integers
>> return the min or max value among all elements of an array. Moreover I've
>> added an argmin/argmin functions as well, which for given array of
>> double/int values return an index of min/max element within that array.
>>
>> Since I didn't find such functions available in the project, I'm willing
>> to
>> contribute these function into the framework and was curious whenever it's
>> usable? Also what should be the right place to put these functions? I've
>> added them as static method for MathArrays class, however not 100% sure
>> this is the right place.
>>
>> Think further about these functions, I can easily make them work w/
>> instances of Comparable interface of accept Comparator as second
>> parameter.
>>
>> What should be the right way to handle this?
>>
>
> It might be added to MathArrays indeed.
> Note that such a functionality is available in "RealVector".
>

​I might be looking on the wrong source tree, but I do not see it in
"RealVector".
Currently I'm using this repo: "
http://git-wip-us.apache.org/repos/asf/commons-math.git";
and looking on master branch.

Anyway ​if such functionality is already exist in "RealVector", I guess
there is no point of adding
it to MathArrays, unless RealVector should be refactored and functionality
should be removed from
there.



>
> Regards,
> Gilles
>
>
>
>> Best regards,
>>   Artem Barger.
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>