Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Fri, 10 Sep 2010 22:55:33 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: svn commit: r995035 -
 /commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/univariate/BrentOptimizer.java
Message-ID: <20100910205533.GA10200@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <20100908125138.E4C0A23889DA@eris.apache.org>
 <4C87A27D.9070102@free.fr>
 <20100908153752.GN18739@dusk.harfang.homelinux.org>
 <4C87B1D9.3010705@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C87B1D9.3010705@free.fr>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-DCC-scarlet.be-Metrics: eir 20001; Body=1 Fuz1=1 Fuz2=1

> > I don't know whether it is one of those rare cases. The algorithm
> > description in ALGOL uses the "=" sign while the FORTRAN implementation (in
> > the appendix) works around the problem by inversing the checks:
> 
> It may be the case. There is a similar one in the Brent solver, the
> semantic of the test is to check if we have just set one intermediate
> value exactly to one of the bound or if it is a result of some
> interpolation.
> 
> Exact equality or inequality should be considered with the same care. In
> many cases, they should be replaced by proximity checks. Proximity
> checks need a threshold and it is very difficult to find a general one
> (some people may well use numbers in the range of 1.0e-50 which is
> perfectly computable in floating point).
> 
> There is also one very special trick with doubles equality and
> inequality: tests involving NaN always return false. So if for example x
> is a NaN and y is a regular number (normal, subnormal or infinite), all
> the following tests will return false, even the two last ones!
> 
>  x < y, x > y, x <= y, x >= y, x == y, x != y, x == x
> 
> This implies that replacing (x == y) by !(x != y) is a safe replacement
> only if there are no NaNs involved.
> 
> However, I don't think the test here has been written with NaNs in mind,
> so I guess it really is a check for interpolation or no interpolation. I
> did not check the algorithm, though.

I don't think so either.
With the current change, the meaning is as close to "==" as possible since
only two adjacent floating point numbers are considered equal by method
"equals" from "MathUtils". So if checkstyle is happy with that, we could
leave so without much risk, I think.

Gilles

> >>> -                    } else if (fu <= fv || v == x || v == w) {
> >>> +                    } else if (fu <= fv ||
> >>> +                               MathUtils.equals(v, x) ||
> >>> +                               MathUtils.equals(v, w)) {
> >>>                          v = u;
> >>>                          fv = fu;

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org