Yeah my comment was more general - I didn't look at the entire context,
just wasn't sure why you thought that comparison would be faster (nevermind
that it's wrong as you mention :)).
Sent from my phone
On Feb 3, 2012 1:58 PM, "Eamonn McManus" <eam...@mcmanus.net> wrote:
> On 3 February 2012 10:22, Vitaly Davidovich <vita...@gmail.com> wrote:
> > x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp
> against a constant whereas the latter requires negating x (that's a
> dependency too), tying up a register to store the negation, and then doing
> the cmp.
>
> The value -x is needed anyway since it's the return value. But a more
> important reason why my idea is a bad one is that the condition is
> true for x == 0! Writing x == -x && x != 0 is definitely not an
> improvement.
>
> Éamonn
>
>
> On 3 February 2012 10:22, Vitaly Davidovich <vita...@gmail.com> wrote:
> >
> > x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp
> against a constant whereas the latter requires negating x (that's a
> dependency too), tying up a register to store the negation, and then doing
> the cmp.
> >
> > Sent from my phone
> >
> > On Feb 3, 2012 12:53 PM, "Eamonn McManus" <eam...@mcmanus.net> wrote:
> >>
> >> My initial remarks:
> >>
> >> In negateExact, the condition x == -x should be faster to evaluate than
> x
> >> == Integer.MIN_VALUE and reflects the intent just as well.
> >>
> >> In addExact and subtractExact, I would be inclined to implement the int
> >> versions using long arithmetic, like this:
> >>
> >> long lr = x + y;
> >> int r = (int) lr;
> >> if (r == lr) {
> >> return r;
> >> } else {
> >> throw...
> >> }
> >>
> >> I would use this technique of cast-and-compare in the int multiplyExact
> >> instead of comparing against MIN_VALUE and MAX_VALUE, and especially in
> >> toIntExact(long).
> >>
> >> I agree with Stephen Colebourne that brief implementation comments
> would be
> >> useful. But I disagree with his proposed further methods in Math
> >> (increment, decrement, int+long variants), which I don't think would
> pull
> >> their weight.
> >>
> >> Éamonn
> >>
> >>
> >> On 2 February 2012 12:15, Roger Riggs <roger.ri...@oracle.com> wrote:
> >>
> >> > There is a need for arithmetic operations that throw exceptions
> >> > when the results overflow the representation of int or long.
> >> >
> >> > The CR is 6708398: Support integer overflow <http://bugs.sun.com/**
> >> > bugdatabase/view_bug.do?bug_**id=6708398<
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6708398>
> >> > >
> >> >
> >> > Please review this webrev <http://cr.openjdk.java.net/%**
> >> > 7Erriggs/CR6708398/webrev/<
> http://cr.openjdk.java.net/%7Erriggs/CR6708398/webrev/>>
> >>
> >> > to add static methods in java.lang.Math
> >> > to support addExact(), subtractExact(), negateExact(),
> multiplyExact(),
> >> > and toIntExact() for int and long primitive types.
> >> >
> >> > Thanks, Roger Riggs
> >> >
>
