Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 99120 invoked from network); 7 Nov 2003 21:54:10 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 7 Nov 2003 21:54:10 -0000 Received: (qmail 52726 invoked by uid 500); 7 Nov 2003 21:53:55 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 52609 invoked by uid 500); 7 Nov 2003 21:53:54 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 52594 invoked from network); 7 Nov 2003 21:53:54 -0000 Received: from unknown (HELO localhost.localdomain) (216.17.172.192) by daedalus.apache.org with SMTP; 7 Nov 2003 21:53:54 -0000 Received: from mail.mattcliff.com (mail.mattcliff.com [216.17.172.194]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id hA7LsRC01001 for ; Fri, 7 Nov 2003 14:54:27 -0700 Date: Fri, 7 Nov 2003 14:54:27 -0700 (MST) From: Matt Cliff X-X-Sender: cliff@localhost.localdomain To: Jakarta Commons Developers List Subject: Re: [math] interface for UnivariateRealFunction (differentiability) In-Reply-To: <3FAC0467.2060005@latte.harvard.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I suggest that we remove the derivative methods from the interface. My thought is that in general, a user would not need to calculate and program the first and second derivatives. I'd like to put a little more thought into the Differentiable interface, there are two tracks of thought here: (1) dealing with truly differentiable functions (e.g. polynomials) which can easily have the derivative methods exposed, and (2) applying the appropriate numerical diff. logic at the appropriate place. That is maybe something analagous to the UnivariateRealSolver pattern that an numerical routine such as a three-point or five-point forumla for the derivatives. wrt the term "Univariate" I am impartial. I would lean towards leaving it as is for now. Once Multivariate functions are introduced this can be addressed (my preference is to get a 1.0 release out in a single variable). On Fri, 7 Nov 2003, Mark R. Diggory wrote: > Not attached to this, a Differentiable Interface would be acceptable to > me too. > > On another subject, maybe because of my naivety, why are these > interfaces called "UnivariateRealFunction" and not simply something more > generic like RealFunction? I say this strictly because of what I > consider an overuse of the term "Univariate" in many of our Classnames... > > -Mark > > brent@worden.org wrote: > > > The CubicSplineFunction is the only place, that I'm aware of, that > > truly implements these methods. Also, these method are never called > > anywhere in the code, save the unit tests. This includes calls > > through either the interface or the concrete classes. > > > > As I see it we have three choices: > > 1) let it as is > > 2) add a differentiable interface per Mike's suggestion. > > 3) remove the derivative methods from the interface and keep them only > > on CubicSplineFunction. > > > > In order of preference, I choose 2, 1, 3. > > > > On Fri, 07 Nov 2003 15:02:46 -0500, "Mark R. Diggory" wrote: > > > > > >> > >> > >>brent@worden.org wrote: > >> > >> > >>>>What is the purpose for having the firstDerivative() and > >>>>secondDerivative() methods on a UnivariateRealFunction ? > >>> > >>> > >>>One of the interpolating routines use the first and second > >> > >>derivatives. > >> > >>> > >>>>It is a little troubling to me to have at this level (perhaps if > >>>>needed a subclass such as UnivariateDifferentiableRealFunction ). > >>> > >>> > >>>This might be a good idea. When I used the solvers to evaluate the > >>>inverse cumulative distribution functions, I found the > >>>UnivariateRealFunction interface a bit cumbersome for my needs. > >>> > >> > >>Some methods do not neccessarily need to be exposed via an interface > >>if > >>they are used internally. While some UnivariateRealFunction > >>implementations may require this capability, is it required to be in > >>the > >>interface? > >> > >>-Mark > >> > >>-- > >>Mark Diggory > >>Software Developer > >>Harvard MIT Data Center > >>http://osprey.hmdc.harvard.edu > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org > > > > > > Brent Worden > > http://www.brent.worden.org/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org > > > > -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org