On Tue, Jun 24, 2014 at 1:46 AM, Gilles <gil...@harfang.homelinux.org> wrote: > Hi. > > > On Tue, 24 Jun 2014 00:06:16 +0530, venkatesha murthy wrote: >> >> I am adding a canEqual method in MathUtils since neither Math.equals nor >> >> Precision.equalsIncludingNaN performs better under heavy load (I have >> attached the test code for the same in the patch). >> >> The reason as far as i can think is : >> In case of equals it keeps churning new objects and makes Double.equals >> and in case of Precision.equalsIncludingNaN it might be that >> it has not covered the case of quick elimination of detecting one of >> them as nan as in that case it can return false. >> >> >> The change i am bringing in is simple in that in any case of either of >> them nan or both then return true or false and if and only if both are >> *not nan* then get to Precision.equals >> >> Does any on have a concern adding this method or if the change needs >> to be done else where such as in Precision.equalsIncludingNaN > > > What is the semantics of this new method? > Is it different from all of the following: > * MathUtils.equals > * Precision.equals > * Precision.equalsIncludingNaN > ? No. its the same as all the three methods with just 2 double attributes and a boolean return > > Or is the issue about performance? > If so the problem must be identified and the corresponding method improved. > In that case i am planning to improve Precision.equalsIncludingNaN method(s). I will send the patch for the same (after removing canEqual) along with modified patch on methods that are using canEqual. Hope this is fine. > > Best regards, > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
