Le mer. 5 juin 2019 à 23:14, sebb a écrit :
>
> On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski wrote:
> >
> > Le mer. 5 juin 2019 à 17:57, James Carman a
> > écrit :
> > >
> > > I’m having a hard time understanding the comparing APIs use case. If I
izes the creation is faster
>
> - For large array sizes built using an int/long the creation is
> marginally slower (but the seed should be better as it uses the SplitMix
> algorithm rather than the self-seeding strategy of the BaseProvider [3])
Where is it done?
>
> Caching t
[If it's not easy[1], they won't do it.]
Regards,
Gilles
[1] Like: You "just" have to install "git", check out the source, install
"maven", run the "package" goal, then move the "target/whatever.jar"
file to where your code will look for it.
>
&
Le mer. 5 juin 2019 à 17:04, James Carman a écrit :
>
> What sort of comparison are you looking to do within the same code?
> Performance?
Yes, that's one possibility; another is comparing different APIs
.Foo".
But those 2 classes can very well be different and incompatible.
However, we can consider that after the release of "1.0", all
"1.0-alphaX" releases are obsolete and serve zero purpose.
The beta releases are "comparable" only within the same base
(unreleased) ve
Le mer. 5 juin 2019 à 16:47, James Carman a écrit :
>
> Ok, what about 1.2?
How is it different?
Gilles
>
> On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski
> wrote:
>
> > Le mer. 5 juin 2019 à 16:18, James Carman a
> > écrit :
> > >
> > > What
Le mer. 5 juin 2019 à 16:22, sebb a écrit :
>
> On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski wrote:
> >
> > Le mer. 5 juin 2019 à 15:59, sebb a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote:
> > > >
&g
Le mer. 5 juin 2019 à 16:18, James Carman a écrit :
>
> What happens if/when you want to release a 2.0-alpha1 in the future?
Hmm, what happens?
[At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
Gilles
>
> On Tue, Jun 4, 2019 at 6:53 A
Le mer. 5 juin 2019 à 16:18, Gary Gregory a écrit :
>
> On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski
> wrote:
>
> > Le mer. 5 juin 2019 à 15:59, sebb a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski
> > wrote:
> > > &
Le mer. 5 juin 2019 à 16:04, Gary Gregory a écrit :
>
> On Wed, Jun 5, 2019 at 9:59 AM sebb wrote:
>
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb a écrit :
> > > >
> > &g
Le mer. 5 juin 2019 à 15:59, sebb a écrit :
>
> On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote:
> >
> > Le mer. 5 juin 2019 à 15:18, sebb a écrit :
> > >
> > > I'm not sure what problem this is trying to solve.
> > >
> > > H
the
toplevel package name
o.a.c.somecomp
to
o.a.c.somecomp.alpha1
And, if the upcoming version is, say, "2.3", the generated
artefact(s) would be:
commons-somecomp-2.3-alpha1
Regards,
Gilles
>
> On Tue, 4 Jun 2019 at 17:35, Matt Sicker wrote:
> >
> > This s
ut the problem hasn't been fixed.
See
https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry/65/console
>
> Kind regards
> Karl Heinz Marbaise
> On 31.05.19 20:10, Karl Heinz Marbaise wrote:
> > Hi,
> >
> > On 31.05.19 20:03, Gilles Sadowski wrote:
Hi.
Is there a purpose to having mails from "WIP" commits?
It's difficult to know when/what to comment about.
Regards,
Gilles
P.S. In the below commits, I don't understand the purpose of
"UNKNOWN". Also, I'd say that having a named constant ZERO
for the value "0"
gt; https://issues.apache.org/jira/browse/NUMBERS-104
>
Thanks for your contribution.
PR 46 has been merged.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
.a.c.compid.alpha1"
and all the tools operate on that)?
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
statistics like Mean() or
> Variance(), or StandardDeviation(), should be updatable, as Gilles said, or
> handle different kind of streams like Alex said. Yet these classes need to
> be designed so that they perform as well as simple implementations when
> desired.
>
Related discussion:
h
Hello.
Le dim. 2 juin 2019 à 10:00, Karl Heinz Marbaise a écrit :
>
> Hi,
>
> On 02.06.19 00:06, Alex Herbert wrote:
> >
> >> On 1 Jun 2019, at 22:49, Gilles Sadowski wrote:
> >>
> >> Hello.
> >>
> >> Le sam. 1 juin 2019 à 21:56,
bjections would it be Ok to merge that to master?
I'm against "throws" clauses for unchecked exception; as per J. Bloch:
"[...] do not provide throws clauses for unchecked exceptions".[1]
Regards,
Gilles
[1]
https://books.google.be/books?id=ka2VUBqHiWkC=PA253=PA253=effective+java
uot;commons" team.
>
> That is just fine...should I send a mail personally to him?
As you wish, I guess. Usually, he would notice such requests; if not
done by next week, it might help. ;-)
Regards,
Gilles
> [...]
--
Hi.
All builds fail:
https://builds.apache.org/view/A-D/view/Commons/job/commons-geometry/
Thanks,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h
l make more
> use of the "request review" portion of the PR interface. For numbers, this
> might entail requesting review from Gilles and one peer. To clarify, this
> is only my suggestion and others may disagree.
Partly (depending on the contents of the change).
And if we think we
lready access to JIRA but unfortunately I can't assign JIRA
> issue to myself ?
>
> Is this intentionally or is this an issue?
That should be fixed with Gary's action mentioned above.
Thanks,
Gilles
>
> Kind regards
> Karl Heinz Marbaise
>
>
> [1]: https://commons.a
ent state of workers. */
public void collect() { /* ... */ }
/** @return the current (combined) value of a named quantity. */
public double get(String name) { /* ... */ }
private StatCollector implements Callable {
StatCollector(DoubleStream data) { /* ... */ }
}
}
This is all totally untested, very partial, and probably wrong-headed but
I thought that we were looking at this kind of refactoring.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
lex
>
It was assumed that upgrading sub-modules of "commons-rng-examples"
was allowed if a particular example requires it.
+1 for "jmh"
+0 for "quadrature"
Gilles
-
To unsubscribe,
we did a complete conversion and not just
> introduced new syntax.
+1
> I've actually done this before on a largish Java
> project from JUnit3/4 to 5. It isn't hard, just a fair amount of mechanical
> code changes.
Patch/PR welcome.
Regards,
Gilles
>
> On Wed, 22 May
the "dev" ML) proposals that are connected to the GSoC
work discussed in these meetings.
Please engage with them in order to come up with an consensus on the
way(s) forward.
Thanks,
Gilles
> [...]
-
To unsubscribe
Hi.
Le jeu. 23 mai 2019 à 15:37, Rob Tompkins a écrit :
>
>
>
> > On May 23, 2019, at 7:25 AM, Gilles Sadowski wrote:
> >
> > Hi.
> >
> >> Le mer. 22 mai 2019 à 14:07, Matt Juntunen a
> >> écrit :
> >>
> >> Hi Sven,
>
lass has taken the best name.
>
> Any instance role for the class would require that it is typed for
> generics. But a quick try seems to pass clirr.
>
> Gilles, any opinion on a future for ListSampler as:
>
> public class ListSampler {
>
> // Other static stuff (al
gt;
>
> Given the class could not have been extended (due to a private
> constructor) it seems OK to allow the final modifier.
I think so.
>
> So can the final modifier be added? Is there a precedent here with
> regard to releases?
Cf. above.
Gilles
--
just rename to
>
> SaddlePointExpansionHelper
> SaddlePointExpansionUtils
Sure. Also, the class is package-private.
Gilles
>
> Alex
>
>
> [1] https://github.com/apache/commons-statistics/pull/13
>
-
T
our artifactory server but that
> looks like a pretty hard
> way. Currently maven wants me to commit to 'https://gitbox.apache.org' :),
> which is not exactly what I want.
>
> Do you see a way how I can release my app
used for 'mvn
> install'.
No idea; I always specify something to do.
Before a commit, I generally run
$ mvn site site:stage
and have a look at the generated reports (mainly CheckStyle).
Regards,
Gilles
>
> Alex
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
se to add JUnit 5 as a dependency in
> commons-numbers. JUnit 5 has several "assertThrows" methods that would
> solve the described dilemma.
+1
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi Eric.
Will you have look a NUMBERS-100:
https://issues.apache.org/jira/browse/NUMBERS-100
I've just thought that it might interfere with your changes in the
"fraction-dev" branch.
Regards,
Gilles
Le mer. 22 mai 2019 à 21:23, a écrit :
>
> This is an automated email f
Hi Alex.
PR looks fine.
Thanks,
Gilles
Le mer. 22 mai 2019 à 17:09, Alex Herbert a écrit :
>
> I'm trying to get pmd:check to be useful.
>
> This means fixing all the PMD violations. To fix some would be a
> refactor of reference algorithms which I do not want to start doing.
o be applied for the new components, is to
avoid that they become a dump of numerous disparate little tools.
Maybe I'm missing what you are getting at.
Hopefully, someone else can comment (Eric?).
Regards,
Gilles
>
> On Fri, 17 May 2019 at 15:37, Gilles Sadowski wrote:
>
> > Hi
Hi.
Thanks for the CheckStyle update.
I'd say that we enforce it for the "main" parts of the repositories and
be lenient for the existing unit tests (but try to follow convention for
new tests).
Regards,
Gilles
Le mar. 21 mai 2019 à 17:23, Alex Herbert a écrit :
>
> On 21/05/
of that
(later, according to code logic), not because the file is missing.
> I'd like to add a 'includesoptional' where nothing happens if the file is
> missing.
>
> Any objections or thoughts on a better name?
includeif
Hi.
> >
> >> On 17 May 2019, at 23:24, Gilles Sadowski >> <mailto:gillese...@gmail.com>> wrote:
> >>
> >> Hi.
> >>
> >> Le ven. 17 mai 2019 à 18:33, Alex Herbert >> <mailto:alex.d.herb...@gmail.com>> a écrit :
>
at INFRA:
https://issues.apache.org/jira/browse/INFRA-18398
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hello.
Le ven. 17 mai 2019 à 16:10, Alex Herbert a écrit :
>
>
> On 17/05/2019 14:41, Gilles Sadowski wrote:
> > Hi Alex.
> >
> > Le ven. 17 mai 2019 à 15:33, a écrit :
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
&
Hi Alex.
Le ven. 17 mai 2019 à 15:33, 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
>
> commit 5cf993a22bcedfe8c66dd9ae6536c1ee2db146ea
> Author:
but that "package" does not exist yet; hence we (you) have to
1. suggest a scope for a new maven module,
2. show how your proposed code fit within the rest (even if it's not
implemented yet).
>
> >How w
veragingInt in JDK.
How will a user get e.g. the variance too?
Regards,
Gilles
> I've already started implementing BigDecimalStatistics on my fork but I
> haven't pushed those changes on my fork
>
>
> On Fri, 17 May 2019 at 14:19, Gilles Sadowski wrote:
>
> > Hello.
&
ed to perform
the operations? "Commons Numbers" has some suggestions[1][2]; those can,
and should, be adapted to actual use-cases, such as "streams" (preferably
before the first release).
It would perhaps be helpful to know why there is no "BigDecimalStatistics" in
the J
n the latter case, it will be worth considering how all the functionality in
Commons Math's "o.a.c.math4.stat.descriptive" package[1] will be
supported.
Regards,
Gilles
[1]
https://gitbox.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/stat/descriptive
Hi.
Le jeu. 16 mai 2019 à 16:04, Alex Herbert a écrit :
>
>
>
> > On 16 May 2019, at 14:42, Gilles Sadowski wrote:
> >
> > Hello.
> >
> > Le jeu. 16 mai 2019 à 12:06, Alex Herbert > <mailto:alex.d.herb...@gmail.com>> a écrit :
> >&g
ture. All results can reside in a single directory.
> - Ignore for now the bit-reversed results.
> - Delete the old stress test code. The new code supersedes all functionality
> of the old version.
> - Commit the new ‘results’ command when I have confirmed the APT table is
> correctly generated.
+1
>
> Questions:
>
> 1. Do we stick to using 3 trials or update to 5 (because I have the results)?
+1
> 2. Do we remove the diehard_sums test result?
>
> I would recommend removing diehard_sums. It pollutes the results for most
> generators with a spurious fail that should be ignored. So I think we should
> ignore it.
+0 (as you wish)
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi Eric.
I won't be able to attend (but I've already provided comments on the ML).
Best,
Gilles
Le mar. 14 mai 2019 à 18:57, Rob Tompkins a écrit :
>
>
> On 5/14/2019 12:47 PM, Eric Barnhill wrote:
> > Should we have another Slack meeting at the same time this Thursday, 5
ay be implemented for the convenience of users.
> while allowing multiple types of regression to be calculated via a universal
> form….
> which could become a challenge once details are in order.
>
>
>
> So this is the current state of my plan,
Le sam. 11 mai 2019 à 23:32, Alex Herbert a écrit :
>
>
>
> > On 10 May 2019, at 15:07, Gilles Sadowski wrote:
> >
> > Hi.
> >
> > Le ven. 10 mai 2019 à 15:53, Alex Herbert > <mailto:alex.d.herb...@gmail.com>> a écrit :
> >>
> &g
rogress towards a release,
because "Statistics", and others, depend on it.
Regards,
Gilles
[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20status%20%3D%20Open
>
> On Fri, 10 May 2019, 2:15 am Alex Herbert, wrote:
>
> >
>
Hi.
Le ven. 10 mai 2019 à 15:53, Alex Herbert a écrit :
>
>
> On 10/05/2019 14:27, Gilles Sadowski wrote:
> > Hi Alex.
> >
> > Le ven. 10 mai 2019 à 13:57, Alex Herbert a
> > écrit :
> >> Can I get a review of the PR for RNG-101 please.
>
MarsagliaTsangWangBinomialSampler
but
MarsagliaTsangWangSmallMeanPoissonSampler
seems to be missing.
Regards,
Gilles
> This is a new sampler based on the source code from the paper:
>
> George Marsaglia, Wai Wan Tsang, Jingbo Wang (2004)
> Fast Generation of Discrete Random Variables.
> Journal of Statistic
Le jeu. 9 mai 2019 à 17:00, Alex Herbert a écrit :
>
>
> On 09/05/2019 15:39, Gilles Sadowski wrote:
> > Le jeu. 9 mai 2019 à 15:41, Alex Herbert a écrit
> > :
> >> On Sat, 4 May 2019 at 23:52, Alex Herbert wrote:
> >>
> >>>
>
Le jeu. 9 mai 2019 à 17:07, Alex Herbert a écrit :
>
>
> On 09/05/2019 15:46, Gilles Sadowski wrote:
> > Le jeu. 9 mai 2019 à 14:30, Alex Herbert a écrit
> > :
> >>
> >>
> >>> On 9 May 2019, at 12:58, Gilles Sadowski wrote:
> >>>
Le jeu. 9 mai 2019 à 14:30, Alex Herbert a écrit :
>
>
>
> > On 9 May 2019, at 12:58, Gilles Sadowski wrote:
> >
> > Hi.
> >
> > Le jeu. 9 mai 2019 à 13:31, Alex Herbert > <mailto:alex.d.herb...@gmail.com>> a écrit :
> >>
> >&
Le jeu. 9 mai 2019 à 15:41, Alex Herbert a écrit :
>
> On Sat, 4 May 2019 at 23:52, Alex Herbert wrote:
>
> >
> >
> > > On 4 May 2019, at 22:34, Gilles Sadowski wrote:
> > >
> > > Hi.
> > >
> > > Le sam. 4 mai 2019 à 21:31, Alex
d overloads defined, for all implementations.
The "accessor" methods refer to fields that were set by the contructor;
e.g. for "CauchyDistribution", "median" and "scale".
In this case, it happens that "mode" has the same value as "media
ike when passing a
bad seed), and
"RandomSource" ("simple" module) would offer to provide an instance
for which the
increment was computed according to the recommendation.
Regards,
Gilles
>
> Note that the function is an alternative to that used by the SplittableRandom
>
s (cf. list in the above link),
so that we can switch from one to another and analyze the impact of
doing so.
Regards,
Gilles
> with thanks and attribution to the EJML site and org.
>
>
> On Wed, May 8, 2019 at 2:49 PM Rob Tompkins wrote:
>
> >
> >
> > > On May 8,
singhdhad...@users.noreply.github.com>
Abhishek,
You might want to have your actual email address appear in the log...
Regards,
Gilles
> AuthorDate: Thu May 9 00:35:29 2019 +0530
>
> Update pom.xml
> ---
> pom.xml | 3 +++
> 1 file changed, 3 insertions(+)
>
> dif
alternative design are tried out.
Regards,
Gilles
> The mentees and others can then create feature branches off of develop, and
> submit pull requests for feature branches into develop. Then develop is
> merged into master periodically when all is clear. That is the typical
> GitHub ca
Hi.
I see that a discussion about is still going on on GitHub[1]; thus,
I remind that API changes *must* be agreed on here. [Please start
a new thread.]
Best,
Gilles
[1] https://github.com/apache/commons-statistics/pull/4#discussion_r282004202
san.casio.com/menu/system/0540
Gilles
> Thanks
>
> On Fri, May 3, 2019 at 7:26 PM Udit Arora wrote:
>
> > Ok sir..
> > Thanks
> >
> > On Fri, 3 May 2019, 6:23 pm Gilles Sadowski, wrote:
> >
> >> Hello.
> >>
> >> Le je
Hi.
Le sam. 4 mai 2019 à 21:31, Alex Herbert a écrit :
>
>
>
> > On 4 May 2019, at 14:46, Gilles Sadowski wrote:
> >
> > Hello.
> >
> > Le ven. 3 mai 2019 à 16:57, Alex Herbert > <mailto:alex.d.herb...@gmail.com>> a écrit :
> >>
>
erator (method "sample"),
* generator generator (method "newInstance").
[But I currently don't have an example where this would be a problem.]
Regards,
Gilles
> Alex
>
> [1] https://issues.apache.org/jira/browse/RNG-91
>
> [2] kB, or possibly MB, of tabul
other functions.
> Please let me know if I should go ahead with this idea.
Sure!
For a new implementation, you should provide reference(s) and
unit tests (based on those that exist for the other implementations,
preferably reaching for full coverage).
Thanks,
Gilles
>
Hello.
Le jeu. 2 mai 2019 à 23:49, Alex Herbert a écrit :
>
>
>
> > On 1 May 2019, at 23:15, Gilles Sadowski wrote:
> >
> > Hi.
> >
> >>> [...]
> >>
> >> So do we do:
> >>
> >> UniformRandomProvider res
Thank you Bruno and Alex!
Best,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
ow that
we won't apply PRs without tracking information (JIRA ticket and/or
post on "dev"), as per the "contributions guidelines".[4]
Thanks,
Gilles
[1] Last examples:
https://github.com/apache/commons-math/pull/105
https://github.com/apache/commons-statistics/pull/4
[2]
y adds two new methods. The first has 3 new methods
> (deprecating unrestorable with restrict) but suffers from having to cast
> instances of multiple interfaces to ensure the correct restrict is called.
Oops indeed.
This is too error-prone.
> So this makes me favou
Hi.
Le mar. 30 avr. 2019 à 17:08, Alex Herbert a écrit :
>
> On 29/04/2019 22:14, Gilles Sadowski wrote:
> > Hello.
> >
> > Le lun. 29 avr. 2019 à 19:09, Alex Herbert a
> > écrit :
> >> On 28/04/2019 19:11, Gilles Sadowski wrote:
> >>> Le dim.
Hello.
Le lun. 29 avr. 2019 à 19:09, Alex Herbert a écrit :
>
> On 28/04/2019 19:11, Gilles Sadowski wrote:
> > Le dim. 28 avr. 2019 à 17:02, Alex Herbert a
> > écrit :
> >>
> >>
> >>> On 28 Apr 2019, at 00:59, Bernd Eckenfels wrote:
>
mRandomProvider extends UniformRandomProvider {
> /** Jump the current instance ahead. */
> void jump();
> /** Copy the instance. This is intended to be used either before or after
> a call to jump()
> * to create a series of generators. */
> JumpableUniformRandomProvider copy();
> }
As you indicated above, there is no advantage in having separate
"jump()" and "copy()",
as counter-intuitive it may look at first sight.
Regards,
Gilles
>
> WDYT?
>
> Alex
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi.
>
> Just a question, I am unclear on the terminology, is „jump“ (did I miss the
> discussion leading toot?) something invented here?
Not invented here: It's a functionality that exist for some RNG algorithms.
> It sounds to me like this is a generator where the state can be cloned and it
Hello.
>
>
> > On 27 Apr 2019, at 14:49, Gilles Sadowski wrote:
> >
> > Hi.
> >
> > Le sam. 27 avr. 2019 à 15:05, Alex Herbert > <mailto:alex.d.herb...@gmail.com>> a écrit :
> >>
> >> I have created RNG-97 and RNG-
mp series) in
> RandomSource seems the best way to avoid incorrect usage.
+1
I think that the default should be to prevent a "jump" on the returned
instances.
An overload could be defined with a parameter (e.g. "allowFurtherJum
19 13:09:42 2019 -0400
>
> japicmp-maven-plugin should not break builds on source incompatible
> changes by default.
Doesn't seem to match the huge change!
Gilles
> ---
> pom.xml | 3648
> ---
> src/changes
Le jeu. 18 avr. 2019 à 21:53, Alex Herbert a écrit :
>
>
>
> > On 18 Apr 2019, at 14:12, Gilles Sadowski wrote:
> >
> > Hello Alex.
> >
> >>>> [...]
> >>
> >> OK so this results in:
> >>
> >> /**
> &
= restrict(tmp);
> > tmp = tmp.jump();
> > }
> > return rngs;
> > }
>
> +1. Remove the need for the user to repeat boiler plate code.
>
> Same sort of idea of longJump() too.
+1
> >> It is not actually possible to jump fo
Hello.
Le lun. 15 avr. 2019 à 01:03, Alex Herbert a écrit :
>
>
>
> > On 14 Apr 2019, at 01:31, Gilles Sadowski wrote:
> >
> > Hello.
> >
> >> On 11/04/2019 13:22, Gilles Sadowski wrote:
> >>>>> [...]
> &
Hello.
> On 11/04/2019 13:22, Gilles Sadowski wrote:
> >>> [...]
> >> Not adding a dedicated method would mean everyone has to do this:
> >>
> >> JumpableUniformRandomProvider rng = (JumpableUniformRandomProvider)
> >> RandomSou
-overlap, with high probability (why "weak assurance"?)
Anyways, I agree that SPLIT_MIX_64_K is low priority, but especially if we
cannot ensure that the added flexibility does not come with unsuspected
drawbacks (?). [IIRC, the article about "TwoCmres" reported experiments for
choosing the (hard-coded) values that do produce good sequences.]
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le mer. 10 avr. 2019 à 18:26, Alex Herbert a écrit :
>
>
> On 10/04/2019 15:59, Gilles Sadowski wrote:
> > Hello.
> >
> > Le mer. 10 avr. 2019 à 15:22, Alex Herbert a
> > écrit :
> >> On 10/04/2019 13:46, Alex Herbert wrote:
> >>> The code
Hi.
>
> On 10/04/2019 18:58, Gilles Sadowski wrote:
> > Hi.
> >
> >> [... long quote skipped where I think we largely agree on the
> >> conclusions ...]
> >> So do we have a working idea to:
> >>
> >> - Add interface 'JumpableUnifor
rive the Weyl sequence increment.
Is the new seed length a temporary workaround for the test,
to be replaced with a new "SPLIT_MIX_64_K" provider, as
mentioned in your previous message, if the test passes?
Gilles
>
> Alex
>
>
> >
> > Regards,
> > Gilles
&g
mmons RNG are mostly good providers
With the notable exception of "JDK"...
> of bits the change to use the lower order bits should be reasonable.
... Hence, calling "nextInt(int)" on that provider will generate a
sequence even worse than it would be from direct call
ly until nobody knows why it was there... ]
If you are sure that no functionality is lost, and that the replacement
is better; I'd favour removing it. Code archaelogists can always turn
to the VCS, if need be.
Regards,
Gilles
> ---
> .../rng/examples/jmh/GenerationPerformance.java| 2
Hello.
Le mar. 9 avr. 2019 à 16:42, Alex Herbert a écrit :
>
> Hi Gilles,
>
> Lots of sensible discussion here. I'll just put all replies at the end.
>
> On 09/04/2019 13:28, Gilles Sadowski wrote:
> > Hello.
> >
> >> Hi Gilles,
> >>
> >>
Le mar. 9 avr. 2019 à 14:11, Rob Tompkins a écrit :
>
>
>
> > On Apr 9, 2019, at 7:21 AM, Gilles Sadowski wrote:
> >
> > Le mar. 9 avr. 2019 à 13:03, sebb > <mailto:seb...@gmail.com>> a écrit :
> >>
> >
Hello.
>
> Hi Gilles,
>
> You ask some good questions which I may have been vague about due to
> familiarity with the possibilities. I hope to clarify a bit below.
>
> On 08/04/2019 16:05, Gilles Sadowski wrote:
> > Hi Alex.
> >
> > Le lun. 8 avr. 2
Le mar. 9 avr. 2019 à 13:03, sebb a écrit :
>
> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski wrote:
> >
> > > [...]
> > > >
> > > > $ git diff pom.xml
> > > > diff --git a/pom.xml b/pom.xml
> > > > index 2612dd6..54a88e4 100644
1.3
> > 1.3
> >
> > +
> > +${project.artifactId}
No default should be defined (to avoid the risk of creating incompatible
but identically named modules).
Then the release plugin could be enhanced (?) so that it w
may not be flexible enough going forward.
I'm missing many points, and this one too as a consequence.
My (simplistic?) idea was to have methods added to the
"UniformRandomProvider" interface:
public interface UniformRandomProvider {
// ...
boolean isJumpable();
UniformRando
Hi Rob.
Le lun. 8 avr. 2019 à 14:16, Rob Tompkins a écrit :
>
> I think that maybe hits what you guys were getting after with my wording.
You probably missed a thread.
I've just committed the alternative text.
Regards,
Gilles
>
> And you know me, english as a first language, s
Le sam. 6 avr. 2019 à 16:59, Rob Tompkins a écrit :
>
> @Gilles - thoughts on this wording:
> https://github.com/apache/commons-lang/commit/3f43706192b1b75c5023f165534a12b192c31442
>
> <https://github.com/apache/commons-lang/commit/3f43706192b1b75c5023f1
Le sam. 6 avr. 2019 à 16:00, Jochen Wiedmann
a écrit :
>
> On Fri, Apr 5, 2019 at 4:27 AM Rob Tompkins wrote:
> >
> > > On Apr 4, 2019, at 9:20 AM, Gilles Sadowski wrote:
> > >
> > >> Any thoughts on doing a 3.9 release of [lang]. I think Benedikt wa
Hi Rob.
Le ven. 5 avr. 2019 à 04:27, Rob Tompkins a écrit :
>
>
>
> > On Apr 4, 2019, at 9:20 AM, Gilles Sadowski wrote:
> >
> >> Any thoughts on doing a 3.9 release of [lang]. I think Benedikt want’s us
> >> to go up with what we have. Any thoughts for
1101 - 1200 of 4252 matches
Mail list logo
