On Thu, Jul 07, 2011 at 03:40:19PM +0200, Luc Maisonobe wrote:
> Le 07/07/2011 14:41, Gilles Sadowski a écrit :
> >Hi.
> >
> >>>We also do not have a clear separation between algorithms that take a
> >>>bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
> >>>If the "solve" met
Le 07/07/2011 14:41, Gilles Sadowski a écrit :
Hi.
We also do not have a clear separation between algorithms that take a
bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
If the "solve" methods called by the user contains more parameters than
needed by the algorithm imple
Hi.
> > We also do not have a clear separation between algorithms that take a
> > bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
> > If the "solve" methods called by the user contains more parameters than
> > needed by the algorithm implemented in the instance, they will
Le 07/07/2011 09:35, Dennis Hendriks a écrit :
Hi Gilles,
> We also do not have a clear separation between algorithms that take a
> bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
> If the "solve" methods called by the user contains more parameters than
> needed by t
Hi Gilles,
> We also do not have a clear separation between algorithms that take a
> bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
> If the "solve" methods called by the user contains more parameters than
> needed by the algorithm implemented in the instance, they will
While there is a discussion of solvers going on I thought I would point out
that I have done a Java translation of Dario Bini's implementation of Aberth's
method. I've attached the header of the original Fortran file below. I'd be
happy to donate my translation to Commons Math if there is inte
Hello.
>
> Here are my personal opinions on this entire discussion:
>
> I'm not sure I like the auto-magic under the hood conversion from unbracketed
> solver to bracketed solver.
It's not really "under the hood", as the user must specify an enum value to
get the "bracketing". The default ("AN
Van: Hendriks, D. [d.hendr...@tue.nl]
Verzonden: woensdag 6 juli 2011 18:43
Aan: Commons Developers List
Onderwerp: RE: [math] puzzled by generics in root solvers
I agree that since we now have LEFT_SIDE, RIGHT_SIDE, ABOVE_SIDE, and
BELOW_SIDE, it makes sense to rename it to
that are available maintain a bracketed solution,
besides the secant-based methods?
Best regards,
Dennis
Van: luc.maison...@free.fr [luc.maison...@free.fr]
Verzonden: dinsdag 5 juli 2011 22:39
Aan: Commons Developers List
Onderwerp: Re: [math] puzzle
...@harfang.homelinux.org]
Verzonden: woensdag 6 juli 2011 12:03
Aan: dev@commons.apache.org
Onderwerp: Re: [math] puzzled by generics in root solvers
On Tue, Jul 05, 2011 at 07:45:47PM -0700, Ted Dunning wrote:
> Why?
>
> On Tue, Jul 5, 2011 at 2:34 PM, Gilles Sadowski <
> gil...@harfang.homel
On Tue, Jul 05, 2011 at 07:45:47PM -0700, Ted Dunning wrote:
> Why?
>
> On Tue, Jul 5, 2011 at 2:34 PM, Gilles Sadowski <
> gil...@harfang.homelinux.org> wrote:
>
> > By the way, shouldn't "EITHER_SIDE" be renamed to "ANY_SIDE"?
> >
Because there are more than two sides.
Gilles
--
Why?
On Tue, Jul 5, 2011 at 2:34 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> By the way, shouldn't "EITHER_SIDE" be renamed to "ANY_SIDE"?
>
Hello Luc.
> [...]
> >
> > If such a fine control ("AllowedSolutions") is a desirable/necessary
> > feature, couldn't we directly add it at the level of the base class
> > (and
> > interface)? I.e. the main "solve" method would become:
> >
> > public abstract class BaseAbstractUnivariateRealSol
Hi Gilles,
- "Gilles Sadowski" a écrit :
> Hello.
>
> > [...]
> > >
> > > The purpose of the "BaseUnivariateRealSolver" is to avoid code
> > > duplication in CM. It must be general enough so that CM
> developers
> > > should
> > > not implement an "AbstractXxxsolver" that would not inherit
Hello.
> [...]
> >
> > The purpose of the "BaseUnivariateRealSolver" is to avoid code
> > duplication in CM. It must be general enough so that CM developers
> > should
> > not implement an "AbstractXxxsolver" that would not inherit from it.
>
> OK, so I think we need to introduce slight changes.
Hi Gilles,
- "Gilles Sadowski" a écrit :
> Hi.
>
> >
> > I am a little puzzled by our use of generics in the
> analysis.solvers
> > package.
> >
> > Hoping the following ASCII art will survive mail,
>
> It's very nice! :-)
>
> > here is a rough
> > overview (simplified) of what we have.
Hi.
>
> I am a little puzzled by our use of generics in the analysis.solvers
> package.
>
> Hoping the following ASCII art will survive mail,
It's very nice! :-)
> here is a rough
> overview (simplified) of what we have.
>
> BaseUnivariateRealSolver
> |
Hello,
I am a little puzzled by our use of generics in the analysis.solvers
package.
Hoping the following ASCII art will survive mail, here is a rough
overview (simplified) of what we have.
BaseUnivariateRealSolver
|
+-+---
18 matches
Mail list logo
