Re: [geometry] Initial Project Structure

[Gilles]

On Sat, 14 Apr 2018 10:46:40 -0400, Rob Tompkins wrote:
On Apr 14, 2018, at 9:00 AM, Gilles  
wrote:


Hello.

On Sat, 14 Apr 2018 04:24:35 +, Matt Juntunen wrote:

Hi Gilles,

That's actually really close to what I ended up with after I 
started

moving the code over. I currently have

 *   commons-geometry-core
 *   commons-geometry-euclidean
 *   commons-geometry-spherical
 *   commons-geometry-hull


I’m a little surprised that you’re giving an entire package to hull.
Wouldn’t determining a convex hull in spherical geometry differ from
in euclidean?


https://github.com/darkma773r/commons-geometry/tree/geometry-1/commons-geometry-hull/src/main/java/org/apache/commons/geometry


Are we going to do more than just euclidean and spherical? Maybe our
names should be “euclidean” and “non-euclidean” so that we can put 
all

of the different geometries that avoid the parallel postulate in one
sub-project?

All thoughts, I’m +0 to +1 for the packages shown.

Cheers,
-Rob


 *   commons-geometry-enclosing
[...]



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

Re: [geometry] Initial Project Structure

[Rob Tompkins]

> On Apr 14, 2018, at 9:00 AM, Gilles  wrote:
> 
> Hello.
> 
> On Sat, 14 Apr 2018 04:24:35 +, Matt Juntunen wrote:
>> Hi Gilles,
>> 
>> That's actually really close to what I ended up with after I started
>> moving the code over. I currently have
>> 
>>  *   commons-geometry-core
>>  *   commons-geometry-euclidean
>>  *   commons-geometry-spherical
>>  *   commons-geometry-hull

I’m a little surprised that you’re giving an entire package to hull. Wouldn’t 
determining a convex hull in spherical geometry differ from in euclidean?

Are we going to do more than just euclidean and spherical? Maybe our names 
should be “euclidean” and “non-euclidean” so that we can put all of the 
different geometries that avoid the parallel postulate in one sub-project?

All thoughts, I’m +0 to +1 for the packages shown.

Cheers,
-Rob

>>  *   commons-geometry-enclosing
>> 
>> So, it's basically split up by space and algorithm.
> 
> +1
> 
>> I have the code
>> at https://github.com/darkma773r/commons-geometry/tree/geometry-1.
>> It's not quite ready for a pull request yet but I'm ready for any
>> feedback you or anyone else may have.
> 
> I had a brief and very partial look; and noticed the following:
> * Exceptions
>   Please have a look at how they are defined, instantiated and
>   used in the various modules of "Commons Numbers" (executive
>   summary: only JDK exception types are part of the public API)
> * Packages vs (JPMS) modules
>   I'd avoid defining classes in "o.a.c.geometry" unless you are
>   sure that no other (maven) module than "core" will.
>   [Safer would be to create a "o.a.c.geometry.core" package and
>move the "Geometry", "Space", "Point" and "Vector" classes
>into it.]
> 
> Regards,
> Gilles
> 
>> 
>> -Matt
>> 
>> 
>> From: Gilles 
>> Sent: Thursday, April 12, 2018 9:12 AM
>> To: dev@commons.apache.org
>> Subject: Re: [geometry] Initial Project Structure
>> 
>> Hi Matt.
>> 
>> On Sun, 8 Apr 2018 02:40:26 +, Matt Juntunen wrote:
>>> Hi all,
>>> 
>>> I'm forwarding a conversation I had with Gilles on the project
>>> structure for the new commons-geometry project in order to get
>>> feedback on it from everyone. Basically, Gilles is proposing (and has
>>> initially set up) a multi-module project with the following modules
>>> so
>>> far:
>>> 
>>>  *   commons-geometry-bsp
>>>  *   commons-geometry-euclidean-oned
>>>  *   commons-geometry-euclidean-twod
>>>  *   commons-geometry-euclidean-threed
>>> 
>>> My thought was that this module break up is too fine-grain and would
>>> make development of code that uses more than one dimension more
>>> difficult than it should be. I was initially picturing having a
>>> single
>>> project for all of the current geometry code since it's all so
>>> closely
>>> related and there's not much of it. However, I can see where Gilles
>>> is
>>> coming from with the previous experience on commons-math. So, I'd
>>> like
>>> to propose an alternative module break up, one that keeps all of the
>>> basic euclidean primitives in one place:
>>> 
>>>  *   commons-geometry-core -- This would contain the code currently
>>> in the packages
>>> *   o.a.c.m.geometry
>>> *   o.a.c.m.partitioning
>>> *   o.a.c.m.geometry.euclidean.oned
>>> *   o.a.c.m.geometry.euclidean.twod
>>> *   o.a.c.m.geometry.euclidean.threed
>>> *   o.a.c.m.geometry.hull
>>> *   o.a.c.m.geometry.twod.hull
>>> *   o.a.c.m.geometry.enclosing (this is the odd-ball in the
>>> group here so I could be convinced to put this elsewhere)
>>>  *   commons-geometry-spherical -- This would contain
>>> *   o.a.c.m.geometry.spherical.oned
>>> *   o.a.c.m.geometry.spherical.twod
>>> 
>>> Basically, core would contain the main geometry interfaces (eg,
>>> Point, Space, Vector) as well as all of the basic euclidean
>>> functionality. Most users would only ever need to pull in this
>>> module.
>>> The other modules would be for other spaces, such as spherical, and
>>> other special-purpose code that we have yet to develop.
>>> 
>>> Thoughts?
>> 
>> Could we have the following modules:
>> 
>>  * commons-geometry-core
>>  * commons-geometry-euclidean
>>  * commons-geometry-spherical
>> 
>> ?
>> 
>> Gilles
>> 
>>> Thanks,
>>> Matt Juntunen
>>> 
>>> 
>>> 
>>> From: Gilles 
>>> Sent: Saturday, April 7, 2018 6:39 PM
>>> To: Matt Juntunen
>>> Subject: Re: Commons Geometry Project Structure
>>> 
>>> Hi Matt.
>>> 
>>> On Sat, 7 Apr 2018 16:01:32 +, Matt Juntunen wrote:
 Hi Gilles,
 
 Yes, I'm picturing a few possible issues with the current structure.
 First, I think that splitting everything up into modules at this
 point
 will inhibit development. For example, each time we add a new
 feature,
 we'll need to worry about either creating a new module or making it
 fit into existing 

Re: [geometry] Initial Project Structure

[Gilles]

Hello.

On Sat, 14 Apr 2018 04:24:35 +, Matt Juntunen wrote:

Hi Gilles,

That's actually really close to what I ended up with after I started
moving the code over. I currently have

  *   commons-geometry-core
  *   commons-geometry-euclidean
  *   commons-geometry-spherical
  *   commons-geometry-hull
  *   commons-geometry-enclosing

So, it's basically split up by space and algorithm.


+1


I have the code
at https://github.com/darkma773r/commons-geometry/tree/geometry-1.
It's not quite ready for a pull request yet but I'm ready for any
feedback you or anyone else may have.


I had a brief and very partial look; and noticed the following:
 * Exceptions
   Please have a look at how they are defined, instantiated and
   used in the various modules of "Commons Numbers" (executive
   summary: only JDK exception types are part of the public API)
 * Packages vs (JPMS) modules
   I'd avoid defining classes in "o.a.c.geometry" unless you are
   sure that no other (maven) module than "core" will.
   [Safer would be to create a "o.a.c.geometry.core" package and
move the "Geometry", "Space", "Point" and "Vector" classes
into it.]

Regards,
Gilles



-Matt


From: Gilles 
Sent: Thursday, April 12, 2018 9:12 AM
To: dev@commons.apache.org
Subject: Re: [geometry] Initial Project Structure

Hi Matt.

On Sun, 8 Apr 2018 02:40:26 +, Matt Juntunen wrote:

Hi all,

I'm forwarding a conversation I had with Gilles on the project
structure for the new commons-geometry project in order to get
feedback on it from everyone. Basically, Gilles is proposing (and 
has

initially set up) a multi-module project with the following modules
so
far:

  *   commons-geometry-bsp
  *   commons-geometry-euclidean-oned
  *   commons-geometry-euclidean-twod
  *   commons-geometry-euclidean-threed

My thought was that this module break up is too fine-grain and would
make development of code that uses more than one dimension more
difficult than it should be. I was initially picturing having a
single
project for all of the current geometry code since it's all so
closely
related and there's not much of it. However, I can see where Gilles
is
coming from with the previous experience on commons-math. So, I'd
like
to propose an alternative module break up, one that keeps all of the
basic euclidean primitives in one place:

  *   commons-geometry-core -- This would contain the code currently
in the packages
 *   o.a.c.m.geometry
 *   o.a.c.m.partitioning
 *   o.a.c.m.geometry.euclidean.oned
 *   o.a.c.m.geometry.euclidean.twod
 *   o.a.c.m.geometry.euclidean.threed
 *   o.a.c.m.geometry.hull
 *   o.a.c.m.geometry.twod.hull
 *   o.a.c.m.geometry.enclosing (this is the odd-ball in the
group here so I could be convinced to put this elsewhere)
  *   commons-geometry-spherical -- This would contain
 *   o.a.c.m.geometry.spherical.oned
 *   o.a.c.m.geometry.spherical.twod

Basically, core would contain the main geometry interfaces (eg,
Point, Space, Vector) as well as all of the basic euclidean
functionality. Most users would only ever need to pull in this
module.
The other modules would be for other spaces, such as spherical, and
other special-purpose code that we have yet to develop.

Thoughts?


Could we have the following modules:

  * commons-geometry-core
  * commons-geometry-euclidean
  * commons-geometry-spherical

?

Gilles


Thanks,
Matt Juntunen



From: Gilles 
Sent: Saturday, April 7, 2018 6:39 PM
To: Matt Juntunen
Subject: Re: Commons Geometry Project Structure

Hi Matt.

On Sat, 7 Apr 2018 16:01:32 +, Matt Juntunen wrote:

Hi Gilles,

Yes, I'm picturing a few possible issues with the current 
structure.

First, I think that splitting everything up into modules at this
point
will inhibit development. For example, each time we add a new
feature,
we'll need to worry about either creating a new module or making it
fit into existing modules. For example, if we make a general 
utility
class that makes use of 1D, 2D, and 3D, we'd need to make a 
separate

module for it so that it can pull in all of the other dimension
modules.


Yes. No problem then?


It wouldn't make sense to put it into 3D since it wouldn't
just be 3D. This is actually the case with the GeometryTestUtils
class
I wrote.

Also, the code may be able to be split up now but there's no
guarantee that features we want to add in the future won't 
introduce

circular dependencies and other issues.


I find it difficult to reason on hypotheticals.
 From a developer's POV, circular dependencies are best avoided.

Second, having a single module for the current functionality will 
be

much more convenient for users. They would just need to pull in a
single dependency to have access to core functionality for all
standard dimensions. Plus, a single module makes it much easier to
discover the overall 

Re: [Statistics] Port codes from Commons Math

[Gimhana Nadeeshan]

Hello devs,

*Covariance stats=
> > IntStream.of(1,2,3).collect(Covariance::new,Covariance::
> accept,Covariance::combine);*
>
>
> Can you explain a bit more what is happening with the method references
> "accept" and "combine"?
>

The mutable reduction operation - collect() accumulates input elements into
a mutable result container, such as a Collection. It requires 3 functions.
A *supplier function* construct new instance of the result container.
An *accumulator
function *incorporate an input element into a result container and a *combining
function* to merge the contents of one result container into another.

So the accept() method, Records a new value into the result container.
(Here Covariance Object). Accepting the values in the Stream, to the
Covariance Object. It is the functionality of the functional interface I'm
going to implement to make use the Lambda Expressions of Java8.

combine()  method will combine the state of another Covariance Object into
this one. It merges the results of one results container to another.
Generation of new object is replaced by Replacing.

As a whole the meaning of those implementation is like generating a single
string object by concatenating strings in an array list. All the
statistical functionalities are served as a state object in this
implementation.

*Week 2: Begin porting the code according to the dependency hierarchy
> > identified. *
> >
>
> Sorry but I cannot see where you identify the dependency hierarchy. Are you
> referring to your diagram?


Dependency Hierarchy is not mentioned separately in the proposal. But I
have created the Time-line of the proposed project according to that. Less
dependent modules are porting at the beginning and gradually going for the
more coupled ones. So at that point of view I am going to port Ranking
Module at the beginning and gradually port
Interval,Regression,Descriptive,Correlation,Interference modules and so on.

A further comment: L1-type statistics such as median and quantiles can also
> be included in the API by using the stream.sorted() method to sort the
> stream first.
>
> While it is true medians can be in the aggregate sped up by partitioning
> algorithms, I think making use of built-in methods like sorted() is still
> likely to produce the best and most consistent performance with the JVM.


Definitely. Using built-in-methods provided, will make the package
performance and the ease of use and using inbuilt-methods where is possible
is one of the main goals of the proposed project.

Best Regards,
Gimhana.


Nadeeshan Gimhana

Batch Representative (15' batch)

Department of Computer Science & Engineering

University of Moratuwa

*Mobile :+94775744613*


*Website : https://ngimhana94.wixsite.com/gimhanadesilva/
*

*L**inkedin **:www.linkedin.com/in/nadeeshangimhana/
*


* *


* *



On 13 April 2018 at 12:26, Eric Barnhill  wrote:

> A further comment: L1-type statistics such as median and quantiles can also
> be included in the API by using the stream.sorted() method to sort the
> stream first.
>
> While it is true medians can be in the aggregate sped up by partitioning
> algorithms, I think making use of built-in methods like sorted() is still
> likely to produce the best and most consistent performance with the JVM.
>
> On Thu, Apr 12, 2018 at 2:03 PM, Eric Barnhill 
> wrote:
>
> > HI Gimhana,
> >
> > Sorry for the delay in response, but you posted this right before our
> > two-week Easter holiday, for which I was completely absent ; then I
> needed
> > a few days back at work to clean up all the mess. :)
> >
> > Your overall goals look good to me. You have gone right to the heart of
> > the matter and propose to reinvent the statistics tools to make good use
> of
> > the Java 8 API. I think that's great and you should get started. Your
> goal
> > of eliminating dependencies on Commons-Math is also right.
> >
> > I noticed this in the proposal:
> >
> > *Covariance stats=
> >> IntStream.of(1,2,3).collect(Covariance::new,Covariance::
> accept,Covariance::combine);*
> >
> >
> > Can you explain a bit more what is happening with the method references
> > "accept" and "combine"?
> >
> > Also this
> >
> > *Week 2: Begin porting the code according to the dependency hierarchy
> >> identified. *
> >>
> >
> > Sorry but I cannot see where you identify the dependency hierarchy. Are
> > you referring to your diagram?
> >
> > Eric
> >
> >
> > On Mon, Mar 26, 2018 at 8:07 AM, Gimhana Nadeeshan <
> > gimhanadesilva...@cse.mrt.ac.lk> wrote:
> >
> >> Hello devs,
> >>
> >> I have updated my draft proposal (Port codes from Commons Math
> >>  >> OBOqTOeMnPaBsE9U5YhU/edit?usp=sharing>)
> >> -Timeline added; before submitting the final at the