On 02/14/2012 05:20 PM, Jeff Hain wrote:
Indeed exact can be understood as mathematically exact, and it's
concise. The main problem I see with exact is if wanting to add some
non-throwing version afterwards: it should have a close but different
name, and I don't see how if using xxxExact. But
I can do the commit.
On 2/16/2012 8:09 AM, Roger Riggs wrote:
I don't anticipate making any more changes though a few of the
comments deserve followup as a separate CR.
Is there an OpenJDK committer who would commit?
Thanks, Roger
Updated the webrev for CR6708398:
Reviewed-by: emcmanus
Éamonn
On 16 February 2012 08:23, Xueming Shen xueming.s...@oracle.com wrote:
I can do the commit.
On 2/16/2012 8:09 AM, Roger Riggs wrote:
I don't anticipate making any more changes though a few of the
comments deserve followup as a separate CR.
Is there an
For toInt method(s), and other methods that don't involve mathematical
operations but just transtyping, I think the naming conventions I was talking
about
(xxxInRange/xxxToRange for add/substract/multiply/negate/increment/etc.)
don't need to apply.
One could just use asInt for the throwing
FieldUtils.safeMultiply(long,long) doesn't handle (Long.MIN_VALUE,-1)]
Thanks, Roger
Jeff
De : Roger Riggsroger.ri...@oracle.com
À : core-Libs-Devcore-libs-dev@openjdk.java.net
Envoyé le : Samedi 11 février 2012 18h31
Objet : Review: JDK 8 CR for Support Integer
Saturating arithmetic can be useful but there have been few requests.
Some needs can be unformulated until someone fulfils them :)
But indeed not being hit by integer/modulo arithmetic while still being exact
is surely a more common need than jumping to the closest value.
I must be biased due
In your subsequent email, I found that the asXXX and toXXX variants to be too
similar to
make it clear which throws and which does not or other differences unless it
were a pervasive
pattern that all developers would know and use.
We encourage this convention:
- Use asXxx to describe
On 11 February 2012 17:31, Roger Riggs roger.ri...@oracle.com wrote:
Updated the webrev for CR6708398:
http://cr.openjdk.java.net/~rriggs/6708398.2
- Added a paragraph to the class javadoc for Math and StrictMath to
introduce the exact arithmetic methods and their uses.
-
Thanks for the raising the question on the blog and the comments.
I see support based only on general principles and not from use cases
where the function would be essential. At this point, we're not trying to
provide a complete set of exact arithmetic functions but to cover the cases
where
(long,long) doesn't handle (Long.MIN_VALUE,-1)]
Jeff
De : Roger Riggs roger.ri...@oracle.com
À : core-Libs-Dev core-libs-dev@openjdk.java.net
Envoyé le : Samedi 11 février 2012 18h31
Objet : Review: JDK 8 CR for Support Integer overflow updated
Updated
Am 14.02.2012 00:41, schrieb Jeff Hain:
(I don't really like the term exact, which supposes modulo arithmetic is
not exact in its kind, and it doesn't contain the supposition that the result should be
in range.)
+1
-Ulf
Thanks for the review and comments:
The comments and suggestions are included in the updated webrev:
http://cr.openjdk.java.net/~rriggs/6708398.1
* Corrected error in multipleExact(long,long) with the special case
Long.MIN_VALUE * -1.
* Verified that retaining the optimization for small
Looks good to me (emcmanus). One really trivial thing is that
Math.java:830 is indented one space too far. I thought that the common
(int)value subexpression could be put in a variable in toIntExact but
it turns out that javac generates more code in that case.
Éamonn
On 6 February 2012 13:16,
On 6 February 2012 21:16, Roger Riggs roger.ri...@oracle.com wrote:
* Removed the negateExact methods since they don't pull their weight
in the API,
simple tests for MIN_VALUE and MAX_VALUE can be done by the
developer more efficiently.
Sorry, but I can't agree with this. Developers
I'm with Roger on this.
Sorry, but I can't agree with this. Developers get negation of numbers
wrong all the time by ignoring the special case. Its a big source of
hidden bugs. Increment/decrement are replaceable by add/subtract (with
less readability), but negate is not.
First of all,
15 matches
Mail list logo
