[Math] Getting things done

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

[Math] Getting things done

jochen-2
Hi,

I'd like an attempt to put an end to all those discussions regarding
Commons Math (CM). That means, in particular, that we find an common
agreement on a course of action. So, here's a suggestion (might as
well call it an offer, because acceptance would mean a lot of work on
my side)

  1.) I'll write a proposal to move CM to the Incubator.
  2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
  3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
  4.) If the board accepts the TLP: Very well.
  5.) If not: So what. Now we know, at least.

In either case: At the end of the procedure, we'd have clarity. This
will allow us to focus on a smaller set of issues (technical), and we
can go on.

The important part, to me, is to find something on which we can agree.
That doesn't mean that everyone is happy with the outcome, but that
everyone's got the feeling "I can live with that". In particular,
there must not be any serious opposition later on. If you'd like to
oppose: Please do so here, and now.

Thanks,

Jochen



--
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: [Math] Getting things done

Ralph Goers
+1 - Go for it!

Ralph

> On Jun 23, 2016, at 5:33 AM, Jochen Wiedmann <[hidden email]> wrote:
>
> Hi,
>
> I'd like an attempt to put an end to all those discussions regarding
> Commons Math (CM). That means, in particular, that we find an common
> agreement on a course of action. So, here's a suggestion (might as
> well call it an offer, because acceptance would mean a lot of work on
> my side)
>
>  1.) I'll write a proposal to move CM to the Incubator.
>  2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>  3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>  4.) If the board accepts the TLP: Very well.
>  5.) If not: So what. Now we know, at least.
>
> In either case: At the end of the procedure, we'd have clarity. This
> will allow us to focus on a smaller set of issues (technical), and we
> can go on.
>
> The important part, to me, is to find something on which we can agree.
> That doesn't mean that everyone is happy with the outcome, but that
> everyone's got the feeling "I can live with that". In particular,
> there must not be any serious opposition later on. If you'd like to
> oppose: Please do so here, and now.
>
> Thanks,
>
> Jochen
>
>
>
> --
> 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]
>
>



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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Eric Barnhill
In reply to this post by jochen-2
There has been a lot of support in the discussions for, as Emmanuel put it,
a "base commons-math
component".

Where does that factor into this proposal?

On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann <[hidden email]>
wrote:

> Hi,
>
> I'd like an attempt to put an end to all those discussions regarding
> Commons Math (CM). That means, in particular, that we find an common
> agreement on a course of action. So, here's a suggestion (might as
> well call it an offer, because acceptance would mean a lot of work on
> my side)
>
>   1.) I'll write a proposal to move CM to the Incubator.
>   2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>   3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>   4.) If the board accepts the TLP: Very well.
>   5.) If not: So what. Now we know, at least.
>
> In either case: At the end of the procedure, we'd have clarity. This
> will allow us to focus on a smaller set of issues (technical), and we
> can go on.
>
> The important part, to me, is to find something on which we can agree.
> That doesn't mean that everyone is happy with the outcome, but that
> everyone's got the feeling "I can live with that". In particular,
> there must not be any serious opposition later on. If you'd like to
> oppose: Please do so here, and now.
>
> Thanks,
>
> Jochen
>
>
>
> --
> 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: [Math] Getting things done

jochen-2
It doesn't, at least in my opinion. If the future Math project decides
to have a "base" component: Very well. But, if the other components
are elsewhere: Why should the base stay at Commons?


On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill <[hidden email]> wrote:

> There has been a lot of support in the discussions for, as Emmanuel put it,
> a "base commons-math
> component".
>
> Where does that factor into this proposal?
>
> On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann <[hidden email]>
> wrote:
>
>> Hi,
>>
>> I'd like an attempt to put an end to all those discussions regarding
>> Commons Math (CM). That means, in particular, that we find an common
>> agreement on a course of action. So, here's a suggestion (might as
>> well call it an offer, because acceptance would mean a lot of work on
>> my side)
>>
>>   1.) I'll write a proposal to move CM to the Incubator.
>>   2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>>   3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>>   4.) If the board accepts the TLP: Very well.
>>   5.) If not: So what. Now we know, at least.
>>
>> In either case: At the end of the procedure, we'd have clarity. This
>> will allow us to focus on a smaller set of issues (technical), and we
>> can go on.
>>
>> The important part, to me, is to find something on which we can agree.
>> That doesn't mean that everyone is happy with the outcome, but that
>> everyone's got the feeling "I can live with that". In particular,
>> there must not be any serious opposition later on. If you'd like to
>> oppose: Please do so here, and now.
>>
>> Thanks,
>>
>> Jochen
>>
>>
>>
>> --
>> 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]
>>
>>



--
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: [Math] Getting things done

Ralph Goers
My answer would be slightly different.  It doesn’t. All topics related to the code should be deferred until we know what is happening with the community.

Ralph

> On Jun 23, 2016, at 5:50 AM, Jochen Wiedmann <[hidden email]> wrote:
>
> It doesn't, at least in my opinion. If the future Math project decides
> to have a "base" component: Very well. But, if the other components
> are elsewhere: Why should the base stay at Commons?
>
>
> On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill <[hidden email]> wrote:
>> There has been a lot of support in the discussions for, as Emmanuel put it,
>> a "base commons-math
>> component".
>>
>> Where does that factor into this proposal?
>>
>> On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann <[hidden email]>
>> wrote:
>>
>>> Hi,
>>>
>>> I'd like an attempt to put an end to all those discussions regarding
>>> Commons Math (CM). That means, in particular, that we find an common
>>> agreement on a course of action. So, here's a suggestion (might as
>>> well call it an offer, because acceptance would mean a lot of work on
>>> my side)
>>>
>>>  1.) I'll write a proposal to move CM to the Incubator.
>>>  2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>>>  3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>>>  4.) If the board accepts the TLP: Very well.
>>>  5.) If not: So what. Now we know, at least.
>>>
>>> In either case: At the end of the procedure, we'd have clarity. This
>>> will allow us to focus on a smaller set of issues (technical), and we
>>> can go on.
>>>
>>> The important part, to me, is to find something on which we can agree.
>>> That doesn't mean that everyone is happy with the outcome, but that
>>> everyone's got the feeling "I can live with that". In particular,
>>> there must not be any serious opposition later on. If you'd like to
>>> oppose: Please do so here, and now.
>>>
>>> Thanks,
>>>
>>> Jochen
>>>
>>>
>>>
>>> --
>>> 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]
>>>
>>>
>
>
>
> --
> 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]
>
>



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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Dave Brosius-2
I realize there are good intentions here. But what the common theme of
all these email chains, when you filter out the disagreements, is,
"deferred until"

If 'deferring' is the only thing we can agree on, i think something is
broken with the system.

IMO let the doers do. Clearly Gilles is the main driver of change. It
appears he now has some people who will help at least to some extent,
but he has shown over last half year (at least) that he will be the
primary one to move the code base.

I would just have Gilles (and friends) go ahead and make the changes he
feels are the right direction. If he were to take an inordinate dump in
the code base (he won't), or walk away with it half-baked (he won't),
the next person along, if ever, just can go back to an earlier branch
point and start again.

But we are supposed to be a meritocracy, not an oligarchy. It feels much
like that later at the moment.

dave

On 06/23/2016 08:53 AM, Ralph Goers wrote:

> My answer would be slightly different.  It doesn’t. All topics related to the code should be deferred until we know what is happening with the community.
>
> Ralph
>
>> On Jun 23, 2016, at 5:50 AM, Jochen Wiedmann <[hidden email]> wrote:
>>
>> It doesn't, at least in my opinion. If the future Math project decides
>> to have a "base" component: Very well. But, if the other components
>> are elsewhere: Why should the base stay at Commons?
>>
>>
>> On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill <[hidden email]> wrote:
>>> There has been a lot of support in the discussions for, as Emmanuel put it,
>>> a "base commons-math
>>> component".
>>>
>>> Where does that factor into this proposal?
>>>
>>> On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann <[hidden email]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'd like an attempt to put an end to all those discussions regarding
>>>> Commons Math (CM). That means, in particular, that we find an common
>>>> agreement on a course of action. So, here's a suggestion (might as
>>>> well call it an offer, because acceptance would mean a lot of work on
>>>> my side)
>>>>
>>>>   1.) I'll write a proposal to move CM to the Incubator.
>>>>   2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>>>>   3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>>>>   4.) If the board accepts the TLP: Very well.
>>>>   5.) If not: So what. Now we know, at least.
>>>>
>>>> In either case: At the end of the procedure, we'd have clarity. This
>>>> will allow us to focus on a smaller set of issues (technical), and we
>>>> can go on.
>>>>
>>>> The important part, to me, is to find something on which we can agree.
>>>> That doesn't mean that everyone is happy with the outcome, but that
>>>> everyone's got the feeling "I can live with that". In particular,
>>>> there must not be any serious opposition later on. If you'd like to
>>>> oppose: Please do so here, and now.
>>>>
>>>> Thanks,
>>>>
>>>> Jochen
>>>>
>>>>
>>>>
>>>> --
>>>> 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]
>>>>
>>>>
>>
>>
>> --
>> 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]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Eric Barnhill
In reply to this post by Ralph Goers
Thank you for the clarification.

I like the idea of a commons-math base component, suiting the commons
mission.

If commons math were transmuted to a large scale new math project, that
competes with Hipparchus. Both projects are forks of the same scope and at
the same time. But in the Hipparchus case, the decisions are made by the
people who contribute to the library, and further, there are (I gather)
more very experienced contributors. Here the decisions on math are mostly
not made by people who contribute to math, and the experienced contributors
have dwindled.

I'm sorry but I think the reality is that such a project won't compete.
Certainly if I had to choose, I would probably prefer the other fork,
though in reality without commons-math I would just move my energies to GNU
Octave and ImageJ.

Gilles does not think that the new project will compete either. In
response, Gilles is trying to reshape commons-math in a way that will have
an important and unique place in the world and attract users, uses and
support. This is a code base that interweaves successfully with the commons
mission and code base, with the potential for growth in the form of small
auxiliary modules driven by enthusiasts.

A base commons-math could draw broad support from the community for some
relatively easy to maintain components that really are in common use as the
enthusiasts come and go. Personally, this suits my interests which are not
extravagantly mathematical. I really just want to smooth the terrain
between commons, ImageJ, GNU Octave, and JoCL to maximize my open source
scientific computing pleasure. I'm just as likely to contribute to
commons-lang if that aids these goals. I can only speak for myself of
course.

Maybe four simultaneous votes was not the smoothest way to continue but it
allows Gilles to get going, while the iron is hot. No one has voted -1 so
perhaps Gilles should start the branch and let us know what it is.

I don't anticipate posting any more comments on these matters, but if
Gilles starts a new branch I will show up for work.

Eric


On Thu, Jun 23, 2016 at 2:53 PM, Ralph Goers <[hidden email]>
wrote:

> My answer would be slightly different.  It doesn’t. All topics related to
> the code should be deferred until we know what is happening with the
> community.
>
> Ralph
>
> > On Jun 23, 2016, at 5:50 AM, Jochen Wiedmann <[hidden email]>
> wrote:
> >
> > It doesn't, at least in my opinion. If the future Math project decides
> > to have a "base" component: Very well. But, if the other components
> > are elsewhere: Why should the base stay at Commons?
> >
> >
> > On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill <[hidden email]>
> wrote:
> >> There has been a lot of support in the discussions for, as Emmanuel put
> it,
> >> a "base commons-math
> >> component".
> >>
> >> Where does that factor into this proposal?
> >>
> >> On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann <
> [hidden email]>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> I'd like an attempt to put an end to all those discussions regarding
> >>> Commons Math (CM). That means, in particular, that we find an common
> >>> agreement on a course of action. So, here's a suggestion (might as
> >>> well call it an offer, because acceptance would mean a lot of work on
> >>> my side)
> >>>
> >>>  1.) I'll write a proposal to move CM to the Incubator.
> >>>  2.) We'll wait for the Incubators decision. If the Incubator accepts
> CM.
> >>>  3.) If the Incubator rejects CM, then I'd start another formal TLP
> vote.
> >>>  4.) If the board accepts the TLP: Very well.
> >>>  5.) If not: So what. Now we know, at least.
> >>>
> >>> In either case: At the end of the procedure, we'd have clarity. This
> >>> will allow us to focus on a smaller set of issues (technical), and we
> >>> can go on.
> >>>
> >>> The important part, to me, is to find something on which we can agree.
> >>> That doesn't mean that everyone is happy with the outcome, but that
> >>> everyone's got the feeling "I can live with that". In particular,
> >>> there must not be any serious opposition later on. If you'd like to
> >>> oppose: Please do so here, and now.
> >>>
> >>> Thanks,
> >>>
> >>> Jochen
> >>>
> >>>
> >>>
> >>> --
> >>> 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]
> >>>
> >>>
> >
> >
> >
> > --
> > 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]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Emmanuel Bourg-3
In reply to this post by jochen-2
Le 23/06/2016 à 14:33, Jochen Wiedmann a écrit :

> The important part, to me, is to find something on which we can agree.
> That doesn't mean that everyone is happy with the outcome, but that
> everyone's got the feeling "I can live with that". In particular,
> there must not be any serious opposition later on. If you'd like to
> oppose: Please do so here, and now.

Thank you for proposing a plan Jochen. I'm certainly in the "I can live
with that" category, but I'm a bit skeptical about the outcome. Neither
the incubator nor a TLP sound viable to me at this point, because the
community around commons-math hasn't recovered from the loss of its
historical contributors. I'd would rather incubate the Math TLP within
Commons until more contributors like Eric join the party.

Because the best way to attract developers is to release something
useful, I'd suggest releasing as soon as possible something derived from
the current Commons Math 4 base:
- commons-random: with the random number generators
- commons-math4: with the core math utilities (fractions, complex,
fastmath, stats, FFT, etc) and leaving out the orphaned parts judged too
specialized like the genetic algorithms.

The core commons-math4 may contain "unsupported" parts as long as they
are properly covered by unit tests and not too specialized.

Does this sound like an acceptable compromise?

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Rob Tompkins
In reply to this post by jochen-2
+1 - Tell me how I can help. I like the idea that we contribute a (or some) component(s) back to commons, but I think it makes a lot of sense to just work towards community future state before concerning ourselves with code future state, as that will happen naturally over time.

-Rob

> On Jun 23, 2016, at 8:33 AM, Jochen Wiedmann <[hidden email]> wrote:
>
> Hi,
>
> I'd like an attempt to put an end to all those discussions regarding
> Commons Math (CM). That means, in particular, that we find an common
> agreement on a course of action. So, here's a suggestion (might as
> well call it an offer, because acceptance would mean a lot of work on
> my side)
>
>  1.) I'll write a proposal to move CM to the Incubator.
>  2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>  3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>  4.) If the board accepts the TLP: Very well.
>  5.) If not: So what. Now we know, at least.
>
> In either case: At the end of the procedure, we'd have clarity. This
> will allow us to focus on a smaller set of issues (technical), and we
> can go on.
>
> The important part, to me, is to find something on which we can agree.
> That doesn't mean that everyone is happy with the outcome, but that
> everyone's got the feeling "I can live with that". In particular,
> there must not be any serious opposition later on. If you'd like to
> oppose: Please do so here, and now.
>
> Thanks,
>
> Jochen
>
>
>
> --
> 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]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Gilles Sadowski
In reply to this post by jochen-2
Hello.

On Thu, 23 Jun 2016 14:33:05 +0200, Jochen Wiedmann wrote:

> Hi,
>
> I'd like an attempt to put an end to all those discussions regarding
> Commons Math (CM). That means, in particular, that we find an common
> agreement on a course of action. So, here's a suggestion (might as
> well call it an offer, because acceptance would mean a lot of work on
> my side)
>
>   1.) I'll write a proposal to move CM to the Incubator.
>   2.) We'll wait for the Incubators decision. If the Incubator
> accepts CM.
>   3.) If the Incubator rejects CM, then I'd start another formal TLP
> vote.
>   4.) If the board accepts the TLP: Very well.
>   5.) If not: So what. Now we know, at least.
>
> In either case: At the end of the procedure, we'd have clarity. This
> will allow us to focus on a smaller set of issues (technical), and we
> can go on.
>
> The important part, to me, is to find something on which we can
> agree.
> That doesn't mean that everyone is happy with the outcome, but that
> everyone's got the feeling "I can live with that". In particular,
> there must not be any serious opposition later on. If you'd like to
> oppose: Please do so here, and now.

Thanks for a constructive proposal.

But as you indicated, this means a lot of administrative work whose
ultimate result is far from being certain.
In particular, people have quite clearly pointed out that the incubator
  * is a place for community building
  * not a place to rethink a code base
while we have
  * a community (small perhaps, but sufficient for the code we want to
    release and are able to support), but
  * no viable (IMO) project for salvaging the currently "unsupported"
    code.[1]

If Commons reject its own code (IOW does not accept a new component,
despite its potential usefulness, as noted by Eric), then the next
alternative would be a TLP proposal (as attempted by James).  Because
in the TLP, we'll be allowed to release components according to their
individual level of support (which means that well-tested code can be
released ASAP while in the incubator path, it might never be).
Obviously, this would necessitates that the Commons PMC accepts to let
go of the Commons Math code base without any strings attached.

So... I agree with Dave. ;-)

And partially with Emmanuel.

Indeed, it will be much more productive to let the new(bie) team
experiment within Commons by creating the following new components:
  * Commons RNG
  * Commons AltMath
  * Commons MathTools

The first one, pretty much, was accepted. Amazing.

The second one is more fuzzy for some people, but I'll have to stress
again that it's probably because they should have a look at the code!
It will be a zero dependency component (which I had referred to as
"Standard math functions" in the vote thread) with common
functionality,
useful beyond "math-centric" (whatever that means) applications.

The last one is a smaller "Commons Math", i.e. stripped of
functionality
unsupported at the time of release.
It is _also_ a new component to clearly separate it from Commons Math,
so that users have an upgrade path; or at least, they will be able to
easily figure out what has become unsupported.
If new contributors come in order to fill the gap, more codes can be
transferred to "MathTools".[2]
[At the same time "Commons Math" itself stays clean of packages
reordering, renaming or removal, so that if and when someone wants to
restart from there, it's trivial.]

I see this proposal as a compromise, deferring(!) further splits of
complex and rational" numbers functionality, while allowing to have a
taste of the the advantages and drawbacks of full modularization (i.e.
individual components).

We do this; if the result suits the PMC, we go on; if not: "Now we
know,
at least."

Do you agree?
If not, please let us know why.


Regards,
Gilles

[1] To become a valuable project, the proposal probably needs a "back
to
     basics" study (as noted by Dimitri) in order to generate a
consistent
     initiative, and not just another fork encumbered with all the
     liabilities of the past and no experts to compensate for them.
[2] Of course, the naming is illustrative, subject to a VOTE. ;-)


> Thanks,
>
> Jochen


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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Jörg Schaible
Hi Gilles,

Gilles wrote:

[snip]

> Indeed, it will be much more productive to let the new(bie) team
> experiment within Commons by creating the following new components:
>   * Commons RNG
>   * Commons AltMath
>   * Commons MathTools
>
> The first one, pretty much, was accepted. Amazing.


Not yet, only two binding votes. However, you're able to change this ;-)

Actually RNG is the component with the least strings, because it has never
been released and creates no binary compatibility problems. Simply remove
the code from CM4 and anything is well.


> The second one is more fuzzy for some people, but I'll have to stress
> again that it's probably because they should have a look at the code!
> It will be a zero dependency component (which I had referred to as
> "Standard math functions" in the vote thread) with common
> functionality,
> useful beyond "math-centric" (whatever that means) applications.
>
> The last one is a smaller "Commons Math", i.e. stripped of
> functionality
> unsupported at the time of release.
> It is _also_ a new component to clearly separate it from Commons Math,
> so that users have an upgrade path; or at least, they will be able to
> easily figure out what has become unsupported.
> If new contributors come in order to fill the gap, more codes can be
> transferred to "MathTools".[2]
> [At the same time "Commons Math" itself stays clean of packages
> reordering, renaming or removal, so that if and when someone wants to
> restart from there, it's trivial.]
>
> I see this proposal as a compromise, deferring(!) further splits of
> complex and rational" numbers functionality, while allowing to have a
> taste of the the advantages and drawbacks of full modularization (i.e.
> individual components).


Still, we have not yet cleared what it means to the existing CM to break
these out, since the code to extract *has been* released (see also
Benedikt's question). It's still a "proper" component unless we move it into
dormant and/or hand it over to a TLP.

IMHO the best way out would be a CM 3.7 release (based on latest 3.x) with
all removed classes marked as deprecated. Then you're free to drop the code
in trunk and a future Math TLP might concentrate on specialized mathematical
algorithms and problems that do not have such a wide audience.

And who knows, maybe the Hipparchus fork will use these new components also
in the long run and concentrate themselves on the "interesting" stuff.

Cheers,
Jörg


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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Jörg Schaible
In reply to this post by Emmanuel Bourg-3
Hi Emmanuel,

Emmanuel Bourg wrote:

> Le 23/06/2016 à 14:33, Jochen Wiedmann a écrit :
>
>> The important part, to me, is to find something on which we can agree.
>> That doesn't mean that everyone is happy with the outcome, but that
>> everyone's got the feeling "I can live with that". In particular,
>> there must not be any serious opposition later on. If you'd like to
>> oppose: Please do so here, and now.
>
> Thank you for proposing a plan Jochen. I'm certainly in the "I can live
> with that" category, but I'm a bit skeptical about the outcome. Neither
> the incubator nor a TLP sound viable to me at this point, because the
> community around commons-math hasn't recovered from the loss of its
> historical contributors. I'd would rather incubate the Math TLP within
> Commons until more contributors like Eric join the party.
>
> Because the best way to attract developers is to release something
> useful, I'd suggest releasing as soon as possible something derived from
> the current Commons Math 4 base:
> - commons-random: with the random number generators
> - commons-math4: with the core math utilities (fractions, complex,
> fastmath, stats, FFT, etc) and leaving out the orphaned parts judged too
> specialized like the genetic algorithms.
>
> The core commons-math4 may contain "unsupported" parts as long as they
> are properly covered by unit tests and not too specialized.

Hmm. Here I got lost. Do you now try to keep the "unsupported" parts in CM4
or leave them out as proposed two lines above? As long as we keep the name
"CM" we make promises to existing users and it is difficult to drop
something.

One benefit of Gilles smaller components is their specialized target. We as
PMC failed to realize that CM had been a dumping ground in the last 10 years
(see Dimitri's mail) and that aside the real common math utilities we also
collected very specialized stuff that is hardly used by anyone and that
should have never been added to *Commons* Math (AFAICS the latest released
jar is the threefold size compared to any other Commons component). If we
keep "CM" we might end up in the same situation again.

- Jörg


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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Emmanuel Bourg-3
Le 23/06/2016 à 19:20, Jörg Schaible a écrit :

> Hmm. Here I got lost. Do you now try to keep the "unsupported" parts in CM4
> or leave them out as proposed two lines above?

Well, that really depends on the usefulness of the parts considered. For
example even if we have no developer expert in Fourier transforms,
considering that it's a widely used algorithm that is already well
covered by the unit tests, I think we should keep it. On the other hand,
an unsupported part that is rarely useful could be dropped.

> As long as we keep the name "CM" we make promises to existing users
> and it is difficult to drop something.

I don't see this as an issue, users relying on the removed parts can
stick to CM 3.x (or switch to Hipparchus).

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Brent Worden-2
In reply to this post by Jörg Schaible
On Thu, Jun 23, 2016 at 12:05 PM, Jörg Schaible <[hidden email]>
wrote:

> Hi Gilles,
>
> Gilles wrote:
>
> [snip]
>
> > Indeed, it will be much more productive to let the new(bie) team
> > experiment within Commons by creating the following new components:
> >   * Commons RNG
> >   * Commons AltMath
> >   * Commons MathTools
> >
> > The first one, pretty much, was accepted. Amazing.
>
>
> Not yet, only two binding votes. However, you're able to change this ;-)
>
>
Not to sidetrack this discussion but, I believe there were three binding
votes:
- Benedikt Ritter
- Emmanuel Bourg
- Brent Worden
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Jörg Schaible
Brent Worden wrote:

> On Thu, Jun 23, 2016 at 12:05 PM, Jörg Schaible <[hidden email]>
> wrote:
>
>> Hi Gilles,
>>
>> Gilles wrote:
>>
>> [snip]
>>
>> > Indeed, it will be much more productive to let the new(bie) team
>> > experiment within Commons by creating the following new components:
>> >   * Commons RNG
>> >   * Commons AltMath
>> >   * Commons MathTools
>> >
>> > The first one, pretty much, was accepted. Amazing.
>>
>>
>> Not yet, only two binding votes. However, you're able to change this ;-)
>>
>>
> Not to sidetrack this discussion but, I believe there were three binding
> votes:
> - Benedikt Ritter
> - Emmanuel Bourg
> - Brent Worden

You're right. Actually I missed your vote.

Cheers,
Jörg



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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

michael.brzustowicz@gmail.com
Hi Math3 devs,

Is there a consensus on the future of Math3? I rely on the Linear Algebra
package and also Stats.
Is there major changes planned for those? I have heard some mentions of
refactoring going on,
but not sure how much would change to the API ... or if it's just
implementation details.

I do hope to contribute some code (probably in linalg, stats,
machine-learning) when some current
side projects clear up and I have time to dedicate.

Thanx,
Mike Brzustowicz

On Sat, Jun 25, 2016 at 7:58 AM, Jörg Schaible <[hidden email]>
wrote:

> Brent Worden wrote:
>
> > On Thu, Jun 23, 2016 at 12:05 PM, Jörg Schaible <[hidden email]>
> > wrote:
> >
> >> Hi Gilles,
> >>
> >> Gilles wrote:
> >>
> >> [snip]
> >>
> >> > Indeed, it will be much more productive to let the new(bie) team
> >> > experiment within Commons by creating the following new components:
> >> >   * Commons RNG
> >> >   * Commons AltMath
> >> >   * Commons MathTools
> >> >
> >> > The first one, pretty much, was accepted. Amazing.
> >>
> >>
> >> Not yet, only two binding votes. However, you're able to change this ;-)
> >>
> >>
> > Not to sidetrack this discussion but, I believe there were three binding
> > votes:
> > - Benedikt Ritter
> > - Emmanuel Bourg
> > - Brent Worden
>
> You're right. Actually I missed your vote.
>
> Cheers,
> Jörg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Getting things done

Jörg Schaible-5
Hello Mike,

[hidden email] wrote:

> Hi Math3 devs,
>
> Is there a consensus on the future of Math3?

Definately. Not necessarily as Math3 for mid-term, since the plan was to
establish a Math TLP with the code base of Math 3/4 minus the code for the
three new components.

> I rely on the Linear Algebra
> package and also Stats.
> Is there major changes planned for those? I have heard some mentions of
> refactoring going on,
> but not sure how much would change to the API ... or if it's just
> implementation details.

Actually I have no knowledge about the current state of the code, esp. what
happened between Math 3 and 4 for the areas you've mentioned here.
 
> I do hope to contribute some code (probably in linalg, stats,
> machine-learning) when some current
> side projects clear up and I have time to dedicate.

Any help is welcome. The future of Math needs an active community caring for
the individual parts of the code.

Cheers.
Jörg


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