Looks fine Roger; thanks,
-Joe
On 10/13/2012 9:21 AM, Roger Riggs wrote:
Thanks for the comments and suggestions from Eamonn, Joe, and Bruce.
The updates add the suggested text and note the special case for
floorDiv(MIN_VALUE/-1).
Updated webrev:
http://cr.openjdk.java.net/~rriggs/62821
Thanks for the comments and suggestions from Eamonn, Joe, and Bruce.
The updates add the suggested text and note the special case for
floorDiv(MIN_VALUE/-1).
Updated webrev:
http://cr.openjdk.java.net/~rriggs/6282196.5/
Roger
On 10/11/2012 08:40 PM, Joseph Darcy wrote:
Hi Roger,
The c
Thanks for pointing out that omission.
I will fix the spec and the tests to note the special case as
described for the division operator in the JLS.
The other result returning MAX_VALUE from floorDiv(Integer.MIN_VALUE, -1)
does not seem any more beneficial.
Thanks, Roger
On 10/10/2012 12:12 PM
And maybe say "round toward" rather than "round to", the first implies a
direction, the second implies a destination.
Bruce
On 12/10/2012 1:40 p.m., Joseph Darcy wrote:
Hi Roger,
The changes look fine. However, I suggest adding an explanatory note
along the lines of "Normal integer division
Hi Roger,
The changes look fine. However, I suggest adding an explanatory note
along the lines of "Normal integer division operates under the round to
zero rounding mode (truncation). This operation instead acts under the
round to negative infinity (floor) rounding mode. The floor rounding
The floorDiv/floorMod functions do not throw exceptions for out of range
values
to be consistent with the builtin language math operations.
The |toIntExact |method is used by developers because it does the
range check and throws an exception.
It is cleaner not to mix the semantics of the two oper
One edge case: the spec for floorDiv implies that
floorDiv(Integer.MIN_VALUE, -1) should be Integer.MAX_VALUE but I
believe the code produces Integer.MIN_VALUE. EIther the spec or the
code should be fixed.
Éamonn
2012/10/10 Roger Riggs :
> A reviewer is needed for:
>
> 6282196 There should be Ma
On 10 October 2012 15:22, Roger Riggs wrote:
> A reviewer is needed for:
>
> 6282196 There should be Math.mod(number, modulo) methods
>
> The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
Just to note that floorMod(long, int) is not present. This is often
useful as the mod side general
A reviewer is needed for:
6282196 There should be Math.mod(number, modulo) methods
The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
Thanks, Roger
On 04/17/2012 07:50 AM, Roger Riggs wrote:
I'm not sure have all the history around the Math vs StrictMath
distinction.
For the more "interesting" mathematical methods where multiple
implementations are reasonable, the StrictMath version provides
cross-platform reproducibility by specifying t
I'm not sure have all the history around the Math vs StrictMath distinction.
There are many cross references between Math and StrictMath for common
functions, for example, ulp, getExponent, copySign, etc.
The distinction is clearer for floating point operations than for
int/log computations.
Ro
Hi Roger,
In a case like this where the Math and StrictMath versiosn of a method
have exactly the same behavior defined, I strongly suggest having the
Math version of the test invoke tests for both Math and StrictMath
siblings of a method. In other words, have a single
test/java/lang/Ma
Hi there,
Sorry if this has been asked before, but I am curious as to why the
newer methods in StrictMath (including addExact etc.) are now
delegating to methods in Math.
Looking at the other static methods, they seem to be going in the
opposite direction, i.e. Math methods calling equivalent met
Hi,
I've corrected a number of issues raised with javadoc in java.lang.Math
and java.lang.StrictMath. The updated webrev is:
http://cr.openjdk.java.net/~rriggs/6282196.2/
Please review.
Thanks, Roger
On 03/05/2012 08:38 AM, Roger Riggs wrote:
CR 6282196 There should be Math.mod(number, mod
Hi,
CR 6282196 There should be Math.mod(number, modulo) methods
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282196
Requests that floor and modulus methods be provided for primitive types.
Floor division is pretty straight-forward, rounding toward minus infinity.
For modulus of int and
15 matches
Mail list logo
