[complex] commons-complex module

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[complex] commons-complex module

Eric Barnhill
As the recent contribution shows the commons-math complex library remains
quite useful to many applications.

Following in the footsteps of commons-rng, commons-complex seems like a
good next component of math to spin out and actively maintain. I am willing
to oversee and maintain the project.

It may be that as I get into it, complex will have dependencies that more
properly belong in a core library. I propose to just get started on the
library and sort these issues as they come up.

I would take the following positions as regards this library:

- Add syntactic sugar so that typical C++ calls are compatible: yes
- Keep completely backwards compatible: yes
- Follow the C++ architecture including an Imaginary data type with its own
behavior: no
- Like C++, incorporate complex typing other than double: no

-Eric
Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Gilles Sadowski
Hi.

On Sat, 22 Oct 2016 13:42:56 +0200, Eric Barnhill wrote:
> As the recent contribution shows the commons-math complex library
> remains
> quite useful to many applications.
>
> Following in the footsteps of commons-rng, commons-complex seems like
> a
> good next component of math to spin out and actively maintain. I am
> willing
> to oversee and maintain the project.

Git repository is available:
   https://git-wip-us.apache.org/repos/asf?p=commons-complex.git

Best,
Gilles

>
> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

jochen-2
In reply to this post by Eric Barnhill
Honestly, I really wonder why all this stuff has to fork yet another
commons component. IMO, CM could just have been changed to emit
multiple jar files with no need for other components. No need for
discussions, no need for new repositories in Git, no need for new
stuff in Jira. Or, to put it different: Less to maintain.



On Sat, Oct 22, 2016 at 1:42 PM, Eric Barnhill <[hidden email]> wrote:

> As the recent contribution shows the commons-math complex library remains
> quite useful to many applications.
>
> Following in the footsteps of commons-rng, commons-complex seems like a
> good next component of math to spin out and actively maintain. I am willing
> to oversee and maintain the project.
>
> It may be that as I get into it, complex will have dependencies that more
> properly belong in a core library. I propose to just get started on the
> library and sort these issues as they come up.
>
> I would take the following positions as regards this library:
>
> - Add syntactic sugar so that typical C++ calls are compatible: yes
> - Keep completely backwards compatible: yes
> - Follow the C++ architecture including an Imaginary data type with its own
> behavior: no
> - Like C++, incorporate complex typing other than double: no
>
> -Eric



--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Emmanuel Bourg-3
Le 25/10/2016 à 17:46, Jochen Wiedmann a écrit :
> Honestly, I really wonder why all this stuff has to fork yet another
> commons component. IMO, CM could just have been changed to emit
> multiple jar files with no need for other components. No need for
> discussions, no need for new repositories in Git, no need for new
> stuff in Jira. Or, to put it different: Less to maintain.

+1

This should have been a module of commons-math, there was no consensus
for a new component.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

dbrosIus
In reply to this post by Eric Barnhill
I think we should let the people doing the work,  decide. 

-------- Original message --------
From: Emmanuel Bourg <[hidden email]>
Date: 10/25/16  11:51 AM  (GMT-05:00)
To: Commons Developers List <[hidden email]>
Subject: Re: [complex] commons-complex module

Le 25/10/2016 à 17:46, Jochen Wiedmann a écrit :
> Honestly, I really wonder why all this stuff has to fork yet another
> commons component. IMO, CM could just have been changed to emit
> multiple jar files with no need for other components. No need for
> discussions, no need for new repositories in Git, no need for new
> stuff in Jira. Or, to put it different: Less to maintain.

+1

This should have been a module of commons-math, there was no consensus
for a new component.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

garydgregory
In reply to this post by jochen-2
On Tue, Oct 25, 2016 at 8:46 AM, Jochen Wiedmann <[hidden email]>
wrote:

> Honestly, I really wonder why all this stuff has to fork yet another
> commons component. IMO, CM could just have been changed to emit
> multiple jar files with no need for other components. No need for
> discussions, no need for new repositories in Git, no need for new
> stuff in Jira. Or, to put it different: Less to maintain.
>

+1

I am against this constant spinning out.

Gary

>
>
>
> On Sat, Oct 22, 2016 at 1:42 PM, Eric Barnhill <[hidden email]>
> wrote:
> > As the recent contribution shows the commons-math complex library remains
> > quite useful to many applications.
> >
> > Following in the footsteps of commons-rng, commons-complex seems like a
> > good next component of math to spin out and actively maintain. I am
> willing
> > to oversee and maintain the project.
> >
> > It may be that as I get into it, complex will have dependencies that more
> > properly belong in a core library. I propose to just get started on the
> > library and sort these issues as they come up.
> >
> > I would take the following positions as regards this library:
> >
> > - Add syntactic sugar so that typical C++ calls are compatible: yes
> > - Keep completely backwards compatible: yes
> > - Follow the C++ architecture including an Imaginary data type with its
> own
> > behavior: no
> > - Like C++, incorporate complex typing other than double: no
> >
> > -Eric
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/
> evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Emmanuel Bourg-3
In reply to this post by dbrosIus
Le 25/10/2016 à 18:20, dbrosIus a écrit :
> I think we should let the people doing the work,  decide.

In general I agree with that, but there is a minimum level of formalism
to follow for creating new components. Otherwise Commons will just turn
into a GitHub/SourceForge clone inside Apache.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
On Tue, 25 Oct 2016 17:51:00 +0200, Emmanuel Bourg wrote:
> Le 25/10/2016 à 17:46, Jochen Wiedmann a écrit :
>> Honestly, I really wonder why all this stuff has to fork yet another
>> commons component. IMO, CM could just have been changed to emit
>> multiple jar files with no need for other components. No need for
>> discussions, no need for new repositories in Git, no need for new
>> stuff in Jira. Or, to put it different: Less to maintain.

I proposed to strip the unsupported parts from the next CM release.
This has been conspicuously ___refused___. Please refer to ML archive.

> +1
>
> This should have been a module of commons-math, there was no
> consensus
> for a new component.

There was a vote. No one opposed it. Please refer to the archive.

Gilles

>
> Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Gilles Sadowski
In reply to this post by garydgregory
On Tue, 25 Oct 2016 10:32:20 -0700, Gary Gregory wrote:

> On Tue, Oct 25, 2016 at 8:46 AM, Jochen Wiedmann
> <[hidden email]>
> wrote:
>
>> Honestly, I really wonder why all this stuff has to fork yet another
>> commons component. IMO, CM could just have been changed to emit
>> multiple jar files with no need for other components. No need for
>> discussions, no need for new repositories in Git, no need for new
>> stuff in Jira. Or, to put it different: Less to maintain.
>>
>
> +1
>
> I am against this constant spinning out.

I've argued that the original mistake was to let CM extend beyond
the stat toolbox it was when the component was created.
Please refer to the ML archive.
The fix is to separate what was never actually a coherent whole
(from the contents, programming style, and management POVs).

If you are against something, you have to provide a technical
argument.  There can be none (see previous paragraph).

This discussion could have been the business of a new TLP (as
promoted by James Carman).
This has been REFUSED.

People are willing to actively create, maintain and use an
eco-system of components on which they are more expert than
anyone else here.
And people who never read a single line from the CM codebase
would just be "against" it?


Gilles

>
> Gary
>
>>
>>
>>
>> On Sat, Oct 22, 2016 at 1:42 PM, Eric Barnhill
>> <[hidden email]>
>> wrote:
>> > As the recent contribution shows the commons-math complex library
>> remains
>> > quite useful to many applications.
>> >
>> > Following in the footsteps of commons-rng, commons-complex seems
>> like a
>> > good next component of math to spin out and actively maintain. I
>> am
>> willing
>> > to oversee and maintain the project.
>> >
>> > It may be that as I get into it, complex will have dependencies
>> that more
>> > properly belong in a core library. I propose to just get started
>> on the
>> > library and sort these issues as they come up.
>> >
>> > I would take the following positions as regards this library:
>> >
>> > - Add syntactic sugar so that typical C++ calls are compatible:
>> yes
>> > - Keep completely backwards compatible: yes
>> > - Follow the C++ architecture including an Imaginary data type
>> with its
>> own
>> > behavior: no
>> > - Like C++, incorporate complex typing other than double: no
>> >
>> > -Eric
>>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Eric Barnhill
In reply to this post by garydgregory
On Tue, Oct 25, 2016 at 7:32 PM, Gary Gregory <[hidden email]>
wrote:

>
> I am against this constant spinning out.
>
> Gary
>
>
The proposed commons-filter is not a spin out. There was one filter in math
and it didn't belong there. Now we have at least couple of people around
who know signal processing and would like to make a commons-filter package.
Virtually none of which is coming from commons-math except dependencies.
Does such a package suit commons? I think so. Filtering is needed from
image processing to statistics. Others can vote no if they disagree.

Complex was in math too. Did it belong there? In C++ or Python, complex is
just another data type, like String. Its placement in math was not
straightforward. A self contained component to handle complex data types
seems more sensible to me than having it in Math. In any case Gilles is
making me a branch to populate, so that I can propose this component later,
IIUC.


Eric
Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

garydgregory
In reply to this post by Gilles Sadowski
I am against spinning out org.apache.commons.math4.complex out into yet
another component. The argument that Gilles refuses to
support org.apache.commons.math4.complex because he does not want to
support all of org.apache.commons.math4 in favor of supporting a COPY
of org.apache.commons.math4.complex into org.apache.commons.complex does
not hold water for me. If I misrepresent, I apologize.

On Tue, Oct 25, 2016 at 11:00 AM, Gilles <[hidden email]>
wrote:

> On Tue, 25 Oct 2016 10:32:20 -0700, Gary Gregory wrote:
>
>> On Tue, Oct 25, 2016 at 8:46 AM, Jochen Wiedmann <
>> [hidden email]>
>> wrote:
>>
>> Honestly, I really wonder why all this stuff has to fork yet another
>>> commons component. IMO, CM could just have been changed to emit
>>> multiple jar files with no need for other components. No need for
>>> discussions, no need for new repositories in Git, no need for new
>>> stuff in Jira. Or, to put it different: Less to maintain.
>>>
>>>
>> +1
>>
>> I am against this constant spinning out.
>>
>
> I've argued that the original mistake was to let CM extend beyond
> the stat toolbox it was when the component was created.
> Please refer to the ML archive.
>

That's way in the past and we have math3 and math4 now.


> The fix is to separate what was never actually a coherent whole
> (from the contents, programming style, and management POVs).
>

That's not a "fix". That's a complete re-architecting, hence perhaps the
"H" project.


> If you are against something, you have to provide a technical
> argument.  There can be none (see previous paragraph).
>

What you provide is not a technical argument, it's an opinion, IMO ;-)

Moving code around and putting bits in different buckets is not a technical
argument IMO. That's just managing deliverables, which is worth talking
about.

Gary


>
> This discussion could have been the business of a new TLP (as
> promoted by James Carman).
> This has been REFUSED.
>
> People are willing to actively create, maintain and use an
> eco-system of components on which they are more expert than
> anyone else here.
> And people who never read a single line from the CM codebase
> would just be "against" it?
>
>
> Gilles
>
>
>> Gary
>>
>>
>>>
>>>
>>> On Sat, Oct 22, 2016 at 1:42 PM, Eric Barnhill <[hidden email]>
>>> wrote:
>>> > As the recent contribution shows the commons-math complex library
>>> remains
>>> > quite useful to many applications.
>>> >
>>> > Following in the footsteps of commons-rng, commons-complex seems like a
>>> > good next component of math to spin out and actively maintain. I am
>>> willing
>>> > to oversee and maintain the project.
>>> >
>>> > It may be that as I get into it, complex will have dependencies that
>>> more
>>> > properly belong in a core library. I propose to just get started on the
>>> > library and sort these issues as they come up.
>>> >
>>> > I would take the following positions as regards this library:
>>> >
>>> > - Add syntactic sugar so that typical C++ calls are compatible: yes
>>> > - Keep completely backwards compatible: yes
>>> > - Follow the C++ architecture including an Imaginary data type with its
>>> own
>>> > behavior: no
>>> > - Like C++, incorporate complex typing other than double: no
>>> >
>>> > -Eric
>>>
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

garydgregory
In reply to this post by Eric Barnhill
On Tue, Oct 25, 2016 at 12:07 PM, Eric Barnhill <[hidden email]>
wrote:

> On Tue, Oct 25, 2016 at 7:32 PM, Gary Gregory <[hidden email]>
> wrote:
>
> >
> > I am against this constant spinning out.
> >
> > Gary
> >
> >
> The proposed commons-filter is not a spin out. There was one filter in math
> and it didn't belong there. Now we have at least couple of people around
> who know signal processing and would like to make a commons-filter package.
> Virtually none of which is coming from commons-math except dependencies.
> Does such a package suit commons? I think so. Filtering is needed from
> image processing to statistics. Others can vote no if they disagree.
>
> Complex was in math too. Did it belong there? In C++ or Python, complex is
> just another data type, like String. Its placement in math was not
> straightforward. A self contained component to handle complex data types
> seems more sensible to me than having it in Math. In any case Gilles is
> making me a branch to populate, so that I can propose this component later,
> IIUC.
>

It sounds like you can create your new component on top of math4, correct?
You do not need anything else? Aside from a better component name IMO.
"filter" is way to generic for me.

Gary

>
>
> Eric
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Bernd Porr
Hi all,

I agree that 'filter' is slightly problematic but I'd say because it's
been used in different contexts and often misleading. However, I cannot
think of a better word. That also depends where we place 2D image
processing. They are also called filters. For IIR , Kalman(and possibly
FIR) filters these are causal digital filters as they essentially behave
as an analogue circuit in a digital form. For the casual (!) user of
filters they'd probably just look for a filter...

/Bernd

On 25-Oct-16 23:00, Gary Gregory wrote:

> On Tue, Oct 25, 2016 at 12:07 PM, Eric Barnhill <[hidden email]>
> wrote:
>
>> On Tue, Oct 25, 2016 at 7:32 PM, Gary Gregory <[hidden email]>
>> wrote:
>>
>>> I am against this constant spinning out.
>>>
>>> Gary
>>>
>>>
>> The proposed commons-filter is not a spin out. There was one filter in math
>> and it didn't belong there. Now we have at least couple of people around
>> who know signal processing and would like to make a commons-filter package.
>> Virtually none of which is coming from commons-math except dependencies.
>> Does such a package suit commons? I think so. Filtering is needed from
>> image processing to statistics. Others can vote no if they disagree.
>>
>> Complex was in math too. Did it belong there? In C++ or Python, complex is
>> just another data type, like String. Its placement in math was not
>> straightforward. A self contained component to handle complex data types
>> seems more sensible to me than having it in Math. In any case Gilles is
>> making me a branch to populate, so that I can propose this component later,
>> IIUC.
>>
> It sounds like you can create your new component on top of math4, correct?
> You do not need anything else? Aside from a better component name IMO.
> "filter" is way to generic for me.
>
> Gary
>
>>
>> Eric
>>
>
>

--
http://www.eigenproductions.co.uk
http://www.linux-usb-daq.co.uk
http://www.berndporr.me.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Gilles Sadowski
In reply to this post by garydgregory
Hi Gary.

On Tue, 25 Oct 2016 14:59:27 -0700, Gary Gregory wrote:
> I am against spinning out org.apache.commons.math4.complex out into
> yet
> another component. The argument that Gilles refuses to
> support org.apache.commons.math4.complex because he does not want to
> support all of org.apache.commons.math4 in favor of supporting a COPY
> of org.apache.commons.math4.complex into org.apache.commons.complex
> does
> not hold water for me. If I misrepresent, I apologize.

You do misrepresent.
And I've a hard time accepting apologies since you and others make
me repeat, ad nauseum, my technical arguments (of which truthfulness
to the Apache way, as regularly reminded by Dave, is an essential
part).

> On Tue, Oct 25, 2016 at 11:00 AM, Gilles
> <[hidden email]>
> wrote:
>
>> On Tue, 25 Oct 2016 10:32:20 -0700, Gary Gregory wrote:
>>
>>> On Tue, Oct 25, 2016 at 8:46 AM, Jochen Wiedmann <
>>> [hidden email]>
>>> wrote:
>>>
>>> Honestly, I really wonder why all this stuff has to fork yet
>>> another
>>>> commons component. IMO, CM could just have been changed to emit
>>>> multiple jar files with no need for other components. No need for
>>>> discussions, no need for new repositories in Git, no need for new
>>>> stuff in Jira. Or, to put it different: Less to maintain.
>>>>
>>>>
>>> +1
>>>
>>> I am against this constant spinning out.
>>>
>>
>> I've argued that the original mistake was to let CM extend beyond
>> the stat toolbox it was when the component was created.
>> Please refer to the ML archive.
>>
>
> That's way in the past and we have math3 and math4 now.

Sure, way in the past was the mistake, which the CM team always
refused to tackle.
As long as they were regular contributors, their opinion was
essential to the continuation of CM.

It is a distinctive feature of this PMC, that people who do not
did any of the work, neither before the fork, nor after, think
they are right to block, for months now, the continuation of an
alternative project.

There cannot be a consensus of you forcing us do what we
consider is heading in the wrong direction, on the basis that
still others (who have now left the project) took some decisions
way in the past.

>> The fix is to separate what was never actually a coherent whole
>> (from the contents, programming style, and management POVs).
>>
>
> That's not a "fix". That's a complete re-architecting,

Yes.
I proposed to do it inside CM.

It was refused; and there is a _valid_ argument that it was not
necessary to perform the re-design within the CM component: leave
open the possibility that an alternative team wants to take it
over from there.
It just happens that for now there is nobody in that team.
Those in the PMC who favor that alternative did not do anything
to make it more than a pipe-dream.

> hence perhaps the
> "H" project.

Certainly not: that project continues on the same road which I
pointedly want us to leave.
[Which the notable exceptions that they made some changes which
they refused to do when in "Commons"!]

I've argued why we cannot do what they do (see the archives).

>> If you are against something, you have to provide a technical
>> argument.  There can be none (see previous paragraph).
>>
>
> What you provide is not a technical argument, it's an opinion, IMO
> ;-)

How so?

>
> Moving code around and putting bits in different buckets is not a
> technical
> argument IMO. That's just managing deliverables, which is worth
> talking
> about.

It's partly that, indeed, but hardly only that.
For the n-th time: what is at stake is the "liveness" of a project
that had a lot of good code within it, but that never succeeded
in attracting a diverse community because, because... well see the
archives!

Gilles


> Gary
>
>
>>
>> This discussion could have been the business of a new TLP (as
>> promoted by James Carman).
>> This has been REFUSED.
>>
>> People are willing to actively create, maintain and use an
>> eco-system of components on which they are more expert than
>> anyone else here.
>> And people who never read a single line from the CM codebase
>> would just be "against" it?
>>
>>
>> Gilles
>>
>>
>>> Gary
>>>
>>>
>>>>
>>>>
>>>> On Sat, Oct 22, 2016 at 1:42 PM, Eric Barnhill
>>>> <[hidden email]>
>>>> wrote:
>>>> > As the recent contribution shows the commons-math complex
>>>> library
>>>> remains
>>>> > quite useful to many applications.
>>>> >
>>>> > Following in the footsteps of commons-rng, commons-complex seems
>>>> like a
>>>> > good next component of math to spin out and actively maintain. I
>>>> am
>>>> willing
>>>> > to oversee and maintain the project.
>>>> >
>>>> > It may be that as I get into it, complex will have dependencies
>>>> that
>>>> more
>>>> > properly belong in a core library. I propose to just get started
>>>> on the
>>>> > library and sort these issues as they come up.
>>>> >
>>>> > I would take the following positions as regards this library:
>>>> >
>>>> > - Add syntactic sugar so that typical C++ calls are compatible:
>>>> yes
>>>> > - Keep completely backwards compatible: yes
>>>> > - Follow the C++ architecture including an Imaginary data type
>>>> with its
>>>> own
>>>> > behavior: no
>>>> > - Like C++, incorporate complex typing other than double: no
>>>> >
>>>> > -Eric


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Gilles Sadowski
In reply to this post by garydgregory
On Tue, 25 Oct 2016 15:00:55 -0700, Gary Gregory wrote:

> On Tue, Oct 25, 2016 at 12:07 PM, Eric Barnhill
> <[hidden email]>
> wrote:
>
>> On Tue, Oct 25, 2016 at 7:32 PM, Gary Gregory
>> <[hidden email]>
>> wrote:
>>
>> >
>> > I am against this constant spinning out.
>> >
>> > Gary
>> >
>> >
>> The proposed commons-filter is not a spin out. There was one filter
>> in math
>> and it didn't belong there. Now we have at least couple of people
>> around
>> who know signal processing and would like to make a commons-filter
>> package.
>> Virtually none of which is coming from commons-math except
>> dependencies.
>> Does such a package suit commons? I think so. Filtering is needed
>> from
>> image processing to statistics. Others can vote no if they disagree.
>>
>> Complex was in math too. Did it belong there? In C++ or Python,
>> complex is
>> just another data type, like String. Its placement in math was not
>> straightforward. A self contained component to handle complex data
>> types
>> seems more sensible to me than having it in Math. In any case Gilles
>> is
>> making me a branch to populate, so that I can propose this component
>> later,
>> IIUC.
>>
>
> It sounds like you can create your new component on top of math4,
> correct?

Would you rather reply to the technical arguments put forward in the
preceding paragraph?

I've already answered your question many times (see the archive).

> You do not need anything else? Aside from a better component name
> IMO.
> "filter" is way to generic for me.

Is that the crux of the matter?
"Math" wasn't too generic perhaps?

Gilles

>
> Gary
>
>>
>>
>> Eric
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Eric Barnhill
On Wed, Oct 26, 2016 at 2:25 PM, Gilles <[hidden email]>
wrote:

>
>> It sounds like you can create your new component on top of math4, correct?
>>
>
> Would you rather reply to the technical arguments put forward in the
> preceding paragraph?
>
> I've already answered your question many times (see the archive).
>
> You do not need anything else? Aside from a better component name IMO.
>> "filter" is way to generic for me.
>>
>
> Is that the crux of the matter?
> "Math" wasn't too generic perhaps?
>
> Gilles


Hi Gilles, I read this email differently than you. My understanding is that
Gary is open to a filter subproject but would just like a different name
(to which Bernd replied).

But, I don't really know what he meant by the expression "built on top of
math 4". I did not interpret it as putting all these new modules in math4 .

Eric
Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Gilles Sadowski
Hi Eric.

On Wed, 26 Oct 2016 14:48:17 +0200, Eric Barnhill wrote:

> On Wed, Oct 26, 2016 at 2:25 PM, Gilles
> <[hidden email]>
> wrote:
>
>>
>>> It sounds like you can create your new component on top of math4,
>>> correct?
>>>
>>
>> Would you rather reply to the technical arguments put forward in the
>> preceding paragraph?
>>
>> I've already answered your question many times (see the archive).
>>
>> You do not need anything else? Aside from a better component name
>> IMO.
>>> "filter" is way to generic for me.
>>>
>>
>> Is that the crux of the matter?
>> "Math" wasn't too generic perhaps?
>>
>> Gilles
>
>
> Hi Gilles, I read this email differently than you. My understanding
> is that
> Gary is open to a filter subproject

That is not clear either.
[In the same way that nobody argued (no "-1") against a "complex"
component when a vote took place nearly 4 months ago.]

> but would just like a different name
> (to which Bernd replied).

I wanted to note that some people view the same things with
different glasses, depending on how involved they are in the
projects.

> But, I don't really know what he meant by the expression "built on
> top of
> math 4".

As I indicated in the other post, I interpret this as forcing
the current volunteers, who happen to use or want to maintain
a _tiny_ part of what is in CM, to take upon themselves the work
that would be required to modularize/maintain/release the whole
of CM.

If the last 10 months are any representative sample, this won't
happen, and consequently, the components which you, Bernd and
Arne are considering, will never be released either, unless you
copy/paste the CM "complex"-related codes into that component
(which I obviously do not recommend).

The question is: Why do some PMC members refuse to let us create
those components?
How is <any other Commons project> a better "component" than
"Commons Complex" would be?

> I did not interpret it as putting all these new modules in math4 .

I'm pretty sure that if you proposed to put them there it would
have been enthusiastically accepted...
Fortunately (for this project), on this "filter" matter, experts
argue that this is not the right way to go.


Gilles

P.S. The same arguments will apply to Artem's proposed component
      ("clustering" based on CM's "o.a.c.m.ml" package).

>
> Eric


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Benedikt Ritter-4
In reply to this post by dbrosIus
dbrosIus <[hidden email]> schrieb am Di., 25. Okt. 2016 um
18:26 Uhr:

> I think we should let the people doing the work,  decide.
>

I agree with David. Apache is a Do-ocracy.

Nevertheless I think we should focus on finishing the first release of RNG
instead of starting of the next component. we already have some proper
components who have never seen a release (imaging, functor, OGNL 4.0) and I
don't want the new math components to have the same fate.

Benedikt


>
> -------- Original message --------
> From: Emmanuel Bourg <[hidden email]>
> Date: 10/25/16  11:51 AM  (GMT-05:00)
> To: Commons Developers List <[hidden email]>
> Subject: Re: [complex] commons-complex module
>
> Le 25/10/2016 à 17:46, Jochen Wiedmann a écrit :
> > Honestly, I really wonder why all this stuff has to fork yet another
> > commons component. IMO, CM could just have been changed to emit
> > multiple jar files with no need for other components. No need for
> > discussions, no need for new repositories in Git, no need for new
> > stuff in Jira. Or, to put it different: Less to maintain.
>
> +1
>
> This should have been a module of commons-math, there was no consensus
> for a new component.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Rob Tompkins
In reply to this post by garydgregory

> On Oct 25, 2016, at 5:59 PM, Gary Gregory <[hidden email]> wrote:
>
> I am against spinning out org.apache.commons.math4.complex out into yet
> another component. The argument that Gilles refuses to
> support org.apache.commons.math4.complex because he does not want to
> support all of org.apache.commons.math4 in favor of supporting a COPY
> of org.apache.commons.math4.complex into org.apache.commons.complex does
> not hold water for me. If I misrepresent, I apologize.

I’ve been thinking about this some over the last few days, and it occurs to me that we can accomplish all this modularization within "commons-math.” Might we consider creating all of the sub-modules within the math repository as sub-jars?

I think Gilles’ point would then be that we can’t independently release each artifact and have to maintain all of the other code in doing this. So, let’s consider the following proposal to see if it accomplishes what Gilles desires with independent releasability:

(1) We assume that an un-changed sub-jar can be released as many times as we wish. (For the time being let’s assume that we release it all with a single version on all of the sub-jars even if they are unchanged in the release).
(2) We create a single master line intended just for creating releases that we do no work on.
(3) We have a branch associated for the development work on each of the independent sub-jars which we clearly would need to update update upon a release of the master branch.
(4) When creating a release, we merge a sub-jar branch into the master branch and attempt a release (and roll that back out of master if the release fails).

By doing this I think we can independently release sub-jars and don’t have to worry about the maintenance of the other portions of the code when doing a release because those portions will remain unchanged. Now, versioning could be a little difficult here, but I think that’s probably a problem we could solve moving forward.

Any thoughts?

Cheers,
-Rob

>
> On Tue, Oct 25, 2016 at 11:00 AM, Gilles <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>> On Tue, 25 Oct 2016 10:32:20 -0700, Gary Gregory wrote:
>>
>>> On Tue, Oct 25, 2016 at 8:46 AM, Jochen Wiedmann <
>>> [hidden email]>
>>> wrote:
>>>
>>> Honestly, I really wonder why all this stuff has to fork yet another
>>>> commons component. IMO, CM could just have been changed to emit
>>>> multiple jar files with no need for other components. No need for
>>>> discussions, no need for new repositories in Git, no need for new
>>>> stuff in Jira. Or, to put it different: Less to maintain.
>>>>
>>>>
>>> +1
>>>
>>> I am against this constant spinning out.
>>>
>>
>> I've argued that the original mistake was to let CM extend beyond
>> the stat toolbox it was when the component was created.
>> Please refer to the ML archive.
>>
>
> That's way in the past and we have math3 and math4 now.
>
>
>> The fix is to separate what was never actually a coherent whole
>> (from the contents, programming style, and management POVs).
>>
>
> That's not a "fix". That's a complete re-architecting, hence perhaps the
> "H" project.
>
>
>> If you are against something, you have to provide a technical
>> argument.  There can be none (see previous paragraph).
>>
>
> What you provide is not a technical argument, it's an opinion, IMO ;-)
>
> Moving code around and putting bits in different buckets is not a technical
> argument IMO. That's just managing deliverables, which is worth talking
> about.
>
> Gary
>
>
>>
>> This discussion could have been the business of a new TLP (as
>> promoted by James Carman).
>> This has been REFUSED.
>>
>> People are willing to actively create, maintain and use an
>> eco-system of components on which they are more expert than
>> anyone else here.
>> And people who never read a single line from the CM codebase
>> would just be "against" it?
>>
>>
>> Gilles
>>
>>
>>> Gary
>>>
>>>
>>>>
>>>>
>>>> On Sat, Oct 22, 2016 at 1:42 PM, Eric Barnhill <[hidden email]>
>>>> wrote:
>>>>> As the recent contribution shows the commons-math complex library
>>>> remains
>>>>> quite useful to many applications.
>>>>>
>>>>> Following in the footsteps of commons-rng, commons-complex seems like a
>>>>> good next component of math to spin out and actively maintain. I am
>>>> willing
>>>>> to oversee and maintain the project.
>>>>>
>>>>> It may be that as I get into it, complex will have dependencies that
>>>> more
>>>>> properly belong in a core library. I propose to just get started on the
>>>>> library and sort these issues as they come up.
>>>>>
>>>>> I would take the following positions as regards this library:
>>>>>
>>>>> - Add syntactic sugar so that typical C++ calls are compatible: yes
>>>>> - Keep completely backwards compatible: yes
>>>>> - Follow the C++ architecture including an Imaginary data type with its
>>>> own
>>>>> behavior: no
>>>>> - Like C++, incorporate complex typing other than double: no
>>>>>
>>>>> -Eric
>>>>
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> E-Mail: [hidden email] <mailto:[hidden email]> | [hidden email] <mailto:[hidden email]>
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8 <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>>
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Reply | Threaded
Open this post in threaded view
|

Re: [complex] commons-complex module

Bernd Porr
In reply to this post by Eric Barnhill
Hi Eric,

how do we move this forward? I cannot commit to the CVS so shall I send
you patches and you work them in or what is the workflow?

Best
/Bernd

On 26/10/16 13:48, Eric Barnhill wrote:

> On Wed, Oct 26, 2016 at 2:25 PM, Gilles <[hidden email]>
> wrote:
>
>>
>>> It sounds like you can create your new component on top of math4, correct?
>>>
>>
>> Would you rather reply to the technical arguments put forward in the
>> preceding paragraph?
>>
>> I've already answered your question many times (see the archive).
>>
>> You do not need anything else? Aside from a better component name IMO.
>>> "filter" is way to generic for me.
>>>
>>
>> Is that the crux of the matter?
>> "Math" wasn't too generic perhaps?
>>
>> Gilles
>
>
> Hi Gilles, I read this email differently than you. My understanding is that
> Gary is open to a filter subproject but would just like a different name
> (to which Bernd replied).
>
> But, I don't really know what he meant by the expression "built on top of
> math 4". I did not interpret it as putting all these new modules in math4 .
>
> Eric
>

--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12