commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Cleaning up the curve fitters
Date Thu, 18 Jul 2013 16:34:38 GMT
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message