[ 
https://issues.apache.org/jira/browse/MATH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17741945#comment-17741945
 ] 

Gilles Sadowski commented on MATH-1656:
---------------------------------------

bq. With plain junit, you just have a statement like "result is 5, should be 4" 
[...] I hated it when I first use junit some ... 24 years ago.

At the time, it was certainly an improvement over code being released with no 
tests... ;-)

bq. [...] I deeply feel that I won't ever convince you.

More on that below.  Here the point is about uniformity of the code base: 
Current de facto consensus is that new code should be maintainable, i.e. not 
add to the pile that is not (prime example being the implementation of 
"BOBYQA").  In CM (as in all the new components that were created from code 
originally in CM), top priorities (_current_ consensus) are
# full documentation,
# full coverage,
# align on "standard" usage of "JUnit 5".

I cannot decide, now and by myself, to commit your "DiffTest.java" file since 
it is at odds with the 3 points above:
# It is undocumented.
# If (for some hypothetical reason) your test framework is removed, the code 
that was covered, won't be anymore.
# It differs from the rest (even within the "optim" package).

The *consensus can change* but, on such matters, it would be settled through a 
_discussion_ on the "dev" ML.

IOW, on the framework itself, I didn't say anything other that _it might be a 
neat idea_.  But it is (currently) not something that (IMHO) CM should maintain 
just for the sake of testing a relatively small part of its code.  [You are 
welcome to ask for others' opinion on the "dev" ML.]

That said, some time ago, Gary Gregory proposed to create a "Commons Testing" 
component; I'm readily convinced that your framework would fit within the scope 
of such an endeavour.  So please *post your proposal to the "dev" ML* (with a 
"Subject: " prefix like "[All][Testing]").  Then, if the new component gets 
traction, the whole "Commons" team will bear the maintenance burden; and it 
will be much easier for CM to have it as a dependency (and gradually replace 
the current tests).


> Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) 
> are missing
> --------------------------------------------------------------------------------------
>
>                 Key: MATH-1656
>                 URL: https://issues.apache.org/jira/browse/MATH-1656
>             Project: Commons Math
>          Issue Type: Wish
>          Components: legacy
>    Affects Versions: 4.0-beta1
>            Reporter: François Laferrière
>            Priority: Major
>              Labels: features
>         Attachments: MATH-1656-GradientDescent-Newton-BFGS-v2.0.zip, 
> MATH-1658-GradientDescent-Newton-BFGS.patch, Screenshot from 2023-07-10 
> 12-13-38.png
>
>
> Some classical multivariate such as
>  * gradient descent,
>  * Raphson-Newton,
>  * BFGS
> are missing.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to