[All][Math] New component: "Commons Geometry"?

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

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
On Mon, 21 Aug 2017 10:52:28 -0700, Ralph Goers wrote:

>> On Aug 21, 2017, at 4:39 AM, Gilles <[hidden email]>
>> wrote:
>>
>> On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote:
>>>> Am 20.08.2017 um 23:11 schrieb Ralph Goers
>>>> <[hidden email]>:
>>>>
>>>> I have to agree with Jochen and am -1 to this proposal. I have
>>>> stated before that I don’t want to see Commons become the
>>>> placeholder for all the Math related components. If Math has stuff
>>>> that can’t be maintained then create a MathLegacy project in the
>>>> sandbox and move the stuff there.
>>>
>>> I’ve also already argued in that direction.
>>
>> I gave technical arguments in favour of the proposal (cf. first
>> post in this thread).
>>
>> People opposing it give none.
>> A sudden "allergy" of some PMC members to "math"-related code
>> does not warrant rejecting non-obsolete code.[1]
>>
>> A good start would be to answer this question: Why is it bad (or
>> worse than the current situation) to have this "new" component?
>
> Technical arguments are not required since this is basically a
> housekeeping issue.

It is not, unless you consider that doing some ground work for
an (Apache) community to grow around an objectively useful piece
of code is not worth trying.

> I’m not sure why I would answer your last question since you are
> clearly going to have a different opinion.

My opinion is based on technical arguments; so why shouldn't
yours too?
Maybe those arguments can then convince me that I should let
it down (and that over 10 years of volunteering work here were
basically a waste of time).

> But many of us believe that
> Math is a great name for a project that contains math subcomponents,
> rather than wading through a bunch of different Commons projects.

I've already answered to this argument. Here is some of the
reasoning:
1. "Math" is not a well-defined project name.  It is much,
    much, much, too broad.  It was the source of endless
    managements problems for "Commons Math", on to the fork
    itself.
2. "Commons Math" contains such loosely related things that
    grouping them hardly makes more sense than declaring that
    all "Commons" components should be modules of a unique
    maven project.
3. It is very unlikely that such a diversity of codes can be
    maintained by people who are able or willing to maintain
    all of it.
4. This has led to swaths of codes being developed without
    any review whatsoever.  Confidence in them solely resided
    in the expertise of its developer (no plural intended).
5. The sole consensus on global development that could be
    reached was on including more and more code that would
    become unmaintainable once the developer responsible for
    would leave (as _proven_ by the facts, since the fork).

And on, and on...

> Eventually you are going to want Commons Statistics, Commons
> Transforms, Commons Primes, etc. or things that are even more
> specific.

No. *I* do not want it.
The only thing I want is to release _good_ components.
"Commons Math" has good code in it, but is a bad "component".
[I've tried to show with "Commons RNG" what (I think) is a
good component: narrow focus, modular, simple API and usage.]

Other programming languages eco-systems successfully follow
an approach based on (really) small components; why would you
want "Commons Math" to remain this monolithic beast?

> All of these should be modules under Math. To be honest, I’m
> really not clear why Commons Numbers was approved as I’ve never heard
> anyone talk about complex numbers or fractions in anything but a
> mathematical concept.

Again, arguing that all things pertaining to "a mathematical
concept" should belong to a single library is no more sensible
than, for example, assuming that all logging frameworks should
all be modules of a unique library...

> I get that what you are really trying to do is kill Commons Math off
> piece by piece. I just don’t agree with doing that.

The "Commons Math" component was killed off by those who
decided to fork it. Period.

Long before that, I had indicated that some change was
desirable (IMHO); but the course was set by the majority
of regular contributors, who were able to maintain the
various pieces. That was fair.
But, since the fork, who belongs to that category?
Why do you want to pretend that a healthy "Commons Math"
component exists, when big parts of it are not maintained
and that no slight refactoring is needed to fix some of
the reported issues?
Did I understand correctly that moving the whole of "Commons
Math" to "dormant" is your most generous offer to those of
us who try to find a way forward for some of the most useful
code that it contains?

Gilles

>
> Ralph
>
>
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Ralph Goers
In reply to this post by garydgregory
That is what I would like to see.

Ralph

> On Aug 21, 2017, at 12:41 PM, Gary Gregory <[hidden email]> wrote:
>
> What about this for a compromise: create Commons Math 5 as a multi-module
> project and bring in as submodules only the newly minted components and
> whatever gets spun out of Math 3/4.
>
> Gary
>
> On Aug 21, 2017 13:26, "Dave Brosius" <[hidden email]> wrote:
>
>>>> I get that what you are really trying to do is kill Commons Math off
>> piece by piece. I just don’t agree with doing that.
>>
>>
>> This is ridiculous. Giles is the primary person trying to keep some
>> semblance of commons-math-like-stuff alive. He has asserted that there is
>> no way he can maintain all of commons-math, and no one else is really all
>> that interested.  Time has proven he is right.
>>
>> Given he is trying his best to keep code going, and actually the one doing
>> the work, perhaps we should be a little bit less offensive about trying to
>> shut him down.
>>
>> --dave
>>
>> On 08/21/2017 01:52 PM, Ralph Goers wrote:
>>
>>> On Aug 21, 2017, at 4:39 AM, Gilles <[hidden email]> wrote:
>>>>
>>>> On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote:
>>>>
>>>>> Am 20.08.2017 um 23:11 schrieb Ralph Goers <[hidden email]
>>>>>>> :
>>>>>>
>>>>>> I have to agree with Jochen and am -1 to this proposal. I have stated
>>>>>> before that I don’t want to see Commons become the placeholder for all the
>>>>>> Math related components. If Math has stuff that can’t be maintained then
>>>>>> create a MathLegacy project in the sandbox and move the stuff there.
>>>>>>
>>>>> I’ve also already argued in that direction.
>>>>>
>>>> I gave technical arguments in favour of the proposal (cf. first
>>>> post in this thread).
>>>>
>>>> People opposing it give none.
>>>> A sudden "allergy" of some PMC members to "math"-related code
>>>> does not warrant rejecting non-obsolete code.[1]
>>>>
>>>> A good start would be to answer this question: Why is it bad (or
>>>> worse than the current situation) to have this "new" component?
>>>>
>>> Technical arguments are not required since this is basically a
>>> housekeeping issue.
>>>
>>> I’m not sure why I would answer your last question since you are clearly
>>> going to have a different opinion. But many of us believe that Math is a
>>> great name for a project that contains math subcomponents, rather than
>>> wading through a bunch of different Commons projects. Eventually you are
>>> going to want Commons Statistics, Commons Transforms, Commons Primes, etc.
>>> or things that are even more specific. All of these should be modules under
>>> Math. To be honest, I’m really not clear why Commons Numbers was approved
>>> as I’ve never heard anyone talk about complex numbers or fractions in
>>> anything but a mathematical concept.
>>>
>>> I get that what you are really trying to do is kill Commons Math off
>>> piece by piece. I just don’t agree with doing that.
>>>
>>> Ralph
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
In reply to this post by Rob Tompkins
On Mon, 21 Aug 2017 15:43:30 -0400, Rob Tompkins wrote:

>> On Aug 21, 2017, at 3:41 PM, Gary Gregory <[hidden email]>
>> wrote:
>>
>> What about this for a compromise: create Commons Math 5 as a
>> multi-module
>> project and bring in as submodules only the newly minted components
>> and
>> whatever gets spun out of Math 3/4.
>
> This feels like a good compromise to me. I'm actually surprised were
> not going this direction with math 4.

This route was not taken because it had been _explicitly_
forbidden by some of the PMC members.

And I admit that there was some technical argument for
not doing it, namely that we must leave the path open in
case some (yet unknown) contributors want to continue from
CM "master".
Following the usual policy, a new release would make
non-included code officially unsupported.
[Doing otherwise would just increase the work load even
more.]

Another aspect of that route, also _explicitly_ enforced
by the PMC policy is that all modules of a component must
be released together, with the same version (cf. ML archive
for the long story).
This does not fit a codebase comprised of totally unrelated
functionalities (see my preceding post): It makes no sense
to have to release, say, a new
   "math-complex"
module (possibly with different package name!) because a
new release of
   "math-genetic"
is required.
There are several components in "Commons" and nobody in
his right mind would suggest to group them all under a
single maven project, for exactly that reason.
Yet somehow, "Oh, this is math-related stuff" is sufficient
to jump to the opposite conclusion.

Gilles

>
> -Rob
>
>>
>> Gary
>>
>> On Aug 21, 2017 13:26, "Dave Brosius" <[hidden email]> wrote:
>>
>>>>> I get that what you are really trying to do is kill Commons Math
>>>>> off
>>> piece by piece. I just don’t agree with doing that.
>>>
>>>
>>> This is ridiculous. Giles is the primary person trying to keep some
>>> semblance of commons-math-like-stuff alive. He has asserted that
>>> there is
>>> no way he can maintain all of commons-math, and no one else is
>>> really all
>>> that interested.  Time has proven he is right.
>>>
>>> Given he is trying his best to keep code going, and actually the
>>> one doing
>>> the work, perhaps we should be a little bit less offensive about
>>> trying to
>>> shut him down.
>>>
>>> --dave
>>>
>>>> On 08/21/2017 01:52 PM, Ralph Goers wrote:
>>>>
>>>>> On Aug 21, 2017, at 4:39 AM, Gilles
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>> On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote:
>>>>>>
>>>>>> Am 20.08.2017 um 23:11 schrieb Ralph Goers
>>>>>> <[hidden email]
>>>>>>>> :
>>>>>>>
>>>>>>> I have to agree with Jochen and am -1 to this proposal. I have
>>>>>>> stated
>>>>>>> before that I don’t want to see Commons become the placeholder
>>>>>>> for all the
>>>>>>> Math related components. If Math has stuff that can’t be
>>>>>>> maintained then
>>>>>>> create a MathLegacy project in the sandbox and move the stuff
>>>>>>> there.
>>>>>>>
>>>>>> I’ve also already argued in that direction.
>>>>>>
>>>>> I gave technical arguments in favour of the proposal (cf. first
>>>>> post in this thread).
>>>>>
>>>>> People opposing it give none.
>>>>> A sudden "allergy" of some PMC members to "math"-related code
>>>>> does not warrant rejecting non-obsolete code.[1]
>>>>>
>>>>> A good start would be to answer this question: Why is it bad (or
>>>>> worse than the current situation) to have this "new" component?
>>>>>
>>>> Technical arguments are not required since this is basically a
>>>> housekeeping issue.
>>>>
>>>> I’m not sure why I would answer your last question since you are
>>>> clearly
>>>> going to have a different opinion. But many of us believe that
>>>> Math is a
>>>> great name for a project that contains math subcomponents, rather
>>>> than
>>>> wading through a bunch of different Commons projects. Eventually
>>>> you are
>>>> going to want Commons Statistics, Commons Transforms, Commons
>>>> Primes, etc.
>>>> or things that are even more specific. All of these should be
>>>> modules under
>>>> Math. To be honest, I’m really not clear why Commons Numbers was
>>>> approved
>>>> as I’ve never heard anyone talk about complex numbers or fractions
>>>> in
>>>> anything but a mathematical concept.
>>>>
>>>> I get that what you are really trying to do is kill Commons Math
>>>> off
>>>> piece by piece. I just don’t agree with doing that.
>>>>
>>>> Ralph


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

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

jochen-2
In reply to this post by Gilles Sadowski
On Mon, Aug 21, 2017 at 11:20 PM, Gilles <[hidden email]> wrote:

> Other programming languages eco-systems successfully follow
> an approach based on (really) small components; why would you
> want "Commons Math" to remain this monolithic beast?

No one is arguing for monolithic. We are simply questioning, whether a
split in Maven modules is sufficient, or not.

My impression is, that you are not even considering that more
lightweight approach. The arguments are giving, are typically answered
just as well with modules. Plus, you avoid losing oversight over the
sum.

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: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
On Tue, 22 Aug 2017 18:35:22 +0200, Jochen Wiedmann wrote:

> On Mon, Aug 21, 2017 at 11:20 PM, Gilles
> <[hidden email]> wrote:
>
>> Other programming languages eco-systems successfully follow
>> an approach based on (really) small components; why would you
>> want "Commons Math" to remain this monolithic beast?
>
> No one is arguing for monolithic. We are simply questioning, whether
> a
> split in Maven modules is sufficient, or not.

It is not.

>
> My impression is, that you are not even considering that more
> lightweight approach.

I have. From the outset.
I'm going to reiterate, once more.[1]

Some of the packages/codes of CM are candidates for standalone
components.
There are several reasons, possibly different for different
candidates:
1. Low-level, e.g.
    * Check for equality between "double" values
    * Fractions
    * Complex numbers
    * Combinatorics
    * Prime numbers
    Each of those can be of interest to quite different categories
    of users.
    [However, being quite low-level, it was not a bad compromise to
    group them all in a component called "Numbers" on the rationale
    that all deal with some kind of "number" (we can look at it as
    the level just above the elementary "Number"s of the JDK).
2. Self-contained (i.e. no dependency on anything else), e.g.
    * Code originally in the "o.a.c.math4.random" package that has
      started the development of "Commons RNG".
      Again of interest to a wide range of users.[2]
3. Standalone (with dependencies on a few low-level utilities
    such as those that are, or would fit, in "Numbers", and "RNG",
    but on nothing else from CM), e.g.
    * Package "o.a.c.math4.geometry"
    * Package "o.a.c.math4.ml"
    * Package "o.a.c.math4.distribution" (except perhaps the
      "multivariate" Gaussian)
    Those are, by all sensible criteria, independent fields of
    expertise and different user/developer communities; there is
    no reason to group them in a single library.

With those, ends the list of what I think would be good
components (with no less general usefulness[3] than some
other "Commons" components).
No "avalanche" of new components, no unbearable "noise"
on the ML, no fear of PMC exhaustion at validating
release candidates.
I contend that project management and review work will
be _easier_ due to the more focused subject matters.
And I've no problem with doing one after the other, as
said previously.

Then there is package "o.a.c.m.genetics", whose support
should be discontinued (IMHO), for reasons given elsewhere.

The rest of CM is comprised of package with intertwined
dependencies:
  * matrix algebra (package "o.a.c.m.linear")
  * functions, integration, interpolation, root solvers
    (package "o.a.c.m.analysis")
  * differential equation solvers (package "o.a.c.m.ode")
  * statistics (package "o.a.c.m.stat")
  * optimizers (packages "o.a.c.m.optim" and "o.a.c.m.fitting")
  * automatic differentiation ("o.a.c.m.analysis.differentiation")

In addition to being the sort of functionality that indeed
constitutes a "math toolbox", those packages would also stay
together for the following practical reasons:
1. Most unresolved issues target codes in them. Some have
    been open for years.  Some seem to require non-trivial
    debugging.
2. Some of those issues can't be solved without significant
    refactoring (particularly in "linear" and "stat").
3. Some codes were left dangling midway of a refactoring
    (namely "optim").

One of my points is to make a clear and useful difference
between actively supported code (the new components) and
code in need of new blood ("MathLegacy").
The former is timely released with all bugs fixed.
The latter could be released (PMC willing) as a WIP, to
not let down users of codes that satisfy their needs (i.e.
the bugs do not show up for them).

Down to the level of practicalities, it will of course be
an improvement of "Mathlegacy" if it can be modularized.
But this in itself is already a lot of work which it would
be insane to complete without also fixing the design bugs
as they are encountered.

> The arguments are giving, are typically answered
> just as well with modules.

If that were true, the same argument would apply to the
whole of "Commons": just release all of it as modules
within a single maven project.

> Plus, you avoid losing oversight over the
> sum.

Adding apples and pears.
Oversight of unrelated functionalities is useless (and even
a liability, as it turned out).

Oversight is required at the "Commons" level, to ensure that
components are healthy.

What other proof do you need that "Commons Math" wasn't?[4]

Plus, a team of maintainers who, together, had a nearly
100% reactivity level could make up for the project's
failure to define a clear "management"; now the reactivity
level is on life-support,[5] and the shortcomings should
be apparent to all.


Gilles

>
> Jochen

[1] Those reasonable arguments are already in the archive in
     one form or another...
[2] If they have strong randomization requirements, they should
     stop using "java.util.Random". See
       
http://commons.apache.org/proper/commons-rng/userguide/rng.html#a5._Quality
[3] We should at least agree to disagree on what is "generally"
     useful, when there is nothing more than vacuous arguments
     like "It's math-related".  Perhaps another way to express
     what I mean: Google turns up
       * About 27.400.000 results for "Wikipedia math"
       * About 1.970.000 results for "Wikipedia java language"
[4] I'm still waiting for a reaction to that post:
       http://markmail.org/message/uiljlf63uucnfyy2
[5] For months (December 2015 up to the announcement of the fork)
     I've been the only one to answer user requests. After the
     fork, I tried to draw your attention on the fact that the
     situation was not sustainable, and offered a viable plan.
     No one proposed an alternative (which they would be ready
     to actually pursue).


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

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Emmanuel Bourg-3
In reply to this post by garydgregory
Le 21/08/2017 à 21:41, Gary Gregory a écrit :
> What about this for a compromise: create Commons Math 5 as a multi-module
> project and bring in as submodules only the newly minted components and
> whatever gets spun out of Math 3/4.

+1 for multiple modules instead of multiple components.

Emmanuel Bourg

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

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
On Wed, 30 Aug 2017 15:28:49 +0200, Emmanuel Bourg wrote:

> Le 21/08/2017 à 21:41, Gary Gregory a écrit :
>> What about this for a compromise: create Commons Math 5 as a
>> multi-module
>> project and bring in as submodules only the newly minted components
>> and
>> whatever gets spun out of Math 3/4.
>
> +1 for multiple modules instead of multiple components.
>
> Emmanuel Bourg
>

-1 to asking others to do one's work.[1]

Gilles

[1] More complete answer _already_ given.
     You should reply to that post, with concrete arguments.


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

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Emmanuel Bourg-3
Le 30/08/2017 à 22:14, Gilles a écrit :

> -1 to asking others to do one's work.[1]

So whatever the others think you don't care? If the quantity of work is
important to you then you should be happy with a multi-module project
since it induces significantly less work than multiple components:
- one source repository
- one JIRA setup
- one site to manage
- less release votes
- less hair-pulling about defining component scopes
- more flexibility to rearrange code between modules

I thought you already realized that when you eventually agreed to pick
this strategy for RNG instead of creating more components.

Emmanuel Bourg

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

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
On Thu, 31 Aug 2017 10:53:56 +0200, Emmanuel Bourg wrote:

> Le 30/08/2017 à 22:14, Gilles a écrit :
>
>> -1 to asking others to do one's work.[1]
>
> So whatever the others think you don't care? If the quantity of work
> is
> important to you then you should be happy with a multi-module project
> since it induces significantly less work than multiple components:
> - one source repository
> - one JIRA setup
> - one site to manage
> - less release votes
> - less hair-pulling about defining component scopes
> - more flexibility to rearrange code between modules
>
> I thought you already realized that when you eventually agreed to
> pick
> this strategy for RNG instead of creating more components.
>
> Emmanuel Bourg
>

Emmanuel,

If you are a "nice guy" (as you once wrote on this ML), then
maybe we've got a "media" problem; it's a pity we cannot meet
in person to sort all those issues, to which I've brought
answers upon answers, several times over (really it's all in
the archive).
[It reminds me that I had to meet the key developer of CM to
have him realize how absurd it was to advocate for checked
exceptions the way he did, whatever arguments I had been
exposing for weeks on the ML.]

You don't seem to get, and neither did the former core team
of CM, that _everybody_ (thus "me too") is entitled to his
opinion; if there are several opinions, then IMHO we must try
to satisfy all the actual _contributors_, if they are willing
to work toward whatever their opinion leads them to. To make
it short and to the point: if you want CM modules, then start
modularizing it.
I'm not against you modularizing CM, I'm against me doing it
just because you "think" it's a better approach to the
(management) problems which I've been describing for at least
two years (and some more).
I've tried to convince people reading this list that some
management mistakes (IMHO) were made; and I showed how I'd
do actual work to try and fix them.
After the "Commons RNG" experience, I'm even more convinced
(and waiting for you to prove otherwise) that _some_ of the
CM codes deserve their own components.
[From here we get back to the initial post of this thread...]
The rest of CM should certainly be modularized (at some point),
but it should also be fixed (at some point), and this will take
a lot of time because CM is such a mixed bag of implementation
designs, pending bugs, dangling refactorings, outdated syntax,
etc.

IMO, prioritizing that work is the job of an active PMC.
In order to continue RERO'ing "math"-related code, we must
create new components.  I thought that "Commons RNG" had made
that obvious. [It does seem that some of the PMC members had now
become more accepting of this view.]

Regards,
Gilles


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

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Emmanuel Bourg-3
Le 31/08/2017 à 23:33, Gilles a écrit :

> it's a pity we cannot meet in person to sort all those issues

Hum, maybe with a few beers you'll be easier to convince ;)


> I'm not against you modularizing CM, I'm against me doing it
> just because you "think" it's a better approach to the
> (management) problems which I've been describing for at least
> two years (and some more).
I understand your point of view, you don't want to spent a lot of time
modularizing CM, dealing with parts of the code you are not comfortable
with and delaying the release of code you really care about. That's fair
and I agree this shouldn't be forced upon you.

The good news is you don't actually have to refactor *all* of CM as a
multi-module project right now. Start with a mostly empty branch
containing just a couple of modules you like and release them. And you
progressively bring more modules after each release from the old CM
branch. That's equivalent to the creation of multiple components (you
cherry-pick the code that you want, and release it when ready), and you
keep the lightweight management of a single 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: [All][Math] New component: "Commons Geometry"?

garydgregory
On Thu, Aug 31, 2017 at 4:28 PM, Emmanuel Bourg <[hidden email]> wrote:

> Le 31/08/2017 à 23:33, Gilles a écrit :
>
> > it's a pity we cannot meet in person to sort all those issues
>
> Hum, maybe with a few beers you'll be easier to convince ;)
>
>
> > I'm not against you modularizing CM, I'm against me doing it
> > just because you "think" it's a better approach to the
> > (management) problems which I've been describing for at least
> > two years (and some more).
> I understand your point of view, you don't want to spent a lot of time
> modularizing CM, dealing with parts of the code you are not comfortable
> with and delaying the release of code you really care about. That's fair
> and I agree this shouldn't be forced upon you.
>
> The good news is you don't actually have to refactor *all* of CM as a
> multi-module project right now. Start with a mostly empty branch
> containing just a couple of modules you like and release them. And you
> progressively bring more modules after each release from the old CM
> branch. That's equivalent to the creation of multiple components (you
> cherry-pick the code that you want, and release it when ready), and you
> keep the lightweight management of a single component.
>

That sounds like a nice iterative approach.

Gary


>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Dave Brosius-2
So volunteers? Gary, Emmanuel, others?? are you up to doing this?


On 08/31/2017 06:29 PM, Gary Gregory wrote:

> On Thu, Aug 31, 2017 at 4:28 PM, Emmanuel Bourg <[hidden email]> wrote:
>
>> Le 31/08/2017 à 23:33, Gilles a écrit :
>>
>>> it's a pity we cannot meet in person to sort all those issues
>> Hum, maybe with a few beers you'll be easier to convince ;)
>>
>>
>>> I'm not against you modularizing CM, I'm against me doing it
>>> just because you "think" it's a better approach to the
>>> (management) problems which I've been describing for at least
>>> two years (and some more).
>> I understand your point of view, you don't want to spent a lot of time
>> modularizing CM, dealing with parts of the code you are not comfortable
>> with and delaying the release of code you really care about. That's fair
>> and I agree this shouldn't be forced upon you.
>>
>> The good news is you don't actually have to refactor *all* of CM as a
>> multi-module project right now. Start with a mostly empty branch
>> containing just a couple of modules you like and release them. And you
>> progressively bring more modules after each release from the old CM
>> branch. That's equivalent to the creation of multiple components (you
>> cherry-pick the code that you want, and release it when ready), and you
>> keep the lightweight management of a single component.
>>
> That sounds like a nice iterative approach.
>
> Gary
>
>
>> Emmanuel Bourg
>>
>> ---------------------------------------------------------------------
>> 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: [All][Math] New component: "Commons Geometry"?

garydgregory
On Thu, Aug 31, 2017 at 8:54 PM, Dave Brosius <[hidden email]> wrote:

> So volunteers? Gary, Emmanuel, others?? are you up to doing this?
>

Not for a while for me. Working and moving.

Gary

>
>
> On 08/31/2017 06:29 PM, Gary Gregory wrote:
>
>> On Thu, Aug 31, 2017 at 4:28 PM, Emmanuel Bourg <[hidden email]>
>> wrote:
>>
>> Le 31/08/2017 à 23:33, Gilles a écrit :
>>>
>>> it's a pity we cannot meet in person to sort all those issues
>>>>
>>> Hum, maybe with a few beers you'll be easier to convince ;)
>>>
>>>
>>> I'm not against you modularizing CM, I'm against me doing it
>>>> just because you "think" it's a better approach to the
>>>> (management) problems which I've been describing for at least
>>>> two years (and some more).
>>>>
>>> I understand your point of view, you don't want to spent a lot of time
>>> modularizing CM, dealing with parts of the code you are not comfortable
>>> with and delaying the release of code you really care about. That's fair
>>> and I agree this shouldn't be forced upon you.
>>>
>>> The good news is you don't actually have to refactor *all* of CM as a
>>> multi-module project right now. Start with a mostly empty branch
>>> containing just a couple of modules you like and release them. And you
>>> progressively bring more modules after each release from the old CM
>>> branch. That's equivalent to the creation of multiple components (you
>>> cherry-pick the code that you want, and release it when ready), and you
>>> keep the lightweight management of a single component.
>>>
>>> That sounds like a nice iterative approach.
>>
>> Gary
>>
>>
>> Emmanuel Bourg
>>>
>>> ---------------------------------------------------------------------
>>> 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: [All][Math] New component: "Commons Geometry"?

Emmanuel Bourg-3
In reply to this post by Dave Brosius-2
Le 1/09/2017 à 04:54, Dave Brosius a écrit :
> So volunteers? Gary, Emmanuel, others?? are you up to doing this?

I can setup the initial branch, but I need at least Gilles' consent and
an indication about the first modules he'd like to integrate.

Emmanuel Bourg

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

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
On Fri, 1 Sep 2017 00:28:19 +0200, Emmanuel Bourg wrote:
> Le 31/08/2017 à 23:33, Gilles a écrit :
>
>> it's a pity we cannot meet in person to sort all those issues
>
> Hum, maybe with a few beers you'll be easier to convince ;)

It would quite probably require a stronger beverage.

>> I'm not against you modularizing CM, I'm against me doing it
>> just because you "think" it's a better approach to the
>> (management) problems which I've been describing for at least
>> two years (and some more).
> I understand your point of view, you don't want to spent a lot of
> time
> modularizing CM, dealing with parts of the code you are not
> comfortable
> with and delaying the release of code you really care about. That's
> fair
> and I agree this shouldn't be forced upon you.

There is some truth, but not all of it.
For a long time, I'm viewing CM more from a maintainer's POV
rather than from a user's POV.  IOW, the "prioritizing" I was
mentioning, in one of the suppressed parts of my preceding
message, is not based on what I "really care about", but on
how generally useful they are (hence my being convinced that
those would be good "Commons" component candidates).

> The good news is you don't actually have to refactor *all* of CM as a
> multi-module project right now. Start with a mostly empty branch
> containing just a couple of modules you like and release them. And
> you
> progressively bring more modules after each release from the old CM
> branch.

Does everyone agree with that?  [I seem to recall having made
such a proposal, and it was not deemed acceptable...]

> That's equivalent to the creation of multiple components (you
> cherry-pick the code that you want, and release it when ready),

Because of "Commons" rules, it is not "equivalent": There was
a long thread concluding that all modules must be released
_together_, and with the same top-level package name and version
number.
It is very "maintainer(s)-unfriendly" because of the quite
different subject matters that coexist in CM.

> and you
> keep the lightweight management of a single component.

I think that the unspecified problem(s) which you refer to
here are mostly alleviated with tools such as git and maven.
The problems I referred to in the preceding paragraph can't
be. [Proof is the management crisis that ultimately doomed CM.]

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: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
On Fri, 1 Sep 2017 09:44:36 +0200, Emmanuel Bourg wrote:
> Le 1/09/2017 à 04:54, Dave Brosius a écrit :
>> So volunteers? Gary, Emmanuel, others?? are you up to doing this?
>
> I can setup the initial branch, but I need at least Gilles' consent
> and
> an indication about the first modules he'd like to integrate.
>
> Emmanuel Bourg
>

I'm still biased toward my own view as the most promising
approach (see other post). [It's so obvious to me that most
of the management problems we've seen with CM simply could
not exist with more focused components.]

However, I can't dismiss that other approaches, even less
optimal (IMHO), could work (at least for some time).
Modularization will certainly be an improvement.
But who sufficiently believes in that approach that they
will do the actual work?  [Those people should speak up
and propose the plan.]

Personally, I've tried to demonstrate something with
"Commons RNG"; I must have failed, but I do not know
what.

Gilles


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

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Bill Igoe
Hi Gang,

I am new to this apache group. My two cents here for a first post. Finally
jumping after reading the threads and sensing the frustration. .  I have
pretty good success in using Math commons 3.6 for financial derivatives,
financial and economics analysis and etc.  Using the 3.6 as my a base
structure accepted by many I have code for Arima, Markov analysis,
constrained regressions, Linear programming for bond and equity
optimization and yes I do use the complex  number for derivative pricing.

http://pfadintegral.com/docs/Schmelzle2010%20Fourier%20Pricing.pdf

In fact I am writing a wrapper around the math common to write a R-like
struct...and it is going well. Adding new objects and routines is far
easier than with R. With a bit of work there is a strong possibility  of
having an ass kicking java algorithmic program.  Thus far it is so easy it
is actually fun!

While I have my own code for matrix algebra and optimization I thought
joining the open source community would provide a steady growth in
algorithmic possibilities. Do you really want a complete revamp? Yikes!


Are there issues?  Yes.  But I would hate to see this group toss the baby
out with the bathwater.  There is some good stuff here and with some work
you can have a darn good statistical optimization package for multiple
disciplines.

My suggestion .... keep the existing code and slowly migrate to a better
structure through deprecation and enhancements

Cheers to you all and keep up the good work,

Bill


On Fri, Sep 1, 2017 at 5:48 PM, Gilles <[hidden email]> wrote:

> On Fri, 1 Sep 2017 09:44:36 +0200, Emmanuel Bourg wrote:
>
>> Le 1/09/2017 à 04:54, Dave Brosius a écrit :
>>
>>> So volunteers? Gary, Emmanuel, others?? are you up to doing this?
>>>
>>
>> I can setup the initial branch, but I need at least Gilles' consent and
>> an indication about the first modules he'd like to integrate.
>>
>> Emmanuel Bourg
>>
>>
> I'm still biased toward my own view as the most promising
> approach (see other post). [It's so obvious to me that most
> of the management problems we've seen with CM simply could
> not exist with more focused components.]
>
> However, I can't dismiss that other approaches, even less
> optimal (IMHO), could work (at least for some time).
> Modularization will certainly be an improvement.
> But who sufficiently believes in that approach that they
> will do the actual work?  [Those people should speak up
> and propose the plan.]
>
> Personally, I've tried to demonstrate something with
> "Commons RNG"; I must have failed, but I do not know
> what.
>
> Gilles
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Rob Tompkins

> On Sep 1, 2017, at 9:35 PM, Bill Igoe <[hidden email]> wrote:
>
> Hi Gang,
>
> I am new to this apache group. My two cents here for a first post. Finally
> jumping after reading the threads and sensing the frustration. .  I have
> pretty good success in using Math commons 3.6 for financial derivatives,
> financial and economics analysis and etc.  Using the 3.6 as my a base
> structure accepted by many I have code for Arima, Markov analysis,
> constrained regressions, Linear programming for bond and equity
> optimization and yes I do use the complex  number for derivative pricing.
>
> http://pfadintegral.com/docs/Schmelzle2010%20Fourier%20Pricing.pdf
>
> In fact I am writing a wrapper around the math common to write a R-like
> struct...and it is going well. Adding new objects and routines is far
> easier than with R. With a bit of work there is a strong possibility  of
> having an ass kicking java algorithmic program.  Thus far it is so easy it
> is actually fun!
>
> While I have my own code for matrix algebra and optimization I thought
> joining the open source community would provide a steady growth in
> algorithmic possibilities. Do you really want a complete revamp? Yikes!
>
>
> Are there issues?  Yes.  But I would hate to see this group toss the baby
> out with the bathwater.  There is some good stuff here and with some work
> you can have a darn good statistical optimization package for multiple
> disciplines.
>
> My suggestion .... keep the existing code and slowly migrate to a better
> structure through deprecation and enhancements

This generally feels like the right direction to me. That said we’ll (all of us who haven’t been in there, myself included) have to start actually putting time into [math].

-Rob

>
> Cheers to you all and keep up the good work,
>
> Bill
>
>
> On Fri, Sep 1, 2017 at 5:48 PM, Gilles <[hidden email]> wrote:
>
>> On Fri, 1 Sep 2017 09:44:36 +0200, Emmanuel Bourg wrote:
>>
>>> Le 1/09/2017 à 04:54, Dave Brosius a écrit :
>>>
>>>> So volunteers? Gary, Emmanuel, others?? are you up to doing this?
>>>>
>>>
>>> I can setup the initial branch, but I need at least Gilles' consent and
>>> an indication about the first modules he'd like to integrate.
>>>
>>> Emmanuel Bourg
>>>
>>>
>> I'm still biased toward my own view as the most promising
>> approach (see other post). [It's so obvious to me that most
>> of the management problems we've seen with CM simply could
>> not exist with more focused components.]
>>
>> However, I can't dismiss that other approaches, even less
>> optimal (IMHO), could work (at least for some time).
>> Modularization will certainly be an improvement.
>> But who sufficiently believes in that approach that they
>> will do the actual work?  [Those people should speak up
>> and propose the plan.]
>>
>> Personally, I've tried to demonstrate something with
>> "Commons RNG"; I must have failed, but I do not know
>> what.
>>
>> Gilles
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: [All][Math] New component: "Commons Geometry"?

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
Le 2/09/2017 à 00:50, Gilles a écrit :

> Because of "Commons" rules, it is not "equivalent": There was
> a long thread concluding that all modules must be released
> _together_, and with the same top-level package name and version
> number.

True, but I don't see this as an issue.


> I think that the unspecified problem(s) which you refer to
> here are mostly alleviated with tools such as git and maven.

I mentioned the problems in a previous message in this thread. Managing
the releases, the JIRA configurations, maintaining the sites... many
tasks can't be automated with tools, that's why I referred to the
multi-modules solution as "lightweight" compared to multiple components.

Emmanuel Bourg

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

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
Hi.

On Mon, 4 Sep 2017 11:41:55 +0200, Emmanuel Bourg wrote:
> Le 2/09/2017 à 00:50, Gilles a écrit :
>
>> Because of "Commons" rules, it is not "equivalent": There was
>> a long thread concluding that all modules must be released
>> _together_, and with the same top-level package name and version
>> number.
>
> True, but I don't see this as an issue.

I see it as a fundamental one: Why should codes unrelated
by scope be artificially tied together by management rules
(such as design, supported language version, release schedule,
etc.)?[1]

>
>> I think that the unspecified problem(s) which you refer to
>> here are mostly alleviated with tools such as git and maven.
>
> I mentioned the problems in a previous message in this thread.
> Managing
> the releases, the JIRA configurations, maintaining the sites... many
> tasks can't be automated with tools, that's why I referred to the
> multi-modules solution as "lightweight" compared to multiple
> components.

That's how much our mileages vary; IMO, all those are mild
nuisances: the site is changed very rarely, JIRA configuration
is done once[2], but managing the releases becomes irremediably
difficult only when the scope of the component was not defined
correctly.[3]

Why do you "prefer" multi-module, independently of the subject
matters being talked about?
Please comment on my suggestion to create a single maven project
for the whole of "Commons".  I'd agree that this suggestion is
ridiculous; yet some of you do the same proposal for "everything
math-related".

If you had been contributing to the math codes (plural), you
perhaps would have understood that it creates more management
problems than it solves.[4]
The former CM core team did not want to see nor even discuss
that aspect of development because there was a fairly strict
segregation between the various functionalities where each one
had a "master" (usually the initial contributor/committer) who
was informally weighing more when it came to modifying "his"
code.[5]

Again, I have to stress on what happened that led me to propose
a new "Commons RNG": obvious improvements to the CM code base
were outrightly rejected based on demonstrably false statements;
i.e. the objections were not technical but for the convenience
of one user.

Do you think that I enjoy contradicting you on these matters?
These discussions are a net loss of goodwill that would be
better used in creating useful codes.
My point is that I'm arguing on what has really happened, while
you still seem to deny that anything actually happened.

Again, please do what you want with modularizing CM and release
and support the code that will be the result.

My "strategic" (!) plan has been clearly stated:
   1. "Commons Numbers",[6] then
   2. "Commons Geometry", then
   3. "Commons Math (legacy) v4.0
        * modularized if people want to work on it, and
        * without "unsupported" if allowed by the PMC

Does the majority of the PMC sees that proposal as a
constructive one?

Do some developers want to contribute time to implement
(parts of) that plan?

Do they want to implement another plan?  What plan?

Without answering these simple questions, I think that we'd
keep going in circles.

Gilles

>
> Emmanuel Bourg
>

[1] The rules are sensible once the scope has been determined
     based on the desire of the implementing team, not the other
     way around.
[2] And I never got the impression that we were creating too
     much work for INFRA (how many new components per year do
     we ask for?).
[3] As it has become of Common Math: the more it grew, the
     more it was likely that not all contributors could agree
     on a path forward, so that the majority "consensus" was on
     staying put; which, in turn, put off contributors who
     wanted to keep in sync with the language evolution.
[4] The fork is an actual proof of that.
[5] I don't deny that this can make sense since that person
     is likely the most knowledgeable in that domain. But it
     becomes a liability when the best design decisions are
     _not_ the same for the different functionalities.
     Modules are not an answer to this sort of problem.
[6] Followed by "Commons SigProc" (contributor's involvement
     pending) since it depends on the "complex numbers".


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

1234