Reviewed-by: emcmanus
Éamonn
On 16 February 2012 08:23, Xueming Shen 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 OpenJDK commit
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:
http://cr.openjdk.
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:
http://cr.openjdk.java.net/~rriggs/6708398.2
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 "xxxExac
> 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 describ
>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
On 02/13/2012 06:41 PM, Jeff Hain wrote:
Hello.
- It could be great to have versions of these methods that don't throw an
ArithmeticException in case of overflow, but would return the closest value
(XXX.MAX_VALUE or XXX.MIN_VALUE).
A common use-case I see (and have) for this is when dealing
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
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
Hello.
- It could be great to have versions of these methods that don't throw an
ArithmeticException in case of overflow, but would return the closest value
(XXX.MAX_VALUE or XXX.MIN_VALUE).
A common use-case I see (and have) for this is when dealing with dates and
durations (*), in which cas
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 deve
On 11 February 2012 17:31, Roger Riggs 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.
> - Editorial correction to fi
12 matches
Mail list logo
