commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] major problem with new released version 3.1
Date Fri, 28 Dec 2012 17:13:52 GMT
On 12/28/12 8:51 AM, Konstantin Berlin wrote:
> Hi,
>
> I can understand Dimitri's frustration, it seems the optimization framework gets worse
with every iteration. However, we should probably look forward and think about how to design
it properly instead. 

+1 - though we have the constraint that we need to maintain backward
compatibility until 4.0.  If we decide it is too far gone, we have
to drop that and either cut 4.0 "quickly" (will probably be hard for
us, given all of the other refactoring we want to get done for 4.0)
or make an exception. 

>
> Several times I brought out some problems and ideas about the package and it seems the
only person who has an opinion is Gilles.
>
> I will list what I consider to be major problems
> 1) The OO design is bad, too much inheritance which could be handled better by interfaces,
We may have gone too far in favoring abstract classes over
interfaces.  What led to this historically was getting "locked in"
to incomplete interface designs due to their immutability wrt
backward compatibility.
>  the structure has no relation to the actual way parts of optimizers can be mixed and
matched. Input functions should also have clear inheritance structure and should return both
the value, gradient, hessian in one function call.
> 2) Incorrect handling of constraints. There are only something like 5 possible constraints
possible in optimization, with each implementation of the solver handling some but not all.
There is no need to this runtime approach, which creates incredible amount of confusion. All
the possible constraints should be explicitly given in the parameters to a function call,
there are only 5. In addition, constraints should be pre-processed a priori! So they should
be an input to the constructor not to the optimization function call.
> 3) Linear algebra package should be used as an interface and internally to increase performance
for larger datasets. Data copying should be avoided as much as possible.

Can you provide a little more detail and maybe some sample code
illustrating above?
> 4) Testing should be done on larger problems.
+1 - I think it would be great to add some test classes not executed
on each build to test large problems.  Do you have some we can use?

Phil
> I know the response is that I am free to go implemented, but I think we should at least
agree on design principles instead of pushing through your own ideas because the other person
is too busy. The only discussion we ever had on this was between me and Gilles, everyone else
disappeared. 
>
> Thanks,
> Konstantin
>
> On Dec 28, 2012, at 11:27 AM, Phil Steitz <phil.steitz@gmail.com> wrote:
>
>> On 12/28/12 8:12 AM, Dimitri Pourbaix wrote:
>>> Luc,
>>>
>>>> So in order to make sure I understand your point, you would be OK
>>>> if I
>>>> deprecate the non-diagonal weights, in which case users needing this
>>>> would have to implement it themselves by premultiplication (as
>>>> both you
>>>> and Konstantin seem to propose)?
>>> Yes, exactly.
>>>
>>>> Sure, but for the record the feature was also a last minute
>>>> change. This
>>>> was discussed on the list, and the final decision was to add this
>>>> feature despite the release was close. No wonder we failed to
>>>> test it
>>>> thoroughsly.
>>> Last minute?  I have been discussing this with Gilles for several
>>> months.
>> Relevant project discussion happens *on this list*
>>>> We don't expect our releases to be perfect. We do our best, with the
>>>> resources we have.
>>> I perfectly understand this but focusing those resources less on
>>> rules
>>> and more on real cases might help.
>> As stated before, you are more than welcome to *become* one of these
>> resources.
>>
>> Phil
>>> Regards,
>>> Dim.
>>> ----------------------------------------------------------------------------
>>>
>>> Dimitri Pourbaix                         *      Don't worry, be happy
>>> Institut d'Astronomie et d'Astrophysique *         and CARPE DIEM.
>>> CP 226, office 2.N4.211, building NO     *
>>> Universite Libre de Bruxelles            *      Tel : +32-2-650.35.71
>>> Boulevard du Triomphe                    *      Fax : +32-2-650.42.26
>>> B-1050 Bruxelles                        *        NAC: HBZSC RG2Z6
>>> http://sb9.astro.ulb.ac.be/~pourbaix     *
>>> mailto:pourbaix@astro.ulb.ac.be
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message