Le dim. 5 avr. 2020 à 00:36, Alex Herbert <alex.d.herb...@gmail.com> a écrit :
>
>
>
> > On 4 Apr 2020, at 22:35, Gilles Sadowski <gillese...@gmail.com> wrote:
> >
> > Hello.
> >
> > Le sam. 4 avr. 2020 à 23:16, <aherb...@apache.org
> > <mailto:aherb...@apache.org>> a écrit :
> >>
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> aherbert pushed a commit to branch master
> >> in repository https://gitbox.apache.org/repos/asf/commons-numbers.git
> >>
> >> commit 08edae944e4abe7ec4b95a72d3791a9f39fb53c8
> >> Author: Alex Herbert <aherb...@apache.org>
> >> AuthorDate: Sat Apr 4 21:23:08 2020 +0100
> >>
> >> Remove a branch from equals tests with NaN.
> >>
> >> A bitwise OR of the booleans is true if either boolean is true. Since
> >> they are both already computed then the || operator short circuit (if
> >> first is true) cannot avoid having to compute the second boolean.
> >>
> >> This change converts 3 conditional evaluations to 2 conditional
> >> evaluations.
> >
> > Is this measurable? Is the difference significant?
> > I'm not actually asking any benchmarking, but such changes
> > should be balanced with the resulting code reduced (IMO)
> > readability.
>
> I do not know. I ensured the unit tests had full coverage and then looked at
> a few ways to improve the class. This change may be reverted.
No need to bother.
Perhaps it's just a matter of habit or taste.
The method is short, and someone puzzled can check
that it behaves as expected.
> It may be something that is done by a good compiler anyway.
>
> There is another change that will eliminate the unreachable code branch. But
> I did not make that change as it was less readable IMO:
>
> Original:
>
> return isEqual && !Double.isNaN(x) && !Double.isNaN(y);
>
> Verses:
>
> return isEqual && !Double.isNaN(x + y);
>
> As is this perhaps:
>
> if (((xInt ^ yInt) & SGN_MASK) == 0L) {
>
> Verses:
>
> if (((xInt ^ yInt) >= 0L) {
>
> Given that none of this is in anyway expected to be in performance critical
> code I can put it back to the previous version if you prefer.
Perhaps just add the equivalent alternative code that's
could be more readily understandable?
Best,
Gilles
> >> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
