From dev-return-127210-apmail-commons-dev-archive=commons.apache.org@commons.apache.org Mon Jul 4 21:29:39 2011 Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D59A96156 for ; Mon, 4 Jul 2011 21:29:39 +0000 (UTC) Received: (qmail 90656 invoked by uid 500); 4 Jul 2011 21:29:39 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 90478 invoked by uid 500); 4 Jul 2011 21:29:38 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 90470 invoked by uid 99); 4 Jul 2011 21:29:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jul 2011 21:29:38 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [193.74.71.28] (HELO sif.is.scarlet.be) (193.74.71.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jul 2011 21:29:32 +0000 Received: from mail.harfang.homelinux.org (ip-213-49-232-19.dsl.scarlet.be [213.49.232.19]) by sif.is.scarlet.be (8.14.2/8.14.2) with ESMTP id p64LT9YD032552 for ; Mon, 4 Jul 2011 23:29:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scarlet.be; s=scarlet; t=1309814950; bh=lkBGw83f3YiK4POHLShsMTJcUWCDY3+s4Gscxj11z7w=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=ADiUcI1vc4ijr2WFrkviFA4fyrSnQn3+wa5IOk1LK/yOPRFoyOM/AT6qUZzw7Lvrv lsgutyjV4svvnFEroLYfUsOFfzrLWyO3pDDWdP0BnbOlJEgzUSoszHABesAh3hMEmW 3wTkOiSKKKDmEowpcq4vzNkL+5QfWCuYQCIZLCQk= X-Scarlet: d=1309814949 c=213.49.232.19 Received: from localhost (mail.harfang.homelinux.org [192.168.20.11]) by mail.harfang.homelinux.org (Postfix) with ESMTP id A1B8E617EE for ; Mon, 4 Jul 2011 23:52:56 +0200 (CEST) Received: from mail.harfang.homelinux.org ([192.168.20.11]) by localhost (mail.harfang.homelinux.org [192.168.20.11]) (amavisd-new, port 10024) with ESMTP id uPEEgaovcklV for ; Mon, 4 Jul 2011 23:52:53 +0200 (CEST) Received: from dusk.harfang.homelinux.org (mail.harfang.homelinux.org [192.168.20.11]) by mail.harfang.homelinux.org (Postfix) with ESMTP id B4AC9617D1 for ; Mon, 4 Jul 2011 23:52:53 +0200 (CEST) Received: from eran by dusk.harfang.homelinux.org with local (Exim 4.72) (envelope-from ) id 1Qdr4X-0007B6-Aj for dev@commons.apache.org; Mon, 04 Jul 2011 23:52:53 +0200 Date: Mon, 4 Jul 2011 23:52:52 +0200 From: Gilles Sadowski To: dev@commons.apache.org Subject: Re: [math] puzzled by generics in root solvers Message-ID: <20110704215252.GK10648@dusk.harfang.homelinux.org> Mail-Followup-To: dev@commons.apache.org References: <4E121F9D.2020006@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E121F9D.2020006@free.fr> X-Operating-System: Tiny Tux X-PGP-Key-Fingerprint: 53B9 972E C2E6 B93C BEAD 7092 09E6 AF46 51D0 5641 User-Agent: Mutt/1.5.20 (2009-06-14) X-DCC-scarlet.be-Metrics: sif 20001; Body=1 Fuz1=1 Fuz2=1 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 > | > +-----------------+---------------------+ > | | > | | > UnivariateRealSolver, BaseAbstractUnivariateRealSolver > PolynomialSolver, | > DifferentiableUnivariateRealSolver | > | | > | | > +-----------------------+---------------+ > | > | > +--------------------+-----+----------------+ > | | | > AbstractUnivariate... AbstractPolynomial... AbstractDifferentiable... > | | | > +-----+----------+ | | > | | | | > BrentSolver, BaseSecantSolver LaguerreSolver NewtonSolver > | > | > | > BaseBracketedSecantSolver > | > | > | > +--------------+---------------+ > | | | > | | | > | | | > Illinois Pegasus RegulaFalsi > > [...] > > The first point is we use "UnivariateReal" both as the name of the > topmost level type when nothing is specified (just as in the name of > the level 0 interface and level 1b abstract class), and as the name > of generic functions, in parallel with polynomial and differentiable > functions. Shouldn't we have a different name for both notions ? We > could have for example UnivariateRealFunction at top level and > GeneralRealFunction at low level. This would help separate the > meanings from level 1b and level 2. "UnivariateReal" is equivalent to your proposed "GeneralReal" "Polynomial" and "Differentiable" are sub-types. > The second point is I don't understand the purpose of interfaces > from level 1a. They are not really necessary. At first, I left them to avoid breaking compatibility. But the main usefulness is that API users can manipulate those "interface" types instead of "BaseAbstractUnivariateRealSolver" or "AbstractDifferentiableUnivariateRealSolver" which are more cumbersome to write. Also there is an asymmetry in the above two classes, due to the fact that they are not at the same level of the hierarchy. The generic base class is not supposed to be used by API users but only by CM developers (as in "AbstractDifferentiableUnivariateRealSolver"). > If on the one hand someone implements a solver by taking advantage > of the generified BaseAbstractUnivariateRealSolver we provide, these > interface merely force to add a redundant implement clause with > declarations like the ones found at level 2: > > AbstractXxxsolver extends BaseAbstractXxxSolver > implements XxxSolver > > instead of using only > > AbstractXxxsolver extends BaseAbstractXxxSolver That's true: as indicated above, this "intricate" code is CM developer's problem. Applications that use CM should never contain any "AbstractXxx..." types; they should use the interfaces. > If on the other hand someone implements a solver without taking > advantage of the generified BaseAbstractXxxSolver we provide, these > interface simply allow to write: > > AbstractXxxsolver implements XxxSolver > > instead of using only > > AbstractXxxsolver implements BaseUnivariateRealSolver This is outside CM's realm. [I don't see why someone would inherit from a CM interface but not use the boiler-plate code in "BaseUnivariateRealSolver".] 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. > I think removing the interfaces from level 1b would simplify the > architecture and help users understand. We would avoid the > losange-shape inheritance between levels 0, 1a/1b and 2. We should probably make it clear that users should not use the generic base class nor the abstract classes, but only the interfaces; maybe adding in the Javadoc a statement like: /** * [...] * * This class is not intended for use outside of the Commons Math library. * @see UnivariateRealSolver * @see PolynomialSolver * @see DifferentiableUnivariateRealSolver */ > The third point is I think I messed thing when I inserted > BracketedUnivariateRealSolver interface back in the hierarchy a few > days ago by extending UnivariateRealSolver. I should probably have > generified it and have it extend BaseUnivariateRealSolver extends UnivariateRealSolver>, thus allowing to have bracketing > solvers also for polynomials and differentiable functions. Do you > agree with this ? Yes. > The fourth point is the generified BaseAbstractUnivariateRealSolver > we provide (level 1b, right of the losange). It forces to implement > a doSolve but in this method we cannot access the function itself > and we cannot reset the evaluations: the fields are private and have > no accessors, even protected, we can only call the function and > incrementing the evaluation at the same time, counting from a > setting the derived class cannot change. It was done on purpose (so as to forbid evaluations that would not increment the counter). > I need access to the > function and I need access to the counter. So i think I will add > some accessors for them. Does this seems reasonable to other > developers ? In refactoring the "solvers" package, I removed a lot of "protected" fields. The current design shows that they were not necessary. Also they are not desirable because they break encapsulation. I'd rather find a way to avoid accessors, and figure out why the new interface does not fit in the design; if we can change it to fit or if we can improve the design so that it fits... > Well, sorry for this long message and the ugly picture. You have a > few hours to read it, as I will not be able to discuss in the few > next hours. > > thanks for your attention ;-) Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org