[Statistics] Convention when outside support?

Hello. For all implemented distributions, what convention should be adopted when methods * density(x) * logDensity(x) * cumulativeProbability(x) are called with "x" out of the "support" bounds? Currently some (but not all[1]) are documented to return "NaN". An alternative could be to throw an

[Geometry] Exceptions hierarchy

Hello. Is there any value added by "GeometryException" over the standard "ArithmeticException"? If not, I'd rather have the public API advertize the latter. We could have an *internal* utility class that instantiates exceptions: ---CUT--- public class ExceptionFactory { public

Re: [Geometry] Jenkins cleanup

Le sam. 23 nov. 2019 à 14:42, Gilles Sadowski a écrit : > > Hi. > > I proposed to delete this item on Jenkins: > https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry-fix/ > > Any objections? Deleted.

Re: [codec] No snapshots built automatically

Le jeu. 28 nov. 2019 à 12:48, Alex Herbert a écrit : > > > On 23/11/2019 14:00, Gilles Sadowski wrote: > > Sorry, I had understood that there was no Jenkins project. > > I've just created a "commons-codec-test" (to avoid breaking anything); > > it seems tha

Re: [VOTE] Release Apache Commons Skin 4.2 based on RC2

Le lun. 25 nov. 2019 à 11:17, Alex Herbert a écrit : > > > On 25/11/2019 10:02, Gilles Sadowski wrote: > > Hello. > > > > Le sam. 23 nov. 2019 à 09:49, Alex Herbert a > > écrit : > >> Thanks Bruno. > >> > >> Can I get a

Re: [VOTE] Release Apache Commons Skin 4.2 based on RC2

Hello. Le sam. 23 nov. 2019 à 09:49, Alex Herbert a écrit : > > Thanks Bruno. > > Can I get a review from anyone else? I've just updated http://commons.apache.org/proper/commons-geometry/ using your instructions. Looks fine. Regards, Gilles > [...]

Re: [codec] No snapshots built automatically

Hello. >> [...] > >> But I cannot see where to configure it, or if I have permissions to > >> do so. > > > > Are you logged in? > > I can log in. But I cannot see any options that would indicate that I have > admin rights. When I log in, what changes is the number of options in the (left) menu.

Re: [codec] No snapshots built automatically

2019-11-23 14:39 UTC+01:00, Alex Herbert : > > >> On 23 Nov 2019, at 12:20, Gilles Sadowski wrote: >> >> 2019-11-23 13:15 UTC+01:00, Alex Herbert : >>> Codec is absent from the snapshots repo [1]. >>> >>> How are snapshots usually performed? I

[Geometry] Jenkins cleanup

Hi. I proposed to delete this item on Jenkins: https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry-fix/ Any objections? Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For

Re: [codec] No snapshots built automatically

2019-11-23 13:15 UTC+01:00, Alex Herbert : > Codec is absent from the snapshots repo [1]. > > How are snapshots usually performed? Is this something to set up on the > Jenkins build with INFRA? No; you can create a Jenkins project there: https://builds.apache.org/view/A-D/view/Commons/ (e.g.

Re: [geometry] Spherical Barycenters

Hello. Le sam. 16 nov. 2019 à 05:40, Matt Juntunen a écrit : > > Gilles, > > The old commons-math code produces the same results. :-( > So, I'm not sure if this is a bug or a known limitation. There isn't any > documentation in the old code in regard to the barycenter computation and > there

Re: [geometry] Spherical Barycenters

Hello. Le ven. 15 nov. 2019 à 15:34, Matt Juntunen a écrit : > > Hi all, > > I'm attempting to wrap up the refactoring work I've been doing with > GEOMETRY-32 but I've hit a snag with the code for computing barycenters in 2D > spherical space. The results I'm getting seem mostly reasonable but

Re: [RNG] Site layout for modular components (Was: Release [...] RNG [...])

Hi. Le jeu. 14 nov. 2019 à 13:12, Alex Herbert a écrit : > > > On 14/11/2019 01:39, Gilles Sadowski wrote: > > 2019-11-14 1:35 UTC+01:00, Alex Herbert : > >> > >>> On 13 Nov 2019, at 23:53, Gilles Sadowski wrote: > >>> > >>> H

Re: [RNG] Site layout for modular components (Was: Release [...] RNG [...])

2019-11-14 1:35 UTC+01:00, Alex Herbert : > > >> On 13 Nov 2019, at 23:53, Gilles Sadowski wrote: >> >> Hello. >> >> Le mer. 13 nov. 2019 à 18:29, Alex Herbert > <mailto:alex.d.herb...@gmail.com>> a écrit : >>> >>> >>>

Re: [RNG] Site layout for modular components (Was: Release [...] RNG [...])

Hello. Le mer. 13 nov. 2019 à 18:29, Alex Herbert a écrit : > > > On 13/11/2019 13:09, Gilles Sadowski wrote: > > Hi. > > > > Do you think that it would be feasible to have all those fixes applied > > to other modular components (that were based on the [RNG] l

Re: [ALL] Updates to commons-parent and commons-skin

Le mer. 13 nov. 2019 à 17:03, sebb a écrit : > > On Wed, 13 Nov 2019 at 15:12, Gilles Sadowski wrote: > > > Le mer. 13 nov. 2019 à 15:52, sebb a écrit : > > > > > > On Wed, 13 Nov 2019 at 14:38, Gilles Sadowski > > wrote: > > > > > > &g

Re: [ALL] Updates to commons-parent and commons-skin

Le mer. 13 nov. 2019 à 15:52, sebb a écrit : > > On Wed, 13 Nov 2019 at 14:38, Gilles Sadowski wrote: > > > Hello. > > > > Le mer. 13 nov. 2019 à 14:49, sebb a écrit : > > > > > > +1 for CP > > > > > > CP versions are entirely opt

Re: [ALL] Updates to commons-parent and commons-skin

Hello. Le mer. 13 nov. 2019 à 14:49, sebb a écrit : > > +1 for CP > > CP versions are entirely optional; Not "entirely". [We already had this discussion.] It happened that a fix for was available in a newer CP but that in CP broke some components (e.g. when CP functionality is "enhanced"

[RNG] Site layout for modular components (Was: Release [...] RNG [...])

Hi. Do you think that it would be feasible to have all those fixes applied to other modular components (that were based on the [RNG] layout) through a common layer (another POM) between those components and "commons-parent"? Regards, Gilles Le mer. 13 nov. 2019 à 12:53, Alex Herbert a écrit :

Re: [VOTE] Release Apache Commons RNG 1.3 based on RC1

Hello. Le mar. 12 nov. 2019 à 17:41, Alex Herbert a écrit : > > > > > On 12 Nov 2019, at 15:39, Gilles Sadowski wrote: > > > > Hello Alex. > > > > Le mar. 12 nov. 2019 à 16:15, Alex Herbert > <mailto:alex.d.herb...@gmail.com>> a écrit : > &

Re: [VOTE] Release Apache Commons RNG 1.3 based on RC1

Hello Alex. Le mar. 12 nov. 2019 à 16:15, Alex Herbert a écrit : > > > On 12/11/2019 09:06, Gilles Sadowski wrote: > > 2019-11-12 2:28 UTC+01:00, Alex Herbert : > >> > >>> On 11 Nov 2019, at 23:40, Gilles Sadowski wrote: > >>> > >>&

Re: [VOTE] Release Apache Commons RNG 1.3 based on RC1

2019-11-12 2:28 UTC+01:00, Alex Herbert : > > >> On 11 Nov 2019, at 23:40, Gilles Sadowski wrote: >> >> Hi. >> >> Maybe I'm missing what the issues really are, > > All empty japicmp reports on the site. > Some confusing empty Jacoco aggregate reports

Re: [VOTE] Release Apache Commons RNG 1.3 based on RC1

the versions; quite the contrary, users are always (kindly) requested to upgrade to the last version of a component (and IIUC, we are asked that older versions are made more difficult to access and download). Regards, Gilles 2019-11-11 23:05 UTC+01:00, Alex Herbert : > > >&

Re: [VOTE] Release Apache Commons RNG 1.3 based on RC1

> > [...] > > > > I will try and find out why these are running and just remove them. > > The pom requires this to skip aggregate reports [2]: > > > org.jacoco > jacoco-maven-plugin > > > > >report >

Re: [VOTE] Release Apache Commons RNG 1.3 based on RC1

Hello. > [...] > > This may have always been the case. Yes. Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers] Arrays of "Complex" objects and RAM

Le dim. 10 nov. 2019 à 00:33, Alex Herbert a écrit : > > > > > On 9 Nov 2019, at 18:10, Alex Herbert wrote: > > > > > > > >> On 9 Nov 2019, at 12:23, Gilles Sadowski >> <mailto:gillese...@gmail.com>> wrote: > >> > >>>

Re: [Numbers] Arrays of "Complex" objects and RAM

Hello Alex. >>> [...] >>> I think at least the minimum implementation of the abstraction will be >>> fairly easy. It can then be performance checked with a few variants. >>> >>> There currently is not a JMH module for numbers. Should I create one >>> under a module included with an optional

Re: [Numbers] Arrays of "Complex" objects and RAM

Hi. Le sam. 9 nov. 2019 à 01:48, Alex Herbert a écrit : > > > > > On 7 Nov 2019, at 23:29, Eric Barnhill wrote: > > > > On Thu, Nov 7, 2019 at 3:25 PM Gilles Sadowski wrote: > > > >> Le jeu. 7 nov. 2019 à 18:36, Eric Barnhill a > >> écrit :

Re: [commons-numbers] branch master updated: Fix Javadoc using tags.

Hi. Le sam. 9 nov. 2019 à 00:18, Alex Herbert a écrit : > > > > > On 8 Nov 2019, at 22:57, Gilles Sadowski wrote: > > > > Hi. > > > >> [...] > >> > >> commit 7b1b38167c9241462cd08578a37d63d5cd9b7a04 > >> Author: Alex Herbert

Re: [commons-numbers] branch master updated: Fix Javadoc using tags.

Hi. > [...] > > commit 7b1b38167c9241462cd08578a37d63d5cd9b7a04 > Author: Alex Herbert > AuthorDate: Fri Nov 8 20:28:15 2019 + > > Fix Javadoc using tags. IMO, the below should rather use MathJax. Regards, Gilles > --- > .../main/java/org/apache/commons/numbers/complex/Complex.java

Re: [Numbers] Arrays of "Complex" objects and RAM

t; abstraction, including accessors that shape the data for use with e.g. JTransforms? Regards, Gilles > On Thu, Nov 7, 2019 at 9:34 AM Eric Barnhill wrote: > > > > > > > On Thu, Nov 7, 2019 at 6:09 AM Gilles Sadowski > > wrote: > > > >> > &g

Re: [Numbers] Arrays of "Complex" objects and RAM

> [...] > >>> > >>> public class ComplexArray { > >>> private final MultidimensionalCounter counter; > >>> // ... > >>> > >>> public ComplexArray(int... dimensions) { > >>> counter = new MultidimensionalCounter(dimensions); > >>> data = new data[counter.getSize()];

Re: [numbers] Bug in complex multiply + divide + isNaN

Le jeu. 7 nov. 2019 à 12:59, Alex Herbert a écrit : > > > On 07/11/2019 11:45, Gilles Sadowski wrote: > > Hello. > > > >>> [...] > >>> > >>>> Also looking at Complex it would benefit from: > >>>> > >>>>

Re: [numbers] Bug in complex multiply + divide + isNaN

Hello. > > [...] > > > >> > >> Also looking at Complex it would benefit from: > >> > >>public Complex subtractFrom(double minuend) { > >>return new Complex(minuend - real, imaginary); > >>} > > > > Is it part of the "standard"? > > IMHO, it's fairly confusing, as nothing in the

Re: [numbers] Bug in complex multiply + divide + isNaN

Hi. Le jeu. 7 nov. 2019 à 01:48, Alex Herbert a écrit : > > > > > On 7 Nov 2019, at 00:34, Gilles Sadowski wrote: > > > > 2019-11-07 1:03 UTC+01:00, Alex Herbert > <mailto:alex.d.herb...@gmail.com>>: > >> > >> > >>> On 6

Re: [numbers] Bug in complex multiply + divide + isNaN

to fixing checkstyle and PMD. > > Then I’ll fix Complex. OK. Regards, Gilles > >> >> On Wed, Nov 6, 2019 at 2:38 PM Alex Herbert >> wrote: >> >>> >>> >>>> On 6 Nov 2019, at 18:17, Gilles Sadowski wrote: >>>> >&g

Re: [numbers] Bug in complex multiply + divide + isNaN

2019-11-06 23:38 UTC+01:00, Alex Herbert : > > >> On 6 Nov 2019, at 18:17, Gilles Sadowski wrote: >> >>> [...] >>> >>> >>> Any objections to updating multiply/divide/isNaN to match the standard? >> >> Let me think... ;-) > >

Re: [numbers] Bug in complex multiply + divide + isNaN

> [...] > > > Any objections to updating multiply/divide/isNaN to match the standard? Let me think... ;-) > > I'll add unit tests to hit the edge cases that should fail with the > current implementation. Thanks, Gilles > > > [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf > > [2]

Re: [Numbers] Arrays of "Complex" objects and RAM

Hi. >>> [...] > > > > public class ComplexArray { > > private final MultidimensionalCounter counter; > > // ... > > > > public ComplexArray(int... dimensions) { > > counter = new MultidimensionalCounter(dimensions); > > data = new data[counter.getSize()]; > >

Re: [Numbers] Arrays of "Complex" objects and RAM

ply(Complex::conjugate); > > This allows a user to pass a function that can do anything to the > current data to create new real and imaginary components which are > stored in a new array object. I do not know how this would effect > performance without a full comparison of the API implemente

Re: [VOTE] Release Apache Commons RNG 1.3 based on RC1

Hi. Le mar. 5 nov. 2019 à 17:36, Alex Herbert a écrit : > > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons RNG 1.2 was released, so I would like to release > Apache Commons RNG 1.3. > > Apache Commons RNG 1.3 RC1 is available for review here: >

Re: [commons-rng] branch master updated: Jira report to contain 'Implemented' resolution.

Hi Alex. Le mar. 5 nov. 2019 à 13:54, a écrit : > > This is an automated email from the ASF dual-hosted git repository. > > aherbert pushed a commit to branch master > in repository https://gitbox.apache.org/repos/asf/commons-rng.git > > > The following commit(s) were added to refs/heads/master

Re: [commons-rng] annotated tag RNG_1_3_RC2 created (now a670c77)

Hi. What happened to RC1? Regards, Gilles Le mar. 5 nov. 2019 à 11:52, a écrit : > > This is an automated email from the ASF dual-hosted git repository. > > aherbert pushed a change to annotated tag RNG_1_3_RC2 > in repository https://gitbox.apache.org/repos/asf/commons-rng.git. > > > at

Re: [rng] Releasing 1.3

Hello. Le lun. 4 nov. 2019 à 13:05, Alex Herbert a écrit : > > > On 04/11/2019 00:42, Gilles Sadowski wrote: > > Hi. > > > >> [...] > >> > >> So there are at least two options: > >> > >> 1. Release using JDK 9 > > +1 >

Re: [rng] Releasing 1.3

Hi. > [...] > > So there are at least two options: > > 1. Release using JDK 9 +1 > 2. Update the examples project to use source 11 for the Java modules code and > release using a non-oracle JDK 11 > > Note that updating to use source 11 will break the Jenkins build which uses > JDK 9 to run a

[Numbers] Arrays of "Complex" objects and RAM

Hello. The class "ComplexUtils" deal with multi-dimensional arrays that hold instances of the "Complex" class. I've recently encountered a use-case where it was pointed out that storing many "Complex" instances (as seems the purpose of these utilities) is quite inefficient memory-wise as each

Re: [lang] immutable BitSet

Hello. 2019-10-29 0:16 UTC+01:00, Claude Warren : > Having "ImmutableBitSet" inherit from "BitSet" breaks the latter's > contract. >> >> > no more Yes, more, AFAICT... > so than the ImmutableSet breaks the Set contract. ... because "Set" is an interface whose contract explicitly mentions some

Re: [statistics-regression] Proposed Regression class/method structure

Hi Eric. 2019-10-28 18:55 UTC+01:00, Eric Barnhill : > Here is a schematic for how the interface might be made more abstract. > > https://imgur.com/a/izx5Xkh This cannot be downloaded. Please attach the image to a JIRA issue. Regards, Gilles > > In this case, we may want to just implement the

Re: [statistics-regression] Proposed Regression class/method structure

Hi. 2019-10-28 22:12 UTC+01:00, Alex Herbert : > > >> On 28 Oct 2019, at 17:55, Eric Barnhill wrote: >> >> Here is a schematic for how the interface might be made more abstract. >> >> https://imgur.com/a/izx5Xkh > > Regression and RegressionResults both have a

Re: [lang] immutable BitSet

Hi. 2019-10-28 20:38 UTC+01:00, Xeno Amess : > Then all ImmutableBitSet instance are instance of a mutable BitSet class > when we use instance of. > I just worry that could be kind of misleading sometimes. > I agree with that remark. Having "ImmutableBitSet" inherit from "BitSet" breaks the

[Numbers][Math] FieldSquareMatrix

Hello. I think I'll revert the commit in [Numbers] that introduced this feature: https://issues.apache.org/jira/projects/NUMBERS/issues/NUMBERS-138 and move to [Math]. Rationale: 1. At the moment, only use-cases are in [Math]. 2. Matrix functionality probably belongs there (or in a new

[RNG] LGTM analysis (Was: [...] branch master updated: Badge.)

che/commons/rng/simple/internal/Long2IntArray.java > [...] > > commit 5461d28594d006365b20a4748957656208c3a599 > Author: Gilles Sadowski > AuthorDate: Thu Oct 24 17:08:08 2019 +0200 > > Badge. > [...] - To unsubscribe,

Re: [statistics-regression] Proposed Regression class/method structure

Hello. Le mar. 22 oct. 2019 à 21:50, Eric Barnhill a écrit : > > I propose the following class structure for commons-statistics-regression. Which? [Attachment was probably stripped: such should go to a JIRA report.] > The interface carried over from commons-math is more of an academic approach

Re: [commons-math] 02/05: Upgrade to "Commons RNG" (v1.2).

/commons-math.git >> >> commit f8c031ee3810721e99534a1c111f567c3ec6ceb7 >> Author: Gilles Sadowski >> AuthorDate: Tue Oct 22 13:49:45 2019 +0200 >> >> Upgrade to "Commons RNG" (v1.2). >> >> Seed had to be modified in class "

Re: [collections] BloomFilter package architecture discussion

m (the concatenation of which is the > > entire set of bits). > > > > I think that most implementations will have some internal structure that > > can generate the above. The wider the item in the stream the faster we can > > move the bits, the better the average performance wil

Re: [collections] BloomFilter package architecture discussion

Hello. 2019-10-19 16:20 UTC+02:00, Claude Warren : > On Fri, Oct 18, 2019 at 3:22 PM Gilles Sadowski > wrote: > >> Hi. >> >> >>> [...] >> > > >> > > Maybe I was not clear enough: I'm not saying that we should prefer >> >

Re: [collections] Bloom filter - Discussion of Shape

Hi. Le ven. 18 oct. 2019 à 17:55, Claude Warren a écrit : > > I think the other discussion is getting a bit long so I thought we could > start this discussion here and see if we can close out the other discussion > with agreement on the remaining topics. > > The “Shape” of a bloom filter

Re: [All] Using "SemVer"?

Hi. Le ven. 18 oct. 2019 à 14:31, Stefan Bodewig a écrit : > > On 2019-10-18, Gilles Sadowski wrote: > > > In another thread, the question was asked whether "Commons" > > follows "SemVer".[1] > > It seems to me that we (informally) abide by the

Re: [collections] BloomFilter package architecture discussion

Hi. >>> [...] > > > > Maybe I was not clear enough: I'm not saying that we should prefer > > some representation (of the state) over another; only that the how > > the state is represented externally need not be the same as the internal > > representation. > > > > But if the state is fully

[All] Using "SemVer"?

Hello. In another thread, the question was asked whether "Commons" follows "SemVer".[1] It seems to me that we (informally) abide by the intended goal. Why not state it explicitly (and make it a formal requirement for a release)? Regards, Gilles [1] https://semver.org/

Re: [collections] BloomFilter package architecture discussion

Hi. 2019-10-15 20:05 UTC+02:00, Claude Warren : > On Tue, Oct 15, 2019 at 1:46 AM Gilles Sadowski > wrote: > >> Hello. >> >> >> >> > Furthermore, >> > the other potential users and supporters have not responded to any >> > communi

Re: [collections] BloomFilter package architecture discussion

Hello. Le lun. 14 oct. 2019 à 14:12, Claude Warren a écrit : > > Greetings, > > > I feel like I have been beating my head against a wall trying to get this > contribution accepted; In my experience, a "wall" would be a plain refusal (or no answer and nobody applying the patch). We are far from

[RNG] Utility for displaying progress (Was: [...] estimate for stress test tasks)

Hello Alex. > [...] > > commit 7177cdc82fd5020442f833ea8947151366dec725 > Author: Alex Herbert > AuthorDate: Mon Oct 14 21:26:48 2019 +0100 > > Better time estimate for stress test tasks. > --- > .../rng/examples/stress/StressTestCommand.java | 35 > ++ > 1 file

Re: [collections] BloomFilter or BitSet functions?

t contribution that would be > > > > int Func.hammingDistance( BitSet one, BitSet two) > > > > The more I think about it the more I think that the BitSet functionality > > should wait until someone wants it. Right now I can proceed without it and > > provide the s

Re: [rng] BigCrush results

Hello. Le ven. 11 oct. 2019 à 15:54, Alex Herbert a écrit : > > > On 07/10/2019 15:00, Gilles Sadowski wrote: > > Hi. > > > > Le lun. 7 oct. 2019 à 15:54, Alex Herbert a > > écrit : > >> I have found a bug in the stress test application

Re: [collections] BloomFilter or BitSet functions?

Hello. Le lun. 7 oct. 2019 à 19:42, Claude Warren a écrit : > > As noted earlier I am preparing a contribution of Bloom Filter classes to > the collections module. As part of this submission there are several > methods that operate on BitSets that are used as part of Bloom Filter >

Re: [collections] ProtoBloomFilter.Builder -- opinions sought

Hi. Le lun. 7 oct. 2019 à 19:01, Claude Warren a écrit : > > Greetings, > > I am preparing a pull request to bring Bloom Filters in the the > collections package. The pull requests is at > https://github.com/apache/commons-collections/pull/83 and the Jira ticket > is

Re: [rng] BigCrush results

Hi. Le lun. 7 oct. 2019 à 15:54, Alex Herbert a écrit : > > I have found a bug in the stress test application that affects all the > BigCrush results. > > This was found when updating the stress test application to support > 64-bit testing within PractRand, and testing of upper and lower 32-bits

Re: [rng] Refactor JMH examples project

2019-09-30 22:48 UTC+02:00, Alex Herbert : > The JMH examples project contains an increasing number of benchmarks. I > suggest a simple refactor to packages that follow the package names of the > four components to which the benchmarks apply. > > Currently there is: > >

Re: Assignment of issue.

Hi. Le jeu. 26 sept. 2019 à 13:54, Shoaib Anwar a écrit : > > Hello, > > I plan on fixing the following open issue, as listed on Jira by with the > following ticket: > https://issues.apache.org/jira/browse/LANG-1488 Thanks for the offer; however, the latest comments seem to indicate that there

Re: New Sub-project Proposal.

> On Wed, Sep 25, 2019 at 5:42 PM Gilles Sadowski > wrote: > >> Hi. >> >> Is there a JIRA report associated with the proposal? >> >> It would help review if there were several PRs that >> differentiates between "core" functionality ("BloomF

Re: New Sub-project Proposal.

Hi. Is there a JIRA report associated with the proposal? It would help review if there were several PRs that differentiates between "core" functionality ("BloomFilter"), with minimal API (vs "syntactic sugar"), and higher-level utilities ("FilterConfiguration", "GatedCollection", etc.).

Re: [rng] Documenting JumpableUniformRandomProvider

Hi. Le lun. 23 sept. 2019 à 22:38, Alex Herbert a écrit : >>> [...] > > > isLongJumpable() > > isJumpable() > > I’ve put these methods into a PR for RNG-116 [1]. > > I’ve also added: > > public int getSeedByteSize() > > However I note that the RandomSource has factory methods to create int[] and

Re: New Sub-project Proposal.

om/browse/proto?s=t > > On Mon, Sep 23, 2019 at 11:13 AM Claude Warren wrote: > > > For the style issues.... is there an Eclipse style package that meets the > > commons style or some other tool that will correctly configure the format > > and style options in Eclipse? > > > &g

Re: Advice on project logo

gt; >>> > >>> On Mon, Sep 9, 2019, 6:03 PM Rob Tompkins >>> <mailto:chtom...@gmail.com>> wrote: > >>> Sure I’d be happy to talk at some time tomorrow. Let me know when you’re > >>> free. I’ll likely be in the hackathon room for a goo

Re: New Sub-project Proposal.

Hello. Here are a few comment from a quick browse of today's update of PR #83. * "package private for testing" is not a good reason (IMO) * There are spurious blank spaces in some of the file ("git diff" shows them in red) * You should always perform "git rebase master" * In "Builder": ** Field

Re: [rng] Documenting JumpableUniformRandomProvider

Hello. [...] > >>> > > 2. Add a method BitSet getSupport() to the RandomSource enum, where T > is an enum that can be expanded as more features are added. Initially is > would be: > >>> > >>> +1 > >>> With "EnumSet", I guess. > >> > >> Yes. > >> > >>> > > enum

Re: [rng] Documenting JumpableUniformRandomProvider

Hi. 2019-09-21 9:53 UTC+02:00, Alex Herbert : > > >> On 21 Sep 2019, at 00:17, Gilles Sadowski wrote: >> >> Hello. >> >> 2019-09-20 18:45 UTC+02:00, Alex Herbert > <mailto:alex.d.herb...@gmail.com>>: >>> I have added some new sectio

Re: [rng] Documenting JumpableUniformRandomProvider

Hello. 2019-09-20 18:45 UTC+02:00, Alex Herbert : > I have added some new sections to the user guide for new additions to > the library. > > Currently the section on JumpableUniformRandomProvider gives an example: > > RandomSource source = RandomSource.XO_RO_SHI_RO_128_SS; // Known to be >

Re: [math] Preparing for v3.6.2 release

Hi. Le lun. 16 sept. 2019 à 19:26, Gary Gregory a écrit : > > Note that right now, builds like 'mvn clean site' in git master fail > because of Checkstyle violations: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on > project

Re: Advice on project logo

s an idea from which to work. I had no intentions of >> suggesting that we vote on it or even use is as I think that there are >> spacing and font issues with it. I thought that my email with the mock-up >> made it clear that it was a rough pass. >> >> -Rob >> >> > O

Re: Advice on project logo

thread); please comment. Gilles > > On Sun, 15 Sep 2019 at 21:13, Gilles Sadowski wrote: > > > > Could we please use *one* (and the original) thread to collect ideas? > > > > Gilles > > > > Le dim. 15 sept. 2019 à 19:47, Rob Tompkins a écrit : > >

Re: New Sub-project Proposal.

.with("Warren") .with("brown"). .with("silver"); BloomFilter filter1 = proto.create(config1); BloomFilter filter2 = proto.create(config2); IIUC, in your current implementation of "ProtoBloomFilter", there is a side-effect of "bu

Re: Advice on project logo

ommons > >>> logo but one for each component and be done. The even simpler path is to > >>> forgo component specific logos, especially since Commons is just one > >>> Apache > >>> project. I like simpler... > >>> > >>&g

Re: [RNG] Duplicated blocks?

>>> [...] > > Could you check that you can declare issues as "solved”? > > I can sign in with GitHub and it links my Apache credentials. This allows me > to comment on issues and ‘confirm’ them which I could not do when not logged > in. > > However I do not see options to mark false positives

Re: [RNG] Duplicated blocks?

Hi. Le ven. 13 sept. 2019 à 22:34, Alex Herbert a écrit : > > > > > On 13 Sep 2019, at 15:27, Gilles Sadowski wrote: > > > > Hello. > > > > SonarQube reports "duplicated blocks": > > > > https://sonarcloud.io/component_measures

[RNG] Duplicated blocks?

Hello. SonarQube reports "duplicated blocks": https://sonarcloud.io/component_measures?id=commons-rng=duplicated_blocks=list Does it report about the license header? If so, how to deactivate that spurious report? Regards, Gilles

Re: New Sub-project Proposal.

> > [...] > > Gilles, > > Take a look at the PR, I added comments to allow the PR to have 0 deps. > > Gary > > IMO, the package should be named "bloomfilter" (without "s"). Naming seems inconsistent in [Collections]: Some (package) names are singular, other plural. * Indent must be 4 spaces. *

Re: New Sub-project Proposal.

Hi. > > [...] > > > > Gilles, > > Take a look at the PR, I added comments to allow the PR to have 0 deps. How about creating a branch on the Apache repository, so that we can commit examples of what needs to be modified in order to comply with the project's style and requirements? Gilles

Re: New Sub-project Proposal.

Le jeu. 12 sept. 2019 à 20:28, Gary Gregory a écrit : > > On Thu, Sep 12, 2019 at 11:42 AM Gilles Sadowski > wrote: > > > Le jeu. 12 sept. 2019 à 17:32, Claude Warren a écrit : > > > > > > The base code depended on commons-lang3 for building hashes. Is this

Re: New Sub-project Proposal.

Le jeu. 12 sept. 2019 à 17:15, Claude Warren a écrit : > > @Gilles > > Missed your suggestion about modularity. Can you point me to the original > message or paraphrase it here? https://markmail.org/message/4bibv2zsibmtyrsg Gilles >> [...]

Re: New Sub-project Proposal.

ularity. Can you point me to the original > > message or paraphrase it here? > > > > Claude > > > > On Thu, Sep 12, 2019 at 11:03 AM Gilles Sadowski > > wrote: > > > >> Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes a > >> écrit : > >>

Re: New Sub-project Proposal.

; > > @Gilles > > > > Missed your suggestion about modularity. Can you point me to the original > > message or paraphrase it here? > > > > Claude > > > > On Thu, Sep 12, 2019 at 11:03 AM Gilles Sadowski > > wrote: > > > > > Le jeu.

Re: New Sub-project Proposal.

Le jeu. 12 sept. 2019 à 10:28, Stian Soiland-Reyes a écrit : > > On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren wrote: > > Actually the code I was thinking of is the multi-filter branch. It cleans > > up some names and simplifies a few things. The collections and storage > > packages might

Re: New Sub-project Proposal.

Hi. Le mer. 11 sept. 2019 à 17:06, Claude Warren a écrit : > > [...] > > The long and short of this is that there is no good unencumbered open > source library available at the current time. Myself and several others, > in conversation here at ApacheCon, have expressed interest in creating such

Re: [CONFIGURATION] Formatting braces

Hello. +1 Le mer. 11 sept. 2019 à 15:54, Gary Gregory a écrit : > > Hi All: > > I only hope that this will not turn into a bike shedding thread... A uniform coding style (for all components); that *seems* obvious (too)... Gilles > > Commons Configuration is one of the few components we have

Re: Advice on project logo

ell as development management). Regards, Gilles > > Gary > > On Mon, Sep 9, 2019, 15:08 Rob Tompkins wrote: > > > > > > > > On Sep 9, 2019, at 11:31 AM, Gilles Sadowski > > wrote: > > > > > > Hi. > > > > > > Le lun. 9 sept

Re: Advice on project logo

unity can converge on a few ideas to help with the design. Best regards, Gilles > > Best, > Sally > > - - - > Vice President Marketing & Publicity > Vice President Sponsor Relations > The Apache Software Foundation > > Tel +1 617 921 8656 | s...@apache.org > &

Re: Updating the logo

Hello. It occurred to me that if the community wants to KISS, the Commons logo could be something like / / Apache / Commons / [The slanted line is the feather. Colors, fonts, sizes variants to be proposed by "Central Services"...] A simple variation for a component that

Re: Advice on project logo

che.org/proper/commons-rng/ [5] Lacking feedback, I opted for an upgrade of the feather using the foundation's new graphics keeping the old (and supposedly consensual) idea for the feather orientation. [6] Even though it's great that Loic Guibert was willing to provide idea and a few examples. > >

<    5   6   7   8   9   10   11   12   13   14   >