[Math] Cleaning up the curve fitters

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

[Math] Cleaning up the curve fitters

Gilles Sadowski
Hello.

Constructors of classes in the "o.a.c.m.fitting" are instantiated using
an (abstract) "MultivariateVectorOptimizer". The only concrete
implementations of this class are
  * LevenbergMarquardtOptimizer
  * GaussNewtonOptimizer
[I.e. the API suggests that the Jacobian is not necessary for
some optimizers but no such (vector) optimizer exists currently.
Anyways the Jacobian is computed automatically (in inner class
"CurveFitter.TheoreticalValuesFunction") so that an optimizer
without derivatives is never necessary...]

Observing that
  1. almost all the unit tests for the fitters use an instance of
     "LevenbergMarquardtOptimizer",
  2. some comments in the "GaussNewtonOptimizerTest" unit test class
makes
     one wonder when "GaussNewtonOptimizer" should actually be preferred
     over "LevenbergMarquardtOptimizer",
I would propose to deprecate the non-default constructors in all fitter
classes (and let the fitting be transparently performed with an
instance
of "LevenbergMarquardtOptimizer").

Any objection?


Regards,
Gilles


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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Cleaning up the curve fitters

Konstantin Berlin
Hi,

Am I missing something? Why is a linear least squares problem (fitting constants of basis functions) being solved using a non-linear least squares solver in the first place?

On Jul 17, 2013, at 11:16 AM, Gilles <[hidden email]> wrote:

> Hello.
>
> Constructors of classes in the "o.a.c.m.fitting" are instantiated using
> an (abstract) "MultivariateVectorOptimizer". The only concrete
> implementations of this class are
> * LevenbergMarquardtOptimizer
> * GaussNewtonOptimizer
> [I.e. the API suggests that the Jacobian is not necessary for
> some optimizers but no such (vector) optimizer exists currently.
> Anyways the Jacobian is computed automatically (in inner class
> "CurveFitter.TheoreticalValuesFunction") so that an optimizer
> without derivatives is never necessary...]
>
> Observing that
> 1. almost all the unit tests for the fitters use an instance of
>    "LevenbergMarquardtOptimizer",
> 2. some comments in the "GaussNewtonOptimizerTest" unit test class makes
>    one wonder when "GaussNewtonOptimizer" should actually be preferred
>    over "LevenbergMarquardtOptimizer",
> I would propose to deprecate the non-default constructors in all fitter
> classes (and let the fitting be transparently performed with an instance
> of "LevenbergMarquardtOptimizer").
>
> Any objection?
>
>
> Regards,
> 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: [Math] Cleaning up the curve fitters

Konstantin Berlin
In reply to this post by Gilles Sadowski
Hi,

I have two points on this
1) See issue  MATH-1009
2) If LM was always better there would be no GuassNewton. Clearly this is not the case.
LM is a mixture between GN and steepest descent, so it is only faster for "tougher" functions. In case of strictly convex function GN should be a good amount faster. So the correct method depends on the problem. Clearly for some of the fitters you know if the problem is well behaved, so they should use GN, for the general method you cannot say. I think you can easily benchmark if this is the case.


On Jul 17, 2013, at 11:16 AM, Gilles <[hidden email]> wrote:

> Hello.
>
> Constructors of classes in the "o.a.c.m.fitting" are instantiated using
> an (abstract) "MultivariateVectorOptimizer". The only concrete
> implementations of this class are
> * LevenbergMarquardtOptimizer
> * GaussNewtonOptimizer
> [I.e. the API suggests that the Jacobian is not necessary for
> some optimizers but no such (vector) optimizer exists currently.
> Anyways the Jacobian is computed automatically (in inner class
> "CurveFitter.TheoreticalValuesFunction") so that an optimizer
> without derivatives is never necessary...]
>
> Observing that
> 1. almost all the unit tests for the fitters use an instance of
>    "LevenbergMarquardtOptimizer",
> 2. some comments in the "GaussNewtonOptimizerTest" unit test class makes
>    one wonder when "GaussNewtonOptimizer" should actually be preferred
>    over "LevenbergMarquardtOptimizer",
> I would propose to deprecate the non-default constructors in all fitter
> classes (and let the fitting be transparently performed with an instance
> of "LevenbergMarquardtOptimizer").
>
> Any objection?
>
>
> Regards,
> 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: [Math] Cleaning up the curve fitters

Gilles Sadowski
On Thu, 18 Jul 2013 09:16:46 -0400, Konstantin Berlin wrote:
> Hi,
>
> I have two points on this
> 1) See issue  MATH-1009

This is not directly related to my question (about cleanup of
_existing_ code); it should thus be discussed in another thread.

> 2) If LM was always better there would be no GuassNewton. Clearly
> this is not the case.
> LM is a mixture between GN and steepest descent, so it is only faster
> for "tougher" functions. In case of strictly convex function GN
> should
> be a good amount faster.

Examples?
Benchmarks?
[Currently there aren't any unit tests showing the advantage for
"GaussNewtonOptimizer". Contributions to this effect are most welcome.]

> So the correct method depends on the problem.
> Clearly for some of the fitters you know if the problem is well
> behaved, so they should use GN, for the general method you cannot
> say.

If we know in advance the best method for a given curve fitter (among
those
instantiated in package "o.a.c.m.fitting", then we could maybe
"parameterize"
the optimizer to be used (e.g. through an abstract method
"createOptimizer()".
It would still be transparent to the users.

> I think you can easily benchmark if this is the case.

I don't understand what this means.

Gilles

>
>
> On Jul 17, 2013, at 11:16 AM, Gilles <[hidden email]>
> wrote:
>
>> Hello.
>>
>> Constructors of classes in the "o.a.c.m.fitting" are instantiated
>> using
>> an (abstract) "MultivariateVectorOptimizer". The only concrete
>> implementations of this class are
>> * LevenbergMarquardtOptimizer
>> * GaussNewtonOptimizer
>> [I.e. the API suggests that the Jacobian is not necessary for
>> some optimizers but no such (vector) optimizer exists currently.
>> Anyways the Jacobian is computed automatically (in inner class
>> "CurveFitter.TheoreticalValuesFunction") so that an optimizer
>> without derivatives is never necessary...]
>>
>> Observing that
>> 1. almost all the unit tests for the fitters use an instance of
>>    "LevenbergMarquardtOptimizer",
>> 2. some comments in the "GaussNewtonOptimizerTest" unit test class
>> makes
>>    one wonder when "GaussNewtonOptimizer" should actually be
>> preferred
>>    over "LevenbergMarquardtOptimizer",
>> I would propose to deprecate the non-default constructors in all
>> fitter
>> classes (and let the fitting be transparently performed with an
>> instance
>> of "LevenbergMarquardtOptimizer").
>>
>> Any objection?
>>
>>
>> Regards,
>> Gilles


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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Cleaning up the curve fitters

Konstantin Berlin
Hi,

Bringing up points with you never leads anywhere since you refuse accept that your proposal might have issues, and as a last result you always bring out the "Examples Benchmarks" red herring, since it has nothing to do with the logical problems of your proposal. Since you work on commons projects, why don't you present benchmarks that say I am wrong, since clearly I presented why theoretically what you want is problematic.

You have done a pretty good job in making the optimization package non-sensical to user. We had a long discussion about this with pretty much everyone complaining but you. But for some reason you decided unilaterally that your opinion about package organization is correct.

If you think your GW method is terrible and it never works better LV why do you have it in the library? To trip up users?

You proposed a change. I just gave you about several reasons why it shouldn't be done without further thinking, yet somehow you feel that it is not enough. I guess you will do whatever you wanted to do anyways, but I would hope you listen to what I just said.

On Jul 18, 2013, at 9:34 AM, Gilles <[hidden email]> wrote:

> On Thu, 18 Jul 2013 09:16:46 -0400, Konstantin Berlin wrote:
>> Hi,
>>
>> I have two points on this
>> 1) See issue  MATH-1009
>
> This is not directly related to my question (about cleanup of
> _existing_ code); it should thus be discussed in another thread.
>
>> 2) If LM was always better there would be no GuassNewton. Clearly
>> this is not the case.
>> LM is a mixture between GN and steepest descent, so it is only faster
>> for "tougher" functions. In case of strictly convex function GN should
>> be a good amount faster.
>
> Examples?
> Benchmarks?
> [Currently there aren't any unit tests showing the advantage for
> "GaussNewtonOptimizer". Contributions to this effect are most welcome.]
>
>> So the correct method depends on the problem.
>> Clearly for some of the fitters you know if the problem is well
>> behaved, so they should use GN, for the general method you cannot say.
>
> If we know in advance the best method for a given curve fitter (among those
> instantiated in package "o.a.c.m.fitting", then we could maybe "parameterize"
> the optimizer to be used (e.g. through an abstract method "createOptimizer()".
> It would still be transparent to the users.
>
>> I think you can easily benchmark if this is the case.
>
> I don't understand what this means.
>
> Gilles
>
>>
>>
>> On Jul 17, 2013, at 11:16 AM, Gilles <[hidden email]> wrote:
>>
>>> Hello.
>>>
>>> Constructors of classes in the "o.a.c.m.fitting" are instantiated using
>>> an (abstract) "MultivariateVectorOptimizer". The only concrete
>>> implementations of this class are
>>> * LevenbergMarquardtOptimizer
>>> * GaussNewtonOptimizer
>>> [I.e. the API suggests that the Jacobian is not necessary for
>>> some optimizers but no such (vector) optimizer exists currently.
>>> Anyways the Jacobian is computed automatically (in inner class
>>> "CurveFitter.TheoreticalValuesFunction") so that an optimizer
>>> without derivatives is never necessary...]
>>>
>>> Observing that
>>> 1. almost all the unit tests for the fitters use an instance of
>>>   "LevenbergMarquardtOptimizer",
>>> 2. some comments in the "GaussNewtonOptimizerTest" unit test class makes
>>>   one wonder when "GaussNewtonOptimizer" should actually be preferred
>>>   over "LevenbergMarquardtOptimizer",
>>> I would propose to deprecate the non-default constructors in all fitter
>>> classes (and let the fitting be transparently performed with an instance
>>> of "LevenbergMarquardtOptimizer").
>>>
>>> Any objection?
>>>
>>>
>>> Regards,
>>> 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: [Math] Cleaning up the curve fitters

Patrick Meyer
>You have done a pretty good job in making the optimization package
non-sensical to user.

+1



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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Cleaning up the curve fitters

Phil Steitz
On 7/18/13 7:12 AM, Patrick Meyer wrote:
>> You have done a pretty good job in making the optimization package
> non-sensical to user.
>
> +1

We have definitely struggled with the design of the optimization
package.  It would be great if we could get to a stable API for 4.0
onwards.  If you guys are willing to help get to a structure that
makes sense from a user's perspective, we are all ears.   If you
have time to help make or at least fully think through the changes
necessary to get there, that would be most appreciated.

I am not an optimization expert.  I do know, however, that what we
are dealing with in this package is well-understood theoretically.
We should listen carefully to those who have the knowledge and
background to help.  And those providing the "help" should be
patient and provide references (online, wherever possible) that we
can use to get to a common understanding of the mathematical
principles and terminology involved.

We all want the same thing here - a high-quality library that is
both maintainable and easy to use.  We are all volunteers with
limited time and of course limited knowledge.  Lets work together on
this.  

Phil
>
>
> ---------------------------------------------------------------------
> 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] Cleaning up the curve fitters

Gilles Sadowski
In reply to this post by Patrick Meyer
>> You have done a pretty good job in making the optimization package
>> non-sensical to user.
>
> +1
>

Check your facts ("svn log", JIRA, this ML), please: All modifications
were done in plain sight, and responded to identified problems which
I cared to solve.
I do not deny that it could have raised issues for cases which I did
not foresee. But all the requests for clearly defined
   use-cases,
   benchmarks,
   actual (i.e. working) code examples,
have been met with unhelpful "do it yourself" statements.[1]

Whatever we try here, including going somewhat in the direction you
suggested for singling out algorithms aimed at solving a (non-linear)
"leastsquares" problem:[2]
   http://markmail.org/message/nkceta2cskpgbkug
raises unsubstantiated criticism that never[3] translated into
_practical_ advice[4] on how to improve the code.


Gilles

[1] What _I_ observed and used led me to try out what I think are
     improvements. I you think otherwise, _you_ have to get your hands
     dirty too.
[2] Except that, at this point, it makes more sense for me, as a user,
     to put it under (model) "fitting" rather than "optim", for the
     reason I gave previously.
[3] And that means: NEVER.
[4] That is: an alternative Java code that compiles, runs and produces
     correct answers.


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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Cleaning up the curve fitters

Konstantin Berlin
In reply to this post by Phil Steitz
I appreciate the comment. I would like to help, but currently my schedule is full. Maybe towards the end of the year.

I think the first approach should be do no harm. The optimization package keeps getting refactored every few months without much thinking involved. We had the discuss previously, with Gilles unilaterally deciding on the current tree, which he now wants to change again.  

As someone who uses optimization regular I would say the current API state (not just package naming) leaves a lot to be desired, and is not amenable to the various modification that people might need for larger problems. So if you are going to modify it, you should at least open up the API to the possibility that different optimization steps can be done using various techniques, depending on the problem.

We should also accept that not everything can fit neatly into a package tree and a single set of APIs. A good example is least squares. Linear least squares does not require an initial guess at a solution, and by performing decomposition ahead of time you can quickly recompute the solution given different input values. However, an iterative least squares method might not have these properties. There are probably countless of other examples.

Because optimization problems are really computationally hard all the little specific differences matter, that is why Gilles approach of sweeping everything under the rug and into some rigid not thought out hierarchical API forces these methods to adapt (or drop) numerical aspects that should not be there (e.x. polynomial fits). This has *huge* performance implications, but the issue is treated as some OO design 101 class, with the focus on how to force everything into a simple inheritance structure, numerics be damned.

I would gladly help with the feedback when I can. Ajo and I provided code for adaptive integration, yet the whole issue was completely ignored. So I am not sure how much effort is required for the developers to take an idea or mostly completed code and make a change, rather than reject even the most basic numerical approaches that are taught in introduction classes as something that needs to be benchmarked.

Here are some helpful webpages on optimization
http://plato.asu.edu/sub/pns.html
http://www.neos-guide.org/optimization-tree


On Jul 18, 2013, at 10:33 AM, Phil Steitz <[hidden email]> wrote:

> On 7/18/13 7:12 AM, Patrick Meyer wrote:
>>> You have done a pretty good job in making the optimization package
>> non-sensical to user.
>>
>> +1
>
> We have definitely struggled with the design of the optimization
> package.  It would be great if we could get to a stable API for 4.0
> onwards.  If you guys are willing to help get to a structure that
> makes sense from a user's perspective, we are all ears.   If you
> have time to help make or at least fully think through the changes
> necessary to get there, that would be most appreciated.
>
> I am not an optimization expert.  I do know, however, that what we
> are dealing with in this package is well-understood theoretically.
> We should listen carefully to those who have the knowledge and
> background to help.  And those providing the "help" should be
> patient and provide references (online, wherever possible) that we
> can use to get to a common understanding of the mathematical
> principles and terminology involved.
>
> We all want the same thing here - a high-quality library that is
> both maintainable and easy to use.  We are all volunteers with
> limited time and of course limited knowledge.  Lets work together on
> this.  
>
> Phil
>>
>>
>> ---------------------------------------------------------------------
>> 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] Cleaning up the curve fitters

Patrick Meyer
In reply to this post by Gilles Sadowski
My vote was not directed toward the technical merits of the optimization
package. I am not an expert on optimization and I trust you in this regard.
My vote was a comment on the usability of the API. I find it to be
increasing difficult to use.





Maybe I have missed some refactoring, but why all of the depreicated
classes like



On Thu, Jul 18, 2013 at 10:58 AM, Gilles <[hidden email]>wrote:

> You have done a pretty good job in making the optimization package
>>> non-sensical to user.
>>>
>>
>> +1
>>
>>
> Check your facts ("svn log", JIRA, this ML), please: All modifications
> were done in plain sight, and responded to identified problems which
> I cared to solve.
> I do not deny that it could have raised issues for cases which I did
> not foresee. But all the requests for clearly defined
>   use-cases,
>   benchmarks,
>   actual (i.e. working) code examples,
> have been met with unhelpful "do it yourself" statements.[1]
>
> Whatever we try here, including going somewhat in the direction you
> suggested for singling out algorithms aimed at solving a (non-linear)
> "leastsquares" problem:[2]
>   http://markmail.org/message/**nkceta2cskpgbkug<http://markmail.org/message/nkceta2cskpgbkug>
> raises unsubstantiated criticism that never[3] translated into
> _practical_ advice[4] on how to improve the code.
>
>
> Gilles
>
> [1] What _I_ observed and used led me to try out what I think are
>     improvements. I you think otherwise, _you_ have to get your hands
>     dirty too.
> [2] Except that, at this point, it makes more sense for me, as a user,
>     to put it under (model) "fitting" rather than "optim", for the
>     reason I gave previously.
> [3] And that means: NEVER.
> [4] That is: an alternative Java code that compiles, runs and produces
>     correct answers.
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Cleaning up the curve fitters

Gilles Sadowski
In reply to this post by Konstantin Berlin
On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
> I appreciate the comment. I would like to help, but currently my
> schedule is full. Maybe towards the end of the year.
>
> I think the first approach should be do no harm. The optimization
> package keeps getting refactored every few months without much
> thinking involved. We had the discuss previously, with Gilles
> unilaterally deciding on the current tree, which he now wants to
> change again.

As I said,
as Luc said,
as Phil said,
again and again and again,
we are not optimization (as a scientific field) experts here,
but we do use Commons Math in scientific code that is pretty compute
intensive (and yes, maybe not in the same sense as you'd like it to
be for your comfort).
Current code has, and may still have problems, but we see them only
through running unit tests, running our applications, running
code examples submitted by issue reporters.
We improve what we can, given time and motivation constraints.
Other than that, there is nothing.

Yes, we already had that asymmetrical conversation where _you_ declare
what _we_ should do.

> As someone who uses optimization regular I would say the current API
> state (not just package naming) leaves a lot to be desired, and is
> not
> amenable to the various modification that people might need for
> larger
> problems. So if you are going to modify it, you should at least open
> up the API to the possibility that different optimization steps can
> be
> done using various techniques, depending on the problem.
>
> We should also accept that not everything can fit neatly into a
> package tree and a single set of APIs. A good example is least
> squares. Linear least squares does not require an initial guess at a
> solution, and by performing decomposition ahead of time you can
> quickly recompute the solution given different input values. However,
> an iterative least squares method might not have these properties.
> There are probably countless of other examples.
>
> Because optimization problems are really computationally hard all the
> little specific differences matter, that is why Gilles approach of
> sweeping everything under the rug and into some rigid not thought out
> hierarchical API forces these methods to adapt (or drop) numerical
> aspects that should not be there (e.x. polynomial fits). This has
> *huge* performance implications, but the issue is treated as some OO
> design 101 class, with the focus on how to force everything into a
> simple inheritance structure, numerics be damned.
>
> I would gladly help with the feedback when I can. Ajo and I provided
> code for adaptive integration, yet the whole issue was completely
> ignored. So I am not sure how much effort is required for the
> developers to take an idea or mostly completed code and make a
> change,
> rather than reject even the most basic numerical approaches that are
> taught in introduction classes as something that needs to be
> benchmarked.

As usual, you are mixing everything, from algorithms to
implementations,
from proposing new features to denigrating existing ones (with
non-existent or inappropriate use-cases), from numerical to efficiency
considerations...
[On top of it, you blatantly affirm that this issue has been ignored,
even as I provided[1] an analysis[2] of what was actually happening.
People like you seem to ignore that we work benevolently on this
project!]
Not even speaking of derogatory remarks like "sweeping [...] under the
rug"
and "not thought out" and insinuating that everything was better and
more
efficient before. Which is simply not true.

It's an asymmetrical discussion because you declare that half-baked
code is good enough and _we_ have to work even more than if we'd have
to implement the feature from scratch.


Gilles

[1] In the spare time I do _not_ have either.
[2] Which dragged me to the implementation of the Gauss-Hermite
quadrature
     scheme (although I had no personal use of it), which seems to be
the
     appropriate way to deal with the improper integral reported in the
     issue which you refer to.


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

Reply | Threaded
Open this post in threaded view
|

RE: [Math] Cleaning up the curve fitters

Roger Whitcomb
As an outsider listening to these discussions, it seems like:
a) *IF* there are problems with the current arrangement of packages, APIs, or whatever, then a constructive approach would be for the one who sees such problems to take the time to not just criticize and point out "flaws", but to dig in and rearrange the packages, redo the APIs, provide unit tests, and submit a patch with these changes, along with quantitative justification, benchmarks, test cases, etc.  It is quite easy to criticize, from the sidelines, the one who is actually doing the work, but quite another matter to roll up your sleeves and join in the work....
b) Since Math is a "library", it seems like there needs to be implementations of many different algorithms, since (quite clearly) not every algorithm is suited to every problem.  To say that X method doesn't work well for problem Y, is not necessarily a reason to rewrite X method, if that method is correctly implementing the algorithm.  Maybe the algorithm is simply not the right one to use for the problem.  
c) Comments that imply (or state outright) that someone who has (clearly) done a lot of work has done it "...without much thinking..." are clearly out of line.  In my experience, the only reason to resort to name calling and character assassination is because one has no worthy arguments to put forward.
d) Kudos to the Commons committers who have been doing the work ...

My 2 cents...

~Roger Whitcomb
Apache Pivot PMC Chair

-----Original Message-----
From: Gilles [mailto:[hidden email]]
Sent: Thursday, July 18, 2013 9:35 AM
To: [hidden email]
Subject: Re: [Math] Cleaning up the curve fitters

On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
> I appreciate the comment. I would like to help, but currently my
> schedule is full. Maybe towards the end of the year.
>
> I think the first approach should be do no harm. The optimization
> package keeps getting refactored every few months without much
> thinking involved. We had the discuss previously, with Gilles
> unilaterally deciding on the current tree, which he now wants to
> change again.

As I said,
as Luc said,
as Phil said,
again and again and again,
we are not optimization (as a scientific field) experts here, but we do use Commons Math in scientific code that is pretty compute intensive (and yes, maybe not in the same sense as you'd like it to be for your comfort).
Current code has, and may still have problems, but we see them only through running unit tests, running our applications, running code examples submitted by issue reporters.
We improve what we can, given time and motivation constraints.
Other than that, there is nothing.

Yes, we already had that asymmetrical conversation where _you_ declare what _we_ should do.

> As someone who uses optimization regular I would say the current API
> state (not just package naming) leaves a lot to be desired, and is not
> amenable to the various modification that people might need for larger
> problems. So if you are going to modify it, you should at least open
> up the API to the possibility that different optimization steps can be
> done using various techniques, depending on the problem.
>
> We should also accept that not everything can fit neatly into a
> package tree and a single set of APIs. A good example is least
> squares. Linear least squares does not require an initial guess at a
> solution, and by performing decomposition ahead of time you can
> quickly recompute the solution given different input values. However,
> an iterative least squares method might not have these properties.
> There are probably countless of other examples.
>
> Because optimization problems are really computationally hard all the
> little specific differences matter, that is why Gilles approach of
> sweeping everything under the rug and into some rigid not thought out
> hierarchical API forces these methods to adapt (or drop) numerical
> aspects that should not be there (e.x. polynomial fits). This has
> *huge* performance implications, but the issue is treated as some OO
> design 101 class, with the focus on how to force everything into a
> simple inheritance structure, numerics be damned.
>
> I would gladly help with the feedback when I can. Ajo and I provided
> code for adaptive integration, yet the whole issue was completely
> ignored. So I am not sure how much effort is required for the
> developers to take an idea or mostly completed code and make a change,
> rather than reject even the most basic numerical approaches that are
> taught in introduction classes as something that needs to be
> benchmarked.

As usual, you are mixing everything, from algorithms to implementations, from proposing new features to denigrating existing ones (with non-existent or inappropriate use-cases), from numerical to efficiency considerations...
[On top of it, you blatantly affirm that this issue has been ignored, even as I provided[1] an analysis[2] of what was actually happening.
People like you seem to ignore that we work benevolently on this project!] Not even speaking of derogatory remarks like "sweeping [...] under the rug"
and "not thought out" and insinuating that everything was better and more efficient before. Which is simply not true.

It's an asymmetrical discussion because you declare that half-baked code is good enough and _we_ have to work even more than if we'd have to implement the feature from scratch.


Gilles

[1] In the spare time I do _not_ have either.
[2] Which dragged me to the implementation of the Gauss-Hermite quadrature
     scheme (although I had no personal use of it), which seems to be the
     appropriate way to deal with the improper integral reported in the
     issue which you refer to.


---------------------------------------------------------------------
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] Cleaning up the curve fitters

Ajo Fod
Hello folks,

There is a lot of work in API design. However, Konstantin's point is that
it takes a lot of effort to convince Gilles of any alternatives. API design
issues should really be second to functionality. This idea seems to be lost
in conversations.

I agree with Gilles that providing tests and benchmarks that exhibit the
advantages of a particular method are probably the best way to show other
contributors the value of an alternative approach.

It is quite depressing to the contributor to see one's contribution be
rejected when efficiency/accuracy improvements are demonstrated. In a
better world, rejecting a patch that passes the hurdle of demonstrating an
efficiency improvement over existing code should come with a responsibility
of showing alternate tests that the patch fails and the original code
passes. Otherwise, the patch should be accepted by default. The person who
commits or designed the API is free to make changes to fit API design.

Just like API designers are not experts at the underlying math,
contributors are not necessarily experts at the underlying API design. To
unlock the efficiency of open source, contributor morale needs to be
considered and classes that pass tests should really be accepted.

For example, Performance AND accuracy improvements to existing algorithm
were demonstrated for AdaptiveQuadrature in my patches to MATH-995
The only joy I got out of that was Gilles putting a comment in the docs for
the existing class:
"The Javadoc now draws attention that the [existing] algorithm is not 100%
fool-proof."!
Also, I was asked to open a new issue about Adaptive Quadratures to figure
out what is the best quadratue method ... all while a patch that is a clear
improvement over existing code wastes away. Why not accept the patch and
make improvements as necessary?

My impression since that patch was rejected, is that it just seems like a
huge hurdle to get any patch past the API design requirements that are
frankly not as clear to me as it is to the designer. I can see how others
feel the same way.

Cheers,
Ajo.

Gilles: if you don't want to end up spending time developing Gauss-Hermite
quadrature or something else you don't really need, perhaps you should
consider accepting/modifying code that was shown to work by someone who
needed that functionality. It is reasonable to develop alternatives to fix
flaws/gaps, but otherwise its your effort wasted.  If someone's
contribution doesn't fit your view of the API, then by all means edit the
patch, but if you go about rejecting things that work, there won't be as
many contributors to CM.






On Thu, Jul 18, 2013 at 10:08 AM, Roger L. Whitcomb <
[hidden email]> wrote:

> As an outsider listening to these discussions, it seems like:
> a) *IF* there are problems with the current arrangement of packages, APIs,
> or whatever, then a constructive approach would be for the one who sees
> such problems to take the time to not just criticize and point out "flaws",
> but to dig in and rearrange the packages, redo the APIs, provide unit
> tests, and submit a patch with these changes, along with quantitative
> justification, benchmarks, test cases, etc.  It is quite easy to criticize,
> from the sidelines, the one who is actually doing the work, but quite
> another matter to roll up your sleeves and join in the work....
> b) Since Math is a "library", it seems like there needs to be
> implementations of many different algorithms, since (quite clearly) not
> every algorithm is suited to every problem.  To say that X method doesn't
> work well for problem Y, is not necessarily a reason to rewrite X method,
> if that method is correctly implementing the algorithm.  Maybe the
> algorithm is simply not the right one to use for the problem.
> c) Comments that imply (or state outright) that someone who has (clearly)
> done a lot of work has done it "...without much thinking..." are clearly
> out of line.  In my experience, the only reason to resort to name calling
> and character assassination is because one has no worthy arguments to put
> forward.
> d) Kudos to the Commons committers who have been doing the work ...
>
> My 2 cents...
>
> ~Roger Whitcomb
> Apache Pivot PMC Chair
>
> -----Original Message-----
> From: Gilles [mailto:[hidden email]]
> Sent: Thursday, July 18, 2013 9:35 AM
> To: [hidden email]
> Subject: Re: [Math] Cleaning up the curve fitters
>
> On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
> > I appreciate the comment. I would like to help, but currently my
> > schedule is full. Maybe towards the end of the year.
> >
> > I think the first approach should be do no harm. The optimization
> > package keeps getting refactored every few months without much
> > thinking involved. We had the discuss previously, with Gilles
> > unilaterally deciding on the current tree, which he now wants to
> > change again.
>
> As I said,
> as Luc said,
> as Phil said,
> again and again and again,
> we are not optimization (as a scientific field) experts here, but we do
> use Commons Math in scientific code that is pretty compute intensive (and
> yes, maybe not in the same sense as you'd like it to be for your comfort).
> Current code has, and may still have problems, but we see them only
> through running unit tests, running our applications, running code examples
> submitted by issue reporters.
> We improve what we can, given time and motivation constraints.
> Other than that, there is nothing.
>
> Yes, we already had that asymmetrical conversation where _you_ declare
> what _we_ should do.
>
> > As someone who uses optimization regular I would say the current API
> > state (not just package naming) leaves a lot to be desired, and is not
> > amenable to the various modification that people might need for larger
> > problems. So if you are going to modify it, you should at least open
> > up the API to the possibility that different optimization steps can be
> > done using various techniques, depending on the problem.
> >
> > We should also accept that not everything can fit neatly into a
> > package tree and a single set of APIs. A good example is least
> > squares. Linear least squares does not require an initial guess at a
> > solution, and by performing decomposition ahead of time you can
> > quickly recompute the solution given different input values. However,
> > an iterative least squares method might not have these properties.
> > There are probably countless of other examples.
> >
> > Because optimization problems are really computationally hard all the
> > little specific differences matter, that is why Gilles approach of
> > sweeping everything under the rug and into some rigid not thought out
> > hierarchical API forces these methods to adapt (or drop) numerical
> > aspects that should not be there (e.x. polynomial fits). This has
> > *huge* performance implications, but the issue is treated as some OO
> > design 101 class, with the focus on how to force everything into a
> > simple inheritance structure, numerics be damned.
> >
> > I would gladly help with the feedback when I can. Ajo and I provided
> > code for adaptive integration, yet the whole issue was completely
> > ignored. So I am not sure how much effort is required for the
> > developers to take an idea or mostly completed code and make a change,
> > rather than reject even the most basic numerical approaches that are
> > taught in introduction classes as something that needs to be
> > benchmarked.
>
> As usual, you are mixing everything, from algorithms to implementations,
> from proposing new features to denigrating existing ones (with non-existent
> or inappropriate use-cases), from numerical to efficiency considerations...
> [On top of it, you blatantly affirm that this issue has been ignored, even
> as I provided[1] an analysis[2] of what was actually happening.
> People like you seem to ignore that we work benevolently on this project!]
> Not even speaking of derogatory remarks like "sweeping [...] under the rug"
> and "not thought out" and insinuating that everything was better and more
> efficient before. Which is simply not true.
>
> It's an asymmetrical discussion because you declare that half-baked code
> is good enough and _we_ have to work even more than if we'd have to
> implement the feature from scratch.
>
>
> Gilles
>
> [1] In the spare time I do _not_ have either.
> [2] Which dragged me to the implementation of the Gauss-Hermite quadrature
>      scheme (although I had no personal use of it), which seems to be the
>      appropriate way to deal with the improper integral reported in the
>      issue which you refer to.
>
>
> ---------------------------------------------------------------------
> 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] Cleaning up the curve fitters

Phil Steitz
On 7/18/13 1:48 PM, Ajo Fod wrote:
> Hello folks,
>
> There is a lot of work in API design. However, Konstantin's point is that
> it takes a lot of effort to convince Gilles of any alternatives. API design
> issues should really be second to functionality. This idea seems to be lost
> in conversations.

With patience and collaboration you can have both and we *need* to
have both.  You can't get to a stable API and approachable and
maintainable code base without thinking carefully about API design.
>
> I agree with Gilles that providing tests and benchmarks that exhibit the
> advantages of a particular method are probably the best way to show other
> contributors the value of an alternative approach.

There is some value to this, but honestly much more value in
carefully researching and presenting the numerical analysis to
support improvement / performance claims.
>
> It is quite depressing to the contributor to see one's contribution be
> rejected when efficiency/accuracy improvements are demonstrated.

What you "demonstrated" in one case was better performance in one
problem instance.  The change of variable approach you implemented
was, in my admittedly possibly naive numerics view, questionable.  I
asked to see numerical analysis support and no one provided that.
Had you provided that, I would have argued to include some version
of the patch.

> In a
> better world, rejecting a patch that passes the hurdle of demonstrating an
> efficiency improvement over existing code should come with a responsibility
> of showing alternate tests that the patch fails and the original code
> passes. Otherwise, the patch should be accepted by default. The person who
> commits or designed the API is free to make changes to fit API design.

This is essentially what Gilles ended up doing.  You may not agree
with the approach, but he did in fact address the core issue.
>
> Just like API designers are not experts at the underlying math,
> contributors are not necessarily experts at the underlying API design. To
> unlock the efficiency of open source, contributor morale needs to be
> considered and classes that pass tests should really be accepted.

I agree that we should try to be friendly and encouraging and I
apologize if we have not been so.  That said, the process of
contributing here is not just tossing patches over the wall.  First
you need to get community support for the ideas.  Then work
collaboratively to get patches that work for the code and community.
>
> For example, Performance AND accuracy improvements to existing algorithm
> were demonstrated for AdaptiveQuadrature in my patches to MATH-995

Sorry, I was not convinced by the accuracy and performance claims
and, as I said above, I suspect that the change of variable approach
may not be the best way to handle improper integrals.  I am not
claiming authority here - just - again - asking for real numerical
analysis arguments to support the claims you are making.

It would be a lot better if we focused discussion on the actual
technical issues and mathematical principles rather than
generalities about how hard / easy it is to get stuff in.

Phil

> The only joy I got out of that was Gilles putting a comment in the docs for
> the existing class:
> "The Javadoc now draws attention that the [existing] algorithm is not 100%
> fool-proof."!
> Also, I was asked to open a new issue about Adaptive Quadratures to figure
> out what is the best quadratue method ... all while a patch that is a clear
> improvement over existing code wastes away. Why not accept the patch and
> make improvements as necessary?
>
> My impression since that patch was rejected, is that it just seems like a
> huge hurdle to get any patch past the API design requirements that are
> frankly not as clear to me as it is to the designer. I can see how others
> feel the same way.
>
> Cheers,
> Ajo.
>
> Gilles: if you don't want to end up spending time developing Gauss-Hermite
> quadrature or something else you don't really need, perhaps you should
> consider accepting/modifying code that was shown to work by someone who
> needed that functionality. It is reasonable to develop alternatives to fix
> flaws/gaps, but otherwise its your effort wasted.  If someone's
> contribution doesn't fit your view of the API, then by all means edit the
> patch, but if you go about rejecting things that work, there won't be as
> many contributors to CM.
>
>
>
>
>
>
> On Thu, Jul 18, 2013 at 10:08 AM, Roger L. Whitcomb <
> [hidden email]> wrote:
>
>> As an outsider listening to these discussions, it seems like:
>> a) *IF* there are problems with the current arrangement of packages, APIs,
>> or whatever, then a constructive approach would be for the one who sees
>> such problems to take the time to not just criticize and point out "flaws",
>> but to dig in and rearrange the packages, redo the APIs, provide unit
>> tests, and submit a patch with these changes, along with quantitative
>> justification, benchmarks, test cases, etc.  It is quite easy to criticize,
>> from the sidelines, the one who is actually doing the work, but quite
>> another matter to roll up your sleeves and join in the work....
>> b) Since Math is a "library", it seems like there needs to be
>> implementations of many different algorithms, since (quite clearly) not
>> every algorithm is suited to every problem.  To say that X method doesn't
>> work well for problem Y, is not necessarily a reason to rewrite X method,
>> if that method is correctly implementing the algorithm.  Maybe the
>> algorithm is simply not the right one to use for the problem.
>> c) Comments that imply (or state outright) that someone who has (clearly)
>> done a lot of work has done it "...without much thinking..." are clearly
>> out of line.  In my experience, the only reason to resort to name calling
>> and character assassination is because one has no worthy arguments to put
>> forward.
>> d) Kudos to the Commons committers who have been doing the work ...
>>
>> My 2 cents...
>>
>> ~Roger Whitcomb
>> Apache Pivot PMC Chair
>>
>> -----Original Message-----
>> From: Gilles [mailto:[hidden email]]
>> Sent: Thursday, July 18, 2013 9:35 AM
>> To: [hidden email]
>> Subject: Re: [Math] Cleaning up the curve fitters
>>
>> On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
>>> I appreciate the comment. I would like to help, but currently my
>>> schedule is full. Maybe towards the end of the year.
>>>
>>> I think the first approach should be do no harm. The optimization
>>> package keeps getting refactored every few months without much
>>> thinking involved. We had the discuss previously, with Gilles
>>> unilaterally deciding on the current tree, which he now wants to
>>> change again.
>> As I said,
>> as Luc said,
>> as Phil said,
>> again and again and again,
>> we are not optimization (as a scientific field) experts here, but we do
>> use Commons Math in scientific code that is pretty compute intensive (and
>> yes, maybe not in the same sense as you'd like it to be for your comfort).
>> Current code has, and may still have problems, but we see them only
>> through running unit tests, running our applications, running code examples
>> submitted by issue reporters.
>> We improve what we can, given time and motivation constraints.
>> Other than that, there is nothing.
>>
>> Yes, we already had that asymmetrical conversation where _you_ declare
>> what _we_ should do.
>>
>>> As someone who uses optimization regular I would say the current API
>>> state (not just package naming) leaves a lot to be desired, and is not
>>> amenable to the various modification that people might need for larger
>>> problems. So if you are going to modify it, you should at least open
>>> up the API to the possibility that different optimization steps can be
>>> done using various techniques, depending on the problem.
>>>
>>> We should also accept that not everything can fit neatly into a
>>> package tree and a single set of APIs. A good example is least
>>> squares. Linear least squares does not require an initial guess at a
>>> solution, and by performing decomposition ahead of time you can
>>> quickly recompute the solution given different input values. However,
>>> an iterative least squares method might not have these properties.
>>> There are probably countless of other examples.
>>>
>>> Because optimization problems are really computationally hard all the
>>> little specific differences matter, that is why Gilles approach of
>>> sweeping everything under the rug and into some rigid not thought out
>>> hierarchical API forces these methods to adapt (or drop) numerical
>>> aspects that should not be there (e.x. polynomial fits). This has
>>> *huge* performance implications, but the issue is treated as some OO
>>> design 101 class, with the focus on how to force everything into a
>>> simple inheritance structure, numerics be damned.
>>>
>>> I would gladly help with the feedback when I can. Ajo and I provided
>>> code for adaptive integration, yet the whole issue was completely
>>> ignored. So I am not sure how much effort is required for the
>>> developers to take an idea or mostly completed code and make a change,
>>> rather than reject even the most basic numerical approaches that are
>>> taught in introduction classes as something that needs to be
>>> benchmarked.
>> As usual, you are mixing everything, from algorithms to implementations,
>> from proposing new features to denigrating existing ones (with non-existent
>> or inappropriate use-cases), from numerical to efficiency considerations...
>> [On top of it, you blatantly affirm that this issue has been ignored, even
>> as I provided[1] an analysis[2] of what was actually happening.
>> People like you seem to ignore that we work benevolently on this project!]
>> Not even speaking of derogatory remarks like "sweeping [...] under the rug"
>> and "not thought out" and insinuating that everything was better and more
>> efficient before. Which is simply not true.
>>
>> It's an asymmetrical discussion because you declare that half-baked code
>> is good enough and _we_ have to work even more than if we'd have to
>> implement the feature from scratch.
>>
>>
>> Gilles
>>
>> [1] In the spare time I do _not_ have either.
>> [2] Which dragged me to the implementation of the Gauss-Hermite quadrature
>>      scheme (although I had no personal use of it), which seems to be the
>>      appropriate way to deal with the improper integral reported in the
>>      issue which you refer to.
>>
>>
>> ---------------------------------------------------------------------
>> 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] Cleaning up the curve fitters

Thomas Neidhart
In reply to this post by Ajo Fod
On 07/18/2013 10:48 PM, Ajo Fod wrote:

> Hello folks,
>
> There is a lot of work in API design. However, Konstantin's point is that
> it takes a lot of effort to convince Gilles of any alternatives. API design
> issues should really be second to functionality. This idea seems to be lost
> in conversations.
>
> I agree with Gilles that providing tests and benchmarks that exhibit the
> advantages of a particular method are probably the best way to show other
> contributors the value of an alternative approach.
>
> It is quite depressing to the contributor to see one's contribution be
> rejected when efficiency/accuracy improvements are demonstrated. In a
> better world, rejecting a patch that passes the hurdle of demonstrating an
> efficiency improvement over existing code should come with a responsibility
> of showing alternate tests that the patch fails and the original code
> passes. Otherwise, the patch should be accepted by default. The person who
> commits or designed the API is free to make changes to fit API design.
>
> Just like API designers are not experts at the underlying math,
> contributors are not necessarily experts at the underlying API design. To
> unlock the efficiency of open source, contributor morale needs to be
> considered and classes that pass tests should really be accepted.
>
> For example, Performance AND accuracy improvements to existing algorithm
> were demonstrated for AdaptiveQuadrature in my patches to MATH-995
> The only joy I got out of that was Gilles putting a comment in the docs for
> the existing class:
> "The Javadoc now draws attention that the [existing] algorithm is not 100%
> fool-proof."!
> Also, I was asked to open a new issue about Adaptive Quadratures to figure
> out what is the best quadratue method ... all while a patch that is a clear
> improvement over existing code wastes away. Why not accept the patch and
> make improvements as necessary?
>
> My impression since that patch was rejected, is that it just seems like a
> huge hurdle to get any patch past the API design requirements that are
> frankly not as clear to me as it is to the designer. I can see how others
> feel the same way.
>
> Cheers,
> Ajo.
>
> Gilles: if you don't want to end up spending time developing Gauss-Hermite
> quadrature or something else you don't really need, perhaps you should
> consider accepting/modifying code that was shown to work by someone who
> needed that functionality. It is reasonable to develop alternatives to fix
> flaws/gaps, but otherwise its your effort wasted.  If someone's
> contribution doesn't fit your view of the API, then by all means edit the
> patch, but if you go about rejecting things that work, there won't be as
> many contributors to CM.

Hi,

I am certainly not happy with the current API of the optimization
package but am looking forward to the suggested improvements from Luc
and how they can be applied to this package.

Otoh, I do not think it is fair to blame Gilles for doing a good job on
analyzing the root cause of reported problems and suggesting /
implementing changes that are generally applicable instead of doing
problem-specific fixes, which would just lead to an unmaintainable mess
(and I have some experience with that ...).

Following the discussions on this topic for a while, the bottom line is
mainly: you (= Commons Math) are doing it wrong. I have not seen a
proposal or draft on doing it better in a clean, maintainable way, and
this is the goal of this library afaik.

Thomas

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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Cleaning up the curve fitters

Ajo Fod
In reply to this post by Phil Steitz
Hi,

I very much appreciate the work that has been done in CM and this is
precisely why I'd like more people to contribute. Even when you didnt'
accept my MATH-995 patch, I got useful input from Konstantin and it has
already made my application more efficient.

What you required of me in the Improper integral example was a comparison
of different methods. This sort of research takes time. I hear that Gilles
is working on it. I appreciate that you guys spent so much effort on this.

However, my contention is that your efforts at researching alternate
solutions to a patch is not justified till you come up with a test that the
patch fails OR if you know an alternate performs better for an application
you have. In the first case, you're losing the efficiency of open source by
reinventing a possibly different wheel without sufficient marginal reward.
In the second case, beware of the fact that numerical algorithms are hairy
beasts, and it takes a while to encode something new. The efficiency of
commons comes from putting the burden of development on the developers who
need the code.

So, I propose an alternate approach to testing if a submitted patch needs
to be accepted:
1. Check if the patch fills a gap in existing CM code
2. if so, check if it passes known tests
3. if so, write up alternate tests to see if the code breaks.
4. if so, wrap the code up in a suitable API and accept the patch

This has two advantages. First CM will have more capabilities per unit of
your precious time. Second you give people the feeling that they are making
a difference.

As far as the debate on AQ(AdaptiveQuadrature) vs
LGQ(IterativeLegendreGaussIntegrator) goes:
The FACTS that support AQ over LGQ are:
1. An example where LGQ failed and AQ succeeded. I also explained why LGQ
fails and AQ will probably converge more correctly. Generally adaptive
quadrature are known to be so succesful at integration that Konstantin even
wondered why we don't have something yet.
2. Efficiency improvement: I also showed that LGQ is more efficient at at
least one example in terms of accuracy in digits per function evaluation.
So, conversely, its now your turn to provide concrete examples where LGQ
does better than AQ. You could pose credible objections by providing
examples where:
1. AQ fails but LGQ passes.
2. LGQ is more efficient in accuracy per evaluation.

All that to illustrate with example where the perception that it is hard to
convince the gatekeepers of commons of the merits of a patch arises from. I
have a package in my codebase with assorted patches that I just dont' think
is worth the time to try to post to commons. I think it is very inefficient
if others have such private patches.

Cheers,
Ajo







On Thu, Jul 18, 2013 at 2:15 PM, Phil Steitz <[hidden email]> wrote:

> On 7/18/13 1:48 PM, Ajo Fod wrote:
> > Hello folks,
> >
> > There is a lot of work in API design. However, Konstantin's point is that
> > it takes a lot of effort to convince Gilles of any alternatives. API
> design
> > issues should really be second to functionality. This idea seems to be
> lost
> > in conversations.
>
> With patience and collaboration you can have both and we *need* to
> have both.  You can't get to a stable API and approachable and
> maintainable code base without thinking carefully about API design.
> >
> > I agree with Gilles that providing tests and benchmarks that exhibit the
> > advantages of a particular method are probably the best way to show other
> > contributors the value of an alternative approach.
>
> There is some value to this, but honestly much more value in
> carefully researching and presenting the numerical analysis to
> support improvement / performance claims.
> >
> > It is quite depressing to the contributor to see one's contribution be
> > rejected when efficiency/accuracy improvements are demonstrated.
>
> What you "demonstrated" in one case was better performance in one
> problem instance.  The change of variable approach you implemented
> was, in my admittedly possibly naive numerics view, questionable.  I
> asked to see numerical analysis support and no one provided that.
> Had you provided that, I would have argued to include some version
> of the patch.
>
> > In a
> > better world, rejecting a patch that passes the hurdle of demonstrating
> an
> > efficiency improvement over existing code should come with a
> responsibility
> > of showing alternate tests that the patch fails and the original code
> > passes. Otherwise, the patch should be accepted by default. The person
> who
> > commits or designed the API is free to make changes to fit API design.
>
> This is essentially what Gilles ended up doing.  You may not agree
> with the approach, but he did in fact address the core issue.
> >
> > Just like API designers are not experts at the underlying math,
> > contributors are not necessarily experts at the underlying API design. To
> > unlock the efficiency of open source, contributor morale needs to be
> > considered and classes that pass tests should really be accepted.
>
> I agree that we should try to be friendly and encouraging and I
> apologize if we have not been so.  That said, the process of
> contributing here is not just tossing patches over the wall.  First
> you need to get community support for the ideas.  Then work
> collaboratively to get patches that work for the code and community.
> >
> > For example, Performance AND accuracy improvements to existing algorithm
> > were demonstrated for AdaptiveQuadrature in my patches to MATH-995
>
> Sorry, I was not convinced by the accuracy and performance claims
> and, as I said above, I suspect that the change of variable approach
> may not be the best way to handle improper integrals.  I am not
> claiming authority here - just - again - asking for real numerical
> analysis arguments to support the claims you are making.
>
> It would be a lot better if we focused discussion on the actual
> technical issues and mathematical principles rather than
> generalities about how hard / easy it is to get stuff in.
>
> Phil
> > The only joy I got out of that was Gilles putting a comment in the docs
> for
> > the existing class:
> > "The Javadoc now draws attention that the [existing] algorithm is not
> 100%
> > fool-proof."!
> > Also, I was asked to open a new issue about Adaptive Quadratures to
> figure
> > out what is the best quadratue method ... all while a patch that is a
> clear
> > improvement over existing code wastes away. Why not accept the patch and
> > make improvements as necessary?
> >
> > My impression since that patch was rejected, is that it just seems like a
> > huge hurdle to get any patch past the API design requirements that are
> > frankly not as clear to me as it is to the designer. I can see how others
> > feel the same way.
> >
> > Cheers,
> > Ajo.
> >
> > Gilles: if you don't want to end up spending time developing
> Gauss-Hermite
> > quadrature or something else you don't really need, perhaps you should
> > consider accepting/modifying code that was shown to work by someone who
> > needed that functionality. It is reasonable to develop alternatives to
> fix
> > flaws/gaps, but otherwise its your effort wasted.  If someone's
> > contribution doesn't fit your view of the API, then by all means edit the
> > patch, but if you go about rejecting things that work, there won't be as
> > many contributors to CM.
> >
> >
> >
> >
> >
> >
> > On Thu, Jul 18, 2013 at 10:08 AM, Roger L. Whitcomb <
> > [hidden email]> wrote:
> >
> >> As an outsider listening to these discussions, it seems like:
> >> a) *IF* there are problems with the current arrangement of packages,
> APIs,
> >> or whatever, then a constructive approach would be for the one who sees
> >> such problems to take the time to not just criticize and point out
> "flaws",
> >> but to dig in and rearrange the packages, redo the APIs, provide unit
> >> tests, and submit a patch with these changes, along with quantitative
> >> justification, benchmarks, test cases, etc.  It is quite easy to
> criticize,
> >> from the sidelines, the one who is actually doing the work, but quite
> >> another matter to roll up your sleeves and join in the work....
> >> b) Since Math is a "library", it seems like there needs to be
> >> implementations of many different algorithms, since (quite clearly) not
> >> every algorithm is suited to every problem.  To say that X method
> doesn't
> >> work well for problem Y, is not necessarily a reason to rewrite X
> method,
> >> if that method is correctly implementing the algorithm.  Maybe the
> >> algorithm is simply not the right one to use for the problem.
> >> c) Comments that imply (or state outright) that someone who has
> (clearly)
> >> done a lot of work has done it "...without much thinking..." are clearly
> >> out of line.  In my experience, the only reason to resort to name
> calling
> >> and character assassination is because one has no worthy arguments to
> put
> >> forward.
> >> d) Kudos to the Commons committers who have been doing the work ...
> >>
> >> My 2 cents...
> >>
> >> ~Roger Whitcomb
> >> Apache Pivot PMC Chair
> >>
> >> -----Original Message-----
> >> From: Gilles [mailto:[hidden email]]
> >> Sent: Thursday, July 18, 2013 9:35 AM
> >> To: [hidden email]
> >> Subject: Re: [Math] Cleaning up the curve fitters
> >>
> >> On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
> >>> I appreciate the comment. I would like to help, but currently my
> >>> schedule is full. Maybe towards the end of the year.
> >>>
> >>> I think the first approach should be do no harm. The optimization
> >>> package keeps getting refactored every few months without much
> >>> thinking involved. We had the discuss previously, with Gilles
> >>> unilaterally deciding on the current tree, which he now wants to
> >>> change again.
> >> As I said,
> >> as Luc said,
> >> as Phil said,
> >> again and again and again,
> >> we are not optimization (as a scientific field) experts here, but we do
> >> use Commons Math in scientific code that is pretty compute intensive
> (and
> >> yes, maybe not in the same sense as you'd like it to be for your
> comfort).
> >> Current code has, and may still have problems, but we see them only
> >> through running unit tests, running our applications, running code
> examples
> >> submitted by issue reporters.
> >> We improve what we can, given time and motivation constraints.
> >> Other than that, there is nothing.
> >>
> >> Yes, we already had that asymmetrical conversation where _you_ declare
> >> what _we_ should do.
> >>
> >>> As someone who uses optimization regular I would say the current API
> >>> state (not just package naming) leaves a lot to be desired, and is not
> >>> amenable to the various modification that people might need for larger
> >>> problems. So if you are going to modify it, you should at least open
> >>> up the API to the possibility that different optimization steps can be
> >>> done using various techniques, depending on the problem.
> >>>
> >>> We should also accept that not everything can fit neatly into a
> >>> package tree and a single set of APIs. A good example is least
> >>> squares. Linear least squares does not require an initial guess at a
> >>> solution, and by performing decomposition ahead of time you can
> >>> quickly recompute the solution given different input values. However,
> >>> an iterative least squares method might not have these properties.
> >>> There are probably countless of other examples.
> >>>
> >>> Because optimization problems are really computationally hard all the
> >>> little specific differences matter, that is why Gilles approach of
> >>> sweeping everything under the rug and into some rigid not thought out
> >>> hierarchical API forces these methods to adapt (or drop) numerical
> >>> aspects that should not be there (e.x. polynomial fits). This has
> >>> *huge* performance implications, but the issue is treated as some OO
> >>> design 101 class, with the focus on how to force everything into a
> >>> simple inheritance structure, numerics be damned.
> >>>
> >>> I would gladly help with the feedback when I can. Ajo and I provided
> >>> code for adaptive integration, yet the whole issue was completely
> >>> ignored. So I am not sure how much effort is required for the
> >>> developers to take an idea or mostly completed code and make a change,
> >>> rather than reject even the most basic numerical approaches that are
> >>> taught in introduction classes as something that needs to be
> >>> benchmarked.
> >> As usual, you are mixing everything, from algorithms to implementations,
> >> from proposing new features to denigrating existing ones (with
> non-existent
> >> or inappropriate use-cases), from numerical to efficiency
> considerations...
> >> [On top of it, you blatantly affirm that this issue has been ignored,
> even
> >> as I provided[1] an analysis[2] of what was actually happening.
> >> People like you seem to ignore that we work benevolently on this
> project!]
> >> Not even speaking of derogatory remarks like "sweeping [...] under the
> rug"
> >> and "not thought out" and insinuating that everything was better and
> more
> >> efficient before. Which is simply not true.
> >>
> >> It's an asymmetrical discussion because you declare that half-baked code
> >> is good enough and _we_ have to work even more than if we'd have to
> >> implement the feature from scratch.
> >>
> >>
> >> Gilles
> >>
> >> [1] In the spare time I do _not_ have either.
> >> [2] Which dragged me to the implementation of the Gauss-Hermite
> quadrature
> >>      scheme (although I had no personal use of it), which seems to be
> the
> >>      appropriate way to deal with the improper integral reported in the
> >>      issue which you refer to.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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] Cleaning up the curve fitters

Phil Steitz
As I said above, let's focus on actual technical discussion here.
We implement standard, well-documented algorithms.  We need to
provide references and convince ourselves that what we release is
numerically sound, well-documented and well-tested.  We do our best
with the volunteer resources we have.  Your help and contributions
are appreciated.

Phil

On 7/19/13 9:44 AM, Ajo Fod wrote:

> Hi,
>
> I very much appreciate the work that has been done in CM and this is
> precisely why I'd like more people to contribute. Even when you didnt'
> accept my MATH-995 patch, I got useful input from Konstantin and it has
> already made my application more efficient.
>
> What you required of me in the Improper integral example was a comparison
> of different methods. This sort of research takes time. I hear that Gilles
> is working on it. I appreciate that you guys spent so much effort on this.
>
> However, my contention is that your efforts at researching alternate
> solutions to a patch is not justified till you come up with a test that the
> patch fails OR if you know an alternate performs better for an application
> you have. In the first case, you're losing the efficiency of open source by
> reinventing a possibly different wheel without sufficient marginal reward.
> In the second case, beware of the fact that numerical algorithms are hairy
> beasts, and it takes a while to encode something new. The efficiency of
> commons comes from putting the burden of development on the developers who
> need the code.
>
> So, I propose an alternate approach to testing if a submitted patch needs
> to be accepted:
> 1. Check if the patch fills a gap in existing CM code
> 2. if so, check if it passes known tests
> 3. if so, write up alternate tests to see if the code breaks.
> 4. if so, wrap the code up in a suitable API and accept the patch
>
> This has two advantages. First CM will have more capabilities per unit of
> your precious time. Second you give people the feeling that they are making
> a difference.
>
> As far as the debate on AQ(AdaptiveQuadrature) vs
> LGQ(IterativeLegendreGaussIntegrator) goes:
> The FACTS that support AQ over LGQ are:
> 1. An example where LGQ failed and AQ succeeded. I also explained why LGQ
> fails and AQ will probably converge more correctly. Generally adaptive
> quadrature are known to be so succesful at integration that Konstantin even
> wondered why we don't have something yet.
> 2. Efficiency improvement: I also showed that LGQ is more efficient at at
> least one example in terms of accuracy in digits per function evaluation.
> So, conversely, its now your turn to provide concrete examples where LGQ
> does better than AQ. You could pose credible objections by providing
> examples where:
> 1. AQ fails but LGQ passes.
> 2. LGQ is more efficient in accuracy per evaluation.
>
> All that to illustrate with example where the perception that it is hard to
> convince the gatekeepers of commons of the merits of a patch arises from. I
> have a package in my codebase with assorted patches that I just dont' think
> is worth the time to try to post to commons. I think it is very inefficient
> if others have such private patches.
>
> Cheers,
> Ajo
>
>
>
>
>
>
>
> On Thu, Jul 18, 2013 at 2:15 PM, Phil Steitz <[hidden email]> wrote:
>
>> On 7/18/13 1:48 PM, Ajo Fod wrote:
>>> Hello folks,
>>>
>>> There is a lot of work in API design. However, Konstantin's point is that
>>> it takes a lot of effort to convince Gilles of any alternatives. API
>> design
>>> issues should really be second to functionality. This idea seems to be
>> lost
>>> in conversations.
>> With patience and collaboration you can have both and we *need* to
>> have both.  You can't get to a stable API and approachable and
>> maintainable code base without thinking carefully about API design.
>>> I agree with Gilles that providing tests and benchmarks that exhibit the
>>> advantages of a particular method are probably the best way to show other
>>> contributors the value of an alternative approach.
>> There is some value to this, but honestly much more value in
>> carefully researching and presenting the numerical analysis to
>> support improvement / performance claims.
>>> It is quite depressing to the contributor to see one's contribution be
>>> rejected when efficiency/accuracy improvements are demonstrated.
>> What you "demonstrated" in one case was better performance in one
>> problem instance.  The change of variable approach you implemented
>> was, in my admittedly possibly naive numerics view, questionable.  I
>> asked to see numerical analysis support and no one provided that.
>> Had you provided that, I would have argued to include some version
>> of the patch.
>>
>>> In a
>>> better world, rejecting a patch that passes the hurdle of demonstrating
>> an
>>> efficiency improvement over existing code should come with a
>> responsibility
>>> of showing alternate tests that the patch fails and the original code
>>> passes. Otherwise, the patch should be accepted by default. The person
>> who
>>> commits or designed the API is free to make changes to fit API design.
>> This is essentially what Gilles ended up doing.  You may not agree
>> with the approach, but he did in fact address the core issue.
>>> Just like API designers are not experts at the underlying math,
>>> contributors are not necessarily experts at the underlying API design. To
>>> unlock the efficiency of open source, contributor morale needs to be
>>> considered and classes that pass tests should really be accepted.
>> I agree that we should try to be friendly and encouraging and I
>> apologize if we have not been so.  That said, the process of
>> contributing here is not just tossing patches over the wall.  First
>> you need to get community support for the ideas.  Then work
>> collaboratively to get patches that work for the code and community.
>>> For example, Performance AND accuracy improvements to existing algorithm
>>> were demonstrated for AdaptiveQuadrature in my patches to MATH-995
>> Sorry, I was not convinced by the accuracy and performance claims
>> and, as I said above, I suspect that the change of variable approach
>> may not be the best way to handle improper integrals.  I am not
>> claiming authority here - just - again - asking for real numerical
>> analysis arguments to support the claims you are making.
>>
>> It would be a lot better if we focused discussion on the actual
>> technical issues and mathematical principles rather than
>> generalities about how hard / easy it is to get stuff in.
>>
>> Phil
>>> The only joy I got out of that was Gilles putting a comment in the docs
>> for
>>> the existing class:
>>> "The Javadoc now draws attention that the [existing] algorithm is not
>> 100%
>>> fool-proof."!
>>> Also, I was asked to open a new issue about Adaptive Quadratures to
>> figure
>>> out what is the best quadratue method ... all while a patch that is a
>> clear
>>> improvement over existing code wastes away. Why not accept the patch and
>>> make improvements as necessary?
>>>
>>> My impression since that patch was rejected, is that it just seems like a
>>> huge hurdle to get any patch past the API design requirements that are
>>> frankly not as clear to me as it is to the designer. I can see how others
>>> feel the same way.
>>>
>>> Cheers,
>>> Ajo.
>>>
>>> Gilles: if you don't want to end up spending time developing
>> Gauss-Hermite
>>> quadrature or something else you don't really need, perhaps you should
>>> consider accepting/modifying code that was shown to work by someone who
>>> needed that functionality. It is reasonable to develop alternatives to
>> fix
>>> flaws/gaps, but otherwise its your effort wasted.  If someone's
>>> contribution doesn't fit your view of the API, then by all means edit the
>>> patch, but if you go about rejecting things that work, there won't be as
>>> many contributors to CM.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jul 18, 2013 at 10:08 AM, Roger L. Whitcomb <
>>> [hidden email]> wrote:
>>>
>>>> As an outsider listening to these discussions, it seems like:
>>>> a) *IF* there are problems with the current arrangement of packages,
>> APIs,
>>>> or whatever, then a constructive approach would be for the one who sees
>>>> such problems to take the time to not just criticize and point out
>> "flaws",
>>>> but to dig in and rearrange the packages, redo the APIs, provide unit
>>>> tests, and submit a patch with these changes, along with quantitative
>>>> justification, benchmarks, test cases, etc.  It is quite easy to
>> criticize,
>>>> from the sidelines, the one who is actually doing the work, but quite
>>>> another matter to roll up your sleeves and join in the work....
>>>> b) Since Math is a "library", it seems like there needs to be
>>>> implementations of many different algorithms, since (quite clearly) not
>>>> every algorithm is suited to every problem.  To say that X method
>> doesn't
>>>> work well for problem Y, is not necessarily a reason to rewrite X
>> method,
>>>> if that method is correctly implementing the algorithm.  Maybe the
>>>> algorithm is simply not the right one to use for the problem.
>>>> c) Comments that imply (or state outright) that someone who has
>> (clearly)
>>>> done a lot of work has done it "...without much thinking..." are clearly
>>>> out of line.  In my experience, the only reason to resort to name
>> calling
>>>> and character assassination is because one has no worthy arguments to
>> put
>>>> forward.
>>>> d) Kudos to the Commons committers who have been doing the work ...
>>>>
>>>> My 2 cents...
>>>>
>>>> ~Roger Whitcomb
>>>> Apache Pivot PMC Chair
>>>>
>>>> -----Original Message-----
>>>> From: Gilles [mailto:[hidden email]]
>>>> Sent: Thursday, July 18, 2013 9:35 AM
>>>> To: [hidden email]
>>>> Subject: Re: [Math] Cleaning up the curve fitters
>>>>
>>>> On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
>>>>> I appreciate the comment. I would like to help, but currently my
>>>>> schedule is full. Maybe towards the end of the year.
>>>>>
>>>>> I think the first approach should be do no harm. The optimization
>>>>> package keeps getting refactored every few months without much
>>>>> thinking involved. We had the discuss previously, with Gilles
>>>>> unilaterally deciding on the current tree, which he now wants to
>>>>> change again.
>>>> As I said,
>>>> as Luc said,
>>>> as Phil said,
>>>> again and again and again,
>>>> we are not optimization (as a scientific field) experts here, but we do
>>>> use Commons Math in scientific code that is pretty compute intensive
>> (and
>>>> yes, maybe not in the same sense as you'd like it to be for your
>> comfort).
>>>> Current code has, and may still have problems, but we see them only
>>>> through running unit tests, running our applications, running code
>> examples
>>>> submitted by issue reporters.
>>>> We improve what we can, given time and motivation constraints.
>>>> Other than that, there is nothing.
>>>>
>>>> Yes, we already had that asymmetrical conversation where _you_ declare
>>>> what _we_ should do.
>>>>
>>>>> As someone who uses optimization regular I would say the current API
>>>>> state (not just package naming) leaves a lot to be desired, and is not
>>>>> amenable to the various modification that people might need for larger
>>>>> problems. So if you are going to modify it, you should at least open
>>>>> up the API to the possibility that different optimization steps can be
>>>>> done using various techniques, depending on the problem.
>>>>>
>>>>> We should also accept that not everything can fit neatly into a
>>>>> package tree and a single set of APIs. A good example is least
>>>>> squares. Linear least squares does not require an initial guess at a
>>>>> solution, and by performing decomposition ahead of time you can
>>>>> quickly recompute the solution given different input values. However,
>>>>> an iterative least squares method might not have these properties.
>>>>> There are probably countless of other examples.
>>>>>
>>>>> Because optimization problems are really computationally hard all the
>>>>> little specific differences matter, that is why Gilles approach of
>>>>> sweeping everything under the rug and into some rigid not thought out
>>>>> hierarchical API forces these methods to adapt (or drop) numerical
>>>>> aspects that should not be there (e.x. polynomial fits). This has
>>>>> *huge* performance implications, but the issue is treated as some OO
>>>>> design 101 class, with the focus on how to force everything into a
>>>>> simple inheritance structure, numerics be damned.
>>>>>
>>>>> I would gladly help with the feedback when I can. Ajo and I provided
>>>>> code for adaptive integration, yet the whole issue was completely
>>>>> ignored. So I am not sure how much effort is required for the
>>>>> developers to take an idea or mostly completed code and make a change,
>>>>> rather than reject even the most basic numerical approaches that are
>>>>> taught in introduction classes as something that needs to be
>>>>> benchmarked.
>>>> As usual, you are mixing everything, from algorithms to implementations,
>>>> from proposing new features to denigrating existing ones (with
>> non-existent
>>>> or inappropriate use-cases), from numerical to efficiency
>> considerations...
>>>> [On top of it, you blatantly affirm that this issue has been ignored,
>> even
>>>> as I provided[1] an analysis[2] of what was actually happening.
>>>> People like you seem to ignore that we work benevolently on this
>> project!]
>>>> Not even speaking of derogatory remarks like "sweeping [...] under the
>> rug"
>>>> and "not thought out" and insinuating that everything was better and
>> more
>>>> efficient before. Which is simply not true.
>>>>
>>>> It's an asymmetrical discussion because you declare that half-baked code
>>>> is good enough and _we_ have to work even more than if we'd have to
>>>> implement the feature from scratch.
>>>>
>>>>
>>>> Gilles
>>>>
>>>> [1] In the spare time I do _not_ have either.
>>>> [2] Which dragged me to the implementation of the Gauss-Hermite
>> quadrature
>>>>      scheme (although I had no personal use of it), which seems to be
>> the
>>>>      appropriate way to deal with the improper integral reported in the
>>>>      issue which you refer to.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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]
>>
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Cleaning up the curve fitters

Ted Dunning
The discussion about how to get something into commons when it is (a) well
documented and (b) demonstrated better on at least some domains is
partially procedural, but it hinges on technical factors.

I think that Ajo is being very reserved here.  When I faced similar
discouragement in the past with commons math contributions, I simply went
elsewhere.

It still seems to me that it would serve CM well to pay more attention to
Ajo's comments and suggestions.  Simply saying that we should focus on
technical discussion when CM's list is filled with esthetic arguments
really just sounds like a way of pushing people away.


On Fri, Jul 19, 2013 at 10:21 AM, Phil Steitz <[hidden email]> wrote:

> As I said above, let's focus on actual technical discussion here.
> We implement standard, well-documented algorithms.  We need to
> provide references and convince ourselves that what we release is
> numerically sound, well-documented and well-tested.  We do our best
> with the volunteer resources we have.  Your help and contributions
> are appreciated.
>
> Phil
>
> On 7/19/13 9:44 AM, Ajo Fod wrote:
> > Hi,
> >
> > I very much appreciate the work that has been done in CM and this is
> > precisely why I'd like more people to contribute. Even when you didnt'
> > accept my MATH-995 patch, I got useful input from Konstantin and it has
> > already made my application more efficient.
> >
> > What you required of me in the Improper integral example was a comparison
> > of different methods. This sort of research takes time. I hear that
> Gilles
> > is working on it. I appreciate that you guys spent so much effort on
> this.
> >
> > However, my contention is that your efforts at researching alternate
> > solutions to a patch is not justified till you come up with a test that
> the
> > patch fails OR if you know an alternate performs better for an
> application
> > you have. In the first case, you're losing the efficiency of open source
> by
> > reinventing a possibly different wheel without sufficient marginal
> reward.
> > In the second case, beware of the fact that numerical algorithms are
> hairy
> > beasts, and it takes a while to encode something new. The efficiency of
> > commons comes from putting the burden of development on the developers
> who
> > need the code.
> >
> > So, I propose an alternate approach to testing if a submitted patch needs
> > to be accepted:
> > 1. Check if the patch fills a gap in existing CM code
> > 2. if so, check if it passes known tests
> > 3. if so, write up alternate tests to see if the code breaks.
> > 4. if so, wrap the code up in a suitable API and accept the patch
> >
> > This has two advantages. First CM will have more capabilities per unit of
> > your precious time. Second you give people the feeling that they are
> making
> > a difference.
> >
> > As far as the debate on AQ(AdaptiveQuadrature) vs
> > LGQ(IterativeLegendreGaussIntegrator) goes:
> > The FACTS that support AQ over LGQ are:
> > 1. An example where LGQ failed and AQ succeeded. I also explained why LGQ
> > fails and AQ will probably converge more correctly. Generally adaptive
> > quadrature are known to be so succesful at integration that Konstantin
> even
> > wondered why we don't have something yet.
> > 2. Efficiency improvement: I also showed that LGQ is more efficient at at
> > least one example in terms of accuracy in digits per function evaluation.
> > So, conversely, its now your turn to provide concrete examples where LGQ
> > does better than AQ. You could pose credible objections by providing
> > examples where:
> > 1. AQ fails but LGQ passes.
> > 2. LGQ is more efficient in accuracy per evaluation.
> >
> > All that to illustrate with example where the perception that it is hard
> to
> > convince the gatekeepers of commons of the merits of a patch arises
> from. I
> > have a package in my codebase with assorted patches that I just dont'
> think
> > is worth the time to try to post to commons. I think it is very
> inefficient
> > if others have such private patches.
> >
> > Cheers,
> > Ajo
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Jul 18, 2013 at 2:15 PM, Phil Steitz <[hidden email]>
> wrote:
> >
> >> On 7/18/13 1:48 PM, Ajo Fod wrote:
> >>> Hello folks,
> >>>
> >>> There is a lot of work in API design. However, Konstantin's point is
> that
> >>> it takes a lot of effort to convince Gilles of any alternatives. API
> >> design
> >>> issues should really be second to functionality. This idea seems to be
> >> lost
> >>> in conversations.
> >> With patience and collaboration you can have both and we *need* to
> >> have both.  You can't get to a stable API and approachable and
> >> maintainable code base without thinking carefully about API design.
> >>> I agree with Gilles that providing tests and benchmarks that exhibit
> the
> >>> advantages of a particular method are probably the best way to show
> other
> >>> contributors the value of an alternative approach.
> >> There is some value to this, but honestly much more value in
> >> carefully researching and presenting the numerical analysis to
> >> support improvement / performance claims.
> >>> It is quite depressing to the contributor to see one's contribution be
> >>> rejected when efficiency/accuracy improvements are demonstrated.
> >> What you "demonstrated" in one case was better performance in one
> >> problem instance.  The change of variable approach you implemented
> >> was, in my admittedly possibly naive numerics view, questionable.  I
> >> asked to see numerical analysis support and no one provided that.
> >> Had you provided that, I would have argued to include some version
> >> of the patch.
> >>
> >>> In a
> >>> better world, rejecting a patch that passes the hurdle of demonstrating
> >> an
> >>> efficiency improvement over existing code should come with a
> >> responsibility
> >>> of showing alternate tests that the patch fails and the original code
> >>> passes. Otherwise, the patch should be accepted by default. The person
> >> who
> >>> commits or designed the API is free to make changes to fit API design.
> >> This is essentially what Gilles ended up doing.  You may not agree
> >> with the approach, but he did in fact address the core issue.
> >>> Just like API designers are not experts at the underlying math,
> >>> contributors are not necessarily experts at the underlying API design.
> To
> >>> unlock the efficiency of open source, contributor morale needs to be
> >>> considered and classes that pass tests should really be accepted.
> >> I agree that we should try to be friendly and encouraging and I
> >> apologize if we have not been so.  That said, the process of
> >> contributing here is not just tossing patches over the wall.  First
> >> you need to get community support for the ideas.  Then work
> >> collaboratively to get patches that work for the code and community.
> >>> For example, Performance AND accuracy improvements to existing
> algorithm
> >>> were demonstrated for AdaptiveQuadrature in my patches to MATH-995
> >> Sorry, I was not convinced by the accuracy and performance claims
> >> and, as I said above, I suspect that the change of variable approach
> >> may not be the best way to handle improper integrals.  I am not
> >> claiming authority here - just - again - asking for real numerical
> >> analysis arguments to support the claims you are making.
> >>
> >> It would be a lot better if we focused discussion on the actual
> >> technical issues and mathematical principles rather than
> >> generalities about how hard / easy it is to get stuff in.
> >>
> >> Phil
> >>> The only joy I got out of that was Gilles putting a comment in the docs
> >> for
> >>> the existing class:
> >>> "The Javadoc now draws attention that the [existing] algorithm is not
> >> 100%
> >>> fool-proof."!
> >>> Also, I was asked to open a new issue about Adaptive Quadratures to
> >> figure
> >>> out what is the best quadratue method ... all while a patch that is a
> >> clear
> >>> improvement over existing code wastes away. Why not accept the patch
> and
> >>> make improvements as necessary?
> >>>
> >>> My impression since that patch was rejected, is that it just seems
> like a
> >>> huge hurdle to get any patch past the API design requirements that are
> >>> frankly not as clear to me as it is to the designer. I can see how
> others
> >>> feel the same way.
> >>>
> >>> Cheers,
> >>> Ajo.
> >>>
> >>> Gilles: if you don't want to end up spending time developing
> >> Gauss-Hermite
> >>> quadrature or something else you don't really need, perhaps you should
> >>> consider accepting/modifying code that was shown to work by someone who
> >>> needed that functionality. It is reasonable to develop alternatives to
> >> fix
> >>> flaws/gaps, but otherwise its your effort wasted.  If someone's
> >>> contribution doesn't fit your view of the API, then by all means edit
> the
> >>> patch, but if you go about rejecting things that work, there won't be
> as
> >>> many contributors to CM.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Jul 18, 2013 at 10:08 AM, Roger L. Whitcomb <
> >>> [hidden email]> wrote:
> >>>
> >>>> As an outsider listening to these discussions, it seems like:
> >>>> a) *IF* there are problems with the current arrangement of packages,
> >> APIs,
> >>>> or whatever, then a constructive approach would be for the one who
> sees
> >>>> such problems to take the time to not just criticize and point out
> >> "flaws",
> >>>> but to dig in and rearrange the packages, redo the APIs, provide unit
> >>>> tests, and submit a patch with these changes, along with quantitative
> >>>> justification, benchmarks, test cases, etc.  It is quite easy to
> >> criticize,
> >>>> from the sidelines, the one who is actually doing the work, but quite
> >>>> another matter to roll up your sleeves and join in the work....
> >>>> b) Since Math is a "library", it seems like there needs to be
> >>>> implementations of many different algorithms, since (quite clearly)
> not
> >>>> every algorithm is suited to every problem.  To say that X method
> >> doesn't
> >>>> work well for problem Y, is not necessarily a reason to rewrite X
> >> method,
> >>>> if that method is correctly implementing the algorithm.  Maybe the
> >>>> algorithm is simply not the right one to use for the problem.
> >>>> c) Comments that imply (or state outright) that someone who has
> >> (clearly)
> >>>> done a lot of work has done it "...without much thinking..." are
> clearly
> >>>> out of line.  In my experience, the only reason to resort to name
> >> calling
> >>>> and character assassination is because one has no worthy arguments to
> >> put
> >>>> forward.
> >>>> d) Kudos to the Commons committers who have been doing the work ...
> >>>>
> >>>> My 2 cents...
> >>>>
> >>>> ~Roger Whitcomb
> >>>> Apache Pivot PMC Chair
> >>>>
> >>>> -----Original Message-----
> >>>> From: Gilles [mailto:[hidden email]]
> >>>> Sent: Thursday, July 18, 2013 9:35 AM
> >>>> To: [hidden email]
> >>>> Subject: Re: [Math] Cleaning up the curve fitters
> >>>>
> >>>> On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
> >>>>> I appreciate the comment. I would like to help, but currently my
> >>>>> schedule is full. Maybe towards the end of the year.
> >>>>>
> >>>>> I think the first approach should be do no harm. The optimization
> >>>>> package keeps getting refactored every few months without much
> >>>>> thinking involved. We had the discuss previously, with Gilles
> >>>>> unilaterally deciding on the current tree, which he now wants to
> >>>>> change again.
> >>>> As I said,
> >>>> as Luc said,
> >>>> as Phil said,
> >>>> again and again and again,
> >>>> we are not optimization (as a scientific field) experts here, but we
> do
> >>>> use Commons Math in scientific code that is pretty compute intensive
> >> (and
> >>>> yes, maybe not in the same sense as you'd like it to be for your
> >> comfort).
> >>>> Current code has, and may still have problems, but we see them only
> >>>> through running unit tests, running our applications, running code
> >> examples
> >>>> submitted by issue reporters.
> >>>> We improve what we can, given time and motivation constraints.
> >>>> Other than that, there is nothing.
> >>>>
> >>>> Yes, we already had that asymmetrical conversation where _you_ declare
> >>>> what _we_ should do.
> >>>>
> >>>>> As someone who uses optimization regular I would say the current API
> >>>>> state (not just package naming) leaves a lot to be desired, and is
> not
> >>>>> amenable to the various modification that people might need for
> larger
> >>>>> problems. So if you are going to modify it, you should at least open
> >>>>> up the API to the possibility that different optimization steps can
> be
> >>>>> done using various techniques, depending on the problem.
> >>>>>
> >>>>> We should also accept that not everything can fit neatly into a
> >>>>> package tree and a single set of APIs. A good example is least
> >>>>> squares. Linear least squares does not require an initial guess at a
> >>>>> solution, and by performing decomposition ahead of time you can
> >>>>> quickly recompute the solution given different input values. However,
> >>>>> an iterative least squares method might not have these properties.
> >>>>> There are probably countless of other examples.
> >>>>>
> >>>>> Because optimization problems are really computationally hard all the
> >>>>> little specific differences matter, that is why Gilles approach of
> >>>>> sweeping everything under the rug and into some rigid not thought out
> >>>>> hierarchical API forces these methods to adapt (or drop) numerical
> >>>>> aspects that should not be there (e.x. polynomial fits). This has
> >>>>> *huge* performance implications, but the issue is treated as some OO
> >>>>> design 101 class, with the focus on how to force everything into a
> >>>>> simple inheritance structure, numerics be damned.
> >>>>>
> >>>>> I would gladly help with the feedback when I can. Ajo and I provided
> >>>>> code for adaptive integration, yet the whole issue was completely
> >>>>> ignored. So I am not sure how much effort is required for the
> >>>>> developers to take an idea or mostly completed code and make a
> change,
> >>>>> rather than reject even the most basic numerical approaches that are
> >>>>> taught in introduction classes as something that needs to be
> >>>>> benchmarked.
> >>>> As usual, you are mixing everything, from algorithms to
> implementations,
> >>>> from proposing new features to denigrating existing ones (with
> >> non-existent
> >>>> or inappropriate use-cases), from numerical to efficiency
> >> considerations...
> >>>> [On top of it, you blatantly affirm that this issue has been ignored,
> >> even
> >>>> as I provided[1] an analysis[2] of what was actually happening.
> >>>> People like you seem to ignore that we work benevolently on this
> >> project!]
> >>>> Not even speaking of derogatory remarks like "sweeping [...] under the
> >> rug"
> >>>> and "not thought out" and insinuating that everything was better and
> >> more
> >>>> efficient before. Which is simply not true.
> >>>>
> >>>> It's an asymmetrical discussion because you declare that half-baked
> code
> >>>> is good enough and _we_ have to work even more than if we'd have to
> >>>> implement the feature from scratch.
> >>>>
> >>>>
> >>>> Gilles
> >>>>
> >>>> [1] In the spare time I do _not_ have either.
> >>>> [2] Which dragged me to the implementation of the Gauss-Hermite
> >> quadrature
> >>>>      scheme (although I had no personal use of it), which seems to be
> >> the
> >>>>      appropriate way to deal with the improper integral reported in
> the
> >>>>      issue which you refer to.
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Cleaning up the curve fitters

Phil Steitz
On 7/19/13 12:21 PM, Ted Dunning wrote:

> The discussion about how to get something into commons when it is (a) well
> documented and (b) demonstrated better on at least some domains is
> partially procedural, but it hinges on technical factors.
>
> I think that Ajo is being very reserved here.  When I faced similar
> discouragement in the past with commons math contributions, I simply went
> elsewhere.
>
> It still seems to me that it would serve CM well to pay more attention to
> Ajo's comments and suggestions.  Simply saying that we should focus on
> technical discussion when CM's list is filled with esthetic arguments
> really just sounds like a way of pushing people away.

Please read the threads.  This is not "esthetics."  Maybe you can
help.

Phil

>
>
> On Fri, Jul 19, 2013 at 10:21 AM, Phil Steitz <[hidden email]> wrote:
>
>> As I said above, let's focus on actual technical discussion here.
>> We implement standard, well-documented algorithms.  We need to
>> provide references and convince ourselves that what we release is
>> numerically sound, well-documented and well-tested.  We do our best
>> with the volunteer resources we have.  Your help and contributions
>> are appreciated.
>>
>> Phil
>>
>> On 7/19/13 9:44 AM, Ajo Fod wrote:
>>> Hi,
>>>
>>> I very much appreciate the work that has been done in CM and this is
>>> precisely why I'd like more people to contribute. Even when you didnt'
>>> accept my MATH-995 patch, I got useful input from Konstantin and it has
>>> already made my application more efficient.
>>>
>>> What you required of me in the Improper integral example was a comparison
>>> of different methods. This sort of research takes time. I hear that
>> Gilles
>>> is working on it. I appreciate that you guys spent so much effort on
>> this.
>>> However, my contention is that your efforts at researching alternate
>>> solutions to a patch is not justified till you come up with a test that
>> the
>>> patch fails OR if you know an alternate performs better for an
>> application
>>> you have. In the first case, you're losing the efficiency of open source
>> by
>>> reinventing a possibly different wheel without sufficient marginal
>> reward.
>>> In the second case, beware of the fact that numerical algorithms are
>> hairy
>>> beasts, and it takes a while to encode something new. The efficiency of
>>> commons comes from putting the burden of development on the developers
>> who
>>> need the code.
>>>
>>> So, I propose an alternate approach to testing if a submitted patch needs
>>> to be accepted:
>>> 1. Check if the patch fills a gap in existing CM code
>>> 2. if so, check if it passes known tests
>>> 3. if so, write up alternate tests to see if the code breaks.
>>> 4. if so, wrap the code up in a suitable API and accept the patch
>>>
>>> This has two advantages. First CM will have more capabilities per unit of
>>> your precious time. Second you give people the feeling that they are
>> making
>>> a difference.
>>>
>>> As far as the debate on AQ(AdaptiveQuadrature) vs
>>> LGQ(IterativeLegendreGaussIntegrator) goes:
>>> The FACTS that support AQ over LGQ are:
>>> 1. An example where LGQ failed and AQ succeeded. I also explained why LGQ
>>> fails and AQ will probably converge more correctly. Generally adaptive
>>> quadrature are known to be so succesful at integration that Konstantin
>> even
>>> wondered why we don't have something yet.
>>> 2. Efficiency improvement: I also showed that LGQ is more efficient at at
>>> least one example in terms of accuracy in digits per function evaluation.
>>> So, conversely, its now your turn to provide concrete examples where LGQ
>>> does better than AQ. You could pose credible objections by providing
>>> examples where:
>>> 1. AQ fails but LGQ passes.
>>> 2. LGQ is more efficient in accuracy per evaluation.
>>>
>>> All that to illustrate with example where the perception that it is hard
>> to
>>> convince the gatekeepers of commons of the merits of a patch arises
>> from. I
>>> have a package in my codebase with assorted patches that I just dont'
>> think
>>> is worth the time to try to post to commons. I think it is very
>> inefficient
>>> if others have such private patches.
>>>
>>> Cheers,
>>> Ajo
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jul 18, 2013 at 2:15 PM, Phil Steitz <[hidden email]>
>> wrote:
>>>> On 7/18/13 1:48 PM, Ajo Fod wrote:
>>>>> Hello folks,
>>>>>
>>>>> There is a lot of work in API design. However, Konstantin's point is
>> that
>>>>> it takes a lot of effort to convince Gilles of any alternatives. API
>>>> design
>>>>> issues should really be second to functionality. This idea seems to be
>>>> lost
>>>>> in conversations.
>>>> With patience and collaboration you can have both and we *need* to
>>>> have both.  You can't get to a stable API and approachable and
>>>> maintainable code base without thinking carefully about API design.
>>>>> I agree with Gilles that providing tests and benchmarks that exhibit
>> the
>>>>> advantages of a particular method are probably the best way to show
>> other
>>>>> contributors the value of an alternative approach.
>>>> There is some value to this, but honestly much more value in
>>>> carefully researching and presenting the numerical analysis to
>>>> support improvement / performance claims.
>>>>> It is quite depressing to the contributor to see one's contribution be
>>>>> rejected when efficiency/accuracy improvements are demonstrated.
>>>> What you "demonstrated" in one case was better performance in one
>>>> problem instance.  The change of variable approach you implemented
>>>> was, in my admittedly possibly naive numerics view, questionable.  I
>>>> asked to see numerical analysis support and no one provided that.
>>>> Had you provided that, I would have argued to include some version
>>>> of the patch.
>>>>
>>>>> In a
>>>>> better world, rejecting a patch that passes the hurdle of demonstrating
>>>> an
>>>>> efficiency improvement over existing code should come with a
>>>> responsibility
>>>>> of showing alternate tests that the patch fails and the original code
>>>>> passes. Otherwise, the patch should be accepted by default. The person
>>>> who
>>>>> commits or designed the API is free to make changes to fit API design.
>>>> This is essentially what Gilles ended up doing.  You may not agree
>>>> with the approach, but he did in fact address the core issue.
>>>>> Just like API designers are not experts at the underlying math,
>>>>> contributors are not necessarily experts at the underlying API design.
>> To
>>>>> unlock the efficiency of open source, contributor morale needs to be
>>>>> considered and classes that pass tests should really be accepted.
>>>> I agree that we should try to be friendly and encouraging and I
>>>> apologize if we have not been so.  That said, the process of
>>>> contributing here is not just tossing patches over the wall.  First
>>>> you need to get community support for the ideas.  Then work
>>>> collaboratively to get patches that work for the code and community.
>>>>> For example, Performance AND accuracy improvements to existing
>> algorithm
>>>>> were demonstrated for AdaptiveQuadrature in my patches to MATH-995
>>>> Sorry, I was not convinced by the accuracy and performance claims
>>>> and, as I said above, I suspect that the change of variable approach
>>>> may not be the best way to handle improper integrals.  I am not
>>>> claiming authority here - just - again - asking for real numerical
>>>> analysis arguments to support the claims you are making.
>>>>
>>>> It would be a lot better if we focused discussion on the actual
>>>> technical issues and mathematical principles rather than
>>>> generalities about how hard / easy it is to get stuff in.
>>>>
>>>> Phil
>>>>> The only joy I got out of that was Gilles putting a comment in the docs
>>>> for
>>>>> the existing class:
>>>>> "The Javadoc now draws attention that the [existing] algorithm is not
>>>> 100%
>>>>> fool-proof."!
>>>>> Also, I was asked to open a new issue about Adaptive Quadratures to
>>>> figure
>>>>> out what is the best quadratue method ... all while a patch that is a
>>>> clear
>>>>> improvement over existing code wastes away. Why not accept the patch
>> and
>>>>> make improvements as necessary?
>>>>>
>>>>> My impression since that patch was rejected, is that it just seems
>> like a
>>>>> huge hurdle to get any patch past the API design requirements that are
>>>>> frankly not as clear to me as it is to the designer. I can see how
>> others
>>>>> feel the same way.
>>>>>
>>>>> Cheers,
>>>>> Ajo.
>>>>>
>>>>> Gilles: if you don't want to end up spending time developing
>>>> Gauss-Hermite
>>>>> quadrature or something else you don't really need, perhaps you should
>>>>> consider accepting/modifying code that was shown to work by someone who
>>>>> needed that functionality. It is reasonable to develop alternatives to
>>>> fix
>>>>> flaws/gaps, but otherwise its your effort wasted.  If someone's
>>>>> contribution doesn't fit your view of the API, then by all means edit
>> the
>>>>> patch, but if you go about rejecting things that work, there won't be
>> as
>>>>> many contributors to CM.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 18, 2013 at 10:08 AM, Roger L. Whitcomb <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>> As an outsider listening to these discussions, it seems like:
>>>>>> a) *IF* there are problems with the current arrangement of packages,
>>>> APIs,
>>>>>> or whatever, then a constructive approach would be for the one who
>> sees
>>>>>> such problems to take the time to not just criticize and point out
>>>> "flaws",
>>>>>> but to dig in and rearrange the packages, redo the APIs, provide unit
>>>>>> tests, and submit a patch with these changes, along with quantitative
>>>>>> justification, benchmarks, test cases, etc.  It is quite easy to
>>>> criticize,
>>>>>> from the sidelines, the one who is actually doing the work, but quite
>>>>>> another matter to roll up your sleeves and join in the work....
>>>>>> b) Since Math is a "library", it seems like there needs to be
>>>>>> implementations of many different algorithms, since (quite clearly)
>> not
>>>>>> every algorithm is suited to every problem.  To say that X method
>>>> doesn't
>>>>>> work well for problem Y, is not necessarily a reason to rewrite X
>>>> method,
>>>>>> if that method is correctly implementing the algorithm.  Maybe the
>>>>>> algorithm is simply not the right one to use for the problem.
>>>>>> c) Comments that imply (or state outright) that someone who has
>>>> (clearly)
>>>>>> done a lot of work has done it "...without much thinking..." are
>> clearly
>>>>>> out of line.  In my experience, the only reason to resort to name
>>>> calling
>>>>>> and character assassination is because one has no worthy arguments to
>>>> put
>>>>>> forward.
>>>>>> d) Kudos to the Commons committers who have been doing the work ...
>>>>>>
>>>>>> My 2 cents...
>>>>>>
>>>>>> ~Roger Whitcomb
>>>>>> Apache Pivot PMC Chair
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Gilles [mailto:[hidden email]]
>>>>>> Sent: Thursday, July 18, 2013 9:35 AM
>>>>>> To: [hidden email]
>>>>>> Subject: Re: [Math] Cleaning up the curve fitters
>>>>>>
>>>>>> On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
>>>>>>> I appreciate the comment. I would like to help, but currently my
>>>>>>> schedule is full. Maybe towards the end of the year.
>>>>>>>
>>>>>>> I think the first approach should be do no harm. The optimization
>>>>>>> package keeps getting refactored every few months without much
>>>>>>> thinking involved. We had the discuss previously, with Gilles
>>>>>>> unilaterally deciding on the current tree, which he now wants to
>>>>>>> change again.
>>>>>> As I said,
>>>>>> as Luc said,
>>>>>> as Phil said,
>>>>>> again and again and again,
>>>>>> we are not optimization (as a scientific field) experts here, but we
>> do
>>>>>> use Commons Math in scientific code that is pretty compute intensive
>>>> (and
>>>>>> yes, maybe not in the same sense as you'd like it to be for your
>>>> comfort).
>>>>>> Current code has, and may still have problems, but we see them only
>>>>>> through running unit tests, running our applications, running code
>>>> examples
>>>>>> submitted by issue reporters.
>>>>>> We improve what we can, given time and motivation constraints.
>>>>>> Other than that, there is nothing.
>>>>>>
>>>>>> Yes, we already had that asymmetrical conversation where _you_ declare
>>>>>> what _we_ should do.
>>>>>>
>>>>>>> As someone who uses optimization regular I would say the current API
>>>>>>> state (not just package naming) leaves a lot to be desired, and is
>> not
>>>>>>> amenable to the various modification that people might need for
>> larger
>>>>>>> problems. So if you are going to modify it, you should at least open
>>>>>>> up the API to the possibility that different optimization steps can
>> be
>>>>>>> done using various techniques, depending on the problem.
>>>>>>>
>>>>>>> We should also accept that not everything can fit neatly into a
>>>>>>> package tree and a single set of APIs. A good example is least
>>>>>>> squares. Linear least squares does not require an initial guess at a
>>>>>>> solution, and by performing decomposition ahead of time you can
>>>>>>> quickly recompute the solution given different input values. However,
>>>>>>> an iterative least squares method might not have these properties.
>>>>>>> There are probably countless of other examples.
>>>>>>>
>>>>>>> Because optimization problems are really computationally hard all the
>>>>>>> little specific differences matter, that is why Gilles approach of
>>>>>>> sweeping everything under the rug and into some rigid not thought out
>>>>>>> hierarchical API forces these methods to adapt (or drop) numerical
>>>>>>> aspects that should not be there (e.x. polynomial fits). This has
>>>>>>> *huge* performance implications, but the issue is treated as some OO
>>>>>>> design 101 class, with the focus on how to force everything into a
>>>>>>> simple inheritance structure, numerics be damned.
>>>>>>>
>>>>>>> I would gladly help with the feedback when I can. Ajo and I provided
>>>>>>> code for adaptive integration, yet the whole issue was completely
>>>>>>> ignored. So I am not sure how much effort is required for the
>>>>>>> developers to take an idea or mostly completed code and make a
>> change,
>>>>>>> rather than reject even the most basic numerical approaches that are
>>>>>>> taught in introduction classes as something that needs to be
>>>>>>> benchmarked.
>>>>>> As usual, you are mixing everything, from algorithms to
>> implementations,
>>>>>> from proposing new features to denigrating existing ones (with
>>>> non-existent
>>>>>> or inappropriate use-cases), from numerical to efficiency
>>>> considerations...
>>>>>> [On top of it, you blatantly affirm that this issue has been ignored,
>>>> even
>>>>>> as I provided[1] an analysis[2] of what was actually happening.
>>>>>> People like you seem to ignore that we work benevolently on this
>>>> project!]
>>>>>> Not even speaking of derogatory remarks like "sweeping [...] under the
>>>> rug"
>>>>>> and "not thought out" and insinuating that everything was better and
>>>> more
>>>>>> efficient before. Which is simply not true.
>>>>>>
>>>>>> It's an asymmetrical discussion because you declare that half-baked
>> code
>>>>>> is good enough and _we_ have to work even more than if we'd have to
>>>>>> implement the feature from scratch.
>>>>>>
>>>>>>
>>>>>> Gilles
>>>>>>
>>>>>> [1] In the spare time I do _not_ have either.
>>>>>> [2] Which dragged me to the implementation of the Gauss-Hermite
>>>> quadrature
>>>>>>      scheme (although I had no personal use of it), which seems to be
>>>> the
>>>>>>      appropriate way to deal with the improper integral reported in
>> the
>>>>>>      issue which you refer to.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> 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] Cleaning up the curve fitters

Ted Dunning
On Fri, Jul 19, 2013 at 12:27 PM, Phil Steitz <[hidden email]> wrote:

> > It still seems to me that it would serve CM well to pay more attention to
> > Ajo's comments and suggestions.  Simply saying that we should focus on
> > technical discussion when CM's list is filled with esthetic arguments
> > really just sounds like a way of pushing people away.
>
> Please read the threads.  This is not "esthetics."  Maybe you can
> help.
>

I read the threads.  I stand by my assertions that there are *lots* of
non-technical discussions on CM.

Rejecting this particular argument since it is procedural+technical rather
than just technical seems less supportable than continuing those other
threads.

Help?  The way that I help with the esthetic threads is by staying out of
the way.  Contributing to the noise level is not helpful and the endurance
and spare time of the typical CM poster is apparently boundless.

With this thread, the input I have is that Ajo's comments make a lot of
sense (to me) and the "technical" arguments against including AQ as an
option do not make a lot of sense (to me).
12