Thanks Gilles,
I can provide the same sort of stats across a clustering example
across commons-math (KMeans) vs Apache Ignite, Apache Spark and
Rheem/Apache Wayang (incubating) if anyone would find that useful. It
would no doubt lead to similar conclusions.
Cheers, Paul.
On Sun, Apr 25, 2021 at
Le sam. 24 avr. 2021 à 23:32, Alex Herbert a écrit :
>
> On Sat, 24 Apr 2021 at 17:36, Matt Juntunen
> wrote:
>
> > This is very interesting. With this amount of geometry code, I could
> > picture this as part of a commons-geometry-rng module. The SurfaceSampler,
> > for example, could make use
Hello Paul.
Le sam. 24 avr. 2021 à 04:42, Paul King a écrit :
>
> I added some more comments relevant to if the proposed algorithm
> belongs somewhere in the commons "math" area back in the Jira:
>
> https://issues.apache.org/jira/browse/MATH-1563
Thanks for a "real" user's testimony.
As the
Hi everyone,
I think I figured part of it out myself.
The wiki page
https://cwiki.apache.org/confluence/display/COMMONS/ExtractAndDecompressGzipFiles
does not mention that commons-compress is needed in the classpath.
The github project has some other flaws, too. I will put in some more work.
On Sat, 24 Apr 2021 at 17:36, Matt Juntunen
wrote:
> This is very interesting. With this amount of geometry code, I could
> picture this as part of a commons-geometry-rng module. The SurfaceSampler,
> for example, could make use of the TriangleMesh and Triangle3D classes.
> This would also be an
Hi everyone,
I tried to use vfs2 in a verify.groovy script like this:
def fsManager = VFS.manager
def file =
fsManager.resolveFile("gz:tar:${basedir}/target/dependencies/vfs-invoker-groovy-1.0.0-SNAPSHOT.tar!/hello.txt")
While this works in a junit+groovy maven test case, it won’t in a
On Sat, 24 Apr 2021 at 00:35, Matt Benson wrote:
>
> FWIW, my recollection is that proxy was ready for a 2.0 release which was
> vetoed on the basis that the site didn't contain a migration how-to
> document. Oh well.
I don't think it was vetoed, but it looks like there were only 2 +1 votes:
This is very interesting. With this amount of geometry code, I could picture
this as part of a commons-geometry-rng module. The SurfaceSampler, for example,
could make use of the TriangleMesh and Triangle3D classes. This would also be
an opportunity to expand support for N-dimensional points
On Fri, 23 Apr 2021 at 23:31, Gilles Sadowski wrote:
> Le ven. 23 avr. 2021 à 23:42, Alex Herbert a
> écrit :
>
> > Should new coordinate based samplers be moved to a package inside for
> > example:
> >
> > o.a.c.rng.sampling.geometry
> > o.a.c.rng.sampling.shape
>
> Maybe. I guess that
One more question: what are the originating use cases for these shape samplers?
-Matt J
From: Matt Juntunen
Sent: Saturday, April 24, 2021 7:25 AM
To: Commons Developers List
Subject: Re: [RNG][Geometry] TriangleSampler and other shape samplers
Hello,
>
Hello,
> Currently in my working example for the TriangleSampler I have not validated
> the
> input is a triangle. I state that if the points are collinear then the
> distribution of the samples is undefined.
That seems fine to me for the triangle case. If you attempted to validate the
shape,
11 matches
Mail list logo
