Le 24/11/2011 10:40, Gilles Sadowski a écrit :
> Hi.
>
>>
>> Issues that I have reported are
>> * MATH-581 (Support for iterative linear solvers): there is now a
>> framework for this feature, as well as two solvers (conjugate
>> gradient, SYMMLQ). While this might be extended with other solvers as
>> well, it could certainly wait (and would not lead to a change in the
>> API). The design of these classes could certainly be improved, but for
>> this, we probably need people to use them... So I suggest we solve
>> this issue for the time being. What do you think?
>
> +1
>
>> * MATH-711 (Merge xxxDistribution and xxxDistributionImpl in package
>> distribution): I'm going to work on this one (should be fairly easy).
>> * MATH-655 (General framework for iterative algorithms): this
>> requires a more thorough discussion, and could probably be tagged as
>> "won't fix", or delayed to a later version.
>
> +1 (leaving open)
>
>> I would very much like to
>> have this discussion on the design of custom stopping criteria again,
>> though.
>> * MATH-699 (inverseCumulativeDistribution fails with cumulative
>> distribution having a plateau): I have posted a new implementation of
>> inverseCumulativeDistribution which does "not really" solve this
>> issue. In short, it would allow us to get rid of methods
>> getDomainUpperBound(double), getDomainLowerBound(double) and
>> getInitialDomain(double). As for the plateau issue itself, I've added
>> an extra test which seems fairly robust, but incurs a slight overhead,
>> so I'm reluctant to include it. Two options here:
>> - clearly state in the Javadoc that the default solver *fails* in
>> the presence of plateau, and be done with it,
>> - add a flag to the constructor, to allow for plateau detection.
>> If you have any opinion on this issue, please state it on the JIRA
>> ticket. Thanks!
>
> +1
>
> The most flexible seems to have two constructors, one with the flag, and
> the other where the flag defaults to false ("do not try to detect plateau"),
> stating the caveat in the Javadoc.
>
>> Gilles, if you want, we can coordinate on MATH-689 and MATH-690.
>
> OK. But first I wanted to make sure that the proposed changes are agreed on.
I have no opinion on this, I let the specialists speak.
Luc
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
